Daniel Holbach wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello everybody, > > after a recent discussion about a perceived disconnect between "main > processes" and "universe processes", I thought a bit about the process > for NEW Packages.
Well, just to be clear, there is no disconnect between Main and Universe when it comes to NEW packages because there is only one "policy". Packages go through Universe to get to Main. There is no Main NEW processes (unless you count MIR but I don't think we want to go there). > Historically it was introduced to make sure that new packages are of > tip-top quality when they enter the archive. We started with 3 necessary > ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get > an ACK from other MOTUs. I feel we've been very successful with the work > we've put into Universe and the quality of new packages. Entirely too successful, IMO. Around 1/3 of all Universe Ubuntu packages (ubuntu versioned) are not in Debian which means MOTU is the sole maintainer. Even if we say 10% are Ubuntu-specific that leaves something around 700 packages we have to maintain by ourselves or probably at least 10 packages/MOTU. This is pretty much nuts if you ask me. But that's another discussion so I won't go any further with that. > I propose the following changes: > 1) cut down the requirement to one ACK of a ubuntu-dev member Which will honestly get you many fewer reviews and many more rejections from the archive admins. > 2) requirement for the person who packaged the new software to become > bug contact Seems reasonable, though not really enforceable. Definitely a "best practice" sort of thing. > These changes would have a number of benefits: > - it would cut down the review overhead and the time of waiting Well, yes and no. There is certainly waiting time involved with having to get 2 acks, however I think having 2 MOTUs going sort of working as a team to tackle a package can be pretty darn quick and gives you a much better package. > - instead of a high entry barrier, have a higher emphasis on fixing > problems of packages in Universe Well, to be honest, I consider what we do on REVU to be the *minimum* barrier. I agree that we really need to emphasis fixing problems in packages *already* in the archive. For instance, how are those 700+ packages from REVU that we already are maintaining on our own doing? > - higher similarity between NEW Packages process and Sponsoring process I'm afraid I don't get that. Really if you're going by similarity the only thing you *want* to be different is the number of acks because that is reflecting there much greater review it takes to introduce a NEW package versus a typo fix or something. I think contributors find the complete disconnect in tools used (REVU vs. u-u-s) to be much more confusing that needing 1 ack vs. 2. > - accredit technical skills of approved ubuntu-dev members and don't > require re-review I don't think it's really about not trusting or crediting the technical skills of other MOTUS. My thinking goes like this, I don't really trust myself to be able to properly review any package that's on REVU. I often miss things and there is *so* much to look at. OK, I know this is a long email already but I had a couple thoughts on the larger issue of getting REVU running better: 1) can we pair the 2 MOTUs doing the reviews? What I mean is I would go on review and "sign" up for packages I'm interested in reviewing. Once there are two MOTUs signed up they work together as a team to get that package ready to go. This would eliminate a lot of the waiting I would think. 2) to do the above we need to triage REVU so that packages are in a state where they're most likely not going to be flat-out rejected before 2 MOTUs devote time to them. If we made sure that lintian wouldn't give spurious warnings would it be unreasonable to ask that packages be lintian clean before MOTUs would look at them? Perhaps this is a perfect task for the Ubuntu Apprentices (or whatever we're gonna call them). 3) Perhaps it wouldn't hurt to also ask the question, "Why should we have this software in Universe?". People tend to package up either "latest crack" or "dead, unmaintained, and useful to all of 10 people in the entire world". I don't think we need to get nit-picky, but I firmly believe that every packager should be able to give some reason why we should ship a package other than "dunno, something to do". It gives people motivation to move on the maintaining the package. enough from me already, -Jordan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
