-----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. 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
