On Wed, Apr 16, 2008 at 9:40 AM, Daniel Holbach <[EMAIL PROTECTED]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Cesare Tirabassi schrieb:
> > Its not a question of trust, its a question that 4 eyes see better than
> 2. I
> > know I don't rely on my packaging skills alone, no matter how much I
> work I
> > will always miss something.
>
> Right. That happens to upstreams, happens to uploads of existing
> packages and happens in uploads of new packages. Whenever somebody is
> made member of ubuntu-dev they have the chance to break packages (and
> embarrass themselves) with every single upload.
>
> I guess my question is two-fold: 1) how can we improve our existing ways
> to collaborate on packaging to be less error-prone, 2) why do we deem
> the reviewing of new packages different than uploading for example new
> packages versions, etc.?
>
>
> >> Is the quality of packaging our main concern?
> >
> > Definitively.
>
> Then what can we do to improve it? Is "I will have to ask my colleague"
> the only way to do that?
>
>
> > Very good example, and a showcase of why devs are not very keen in
> reviewing.
> > First, the contributor missed even the more fundamentals of a package
> (other
> > examples are native packages which are not, wrong standards, wrong
> > distribution, etc.), so the reviewer instead of spending a whole morning
> > reviewing the package just points out the more obvious (I would and
> never
> > have done this by the way, this is a side product of having one reviewer
> > trying to "triage" a long queue).
>
> I picked the example to illustrate that sometimes trivialities which
> don't really have a large impact block the upload.
>
>
> > Even then the contributor waits two weeks
> > to make a fix which just takes 5 minutes at the most. Is he really
> interested
> > in packaging? If I were the reviewer I don't think I will want to spend
> my
> > time in reviewing things that will eventually just get thrown out of the
> > window.
>
> If I submitted a package, had to wait weeks to get it reviewed, then got
> a reply "please fix this triviality" I wasn't sure if I made it my first
> priority to come up with a fix.
>
>
> > By the way, how will lowering the required acks to one solve the above
> > example?
>
> If the reviewer feels empowered to make the decision right now and the
> contributor is responsible for incoming bugs, chances are higher to
> directly come to the beef of the packaging problems.
>
>
> > Should I ack a package that I know doesn't meet the required standards?
> I, for
> > one, will not want to see Universe become another automatix or
> deb-o-matic.
> > The right approach here (and this is quite often used) is to say: this
> is
> > wrong but I'm not blocking for this so that the contributor knows about
> it
> > (and a good contributor will upload a fix shortly after).
>
> Right, not-blocking-but-mentioning makes perfect sense.
>
>
> > Having gone very recently through this, yes, it adds frustration and is
> as
> > much a fault of the contributor as of the reviewer. By lowering the bar
> we
> > are not doing anyone a favour, just lowering the quality of the archive.
>
> I still believe that saying "one MOTU's decision is not enough" does not
> fix the problem and that there are better ways to get high quality
> packages into the archive and have responsive people fixing them as
> problems come up.


One of the reasons Open Source software *works* is because it employs the
scientific method. That process relies heavily on peer review. I don't think
we should remove that, discourage that, or ever consider it unimportant. If
everyone had unlimited time and resources, I would get every single one of
my packages reviewed. No, not because I don't think I'm not competent enough
to make the upload myself alone but because I consider peer review the
corner stone of our development model.

Maybe the issue here isn't a philosophical one but more of a technical one?
Maybe we should focus, as you suggested, on improving and innovating review
infrastructure?


>
>
> Have a nice day,
>  Daniel
>
> - --
> My 5 today: #210449 (network-manager-applet), #215043, #193764
> (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome-
> subtitles)
> Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIBfPSRjrlnQWd1esRAsC7AJ993DNk9MgkZHsRj6NUN7qaFROXhgCfXQic
> mLIOv2PDRll0NGBfnup+caI=
> =/vos
> -----END PGP SIGNATURE-----
>
> --
> Ubuntu-motu mailing list
> Ubuntu-motu@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
>



-- 
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112
Cell: 506-449-5899
Email: [EMAIL PROTECTED]
http://www.redcow.ca
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Reply via email to