Re: Proposal for collaborative maintenance of packages
On Thu, 2005-12-29 at 09:28 -0800, Richard A. Hecker wrote:
> skaller wrote:
> >I can suggest whole heap of things that would improve
> >the situation .. but I can't choose which ones to
> >implement. All I can do is ask .. please do SOMETHING
> >to streamline the process a bit more and to make it
> >a bit easier for more people to get involved.
> These things take time.
Indeed. However change must start with awareness.
> Next
> time you feel unappreciated, look at some of the horror stories told about
> the NM process and all the hoops we make them jump through.
Lol! I'm not asking for appreciation. I think I'm suggesting that
there really is a problem with the *process* and it needs to be
changed. Change hurts. That's the negative bit. The positive
bit is that I believe there are a LOT of people that would like
to help that feel they can't. So a small change which makes it
a bit easier for those people (including me) to contribute will
go a long way to speeding up the process.
As the title suggests .. collaboration with Ubuntu maintainers
is an obvious candidate for consideration. However that's
an 'institutional level change' and I'm urging Debian people
not to ignore the 'grass roots' -- both the users of the packages
and the developers are eager to contribute "if only there was
some kind of lower level role in the process."
Of course there is: people can submit bug reports, for example.
> We may even reach a point where the
> typical upstream developer can contribute their expertise in a transparent
> manner.
Hehe .. that's really optimistic. I'd settle for something that
was a bit lighter than being a DD.
> We are always looking for the "trusted collaborators" that Manoj
> referred to. If we can improve the system and streamline things to benefit
> them and us, we will gladly do so.
Surely, but first there must be an idea of what the problems are
and what could be done. And in my opinion the DD's have far too
much 'paper work' to do, and their talents are not well deployed.
My package is only one example -- I also monitor a special subgroup
in which I have an interest, and which has uncovered a weakness
in the process -- the need to upload packages just to trigger
the autobuilder into rebuilding .. even when the sources have
not changed (tool change). I'm watching them do a whole lot of
pointless work because the dependency checking system isn't
working right.
A related problem recently caused a major hassle with gcc/g++
ABI changes.. (it was a disaster for me .. I had to reinstall
the OS 3 times after stupidly creaming it trying to upgrade
prematurely .. :)
A lot of people worked to solve that problem .. but did anyone
actually sit down and ask why it happened?? It's clearly a serious
problem with the dependency management system. Roughly it seems
to be that the package name/library .so names reflect the source
version but fail to incorporate the version of the build tool,
so when the build tool changed ABI the resulting binary was
indistinguishable from one it conflicted with. It's clear
the naming convention/meta data for packages was inadequate.
Maybe gcc isn't going to change ABI again for a while so
you're not worried .. but the other tool I use changes
ABI with every single patch.
> I obviously can only speak from my own experience. But based upon that
> experience and my interactions with other DDs, this summation makes sense.
> Bear with us in this effort and I hope your patience does not wear too thin.
>
> Richard
>
>
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: