Before I reply to your message, Michael, let me briefly let people know why I'm involved :-) I've been a Debian developer since 1995 or so, and someone recently posted to our developer's list information about this thread, and I would like to try to offer a bit of insight on what Debian has done right, what Debian has done wrong, and perhaps explore some areas Debian can work together with the Mandrake community in the future. As a big disclaimer, I know little about the Mandrake community, its size, etc. So some comments may be based on wildly wrong assumptions :-)
Michael Scherer <[EMAIL PROTECTED]> writes: >> > >> >I dunno. How does debian do it? >> >> I beleive a maintainer per package. See: > > Well, we could try something like morethan one developper per package. > Actually, in Debian, only the packager can change something. Debian's organization is laid out in a "bottom-up" fashion, and is described at http://www.debian.org/intro/organization. It is correct to say that each package has a primary maintainer. This is the person that is generally responsible for integration, fixing bugs, upgrading, etc. that particular package. We do have procedures for others to make changes, in the case of maintainer inactivity, urgent security matters, etc. We also have a lot of special-interest groups. Each Debian port has one. There are groups for translations into various languages, for special projects like "Debian for kids" and the desktop enhancement project, etc. For the most part, these groups work with maintainers, sending patches to the official maintainers for new features. Sometimes they develop new code from scratch or maintain packages as a group. The formal organization is based on the Debian Constitution, http://www.debian.org/devel/constitution. These procedures are not the sort of thing that Debian developers think about on a daily basis, but form the ways for us to appoint a Project Leader and certain other positions. The Leader does not have any direct authority over developers, but is more a organizational person to help move along committeess and advance new policies. We have had some growing pains as both the amount of software in Debian and the number of developers has grown significantly each year. Some things work well with a project having 300 developers but fail miserably when you hit 600. In particular, we have problems with developers that become nonresponsive for large periods of time, and we don't yet have good procedures to deal with that. >> I also like their "package adoption" system: >> http://www.debian.org/devel/wnpp/ > > Package adoption is great, but, to orphan a package is not really seen as a > good thing by others developpers. Very true. Debian uses this for two purposes: 1. A developer is still maintaining a package, but wants to stop 2. A developer has stopped maintaining the package and wants to let others know about it. > What about doing it the same way than Netbsd and FreeBSD. > Debian is ported on a lot of processor, we can focus on a smaller subset. > They have goals for each release in term of version of software, we can have > more frequent releases, based on time. I'm not sure what the difference is here. Debian's release schedule is, according to everyone, too long. No quibbles there. It's nominally based on time, too.
