{"thread":{"id":"29787","subject":"Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","startedAt":"2012-02-29T17:19:45Z","lastAt":"2012-03-07T17:18:36Z","messageCount":37,"participants":["opticyclic","Brian Gernhardt","Junio C Hamano","Carlos Martín Nieto","Sitaram Chamarty","Jonathan Nieder","Andrew Ardill","Greg Troxel","Miles Bader","Thomas Rast","Ævar Arnfjörð Bjarmason","Scott Chacon","Neal Kreitzinger","Andreas Ericsson","Vincent van Ravesteijn","Joern Huxhorn","Pau Garcia i Quiles","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"185724","messageId":"CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com","threadId":"29787","inReplyTo":null,"subject":"Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"opticyclic","fromEmail":"opticyclic@gmail.com","sentAt":"2012-02-29T17:19:45Z","receivedAt":"2012-02-29T17:19:45Z","isPatch":false,"sender":{"key":"opticyclic@gmail.com","avatar":null},"body":"Firstly, why is there no Bug Tracker such as JIRA for the git project?\nThis mailing list is next to useless for users since searching is\ndifficult, as is commenting and voting.\n\nSecondly, since one of the alleged reasons for creating git was to not\nhave to deal with patches, why are pull requests disable and patches\nsent to this mailing list?!\nI have read https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches\nand it doesn't explain it.\n\nI'm sure I don't have to tell you that GitHub has discussions on pull\nrequests, which are easier to view than the mailing list archives.\n\nSo why is it done in the current way?\n"},{"id":"185729","messageId":"B5097A6C-16DB-4CFA-B93D-F6E1C6714057@silverinsanity.com","threadId":"29787","inReplyTo":"CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2012-02-29T18:23:00Z","receivedAt":"2012-02-29T18:23:00Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 29, 2012, at 12:19 PM, opticyclic wrote:\n\n> Secondly, since one of the alleged reasons for creating git was to not\n> have to deal with patches, why are pull requests disable and patches\n> sent to this mailing \n\n\nOn the contrary, the design of git was created with the idea of handling patches via e-mail in mind. Tools like git-format-patch, git-am, and git-send-email exist to allow this workflow. Linus wanted a tool that would automate and enhance the way the kernel ML already did work instead of demanding that they change.\n\n~~ Brian G\n"},{"id":"185731","messageId":"7vhay9tqs6.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-29T18:53:29Z","receivedAt":"2012-02-29T18:53:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"opticyclic writes:\n\n> Firstly, why is there no Bug Tracker such as JIRA for the git project?\n\nProbably because nobody volunteered to set-up, actively de-dupe, triage\nand maintain it in general.\n\n> Secondly, since one of the alleged reasons for creating git was to not\n> have to deal with patches, why are pull requests disable and patches\n> sent to this mailing list?!\n\nI think Brian already corrected whoever \"alleges\" such.\n\nWe prefer to develop in the open, reviewing and improving both patches and\nideas on the mailing list, without having to rely on a single project\nhosting site everybody has to go and deal with web based interface.\n"},{"id":"185735","messageId":"1330543085.22763.50.camel@beez.lab.cmartin.tk","threadId":"29787","inReplyTo":"CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-02-29T19:18:05Z","receivedAt":"2012-02-29T19:18:05Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2012-02-29 at 12:19 -0500, opticyclic wrote:\n> Firstly, why is there no Bug Tracker such as JIRA for the git project?\n\nBug trackers aren't magical. Just because a bug is in some sort of\ndatabase, it doesn't mean that it's going to get fixed faster. People\nwork on what they find interesting or their sponsors find important. Bug\ndatabases are also notorious for getting filled with duplicate entries\nand languishing bugs that are waiting for the original reporter to\nanswer with some information that the developers asked. Everyone would\nalso need to get an account on that bug tracker, making it harder to\nreport and contribute.\n\n\nThere used to be a wiki for buglets so people could get started, but I'm\nnot sure if it survived the k.org compromise.\n\n> This mailing list is next to useless for users since searching is\n> difficult, as is commenting and voting.\n\nAll you need to comment is an e-mail program, which most people have.\ngmane also allows you to post from the web interface. What voting are\nyou referring to? There is no form of formal voting that isn't\nrestricted to the people responsible (or knowledgeable about) a\nparticular part of the project. And that's not even really voting, but a\nreview on the soundness of the patch.\n\n> \n> Secondly, since one of the alleged reasons for creating git was to not\n> have to deal with patches, why are pull requests disable and patches\n> sent to this mailing list?!\n\nWho said git was made to stop dealing with patches? Some of the git\nterminology is influenced by that (compare 'git revert' with the idea of\na revert that other systems have). Do you follow the linux mailing list?\nIt's full of patches waiting to be reviewed.\n\ngit does use pull requests. That's how gitk and git-svn are updated, in\nthe git repository. I believe the git-subtree inclusion request also\ntook form of a pull request.\n\n> I have read https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches\n> and it doesn't explain it.\n> \n> I'm sure I don't have to tell you that GitHub has discussions on pull\n> requests, which are easier to view than the mailing list archives.\n\nEasier to view? Do you mean it's easier on the eyes? Easier to get an\noverview? What do you want to view in these discussions? Why do you want\neveryone to need a GitHub account to participate in git?\n\nThe GitHub web-UI has no threading, which means that you either discuss\nall the patches together in one line so it's no longer clear who's\nanswering what, or you comment on the commit itself, which means that\nthe whole discussion is at least as segmented as what you get via\ne-mail, and you have to scroll more to get to the discussion of a\nparticular commit.\n\nTL;DR this is the way we've found to be the most effective.\n\n cmn\n"},{"id":"185747","messageId":"CAMK1S_j0gx_OYzvaKim-JrBxAPhJnHSLvLH8_yU5kLkqo9bfJg@mail.gmail.com","threadId":"29787","inReplyTo":"CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-02-29T21:37:41Z","receivedAt":"2012-02-29T21:37:41Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Wed, Feb 29, 2012 at 10:49 PM, opticyclic wrote:\n\n> I'm sure I don't have to tell you that GitHub has discussions on pull\n> requests, which are easier to view than the mailing list archives.\n\nFor some definition of \"easier\". Personally, I loathe the interface.\n\nYou don't seem to realise that using that will force everyone to use\nthat same interface, rather than their choice of email clients.\n\nI run a project that is mainly hosted on github, but I absolutely\npositively refuse to use their web interface for anything. Logging in\nto check, instead of just reacting to email as usual, is a pain but\nthat is not all.\n\nThe issues system does have an email interface, but it is not a\nsubstitute for email. I can't cc anyone else when I want to, for\ninstance (well I can, but any response the original requester then\nmakes using the website will not get cc-d to the person I cc-d, which\nkinda defeats the whole purpose).\n\nThe pull system forces a --no-ff even if the merge is at the top of my\nbranch and doesn't need one. It also gives me no chance to fix up\nminor typos, add any more text to the commit message, etc. (I can do\nthat afterward, but this forces a \"push -f\" or a trivial \"typofix\"\ncommit).\n\nI want everything in *one* interface, and I want it just the way *I*\nwant it, and it shouldn't (necessarily) dictate how *you* should work.\n Email is just that.\n\nsitaram\n"},{"id":"185751","messageId":"20120229225304.GA9099@burratino","threadId":"29787","inReplyTo":"7vhay9tqs6.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-29T22:53:04Z","receivedAt":"2012-02-29T22:53:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> opticyclic writes:\n\n>> Firstly, why is there no Bug Tracker such as JIRA for the git project?\n>\n> Probably because nobody volunteered to set-up, actively de-dupe, triage\n> and maintain it in general.\n\nBy the way, my usual offer/shameless plug[*] still stands: anyone who\ncan stand the interface is welcome to file, triage, and work on bugs\nin the bugtracker at , as long as it\nseems possible that your bugs might also affect Debian.\n\n\"Work on\" usually means \"forward to the git mailing list\", but maybe\nhaving a bug number is a comfort to some people. ;-) See\n for instructions.\n\nAll that said, that is still not The Bug Tracker for the git project.\nI would not want it advertised on git-scm.com until we have had some\nmore practice dealing with outside bugs, and maybe more contributors\nsorting through them.\n\nIt may be that others provide a similar service.\n\nHope that clarifies a little,\nJonathan\n\n[*] http://thread.gmane.org/gmane.comp.version-control.git/181336/focus=181402\n"},{"id":"185753","messageId":"CAH5451miv_Mo_9tZV+mfDEHuEX0491duqAYh66aOzLsMLTNkaA@mail.gmail.com","threadId":"29787","inReplyTo":"20120229225304.GA9099@burratino","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-02-29T23:58:56Z","receivedAt":"2012-02-29T23:58:56Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 09:53, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n>> opticyclic writes:\n>\n>>> Firstly, why is there no Bug Tracker such as JIRA for the git project?\n>>\n>> Probably because nobody volunteered to set-up, actively de-dupe, triage\n>> and maintain it in general.\n>\n> By the way, my usual offer/shameless plug[*] still stands: anyone who\n> can stand the interface is welcome to file, triage, and work on bugs\n> in the bugtracker at , as long as it\n> seems possible that your bugs might also affect Debian.\n>\n> \"Work on\" usually means \"forward to the git mailing list\", but maybe\n> having a bug number is a comfort to some people. ;-) See\n> for instructions.\n>\n> All that said, that is still not The Bug Tracker for the git project.\n> I would not want it advertised on git-scm.com until we have had some\n> more practice dealing with outside bugs, and maybe more contributors\n> sorting through them.\n>\n> It may be that others provide a similar service.\n>\n> Hope that clarifies a little,\n> Jonathan\n>\n> [*] http://thread.gmane.org/gmane.comp.version-control.git/181336/focus=181402\n\nI mentioned I was going to do this a while ago, but decided to bite\nthe bullet and actually do it.\n\nI have set up a JIRA instance using Atlassian's OnDemand service,\navailable at https://git-scm.atlassian.net/\n\nThe set-up is a work in progress, so don't be surprised if you log in\nand it is not brimming with content!\n\nFor now I have locked it down so that anyone can sign up and log in,\nbut only approved users can create issues. I imagine this restriction\nwill be loosened down the track, but for now if you would like to\ncontribute please email me directly with your username and I will add\nyou as a 'Trusted User' (you will need to sign up first). For now,\nnormal users and trusted users are identical except that trusted can\ncreate new issues.\nIf you want to update issues you will need to be a 'Developer' - if\nyou think you fall into this category please tell me and I will add\nyou to it as well (this is the role I think most people active on this\nlist will need to be)! This will allow you to edit issues, be assigned\nissues and resolve them.\n\nIf anyone has experience administrating JIRA and want to help out\n_please_ let me know as I know how quickly these things can grow and\nbecome unmanageable. Additionally, if anyone has any ideas, or thinks\nwe should throw the gates open now (as opposed to locking it down for\na time) comment here and we can make it happen.\n\nAs I see it (and Junio has mentioned before) we are going to need\npeople who are able to manage the issues in this system, ensuring that\nstale issues are closed out and progress matches what is happening on\nthe list. There is no intention to replace the list as a place where\nissues are reported and discussed, however that may happen to some\ndegree anyhow. We should consider how a dedicated bug tracker like\nthis might impact the community and design for that.\nFor my mind, if JIRA was to become a 'mirror' of what goes on here in\nthe list that is ok - perhaps a duplication of efforts, but ok. If\nnothing else, we will have a structured store of information keeping\ntrack of issues that is very easy to access and work with.\n\nI don't think I have enough context on all that is going on on the\nlist to be able to keep everything up-to-date myself, so if you think\nyou can assist in this capacity, again please contact me.\n\nIn case you were interested, some information on me:\nI am a keen git user of who-knows-how-many years, and have been\nfollowing the list for the last 12 months or so. My day job is as a\nJIRA Consultant (and everything else!) with the premier Atlassian\nservices partner [1].\n\nRegards,\n\nAndrew Ardill\n\n[1] customware.net - we also work with Zendesk, and offer custom\nplugins, customisations, theming, training and support packages as\nwell\n"},{"id":"185756","messageId":"rmifwdti2ap.fsf@fnord.ir.bbn.com","threadId":"29787","inReplyTo":"CAH5451miv_Mo_9tZV+mfDEHuEX0491duqAYh66aOzLsMLTNkaA@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2012-03-01T00:37:50Z","receivedAt":"2012-03-01T00:37:50Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\n I have set up a JIRA instance using Atlassian's OnDemand service,\n available at https://git-scm.atlassian.net/\n\nDo people really think it's reasonable to use non-Free tools to develop\ngit? That seems surprising to me.\n\n"},{"id":"185757","messageId":"CAH5451kWaRGutP1esuvjSK-arrEc=5m-SDwVHACx6QF9JFj-MQ@mail.gmail.com","threadId":"29787","inReplyTo":"rmifwdti2ap.fsf@fnord.ir.bbn.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T00:45:52Z","receivedAt":"2012-03-01T00:45:52Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 11:37, Greg Troxel wrote:\n>\n>  I have set up a JIRA instance using Atlassian's OnDemand service,\n>  available at https://git-scm.atlassian.net/\n>\n> Do people really think it's reasonable to use non-Free tools to develop\n> git?  That seems surprising to me.\n>\n\nMaybe not, and if that is the case I am more than happy to let this die.\n\nThat said, this is the tool I know how to use best, and is in my\nopinion the most flexible, reliable and supported. The source code is\navailable on request to customers to extend or modify (or at least it\nused to be) and the company is very supportive of open source projects\nin general.\n\nAdditionally, if we are not prepared to use non-Free tools, we should\nprobably stop using github. (This example is a little trite, seeing as\nthere are non-github alternatives available for grabbing the source\ncode. Then again, the mailing list is not disappearing any time soon,\nso there is a free alternative to _any_ bug tracker that is used)\n\nRegards,\n\nAndrew Ardill\n"},{"id":"185758","messageId":"7vehtdqh46.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"CAH5451kWaRGutP1esuvjSK-arrEc=5m-SDwVHACx6QF9JFj-MQ@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-01T00:50:33Z","receivedAt":"2012-03-01T00:50:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill writes:\n\n> Additionally, if we are not prepared to use non-Free tools, we should\n> probably stop using github. (This example is a little trite, seeing as\n> there are non-github alternatives available for grabbing the source\n> code.\n\nJust on this part.\n\nGithub is not the only place to grab the source code. Far from it.\n"},{"id":"185759","messageId":"7vaa41qgf4.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"CAH5451kWaRGutP1esuvjSK-arrEc=5m-SDwVHACx6QF9JFj-MQ@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-01T01:05:35Z","receivedAt":"2012-03-01T01:05:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill writes:\n\n> On 1 March 2012 11:37, Greg Troxel wrote:\n>>\n>> Do people really think it's reasonable to use non-Free tools to develop\n>> git? That seems surprising to me.\n>\n> Maybe not, and if that is the case I am more than happy to let this die.\n\nI won't speculate how big or small part of the Git community you would be\nrepelling by using a closed/commertial offering. It may not be such a big\ndeal, or it may be. I simply do not know.\n\nBut we will never find out until we try. The same thing can be said for\nthe usefulness of having a bug tracker and feasibility of keeping it\nreasonably clean and useful over time with volunteer effort. I commend\nyou for finally stepping up and biting the bullet to start an experiment.\n\nOne request I may have is to give read/browse-only access to unregistered\nusers without any account (I hate having to maintain credentials to random\nwebsites, and I imagine so do many other people), but I am not the target\naudience, so please do not bend backwards to implement such if it is too\nmuch trouble with the system.\n\nThanks.\n"},{"id":"185760","messageId":"CAH5451mbB8kU_0P=PwpyxT_3+s_UY1TxRF-sBTUZ5kxeZGHe3g@mail.gmail.com","threadId":"29787","inReplyTo":"7vehtdqh46.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T01:05:43Z","receivedAt":"2012-03-01T01:05:43Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 11:50, Junio C Hamano wrote:\n> Andrew Ardill writes:\n>\n>> Additionally, if we are not prepared to use non-Free tools, we should\n>> probably stop using github. (This example is a little trite, seeing as\n>> there are non-github alternatives available for grabbing the source\n>> code.\n>\n> Just on this part.\n>\n> Github is not the only place to grab the source code.  Far from it.\n\nI understand that Github is not the only place to grab the source code\n(maybe it was not clear that I understood that), however the point was\nmore that even though Github is not-Free many people still use it to\ndevelop Free software (including people developing git). As Free\nalternatives to Github are available not many people mind too much (or\nso it seems).\n\nWhy do people use Github at all? Perhaps, because it provides an\naccessible, reliable, powerful and supported platform, with large\namount of penetration in the market and some very desirable features.\n\nI believe that JIRA in the OnDemand package offers similar benefits.\nAdditionally, Free alternatives would still be available (the mailing\nlist). Perhaps there is too much controversy to anoint a JIRA issue\ntracker as 'official', however I continue to hear people ask for a\ntracker, and apart from Jonathan Nieder with the Debian bug tracker\nsee no one else putting their hands up.\n\nIn any case, I spun the instance up because nothing happens until\nsomeone does something, and if it fails then at least we have a record\nof trying it next time someone asks :)\n\nI would love to see it succeed.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"185761","messageId":"CAH5451krbyZCRm8JR+kf+8cDqkbnQKnzXGxmncmRF9YPXvckNA@mail.gmail.com","threadId":"29787","inReplyTo":"7vaa41qgf4.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T01:20:52Z","receivedAt":"2012-03-01T01:20:52Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 12:05, Junio C Hamano wrote:\n> Andrew Ardill writes:\n>\n>> On 1 March 2012 11:37, Greg Troxel wrote:\n>>>\n>>> Do people really think it's reasonable to use non-Free tools to develop\n>>> git? That seems surprising to me.\n>>\n>> Maybe not, and if that is the case I am more than happy to let this die.\n>\n> I won't speculate how big or small part of the Git community you would be\n> repelling by using a closed/commertial offering. It may not be such a big\n> deal, or it may be. I simply do not know.\n\nNeither do I - let's find out!\n\n> But we will never find out until we try. The same thing can be said for\n> the usefulness of having a bug tracker and feasibility of keeping it\n> reasonably clean and useful over time with volunteer effort.  I commend\n> you for finally stepping up and biting the bullet to start an experiment.\n\nI have been meaning to get this going for a few months now, the latest\nthread kickstarted me again.\n\n> One request I may have is to give read/browse-only access to unregistered\n> users without any account (I hate having to maintain credentials to random\n> websites, and I imagine so do many other people), but I am not the target\n> audience, so please do not bend backwards to implement such if it is too\n> much trouble with the system.\n>\n> Thanks.\n\nI have given browse access by default to Anyone (does not require\nlog-in). JIRA is highly customisable, so most requests are typically\nfeasible.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"185784","messageId":"buo399s3nph.fsf@dhlpc061.dev.necel.com","threadId":"29787","inReplyTo":"CAH5451kWaRGutP1esuvjSK-arrEc=5m-SDwVHACx6QF9JFj-MQ@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2012-03-01T05:16:42Z","receivedAt":"2012-03-01T05:16:42Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Andrew Ardill writes:\n> Additionally, if we are not prepared to use non-Free tools, we should\n> probably stop using github.\n\nI think the issue isn't \"using\" non-free tools so much as it's getting\n_locked into_ non-free tools.\n\nSo if JIRA makes all its data trivially exportable in a format which\nis easy to use, and there's some way of isolating references to it so\nthat it's possible to switch to something else without undue hardship,\nmaybe it's not such a big deal.\n\n[Github is a prime example of a non-free tool which is largely avoids\nthe lockin issue, and I imagine that's why so many free projects\nhappily use it. That's generally true of any git repo site, given the\nsuper-easy cloneability of git repos, but Github also provides good\nexport of the meta-data it keeps (issues, etc).]\n\n-Miles\n\n-- \n/\\ /\\\n(^.^)\n(\")\")\n*This is the cute kitty virus, please copy this into your sig so it can spread.\n"},{"id":"185787","messageId":"CAH5451m-Ks+UywfMWfC1TS=5n102VasdgJ0tg-pGym69B2NPQQ@mail.gmail.com","threadId":"29787","inReplyTo":"buo399s3nph.fsf@dhlpc061.dev.necel.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T05:40:02Z","receivedAt":"2012-03-01T05:40:02Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 16:16, Miles Bader wrote:\n> Andrew Ardill writes:\n>> Additionally, if we are not prepared to use non-Free tools, we should\n>> probably stop using github.\n>\n> I think the issue isn't \"using\" non-free tools so much as it's getting\n> _locked into_ non-free tools.\n>\n> So if JIRA makes all its data trivially exportable in a format which\n> is easy to use,\n\nJIRA provides the ability to trivially export any 'filter' as XML or\nCSV data files. A filter is simply a search, and can contain every\nsingle issue in the database. Some pieces of information are slightly\nmore difficult to migrate.\n- Issue attachments such as screenshots are not stored in the\ndatabase, and we would have to request them in order to retrieve them.\n- User information and configuration data is only available in a full\nsite backup (which is available on request).\n- CSV export option does not include comments. (XML, and Word formats do)\n\nAdditionally, there are quite a number of tools to allow migration\nbetween JIRA and other tools, and in my experience Atlassian are quite\nhelpful when you try and move off their products.\n\n> and there's some way of isolating references to it so\n> that it's possible to switch to something else without undue hardship\n\nJIRA has the capacity to automatically link issues to commits which\nmention issue numbers, however this is by no means essential or\nnecessary functionality. JIRA will be happy completely detached from\nthe rest of the world, and will provide additional functionality\ngradually as it becomes more integrated. Some functionality it can\nprovide without forming hard links with the outside world (like\npolling the repository and providing continuous builds)\n\nThe primary thing to look out for would be other sites linking to the\nissue tracker. Unfortunately, there is no way at the moment to provide\nan alternate URI for the tracker, so it is hard to avoid this from\nhappening.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"185804","messageId":"8762eoimp0.fsf@thomas.inf.ethz.ch","threadId":"29787","inReplyTo":"CAH5451miv_Mo_9tZV+mfDEHuEX0491duqAYh66aOzLsMLTNkaA@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-03-01T11:29:31Z","receivedAt":"2012-03-01T11:29:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Andrew Ardill writes:\n\n> I have set up a JIRA instance using Atlassian's OnDemand service,\n> available at https://git-scm.atlassian.net/\n[...]\n> As I see it (and Junio has mentioned before) we are going to need\n> people who are able to manage the issues in this system\n\nNote that you are not the first one to try. The most elaborate plan and\nwriteup that I know of sits at\n\n http://article.gmane.org/gmane.comp.version-control.git/136500 [1]\n\nJan \"jast\" Krüger also mentioned server issues today, so *.jk.gs is\npresumably down because of that, not because gitbugs.jk.gs is no longer\nvalid.\n\nNevertheless, AFAIK it has never been used for \"real work\", so you may\nwant to look into why that happened, and do something different.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"185805","messageId":"CACBZZX4T28m6k7A53Zc32Aquk-jh7_R0KPeq983bSQ3B-r27cA@mail.gmail.com","threadId":"29787","inReplyTo":"8762eoimp0.fsf@thomas.inf.ethz.ch","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-03-01T11:54:21Z","receivedAt":"2012-03-01T11:54:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Mar 1, 2012 at 12:29, Thomas Rast wrote:\n> Andrew Ardill writes:\n>\n>> I have set up a JIRA instance using Atlassian's OnDemand service,\n>> available at https://git-scm.atlassian.net/\n> [...]\n>> As I see it (and Junio has mentioned before) we are going to need\n>> people who are able to manage the issues in this system\n>\n> Note that you are not the first one to try.  The most elaborate plan and\n> writeup that I know of sits at\n>\n>  http://article.gmane.org/gmane.comp.version-control.git/136500  [1]\n>\n> Jan \"jast\" Krüger also mentioned server issues today, so *.jk.gs is\n> presumably down because of that, not because gitbugs.jk.gs is no longer\n> valid.\n>\n> Nevertheless, AFAIK it has never been used for \"real work\", so you may\n> want to look into why that happened, and do something different.\n\nAs someone who submits patches every once in a while I can echo other\nsentiments in this thread, just because you have a list of issues that\ndoesn't mean anyone is working on them.\n\nHowever I'd also sometimes like to work on some random issue because\nI'm bored, and having a collection of issues ordered by priority (or\npopularity) would be useful when that happens.\n\nBut I think any proposal to set up a wholly external system is going\nto fail, we do most of our bug submission / commenting etc. on this\nmailing list, and that isn't going to change, so there's always going\nto be a large chasm between the list and any external system.\n\nWhat I think *would* work however is a system that feeds off the\nmailing list. This could be as simple as a mailing list aggregator\nthat allowed you to star certain messages, and the most starred\nmessages would be the popular issues.\n\nA more fancy solution would:\n\n * Consume every single message that gets sent to the list\n * Group each thread and allow it to be categorized as a\n bug/issue/enhancement/complaint\n * Allow you to mark a collection of threads as describing the same\n issue, so you'd have duplicates marked & the full history of a\n discussion on some issue.\n * Allow you to mark an issue as outstanding / resolved / allow voting\n on it.\n\nThus you'd automatically build up an issue database without anyone\ngoing out of their way, all it would need is the same people who\ncomplain that they can't file bugs either categorizing existing posts,\nor categorizing a post they just made.\n\nMany bug trackers can be made to work with E-Mail (e.g. Jira, RT\netc.), although I don't know if they're well set up to follow a\nmailing list like this. I think e.g. Jira assumes that you have a the\nbug id in the subject, and might not be smart enough to group things\nby In-Reply-To headers.\n"},{"id":"185808","messageId":"CAH5451mmvxQZc1JEZe+W8WD_QwikpELhxG1WHJAKfp6rW3DCHw@mail.gmail.com","threadId":"29787","inReplyTo":"8762eoimp0.fsf@thomas.inf.ethz.ch","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T12:28:12Z","receivedAt":"2012-03-01T12:28:12Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 22:29, Thomas Rast wrote:\n> Andrew Ardill writes:\n>\n>> I have set up a JIRA instance using Atlassian's OnDemand service,\n>> available at https://git-scm.atlassian.net/\n> [...]\n>> As I see it (and Junio has mentioned before) we are going to need\n>> people who are able to manage the issues in this system\n>\n> Note that you are not the first one to try.  The most elaborate plan and\n> writeup that I know of sits at\n>\n>  http://article.gmane.org/gmane.comp.version-control.git/136500  [1]\n>\n> Jan \"jast\" Krüger also mentioned server issues today, so *.jk.gs is\n> presumably down because of that, not because gitbugs.jk.gs is no longer\n> valid.\n>\n> Nevertheless, AFAIK it has never been used for \"real work\", so you may\n> want to look into why that happened, and do something different.\n>\n\nThanks for the links Thomas, I think the general sentiments summarised\nthere are echoed every time someone mentions an issue tracker on the\nlist. It is good to have the summary though!\n\nI think that, to some degree, the model that most quickly arises from\nthe ideals of that list is inherently flawed. The git list is, almost\nby definition, a fairly chaotic place. Issues get looked into because\neither someone makes a loud enough noise, or someone is interested\nenough in the problem. An issue tracker is a much more structured\nbeast, and trying to tether the two is obviously going to be\ndifficult.\nOne of the benefits of an issue tracker is that it keeps all\ndiscussion around an issue in the one place. The driving wedge here is\nthat we *already* have somewhere that issues are tracked, albeit in a\nless structured sense. Anything that reduces the duplication efforts\nneeded is a desirable thing, but more on that later.\n\nThe one thing we need to avoid is single points of failure. In my\nexperience, this is achieved by ensuring that people contributing\nissues are able to do as much of the leg work as possible. Typically\nthey want to help, and are limited most by unnecessary restrictions\nand lack of understanding. If the process is simple enough it becomes\nmuch easier for new people to step in and make valuable contributions\n(the mailing list is in some ways the embodiment of this). We also\nneed to encourage those who are willing and empower each other to be\ntime-effective.\n\nI feel that is enough pontificating from me, and I am really enjoying\nthe discussion. Please, if you think it will work or not, visit the\nsite [1] - sign up if you want to - and provide feedback. I am going\nto open a project to capture feedback, and anything else related that\nis not directly relevant to the list, and that will probably be a good\nplace to test the ropes if you want to get your hands dirty. In\ngeneral, it is very hard to break things so if you would like to have\na play around with the system please let me know and get involved!\n\nRegards,\n\nAndrew Ardill\n\n[1] git-scm.atlassian.net\n"},{"id":"185817","messageId":"CAH5451mx-f0vuJzTRRhs5Ttr6D1HvB6ptoj_=-kyWqkZ=KHJ_Q@mail.gmail.com","threadId":"29787","inReplyTo":"CACBZZX4T28m6k7A53Zc32Aquk-jh7_R0KPeq983bSQ3B-r27cA@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-01T12:46:37Z","receivedAt":"2012-03-01T12:46:37Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 1 March 2012 22:54, Ævar Arnfjörð Bjarmason wrote:\n> As someone who submits patches every once in a while I can echo other\n> sentiments in this thread, just because you have a list of issues that\n> doesn't mean anyone is working on them.\n>\n> However I'd also sometimes like to work on some random issue because\n> I'm bored, and having a collection of issues ordered by priority (or\n> popularity) would be useful when that happens.\n\nJIRA is particularly good at categorising backlogs and filtering out\nissues, so this is a very achievable outcome.\n\n> But I think any proposal to set up a wholly external system is going\n> to fail, we do most of our bug submission / commenting etc. on this\n> mailing list, and that isn't going to change, so there's always going\n> to be a large chasm between the list and any external system.\n\nI agree wholeheartedly.\n\n> What I think *would* work however is a system that feeds off the\n> mailing list. This could be as simple as a mailing list aggregator\n> that allowed you to star certain messages, and the most starred\n> messages would be the popular issues.\n\nThis is an interesting idea, not sure how that would be implemented\nthough. Seems like you would need some client or webservice email\nreader that could be extended like that.\n\n> A more fancy solution would:\n>\n>  * Consume every single message that gets sent to the list\n>  * Group each thread and allow it to be categorized as a\n>   bug/issue/enhancement/complaint\n>  * Allow you to mark a collection of threads as describing the same\n>   issue, so you'd have duplicates marked & the full history of a\n>   discussion on some issue.\n>  * Allow you to mark an issue as outstanding / resolved / allow voting\n>   on it.\n>\n> Thus you'd automatically build up an issue database without anyone\n> going out of their way, all it would need is the same people who\n> complain that they can't file bugs either categorizing existing posts,\n> or categorizing a post they just made.\n>\n> Many bug trackers can be made to work with E-Mail (e.g. Jira, RT\n> etc.), although I don't know if they're well set up to follow a\n> mailing list like this. I think e.g. Jira assumes that you have a the\n> bug id in the subject, and might not be smart enough to group things\n> by In-Reply-To headers.\n\nJIRA allows creation of issues by sending emails to a special email\naddress. The process that is used is as follows (take from [1]):\n\nThe subject of an email message is examined for an existing issue key:\n - If an issue key is found in the subject, the content of the email\nmessage's body is processed and added as a comment to the issue with\nthat issue key.\n - If an issue key is NOT found in the subject, the in-reply-to header\n is examined:\n - If the email message is found to be a reply to another email\nmessage from which an issue was previously created, the body is\nprocessed and added as a comment to that issue.\n - If the email message is NOT found to be a reply, a new issue is created.\n\nAs you can see, it _should_ respect in-reply-to headers, however we\nshould probably test this :)\n\nCurrently only emails that contain issue keys are being captured,\nhowever I will enable issue creation in a throwaway project so we can\ntest them. I might even set up a forwarder to capture all or most of\nthe list traffic to see what happens. If we capture any useful issues\nin that throwaway project, a valid workflow might be to move them over\nto the 'real' project to which they belong. Perhaps the volume will be\nlow enough in reality that we can enable issues being created directly\nin that project, without the move step.\n\nOne thing to consider is the notifications sent out by JIRA on\ndifferent events. We could potentially send an email to the list\nwhenever an issue is commented on, resolved, or something else. The\npossibilities (and permissions around those possibilities) are quite\nversatile, and well worth investigating. For now I will try my best to\nstop _all_ automated responses going to the list, until we can be\ncertain that it won't be just more spam.\n\n\nThanks for your thoughts, I think your ideas give a really strong\ndirection for us to investigate further.\n\nRegards,\n\nAndrew Ardill\n\n[1] http://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email#CreatingIssuesandCommentsfromEmail-Issuecommentcreation\n"},{"id":"185827","messageId":"CAP2yMa+op58gbUPXvyHdx+cLcCBgHmmuBKGBojxA+puDRPSp1Q@mail.gmail.com","threadId":"29787","inReplyTo":"rmifwdti2ap.fsf@fnord.ir.bbn.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-03-01T16:52:53Z","receivedAt":"2012-03-01T16:52:53Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"On Wed, Feb 29, 2012 at 4:37 PM, Greg Troxel wrote:\n>\n>  I have set up a JIRA instance using Atlassian's OnDemand service,\n>  available at https://git-scm.atlassian.net/\n>\n\nHonestly I would argue against this, just because unless you want to\nspend a lot of time on it, I don't think it's going to get used much.\nIssue trackers in general tend not to get traction unless the\nmaintainer uses it and asks people to use it or it's included in the\nworkflow somehow. I use issue trackers in most of my projects, but I\nalso don't use mailing lists - a lot of the things that work for my\nworkflows are not the way that the Git project does it and I think\nyou'll find that it's a bit of a waste of time to try to shoehorn them\nin.\n\nBesides, most of the things you are looking to get out of this are\ngenerally pretty easily obtained from the ML. If you're bored and\nwant a project to work on, ask the ML. If you want to know the status\non something, search or ask the ML. It's not quite as self-service as\na issue tracker, but it gets you into the community more, which I\nthink is also important.\n\n> Do people really think it's reasonable to use non-Free tools to develop\n> git?  That seems surprising to me.\n\nThis is particularly interesting to me. Disclaimer: I work at GitHub\nand have for most of the life of GitHub. That said, it's interesting\nto think about this. What does the freedom of the tooling provide\nyou? Data portability is one thing, but both JIRA and GitHub have\nAPIs to obtain basically any data in them (I think - I never use JIRA,\nbut I've worked on the GH APIs).\n\nI do think that an interesting data point here is the cast of\nkernel.org, though. So that's all free, but also hugely and totally\nfailed everyone here. It wasted hours of my time trying to clean up\nall the broken links from git-scm.com over a month, which is after a\nmonth of thinking that they couldn't possibly be down another day.\nThe wiki is still busted. The docs are still gone. GitHub has\ncontracted a designer and has started spending developer hours working\non a better git-scm.com to take over those functions so it won't\nhappen again. More importantly, that will never happen to GitHub or\nJIRA - there is no conceivable way that either of these relatively\nlarge corporations would tolerate even a full day of downtime or data\nloss.\n\nSo free is great, but what is more important in the tooling and\nservices that help you develop? Is it freedom to some arbitrary\nlevel, or is it simplicity and availability? I value my time a lot\nmore than if I can get the source code to the issue tracker that my\nopen source project uses. If we're going to use an issue tracker, or\nany other tool, I would really rather prefer we use one backed by a\ncompany that takes downtime seriously as opposed to using something\nthat doesn't have the resources to fix things in any timeframe.\nHaving someone saying \"it's going to keep working because if it\ndoesn't we all lose our jobs\" is more freedom to me than having people\nsay \"if it doesn't work at some point you have the freedom to spend\ndays of your time reimplementing it on your own hardware with maybe\nsome of our backed up data and our open source code\". Which is\nliterally what I'm doing today for the hosted man page documentation.\n\nJust some thoughts.\n\nScott\n"},{"id":"185828","messageId":"7vmx80nt68.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"8762eoimp0.fsf@thomas.inf.ethz.ch","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-01T17:10:39Z","receivedAt":"2012-03-01T17:10:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Nevertheless, AFAIK it has never been used for \"real work\", so you may\n> want to look into why that happened, and do something different.\n\nHrm, I totally forgot about that site while we were discussing this\nyesterday. We only see three \"issues\" there, and that shows nobody\nbothered to register issues, and it is very understandable. People who\nread the list know that all communication that is important to Git happen\nhere, and it will be an additional burden for reporters if they have to go\nthere (be it Jan's site, Andrew's one, or the issue system at GitHub for\nthat matter) and put what you already have posted. People who do not read\nthe list had no chance knowing about Jan's site to begin with, given that\neven I didn't immediately remember.\n\nAlso more importantly, the issues posted here are picked up and acted on\nreasonably quickly---it often is more than \"reasonably\" quickly and I\noften find myself looking at a new initial report, analysis of the problem\nand a tested patch in a single thread, when I check my mailbox the morning.\n\nSuch an issue won't hit the tracker, and neither the initial reporter nor\nthe developers who responded should not do a lot of extra work to get the\nthread in a \"bug tracker\" system.\n\nSomething based on the idea mentioned in Ævar's message (downstream in\nthis thread) to seamlessly integrate with the e-mail traffic might have a\nchance to succeed. I also think the integration must be two-way for it to\nbe useful. A summary of \"new issues untouched for N weeks\" and another\n\"older issues unclosed for N weeks\" periodically sent here, or something.\n\nPerhaps collecting messages based on a handful of simple heuristics like\n\"A message mentioned the keyword 'bug', but no In-Reply-To for it from any\nlist regulars came in two weeks\" might be a good place to start.\n"},{"id":"185849","messageId":"7vy5rkkr3y.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"CAP2yMa+op58gbUPXvyHdx+cLcCBgHmmuBKGBojxA+puDRPSp1Q@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-01T20:23:29Z","receivedAt":"2012-03-01T20:23:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Chacon writes:\n\n> So free is great, but what is more important in the tooling and\n> services that help you develop? Is it freedom to some arbitrary\n> level, or is it simplicity and availability? I value my time a lot\n> more than if I can get the source code to the issue tracker that my\n> open source project uses.\n\nI do not particularly want to say this, but I couldn't resist wondering\nhow the above \"The best tool for the job, be it libre or commercial\"\ncompares with what Linus would have had in his mind when the kernel\nproject decided to use BitKeeper.\n"},{"id":"185877","messageId":"4F504699.3070406@gmail.com","threadId":"29787","inReplyTo":"7vmx80nt68.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-03-02T04:03:37Z","receivedAt":"2012-03-02T04:03:37Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 3/1/2012 11:10 AM, Junio C Hamano wrote:\n>\n> Something based on the idea mentioned in Ævar's message (downstream in\n> this thread) to seamlessly integrate with the e-mail traffic might have a\n> chance to succeed. I also think the integration must be two-way for it to\n> be useful. A summary of \"new issues untouched for N weeks\" and another\n> \"older issues unclosed for N weeks\" periodically sent here, or something.\n>\n> Perhaps collecting messages based on a handful of simple heuristics like\n> \"A message mentioned the keyword 'bug', but no In-Reply-To for it from any\n> list regulars came in two weeks\" might be a good place to start.\n>\nWhy don't you just use git for your bug-tracking? With commit-messages, \nannotated-tags, signed-tags, branches, branch-descriptions, git-notes, \nsubmodules, sha-1's, send-email, patches, hooks, etc., not to mention \nall-kinds-of-files you can commit (screen-shots, bug-reports, etc.) it \nseems you have more than enough pieces to build a bug-tracker with git. \n For example:\n\nSome Ideas:\n\n(Setup)\n - The bug tracker repo could be a one-way mirror of git.git. That \nway the bug-reports are literally tied to the source but don't clutter \ngit.git.\n - Create a bug tracking branch parallel to each release branch.\n - Create a bug-branch off-of the buggy-commit and do the fix and make \nthe bug-tracking-admin updates around the bug branch.\n\n(Submitting Bugs)\n - Post-receive hook to assess new commits and send formatted email to \nmailing list, ie. new-bug push sends bug email to mailing list.\n - The mailing list creates \"bug-report-commits\" kind-of-like Junio \nmentioned above so the mailing list also feeding into it.\n - Bugs can be submitted directly to the bug repo and replicated to \nthe mailing list via post-receive hook, and bugs can be submitted via \nthe mailing list and automatically \"forwarded\" to the bug repo as \"bug \nreport\" refs.\n - Screenshots could be a submodule for \"large file\" optimization.\n\n(Issue-Numbers)\n - The sha-1 of the originating bug-report could be its issue-id.\n - Tag the commit with a \"bug tag\". The sha-1 of the bug-tag could be \nthe issue-id.\n - Calculate issue number from commit-counting to assign unique numbers.\n - The sha-1 of the buggy-commit could be the issue-id.\n\n(Status Updates)\n - Use git-notes to update issue status.\n - Use annotated-tags to update issue status.\n - Use commit-messages to update issue status (or a file in the commit).\n\n(Reporting)\n - Interrogate bug-formatted refnames with wildcards to generate \nqueries of whats going on.\n - Use gitk for ad hoc or pre-defined gui queries of what-you-want-to-see.\n - Use git time-machine commands to see how old stuff is or whats new.\n - have a bug-report-id.txt file that people just modify and commit \nand use git-annotate to see the history of that bug-report.\n\n(Signoff)\n - Signed tags for authenticity.\n\n(Standardization)\n - Git-commands or git-aliases or git-contrib-scripts to make sure \npeople do-it-right (format names/messages/files correctly), ie. templates.\n - Commit hook snippet that detects bug branch format and brings up \nbug commit template.\n - Rebase hook snippet that doesn't allow bug branches to be rebased.\n\n(Integration)\n - The bug tracking system becomes part of the release workflow, ie., \nbugs are only considered fixed when they graduate to an official release \nor something close.\n - The \"bug\" tracking system also tracks \"enhancements\" and they are \nintegrated into new releases using that workflow.\n\n(Concurrency control)\n - Concurrent bug-report updates merge-conflict.\n - If someone beat-you-to-it then you cherry-pick or rebase on top of \nthem.\n\n(Interfaces)\n - works from commandline\n - works with gitk, git-gui\n - works with gitweb\n\n(Quality)\n - Do you really need the greatest commercial-bug-tracker \"x\" or \nopensource-bug-tracker \"y\" to meet your needs? If you've done well with \nnothing then you probably don't need all the bells an whistles. \nManagement-by-report is mainly for clueless managers who want to feel \nlike they know whats going on, and to supervise people who \ndon't-really-care. Since git people are on-the-ground and know whats \ngoing on, and are highly motivated individuals you probably don't really \nneed all that fluff. I suspect you would already be using \nopensource-bug-tracker \"y\" if there was one you actually liked using.\n - There's probably someone on this list who thinks they can create a \nbug-tracker with git that's better-than-anything-else-out-there, and \nthey're probably right.\n\n(Intuitive)\n - If you know how to use git then you know how to use git bug-tracker.\n - If you don't know how to use git then you probably shouldn't be \nsubmitting bug reports.\n\n(Open Source Reusability)\n - The git bug repo system can then be used by others internally as \nthey apply that system to their own project's canonical repository to \ntrack their bugs internally.\n\nSome-Stuff-You-Already-Know:\n\n(Distributed)\n - clone, push, pull -- your using git.\n\n(Reliability)\n - you're using git so you know its uncorrupted, and if it does go \ndown just clone from someone else and verify the checksum.\n\n(Support)\n - git@vger.kernel.org\n - If git.git is down there is not much point in bug-tracking it.\n\nI've been wanting to do this internally for a whle, but I'm still \nlearning the git scm part. Some of the git technologies I listed above \nI haven't used yet so they may sound a bit off, but I think you can get \nthe gist of it.\n\nI think git people in general would be enthusiastic about this, and if \nso, that would be the one thing that truly distinguishes this proposal \nfrom the others ;-) You could call the repo or system bug-git, \ngit-err-done, or something like that.\n\nv/r,\nneal\n"},{"id":"185879","messageId":"20120302041924.GG5248@burratino","threadId":"29787","inReplyTo":"4F504699.3070406@gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-03-02T04:19:24Z","receivedAt":"2012-03-02T04:19:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Neal Kreitzinger wrote:\n\n> Why don't you just use git for your bug-tracking?\n[...]\n> I think git people in general would be enthusiastic about this\n\nNot this git person. ;-) I think there is a pretty major mismatch\nbetween most VCSen's features and what a bugtracker needs.\n\nThat said, a good distributed bugtracker (which implies solving hard\nsocial problems like \"what to do if different contributors disagree on\nseverity\" and simple technical problems like \"how to present a\ncoherent conversation based on threads by people who might not have\nbeen aware of each other\") would be a very nice thing to see,\nregardless of the choice of storage and network protocol used to back\nit.\n\n> git-err-done\n\nHeh.\n\nThanks for some food for thought,\nJonathan\n"},{"id":"185880","messageId":"7vty27k4ym.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"20120302041924.GG5248@burratino","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-02T04:21:53Z","receivedAt":"2012-03-02T04:21:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> That said, a good distributed bugtracker (which implies solving hard\n> social problems like \"what to do if different contributors disagree on\n> severity\" and simple technical problems like \"how to present a\n> coherent conversation based on threads by people who might not have\n> been aware of each other\") would be a very nice thing to see,\n> regardless of the choice of storage and network protocol used to back\n> it.\n\nExactly. In the discussion of the \"tracker\" context, the choice of storage\nmedium is secondary.\n"},{"id":"185882","messageId":"4F505F8C.70802@gmail.com","threadId":"29787","inReplyTo":"20120302041924.GG5248@burratino","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-03-02T05:50:04Z","receivedAt":"2012-03-02T05:50:04Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 3/1/2012 10:19 PM, Jonathan Nieder wrote:\n>\n> That said, a good distributed bugtracker (which implies solving hard\n> social problems like \"what to do if different contributors disagree on\n> severity\"\nHow do you solve that now? You can have a field in the bug-report.txt \nfor \"severity\" or a severity-file in the commit. If people keep \nchanging it and don't listen to the appointed tie-breaker then those \npeople's patches probably aren't going to get applied anyway.\n\n> and simple technical problems like \"how to present a\n> coherent conversation based on threads by people who might not have\n> been aware of each other\") would be a very nice thing to see,\n> regardless of the choice of storage and network protocol used to back\n> it.\nYou can have a field in bug-report.txt called \"discussion thread\" or a \nfile called discussion-thread.txt that contains the link to the mailing \nlist for that thread (even terminal emulators automatically bring up \nlinks when you click on them). People would have discussions there like \nthey do now. Real progress updates would be recorded in git. \nDiscussions would remain on the mailing list. Thread posts could also \nbe recorded as git-notes.\n\nPlease let me know what else is a \"hard social problem\". I'm not a \nbug-tracker expert but I've used a few bug-tracking systems and worked \nplenty of bugs though never on an opensource project so maybe I'm not \naware of the \"hard social problems\".\n\nThat being said, I was in a position where I fixed on average over one \nbug per day (reported, fixed, tested, moved to production) for a total \nof 2,000+ bugfixes over about 6 years. The most in one day was about \neight (1 per hour). It was a home-grown bugtracking system based on \nlotus-notes (ie, email integration). Git has send-mail and the mailing \nlist. The workflow was:\n\n(1) User submits bug-report (or enhancement-request). Status = \nUnassigned, Severity = whatever.\n(2) Manager reviews bug-report and assigns to developer or rejects it. \nStatus = Development or Rejected, Severity = whatever (manager might \nchange it).\n(3) Developer makes fix and marks ready for QA. Status = QA.\n(3.1) during development Developer makes comments that are sent as \nemails and User reciprocates.\n(4) User/tester tests fix and gives signoff. Status = Move-to-Prod.\n(4.1) during testing the user/tester and developer make comments that \nare sent as emails.\n(5) Developer promotes fix to production. Status = Completed.\n(6) Manager receives notice and acknowledges. Status = Closed.\n\nHere's how that might work with git:\n\n(1) User (john.doe@nowhere.com) submits bug-report (or request). Status \n= Unassigned, Severity = whatever.\n[BUG] (starts the thread)\n\n(2) Manager (git-maintainer) reviews bug-report and assigns to developer \n(or lieutenant) or rejects it. Status = Development or Rejected, \nSeverity = whatever.\n[DEV] | [REJ] (assigned to developer/lieutentant or rejected)\n\n(3) Developer makes fix and marks ready for QA. Status = QA.\n(3.1) during development Developer makes comments that are sent as \nemails and User reciprocates. (makes posts to thread on mailing list)\n[QA] (fix is in next)\n\n(4) User/tester tests fix and gives signoff. Status = Move-to-Prod.\n(4.1) during testing the user/tester and developer make comments that \nare sent as emails. (makes posts to thread on mailing list)\n[PAS] (fix passed testing)\n\n(5) Developer promotes fix to production. Status = Completed.\n[CMP] (fix is in rc)\n\n(6) Manager (git-maintainer) receives notice. Status = Closed.\n[CLS] (fix is in release)\n\nI realize this is not an exact match of the git-workflow, but you get \nthe idea. I'm also new to mailinglists so I'm not sure if you can \nchange part of the subject line. If not, a header in the body could \npossibly be used.\n\nThank you for your time and consideration.\n\nv/r,\nneal\n"},{"id":"185887","messageId":"20120302062524.GI5248@burratino","threadId":"29787","inReplyTo":"4F505F8C.70802@gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-03-02T06:25:24Z","receivedAt":"2012-03-02T06:25:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Neal Kreitzinger wrote:\n\n> Please let me know what else is a \"hard social problem\". I'm not a\n> bug-tracker expert but I've used a few bug-tracking systems and\n> worked plenty of bugs though never on an opensource project so maybe\n> I'm not aware of the \"hard social problems\".\n\nI was not alluding to bug ping-pong (which is a security or discipline\nproblem) but the task of reconciling independent good-faith updates\n(which is a coordination problem).\n"},{"id":"185888","messageId":"7vsjhrfprz.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"4F505F8C.70802@gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-02T07:03:28Z","receivedAt":"2012-03-02T07:03:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Neal Kreitzinger writes:\n\n> I realize this is not an exact match of the git-workflow, but you get\n> the idea. I'm also new to mailinglists so I'm not sure if you can\n> change part of the subject line. If not, a header in the body could\n> possibly be used.\n\nThe most important information is missing from your discussion: who are\nyou trying to help, and what problem are you trying to solve?\n\nWhen somebody posts a bug report to the list, with the current workflow,\none of these things happens:\n\n 1. It is an already solved issue. People who are familiar with the\n existing fix may immediately answer, after running \"git log\", with \"It\n is fixed in v1.7.6\". Or somebody not so familiar with the fix may\n start \"Does not reproduce for me who use the 'master' version. Git\n from what era are you using?\" conversation. I do not think a bug\n tracker will help much in this case [*1*].\n\n 2. It is an already answered non-issue. People who are familiar with the\n previous discussion may point at the list archive, or somebody may dig\n up the answer in the gmane archive. I do not know if a bug tracker\n will help much in this case. Having a place to point people at is\n better than having to write everything from scratch every time, but\n (1) looking for the previous discussion is the more time consuming\n part, and (2) once the previous discussion is found in the list\n archive, we already have the necessary pointer.\n\n 3. People who are familiar with the area of the problem may start \"Need\n more info\" conversation. This may result in either finding the report\n a non-issue (#1 or #2), or it may turn out to be a real issue, and\n after further analysis, design and coding, may result in a fix. Once\n this flow starts rolling, the current workflow works very well.\n\n 4. It falls through cracks, because nobody even categorizes it into the\n above three.\n\nI think the primary thing people want out of a bug tracker is to reduce\nthe frequency of #4. The real solution for it is to free up time from\npeople who can do the later part of #3 so that they can spend more time to\nturn #4 into #3.\n\nA way to do so is for members of the community who are capable of doing #1\nand #2 but not familiar enough with the code to do the later part of #3 to\nhelp with earlier part of #3 (i.e. triaging).\n\nAs I already said. the mailing-list based workflow serves us reasonably\nwell once the ball is rolling in #3, and that was the reason why I\nsuggested some heuristics to catch #4 in my previous message. There are\ncases where the original reporter disappears during the \"need more info\"\nexchange, and in such a case a tracking system _may_ be able to help us\nremember that the issue is unresolved because of reporter inaction, but\nthe tracker won't respond to \"need more info\" itself, and people tend to\nignore automated nag mails, so there is still a need for warm body human\nbug secretary who interfaces with the reporter in such a case.\n\nIn any case, any solution that demands more things to be done by people\nnear the core developers than they currently are already doing will make\nthings worse by exacerbating the problem that comes from a bottleneck in\nthe process. I do not think your \"The maintainer triages and assigns\nissues to other developers\" or \"The assigned developer marks the issue as\n'done' after fixing it\" will fly very well, regardless of the use of any\nbug tracker.\n\n\n[Footnote]\n\n *1* If the symptom is so straightforward that a simple search in a bug\n tracker can produce hits for an already solved issue, grepping in\n Release Notes should equally work well.\n\n *2* I do not know if this happens too often to be a real problem, though.\n"},{"id":"185923","messageId":"4F50D6C6.3080909@op5.se","threadId":"29787","inReplyTo":"7vsjhrfprz.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-03-02T14:18:46Z","receivedAt":"2012-03-02T14:18:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 03/02/2012 08:03 AM, Junio C Hamano wrote:\n\n... a very concise and exact response.\n\n> \n> In any case, any solution that demands more things to be done by people\n> near the core developers than they currently are already doing will make\n> things worse by exacerbating the problem that comes from a bottleneck in\n> the process. I do not think your \"The maintainer triages and assigns\n> issues to other developers\" or \"The assigned developer marks the issue as\n> 'done' after fixing it\" will fly very well, regardless of the use of any\n> bug tracker.\n> \n\nIt works very well when there's the incentive of roof over one's head\nand food on one's table to take care of the assigned issues. However,\nnothing stops a git developer from saying \"sorry, I'm busy\" when being\nassigned really, really boring tasks that they really don't feel like\ndoing.\n\nOne thing I could see a bugtracker would be good for is to get companies\nthat use git to vote on issues or features using real money. Developers\ncan then pick up the issue and do something with them.\n\nApart from that, I doubt there's much incentive for the people who do\nany of the work to pick up issues nobody cares about. The number of bugs\nfalling through the cracks is too small to go through a lot of work just\nto keep track of them, and the ones that do are ones that are primarily\nof the bikeshedding variant or such weird corner-cases that they don't\nhappen in 99.999% of all use-cases git was designed for and is bid to\nhandle.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"185928","messageId":"7vk433eyts.fsf@alter.siamese.dyndns.org","threadId":"29787","inReplyTo":"4F50D6C6.3080909@op5.se","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-02T16:45:35Z","receivedAt":"2012-03-02T16:45:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> On 03/02/2012 08:03 AM, Junio C Hamano wrote:\n>\n> ... a very concise and exact response.\n>\n>> In any case, any solution that demands more things to be done by people\n>> near the core developers than they currently are already doing will make\n>> things worse by exacerbating the problem that comes from a bottleneck in\n>> the process. I do not think your \"The maintainer triages and assigns\n>> issues to other developers\" or \"The assigned developer marks the issue as\n>> 'done' after fixing it\" will fly very well, regardless of the use of any\n>> bug tracker.\n>\n> It works very well when there's the incentive of roof over one's head\n> and food on one's table to take care of the assigned issues.\n\nYour \"this is a volunteer effort and assignment does not work like corp\nenvironment\" is valid, but I think it is missing the point. A solution\nthat demands more from people who are already bottlenecks will not work\nvery well, even in a corporate environment where you have stronger\nincentive to fill your assigned role.\n"},{"id":"186292","messageId":"CAH5451mcu=sQa8KL8ptGr5w_d-OmtzAD9B-fwtMGE0w5zELgGA@mail.gmail.com","threadId":"29787","inReplyTo":"7vk433eyts.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-03-07T08:03:17Z","receivedAt":"2012-03-07T08:03:17Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Just a quick status update on where the issue tracker experiment at\ngit-scm.atlassian.net is up to:\n\nThe basic structure of the issue tracker is set up, and is ready for\npeople to log bugs if they want to. So far no one seems to inclined,\nbut note that it is still locked down to only people who have both\nregistered, and been promoted to 'trusted'. I will promote everyone\nwho has registered so far to 'trusted' in the hope that some of them\nmight add bugs!\n\nThe next main step is to have conversations on the list automatically\nconverted into issues that can be tracked. This will be either by\nforwarding selected threads to the tracker, or forwarding everything\nto the tracker and managing it from there. Unfortunately, a recent\nupgrade broke the (unsupported) ability to create issues from\nemails[1]. This will hopefully be fixed soon, and when it is we will\nbe able to move this experiment to the next phase.\n\nIf anyone has any ideas they would like to test, please let me know!\n\nRegards,\n\nAndrew Ardill\n\n[1] Reply from Atlassian:\nOfficially we do not support\n(http://confluence.atlassian.com/display/AOD/Restricted+Functions+in+Atlassian+OnDemand)\nissue creation from email in OnDemand. The feature request for this\nfunctionality is located at:\nhttps://studio.atlassian.com/browse/JST-5649\n\nThere was the ability to create issues from email if emails were sent\nto jira@ as you tried to setup, but this\nfunctionality was not officially supported and broke in the recent\nJIRA 5 upgrade (which is why you receive those errors).\n\nI believe we are planning to fix this in an upcoming bugfix release\nwithin the next several weeks though, so please try again later.\n"},{"id":"186295","messageId":"4F572FF2.7030507@lyx.org","threadId":"29787","inReplyTo":"CAH5451mcu=sQa8KL8ptGr5w_d-OmtzAD9B-fwtMGE0w5zELgGA@mail.gmail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-07T09:52:50Z","receivedAt":"2012-03-07T09:52:50Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"Op 7-3-2012 9:03, Andrew Ardill schreef:\n> Just a quick status update on where the issue tracker experiment at\n> git-scm.atlassian.net is up to:\n>\n> The basic structure of the issue tracker is set up, and is ready for\n> people to log bugs if they want to. So far no one seems to inclined,\n> but note that it is still locked down to only people who have both\n> registered, and been promoted to 'trusted'. I will promote everyone\n> who has registered so far to 'trusted' in the hope that some of them\n> might add bugs!\n\nDone: https://git-scm.atlassian.net/browse/GIT-1\n\nVincent\n"},{"id":"186309","messageId":"66B417CA-5F2C-4F6C-BF69-9383CB171C15@googlemail.com","threadId":"29787","inReplyTo":"7vsjhrfprz.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Joern Huxhorn","fromEmail":"jhuxhorn@googlemail.com","sentAt":"2012-03-07T13:04:10Z","receivedAt":"2012-03-07T13:04:10Z","isPatch":false,"sender":{"key":"jhuxhorn@googlemail.com","avatar":"https://gravatar.com/avatar/c8d68ce37da549d9cdaad9c0b5594ef2197cfa36f562b4a843d38afadd05360e?d=mp&s=160"},"body":"\nOn 02.03.2012, at 08:03, Junio C Hamano wrote:\n\n> Neal Kreitzinger writes:\n> \n>> I realize this is not an exact match of the git-workflow, but you get\n>> the idea. I'm also new to mailinglists so I'm not sure if you can\n>> change part of the subject line. If not, a header in the body could\n>> possibly be used.\n> \n> The most important information is missing from your discussion: who are\n> you trying to help, and what problem are you trying to solve?\n> \n> When somebody posts a bug report to the list, with the current workflow,\n> one of these things happens:\n> \n> 1. It is an already solved issue. People who are familiar with the\n> existing fix may immediately answer, after running \"git log\", with \"It\n> is fixed in v1.7.6\". Or somebody not so familiar with the fix may\n> start \"Does not reproduce for me who use the 'master' version. Git\n> from what era are you using?\" conversation. I do not think a bug\n> tracker will help much in this case [*1*].\n> \n> 2. It is an already answered non-issue. People who are familiar with the\n> previous discussion may point at the list archive, or somebody may dig\n> up the answer in the gmane archive. I do not know if a bug tracker\n> will help much in this case. Having a place to point people at is\n> better than having to write everything from scratch every time, but\n> (1) looking for the previous discussion is the more time consuming\n> part, and (2) once the previous discussion is found in the list\n> archive, we already have the necessary pointer.\n> \n> 3. People who are familiar with the area of the problem may start \"Need\n> more info\" conversation. This may result in either finding the report\n> a non-issue (#1 or #2), or it may turn out to be a real issue, and\n> after further analysis, design and coding, may result in a fix. Once\n> this flow starts rolling, the current workflow works very well.\n> \n> 4. It falls through cracks, because nobody even categorizes it into the\n> above three.\n> \n> I think the primary thing people want out of a bug tracker is to reduce\n> the frequency of #4. The real solution for it is to free up time from\n> people who can do the later part of #3 so that they can spend more time to\n> turn #4 into #3.\n> \n> A way to do so is for members of the community who are capable of doing #1\n> and #2 but not familiar enough with the code to do the later part of #3 to\n> help with earlier part of #3 (i.e. triaging).\n> \n> As I already said. the mailing-list based workflow serves us reasonably\n> well once the ball is rolling in #3, and that was the reason why I\n> suggested some heuristics to catch #4 in my previous message. There are\n> cases where the original reporter disappears during the \"need more info\"\n> exchange, and in such a case a tracking system _may_ be able to help us\n> remember that the issue is unresolved because of reporter inaction, but\n> the tracker won't respond to \"need more info\" itself, and people tend to\n> ignore automated nag mails, so there is still a need for warm body human\n> bug secretary who interfaces with the reporter in such a case.\n> \n> In any case, any solution that demands more things to be done by people\n> near the core developers than they currently are already doing will make\n> things worse by exacerbating the problem that comes from a bottleneck in\n> the process. I do not think your \"The maintainer triages and assigns\n> issues to other developers\" or \"The assigned developer marks the issue as\n> 'done' after fixing it\" will fly very well, regardless of the use of any\n> bug tracker.\n> \n> \n> [Footnote]\n> \n> *1* If the symptom is so straightforward that a simple search in a bug\n> tracker can produce hits for an already solved issue, grepping in\n> Release Notes should equally work well.\n> \n> *2* I do not know if this happens too often to be a real problem, though.\n\nSorry for the full quote.\n\nI think the main problems with all issue trackers I know about are\n- they are centralized, i.e. like SVN\n- they all have a more or less clumsy web interface. All of them different, most of them configurable.\n\nTo get accepted in this community, an issue tracker would need to be decentralized (obviously including the ability to merge issue state and so on, likely git-based, probably simply included in the normal git repository of a project or in a separate issues-branch) and require a proper command line interface so it is properly scriptable (to feed it with threads from this mailing list, for example).\n\nI'd love such a system.\n\nI disagree with your assumption in 1. and *1*. A proper issue tracker has the ability to attach additional info (like stack traces or even a workaround) and files. Those would be searched, too, and would most likely not show up in the 'git log'.\nAn issue tracker could therefore remove noise from the mailing list which would automatically reduce workload on the core developers.\n\nYour points 1. 2. and 3. all include \"People who are familiar\", i.e. it always involves some action from more or less cory developers. In case of an issue tracker, even duplicates and already solved issues (1. and 2.) serve a purpose since they'd indicate that either the previous solution hasn't been communicated good enough or that the duplicated issue has a high enough impact to creep up again.\nSomebody needs to keep in mind all issues, in some way. I really wonder how you are able to cope with this task.\n\nI'm not trying to lecture you that you are \"doing it wrong\". Your mailing-list based workflow seems to work incredibly well for you. But it doesn't really help to entice people into the community, either.\n\nI'm (mostly) a silent observer of this list and just a (super-happy) user of git - but I really have a hard time getting a grip on the changes introduced in the different versions. You could obviously argue that I'm not trying hard enough since I'm not reading the 'git log' and all the diffs but I suspect that I'm already trying harder than most users.\n\nFor example, what happened to the git generation numbers discussed (in part) over here: http://comments.gmane.org/gmane.comp.version-control.git/177146\nAre they already included in a released git version? If so, how would I find them? If not, why not? An issue tracker would be able to answer me, as a little-above-casual user, this question without resorting to asking you.\n\nSo I guess it all boils down to waiting until somebody is sufficiently annoyed by the current state of issue trackers and thus tries to implement a properly decentralized one that is likely based on plain text files (for easy merges) and features a proper way to query issues.\n\nJust like Linus was sufficiently annoyed by the state of VCS.\n\nCheers,\nJoern."},{"id":"186312","messageId":"20120307135314.GB2008@burratino","threadId":"29787","inReplyTo":"66B417CA-5F2C-4F6C-BF69-9383CB171C15@googlemail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-03-07T13:53:14Z","receivedAt":"2012-03-07T13:53:14Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Joern Huxhorn wrote:\n\n> To get accepted in this community, an issue tracker would need to be\n> decentralized\n\nNo, I don't think that's a requirement.\n\nThanks for your interest,\nJonathan\n"},{"id":"186315","messageId":"0CBE7FE5-8803-4ECA-A161-6D810D6C128A@googlemail.com","threadId":"29787","inReplyTo":"20120307135314.GB2008@burratino","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Joern Huxhorn","fromEmail":"jhuxhorn@googlemail.com","sentAt":"2012-03-07T14:47:08Z","receivedAt":"2012-03-07T14:47:08Z","isPatch":false,"sender":{"key":"jhuxhorn@googlemail.com","avatar":"https://gravatar.com/avatar/c8d68ce37da549d9cdaad9c0b5594ef2197cfa36f562b4a843d38afadd05360e?d=mp&s=160"},"body":"\nOn 07.03.2012, at 14:53, Jonathan Nieder wrote:\n\n> Joern Huxhorn wrote:\n> \n>> To get accepted in this community, an issue tracker would need to be\n>> decentralized\n> \n> No, I don't think that's a requirement.\n> \n\nI didn't mean to imply that this would be a matter of principle. A decentralized tracker would just offer the same advantages that a decentralized VCS has to offer. One could work on issues while not connected to the internet, for example. So this would be a VeryGoodThing™.\n\nI don't think that it would be a good idea to \"teach\" git issue tracker functionality. I simply wanted to voice my opinion that something like the ideas Neal suggested down the thread, a cli issue tracker with git in the backend, are very worthwhile to evaluate. But it should have an additional layer so it's really easy to use. It has to be so it *is* actually used. It needs to reduce workload instead of increasing it.\n\nCheers,\nJoern."},{"id":"186316","messageId":"CAKcBokvjMaVwnJv=36AUqcJ5Z08Ldfe37CD7XOik=d=FeEXPqg@mail.gmail.com","threadId":"29787","inReplyTo":"66B417CA-5F2C-4F6C-BF69-9383CB171C15@googlemail.com","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Pau Garcia i Quiles","fromEmail":"pgquiles@elpauer.org","sentAt":"2012-03-07T15:08:22Z","receivedAt":"2012-03-07T15:08:22Z","isPatch":false,"sender":{"key":"pgquiles@elpauer.org","avatar":null},"body":"On Wed, Mar 7, 2012 at 2:04 PM, Joern Huxhorn wrote:\n\n> To get accepted in this community, an issue tracker would need to be decentralized (obviously including the ability to merge issue state and so on, likely git-based,\n> probably simply included in the normal git repository of a project or in a separate issues-branch) and require a proper command line interface so it is properly\n> scriptable (to feed it with threads from this mailing list, for example).\n>\n> I'd love such a system.\n\nTake a look at Veracity ( http://veracity-scm.com/ )\n\nAlso, do not forget issue tracking must be possible for people who do\nnot use git. That's why we use git hosted at Assembla (\nhttp://www.assembla.com ) at work: 2/3 of the people in the project\nare not developers but marketing, verification, validation, support,\ntrainers, management, etc.\n\n-- \nPau Garcia i Quiles\nhttp://www.elpauer.org\n(Due to my workload, I may need 10 days to answer)\n"},{"id":"186321","messageId":"CABURp0q7fJLBHGGdD7EQ6pwEu=zErKHz+ZZJ5HLVe5VO2Y66gQ@mail.gmail.com","threadId":"29787","inReplyTo":"7vsjhrfprz.fsf@alter.siamese.dyndns.org","subject":"Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-03-07T17:18:36Z","receivedAt":"2012-03-07T17:18:36Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Mar 2, 2012 at 2:03 AM, Junio C Hamano wrote:\n> Neal Kreitzinger writes:\n>\n>> I realize this is not an exact match of the git-workflow, but you get\n>> the idea.  I'm also new to mailinglists so I'm not sure if you can\n>> change part of the subject line.  If not, a header in the body could\n>> possibly be used.\n>\n> The most important information is missing from your discussion: who are\n> you trying to help, and what problem are you trying to solve?\n\nProblems this could help solve (regardless of whether it's an\nappropriate tool for the job):\n\n1. Collects issues into a more concise list than the mailing list provides.\n\n2. Collects issues (and discussion) conveniently bundled with the git\nsource code.\n\n3. Collects issues for off-line reference and searching.\n\n4. Reduction of list noise, if issues in git.git turn out to be better\ngrep-targets than the mailing list.\n\n5. Serves as an incubator for a git-based distributed issues tracker\nBest Practice or Dire Warning, depending on how it goes.\n\nThe current mailing list bug tracker, where finding existing issues\nand previous discussions is \"crowd-sourced\" to the list, is very\nefficient for the new users, but not so efficient for the core\ndevelopers and respondents.\n\nI doubt this idea is really workable or appropriate for git.git, for\nvarious reasons. But I do think a well-designed, distributed,\ngit-based issue tracker could be useful for many other projects. Many\nothers have tried and failed, so I am probably wrong about this last\nstatement. See [*1*] for a list of mostly stagnating prior art.\n\nPhil\n\n[*1*] http://dist-bugs.branchable.com/software/\n"}]}