Re: Proposal for collaborative maintenance of packages
On Fri, 2005-12-30 at 05:17 +0000, Neil Williams wrote:
> I'm in a similar situation - upstream developer and packager, applying to be a
> DD.
Unfortunately becoming a DD isn't an option for me personally,
at least at the moment.
It rightly requires more commitment to package building than
I'm willing to make -- which is why I'm seeking a viable lesser role,
but still one that is more than 'uncaring upstream developer'.
> 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.
Absolutely. And not all those flaws are in the packaging either.
Some will be in the upstream software itself.
Mine has heaps! And the DD will never find them. Neither
will I: actual users will though, and pretty fast in my
experience.
> 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.
Yes. I agree fully.
> > 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.
For me there are two issues with that:
(a) it doesn't autobuild on all platforms
(b) I can't install it anyhow due to gratuitous differences
between Ubuntu (which my current box uses) and Debian.
I would love to see at least (a) solved -- it seems technically
possible to have a place to put things and have them autobuilt
to check for hidden assumptions. Many of these in my case turn
out not to be platform dependencies .. but gcc compiler issues.
[I will be solving (b) down the track with more hardware ..]
> Depends how much test code you can put into the distribution tarball.
There are something like 400 test steps, around 160 test cases,
and they're run 4 times with different options.
The testing takes longer than the build.
And the tests are grossly inadequate ;(
[My friend just told me the full build takes 15 minutes
on a high performance dual core 64 bit G5 .. its about
5 minutes on amd64 I think]
> What
> suite of programs / exercises qualify as a sufficient and worthwhile test of
> the package functionality?
All are worthwhile .. none are ever sufficient.
Testing is the worst kind of quality assurance, the last
resort. Unfortunately it is necessary.
> Are those in the .orig.tar.gz ? Maybe document a
> test process or provide some sample data (or generate random data)?
The tests are built in, and they're executed by the make
script as part of my quality assurance policy: they help
build confidence in both the software and documentation
(I use literate programming .. the tutorial is the main
regression test .. which helps assure that the documentation
is correct, not just the software).
> 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.
Certainly, and some DD's looking at it too.
> > 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?
Oh sure! The whole of the Debian packaging used to be generated
by the build process itself. In fact the scripts that did this
remain part of the tarball.
And that is part of the problem .. Debian cannot handle it.
In effect it is a Native package. It cannot be 'patched' because
the patches would go in the tarball itself .. and constitute a
complete new version. That's cool for a Native package .. but
the package is not a Debian tool so should not be built as
a native package.
My DD prefers to maintain the packaging himself separately:
I am sure this suits his personal workflow better, since he's
part of a team that manages many other packages, and there
are good arguments it should be that way.
However there is no Policy for 'Semi Native' debian packages,
so there are no guidelines as to what I can do to help him.
I'm guessing other upstream authors with an interest in Debian
packaging would find such guidelines useful if they existed,
but I have no real idea what they should say.
> > > 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 am not qualified to answer that BUT I can and have made some
suggestions: entry level ability to upload a particular package
could be granted by two DDs to the upstream developer or
dedicated non-DD maintainer of a particular package.
They would have more authority than 'none' but much less
than a DD. Exactly how much of what I don't know: enough
to actually put the package in place and trigger an autobuild,
not enough to push the packaging into a place it might end up
in the stable distro.
Such a role could also be a useful stepping stone for those
wishing to become DDs .. and even help train an encourage
people not initially wishing to do that to follow that path.
> If it was quicker (not easier) to complete the NM process, would you consider
> becoming a DD yourself?
I don't think so. I do not really know enough about Debian
to become a DD. My personal focus is on programming languages
and software development, not packaging or distro building.
But I would be happy to do more of the work in areas I care
about, and not just for my own package.
> Becoming a DD is a catch-all -
Yup. The DD needs to be a generalist as well as probably
specialising in some packaging niche.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: