Patch pilot report 2011-10-07
didrocks at ubuntu.com
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?
-> 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
-> 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