Review Process

[Daniel Holbach]

Hello Stefan,

thanks a lot for sharing your thoughts with us and writing them up so
nicely.

I'll comment on a few points.


On Di, 2006-12-12 at 00:09 +0100, Stefan Potyra wrote:
> Well, tbh. I don't know really myself. However here are some thoughts:
> For 1) doing more revu-days might help.

Definitely! That's something the MOTU Council should probably coordinate
and bear in mind. We need them regularly and we need to be better at
spreading the word about them.



> 2) could get fixed by allowing non motu's to do initial reviews as well.

That's something I'd very much like to see and was part of the design.
If MOTU hopeful Daniel can tell MOTU hopeful Sébastien to checkout his
branch and Séb looks at it, Séb might as well change some things and
write some nice comments in the commit log and either push it to his own
~séb namespace or to the ~revu namespace if he's really sure.

This is, what will speed up the process and with 'bzr log' and 'bzr diff
-r <revision>' people will be quickly able to see where problems lie.


> It 
> might help, if packages from non-motus would only require one vote

This is something we'll discuss in our first MOTU Council session.


> Finally, it might also help to do motu-school sessions for packaging to get 
> goal 3) covered better outside of revu. Maybe motu-school sessions might even 
> be held in a seminar like manner (dunno if that's the same term in english) 
> where motu-hopefuls hold the actual lessons and motu's will review the 
> lessons in question prior to it and give comments during the lessons to 
> correct possible errors or make things more clear. But that's just a crazy 
> idea from me.

Doesn't sound too bad - we should probably write it up and discuss it in
a meeting.


> 1) abstraction from sourcepackage to bzr-archives
> To serve goal 3), it's imo vital to provide a method that's very close to 
> working with packages for ubuntu. In universe most packages are just plain 
> source packages w.o. any bzr archive behind them. Also since debian uses 
> source packages, this knowledge is highly useful for merges as well.
> Also lp only accepts (at least to my knowledge *g*) source packages. This 
> makes this knowledge imo pretty vital for a motu to be.
> With revu, you are forced to learn the basic stuff about source pacakages: 
> You're forced to upload signed source packages (almost) like to the real 
> archive.

I don't think that source packages and running debuild -S is concept
hard to learn. I agree that we still need it (we'll see when
NoMoreSourcePackages is going to be implemented), but I don't think that
it's problematic and should be inherent to the review process.

People will learn it quickly, if they use pbuilder at home or if they
prepare debdiffs etc.


> 2) It's harder for the reviewers to check the complete package. Unless we have 
> some means (maybe a script?) to fetch a bzr-branch and turn it into a regular 
> source package, this makes it harder for a potential reviewer to testbuild 
> the package and get a complete picture of the resulting source package. For 
> revu I do "dget <link to dscfile>" and have the source package at hand.

Absolutely valid point. We need to figure something out for that. I just
didn't find it feasible to commit the upstream source to the bzr branch
too. We can and should discuss this some more.


> 3) I personally like to make separate comments to a specific version of an 
> upload. I haven't found out how this is addressed via the proposed process, 
> maybe someone can enlighten me there. 

Commit messages can do that. They preserve history. The status
whiteboard, I agree has some problems with that.


> Ideally this could be done by s.th. 
> like a bug report that's referred to right next to the branch in question. 
> That way we would get an email-interface for free :).

Interesting idea. I need to think about it a bit.


> 4) While it's nice to have a good solution provided by lp, this also means 
> that we cannot fix any bugs/inconveniences ourselves. We also cannot add 
> features to it directly.

Valid, but I think that it will be more worth to discuss with the
Launchpad folks, write specs with them and let them work something out
that's of a benefit for everybody working with branches.


> * orig-tarball: I always check, if the orig-tarball is in fact the same thing 
> as the upstream supplied one. That's a tedious task though, as it usually 
> involves looking around various urls.

If we write a script, why not ask people to supply the link to the
upstream tarball? That should be easiest. :)


> * autobuilding: There should be a convenient way for a reviewer to have the 
> package autobuilt. With revu-tools we have at least a basic method to do this 
> (I must admit, that I've never tested these myself), but ideally there would 
> be just a button to have it autobuilt on all ubuntu supported architectures.

Until we have PPA (Personal Package Archives, which is a spec for
Launchpad), I'm sure we can cook something up. I already wrote the
automatic artwork builder
(https://wiki.ubuntu.com/AutomaticArtworkBuilderInstructions) which
could do something along those lines. I'll think about it and ask Mark
and/or Matt on their opinions.


> Apart from that, I like from the proposed process, that people will learn how 
> to use bzr. That's definitely a big plus for goal 3). 

Yes, I'm sure we'll all make more use of bzr in the future.


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/20061212/24cc4788/attachment.pgp