Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes: > There is no strict policy on this, but if the packages are not one of the > base (important, essential) packages or of the tool chain (gcc, gdb), it's > okay to upload those. Well there's Debian Developer's Reference section 8.2, which says that it's okay to do binary NMUs (no change whatsoever to the source) right away (no asking, no waiting). That's what autobuilders are doing. > Please test if at least the basic functionality is > there, and the installation works at least on your system (it can be useful > to upload even if a force-depends is necessary, or other small bugs are > there). New versions may involuntarily break/undo some Hurd fix that was in the old version. Uploading a broken package will of course hurt Hurd herders, but ultimately I don't think the builder should be held responsible -- IMHO it's OK for such bugs to go to the maintainer, whom we should help of course. > > What if changes to the source code are required? > > [...], and even doing NMUs is a lot of work, and costs time spread > over several days, which is difficult to organize in most peoples > life. Hmm, I've not done a porter NMU yet, but I imagine it as follows: Day D: Try to compile package P, notice it does not work, fix it, test it, produce a patch, report to BTS noting that you intend to NMU. Day D+n: Do a source NMU. (n >= 7 for non-critical issues) Time cost on D varies greatly of course, but time cost on D+n should be about 10 minutes (and you can always postpone by increasing n at your leisure). The only real problem arises, if the maintainer releases a new version between D and D+n *without* your fix. That raises your amount of work. -- Robbe
Attachment:
signature.ng
Description: PGP signature