Hi, On Thu, Apr 24, 2014 at 1:40 PM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > On Fri, 2014-04-18 at 15:57 +0000, Felipe Sateler wrote: >> On Thu, 17 Apr 2014 12:14:02 +0300, Tanu Kaskinen wrote: >> >> > Patch review status updated: >> > http://www.freedesktop.org/wiki/Software/PulseAudio/PatchStatus/ >> > >> > Statistics: >> > >> > * 2014-04-17 >> > * 157 patches are pending review (not counting the "in a github >> > branch" patches). >> >> What does "in a github branch" mean (what repo)? Does this mean that >> github pull requests are acceptable forms of supplying patches? It >> appears to me that current practice is to *not* submit patches through >> the bugzilla. Is this understanding correct? > > Sorry for taking a while with this reply... No worries, we are all busy ;) > "In a github branch" means > that the patches only exist in a github branch. They are not included in > the "X patches are pending review" count, because there's no guarantee > that the branch contents don't suddenly change. Github pull requests > certainly aren't the recommended way of submitting patches, but it's not > strictly forbidden either (although I wouldn't mind an "if it's not on > the list, it didn't happen" policy). > > Regarding bugzilla, I do follow what is submitted there, but the > preferred submission method is via email (and git send-email is > preferred over patch attachments). OK, so I'll go with sending them to the list. > >> Background: >> >> I recently joined the PA maintenance team in debian (Hi All!). As I have >> been sifting through old (downstream) bug reports I have forwarded some >> things (as did Balint for the patches we carry), but tracking their >> status is not easy, as it requires searching through the mailing list >> archives to see if the patch had objections, or maybe was resubmitted, or >> was NACKed. >> >> What would be ideal from my POV is a single (unchanging) URL per patch, >> so that I can point my downstream tracker to that and then I can simply >> go check if the patch was merged or not. Currently the forward notes > > What do you mean by "forward notes"? Is it some file that Debian PA > maintainers are maintaining? The debian bug tracker has a concept of a "forwarded to" address. This is a freeform text (can be an email, url, or anything). It is very useful when something is not really a packaging issue but rather an upstream problem. There are even some tools that notify us when the bug is fixed if the pointed to url is a known bug tracker (like bugzilla). For example, you can see this bug which I recently forwarded to the bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561780 This is useful not only for patches, but also for bugs even when there is no patch (yet). > >> do >> not really work as the pointer is to a mailing list archive, and the >> discussion could have moved on since the first submission. In other >> words, it is hard to keep track of the stuff we have forwarded. > > What scenario are you thinking of when you say "the discussion could > have moved on since the first submission"? The result of the first > submission should be visible in the mailing list thread, so if you have > a link to the patch in the list archive, doesn't that make it pretty > simple to check the patch status? Not really. Mailing lists archives are not very helpful in this regard. If I submit a patch this month and you (N)ACK it next month the thread is broken in the web archive. > If another submission has been made in > a different thread, shouldn't you update the "forward notes" at the same > time you submit the new patch? Yes, if I submit a new version of the patch, then I should update the forward note. But if a third party does (say, a different/updated patch fixes the same issue the original patch), they may not update the forward note. The issue is that changing URLs means having to remember updating the note, and for that I need to wait for my message to appear in the archive so I can know the url. Moreover, if I visit an old bug, I still have to check if the patch was resubmitted at a later date without updating the forward note. In any case, I will from now on send patches with git send-email. -- Saludos, Felipe Sateler
