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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
