On Friday 30 December 2005 3:12 am, skaller wrote: > On Thu, 2005-12-29 at 19:12 -0200, Guilherme de S. Pastore wrote: > > Even then, do you think you are ready to upload a package to the Debian > > archive? > > Mine, yes. I know more about it than anyone else, I know > what the issues are and have a sponsor to ask for help, I'm in a similar situation - upstream developer and packager, applying to be a DD. It's not uncommon but the process of sponsoring a package can reveal flaws that someone so close to the code as an upstream developer can miss. Generally, these are documentation ambiguities, hidden assumptions etc. My sponsor helped me fix things like this. The benefit is that changes go straight into the upstream. The downside is the workload of the sponsor. > Particularly if the uploads I made went to a repository > for such MUP packages, and needed a DD to move it on I use my own trivial apt repository for that purpose. I package locally, upload to a server of my own and my sponsor obtains the source and packaging information using apt. > -- at least > I would have more confidence everything was working when asking > for it to be moved on, and, feel less hassled about asking > for that to be done, since I'd have the lintian/autobuilder > output to verify it was clean -- at least as seen by > automated tools. Depends how much test code you can put into the distribution tarball. What suite of programs / exercises qualify as a sufficient and worthwhile test of the package functionality? Are those in the .orig.tar.gz ? Maybe document a test process or provide some sample data (or generate random data)? lintian and other general-purpose tools cannot always tell if the build completed successfully - there has to be some way of a human testing the binaries. > Right now, however, when I release an upstream tarball, > there is a whole bunch of work for the maintainer/DD to > do .. the set of files in the package may have changed, > the dependencies may have changed, the documentation > set may have changed. Can you carry those files in upstream CVS/svn ? Can any of the details be generated automatically by the build itself? Do the files in the package have to be listed explicitly or can you organise the installation directories so that each package brings in an entire directory? Just some ideas. YMMV. > > Would you trust Debian enough to install it on your machine and > > any other machine that may require any degree of trust if there were > > people with upload privileges that have not had their skills checked to > > a bare minimum? > > No. So where do you feel the bare minimum should be set? I wish there was a quicker way through the NM process and I hope to be able to help out once I'm a DD. If it was quicker (not easier) to complete the NM process, would you consider becoming a DD yourself? Becoming a DD is a catch-all - it allows you to package almost anything and the process has to rely on the DD making their own judgement about which packages s/he is capable of packaging. This makes the NM process possibly more wide-ranging than strictly necessary for an upstream developer. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpHLaRPW22G_.pgp
Description: PGP signature