I'm no MOTU and just speak from a newbie uploader's perspective. Daniel Holbach wrote : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stefan Potyra schrieb: >> One argument against it raised in the past is, that this might lead to fewer >> people reviewing a package (or giving an ACK for a package), as they might >> be >> unsure about it. > > Maybe the right fix for this the situation is to establish an easy way to > - solicit feedback about a packaging situation one is unsure about > - document the "best way to solve problem X" either in > https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews or > https://wiki.ubuntu.com/PackagingGuide > > I can see a number of additional benefits in this solution.
I'm no MOTU or REVU expert, so I might be completely OT (if so, just disregard my comment) but from what I've understood from scarce contacts with uploading a new package and uploading one packaging patch in Launchpad, there's a few questions/suggestions : 1. Is it possible to review what are the most frequent packaging errors, and how much of these can be picked up by a few scripts? IMHO, most new contributors would omit debian/copyright, or tend to indicate the wrong Ubuntu version (i.e. the stable release instead of the development one, since at first you're not going to know about SRU policy), leave the Debian one, forget to fill some fields in debian/control, include binaries, etc... Could it be possible to automate most of these checks and others, so each uploader would get feedback on the first screening errors ( a process which, at the moment, can take 2+ weeks)? The system could point to the relevant parts of the documentation (hypertext links or extracts) for each problem, and provide information on how to receive human interaction if necessary - irc, mailing list or, better, a packaging forum since Windows users aren't used to irc and mailing lists). In short, a kind of lintian for common mortals, but server-side. Result : the packager gets immediate input, and reviewers know that they're only reviewing pre-screened packages which should already build and meet a few basic standards. How costly would it be for the server to try and test building each upload - getting the tarball, applying the patches, trying to build the package, and even trying to run it?) The system could even replace all Debian versions or wrong Ubuntu versions in debian/control by the development one, and see if it still builds/run. 2. When the new package is uploaded, the uploader's email could be added as a bug contact, while all reviewing comments (including the automated screening results) are forwarded to its email address, ensuring nobody loses touch with their package unless they'd really have no interest in it (which I assume isn't the case in the first place). I can imagine lots of people disappear after having uploaded a package because they just stopped checking everyday for feedback after 2 weeks or so. Having an email appear in your letterbox even when you'd long forgotten you ever uploaded a package could solve that problem (who in their right mind would force themselves spending 10 min a day on that when there's no indication you'll ever receive an answer before upstream releases a new version, forcing you to restart the counters - 2+ weeks wait before any new review). After 2 weeks, either you imagine nobody's going to review your package, or - at best - you imagine there's always going to be a 2+ weeks delay at each step of the process. Having automated screening/answering could save a lot of unproductive time from MOTU. It would be a guaranty that they'll never be spending time on a package whose uploader might disappear, since they'd known the uploader was willing to fix the first packaging errors and has already learnt a bit in the process. First-time uploaders don't have a break between the upload and the fixes, so their interest is keen. A 2 weeks wait also does a lot of harm in any learning process (ask any teacher) since you'll have forgotten most of what you already had to learn in order to build your first package - that means losing a few days again just to get to the level you were when you uploaded the package in the first place, then learning new information to fix your errors. Having an email process also ensures no uploaders forget their uploads, while Help - and explanations on how to get it - is available to the uploader. That's a long email for what is just my two cents. Loïc -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
