Review Process

[Daniel Holbach]

Hello everybody,

some of you might have heard of the CodeReview spec or might even have
had a look at https://wiki.ubuntu.com/CodeReviewSLA - The spec was now
approved and is a new proposal to attack our problems with reviewing NEW
packages.

We had several discussions at UDS, and to me personally two things were
important for a new process for that:

      * use of bzr,
      * less maintenance work.


I think that using bzr for packaging has a bunch of advantages over
using an 'archive like structure':

      * quick collaboration between MOTU hopefuls
      * we had packages which just needed small changes to it, but had
        an inactive MOTU hopeful to take care of them - with bzr that's
        no problem anymore.
      * `bzr diff` is easily checkable - it even comes with a history
        that can hold more information, why things need to be done that
        way, etc.
      * ...

In the Telepathy team we used bzr for the packaging and it worked out
really well, even new contributors got things done quickly and learnt a
bunch along the way.


I think that using Launchpad for this will make things easier, because:

      * people work on it for us, we don't need to invent things again,
      * bazaar-launchpad has nice overviews,
      * there is more features planned for the future, which we'll
        benefit from.
      * no maintenance need from our side.


https://wiki.ubuntu.com/CodeReviewSLA outlines the planned workflow.
Please note that there are still some unresolved issues on the Launchpad
end, but none that should stop us from starting us to use it. Most
notable are the following things, though:

      * Bug 73975. This plan is not going to work unless subscribing to
        a branch actually causes emails to be sent. 
      * Bug 55096 prevents teams from subscribing to its bazaar
        branches. 
      * Bug 71303 would make the /+branches overview page much cleaner
        and easier to read. The revu branches page will be quite full
        really soon.


Another problem is the missing tarball, if we just use bazaar-launchpad
for the packaging. We could either use debian/watch files or a
newly-designed X-Tarball: tag in debian/control or a debian/tarball or
something (and hack up revu-scripts to make use of that), but that's
something we can still discuss here on the list.


Let's make this a trial period for the new process and please don't
despair, but let's try to discuss all the problems that surface. We
won't do a full switch now. I made the whole ubuntu-dev team members of
https://launchpad.net/people/revu - so you're all able to use the ~revu
branches. If somebody of ubuntu-dev wants to step up and do member
approvals for the team together with me, please let me know.


If there's anything else you want to know about the process or discuss
with me, let me know.

Thanks a lot - have a nice day,
 Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20061211/7b109fe3/attachment.pgp