Patch pilot report 2011-10-07

Didier Roche didrocks at
Fri Oct 7 10:42:09 UTC 2011


Not a lot of uploads in this freeze period, but mainly cleaning up (or 
trying to…) the list.
-> tested that the fix applied was enough, closed the bug when confirmed.
-> this one is uploaded but as it was targetting the wrong series (natty 
and not oneiric)
it wasn't marked as merged. Can anyone having those right can do it please?
-> typo fixes, asked to use a patch system like quilt providing the 
needed link and to upstream it.
-> pinged upstream directly :)
-> already in oneiric, set as merged., 
requires a FFe ack on
Subscribed the right component to it to get it reviewed by the release team.
-> dobey already disapproved it, can someone reject it?
-> sponsored
-> too late to land it for Oneiric, even in update, should be for 
Precise. Same question than previously, no other way to pend the change
than pushing it in progress and following manualy for pushing it at the 
right time?
-> typo in debian/control. The change can be pushed in precise I guess 
(I also asked to push the change to
debian about it). Is there any process for those? I can of course merge 
the change in lp:ubuntu/nss, but
I'm afraid it won't be looked before the next upload in precise as all 
recent commits are done by the "Bazaar Package Importer").
Consequently, I keep a tab opened a put the branch as "work in progress".

More generally, we have a lot of typo or rephrasing debian/control pending:
There have been some discussion started in most of them about the 
precise wording and some changes in some, but should we make a special 
so that they all go to debian first and quickly? (like pinging a DD if 
we are not) rather than going to open a bts bug and let the branch stalled?
I think it's clearly the kind of diff we don't really want.

Note that my feeling is that we have a general tracking issue. I saw a 
lot of merge reqs when someone asked to do something, then an additional 
commit is pushed to fix the concerns and nothing happened afterwards. 
How can we get better at that? I'm totally consciencious that it's 
really difficult to track if someone did the needed change (I try to 
subscribe to the merge req. for that, but sometimes, it's not enough) or 
should the next patch pilot not rely on the name of last person who 
commented on it and reopen it to see if something changed? We should 
probably discuss about how to get better at that at UDS.


More information about the ubuntu-devel mailing list