This mail is some major rant. I've already ranted in private and was
asked several times to move this to debian-devel. I've added some
more problems I have detected. Most of the following was discussed
either with a bunch of developers and keen people at the Linux
Kongress.
We currently lack:
. Release plans
There are only fuzzy plans on what will be released as next Debian
release. There are some people who are trying to give slink an
update while the majority believes that potat will be 2.2.
It is still not clear what will be 2.2 and what will happen if
there should be an updated slink called 2.2. Our project leader is
affected, though.
Some ideas against an updated slink in favour of potato being 2.2:
- Confusion as something different than stable, frozen, unstable
will be relelased as stable
- No defined procedure about what will go in and what not
- If an updated slink would be released as 2.2 we must not release
potato within the next four months since a stable release needs
to live for a while (also to justify the name, stable).
- An updated slink will automatically postpone potato and decrease
the importance to work on problems with potato.
- General change in the way how debian works, without letting the
developers vote about it.
- Ignore potato in favour of something else will keep potato
unreleaseable.
. Release goals
Officially "we" have decided that we don't want to have release
goals anymore. Now there were rumors that all packages will have
to be converted to be FHS complient for potato. There still was no
public announcement.
As a maintainer for several packages, I'm still confused what to do.
. Policy changes
It is unclear how policy changes affect packages. The changelog
within debian-policy*.deb is (imho) not detailed enough to tell Joe
Clueless Maintainer what he needs to change in his package other
than s/2\.4\.0\.0/3.0.0.0/ in debian/control to create a package
complient with the current policy.
It's even unclear which policy packages have to support for potato.
It's also unclear what will happen to packages that are not policy
complient.
. Boot-Floppies
It's not clear if/who is working on boot-floppies and into which
direction we're going. Obviously there is nobody working on it
speaking of a general direction, and nobody's about fixing all
those darn bugs. Even worse the current boot-floppies are not even
compilable or will work on potato if they would be.
. Release cycles
"We" decided that there will be two releases within a year. (One in
spring and one in autumn.) Well, speaking of potato this goal
can't be met anymore. Although it's been said that there will be a
freeze on November 1st several developers believe that this date is
rediculous and impossible to be met.
At the current state we won't even have proper boot-floppies. I
don't have to say how much that sucks.
. Stable subreleases
It seems that only very few people care about our stable release.
Out of the security team only one person spent brain on it, the
ftpmasters only worked on unstable, the new Stable Release Manager
worked on something between stable and unstable by forgetting about
the stable release. Even though there were common opinions that
only security updates are going into stable, there were tons of
packages uploaded for it.
. Configuration Management
We have ben acknowledged that we need to reduce pre/postinst
interactions and some proposals have been made that are known as
"Configuration Management". pre/postinst questions will interact
with a database that is able to contain preconfiguration so cluster
installations are easier.
We have to face the truth, doing a cluster installation, debian is
one of the most difficult distributions. Maintaining a cluster,
though, it would benefit of Debian.
. Buggy packages
Even though there are quite a lot registrated developers (~550 by
counting logins) there are over 4000 packages with outstanding
bugs. Even though many packages don't seem to be maintained
anymore it is still quite difficult to take over them or to rip
them off of the distribution.
There are also only very few (four) people working on general
bugfixing. It's still the case that (too) many people are working
on their tiny little packages but miss general tasks while even
"old" people are not managing the distribution - as one would have
expected.
. New maintainers
There are a lot of people wanting to become maintainers of some new
(often little) packages, often also without a clue. Packages are
buggy, partially not well maintained, also for packages taken
over. Just adding them to the list of people who are allowed to
upload into the main archive will just increase the distribution in
size, not in quality. [No new-maintainer bashing please!]
I have to acknowledge that Debian has reached the point where it has
grown too much and cannot continue as before. At the moment we
already have chaos all over with no proper leadership. The next
release is months away, boot-floppies are not working, several goals
are only slowly getting passed, still it is the bazaar of little
cathedrals.
Most developers are only working on their tiny five packages or are
even entirely inactive nowadays. Only very few people are taking care
of general management tasks. Remember this is an association of >500
people. There is still no proper management. Guess what would have
happened if it were a company...
I believe that this "strategy" will lead Debian into death if we
continue as before. Therefore things have to change. Since I'm not a
manager either I can't come up proper ideas all the time, and since my
time is limited I cannot force people to do the right thing.
Processing mail already takes much more time than working on software.
Regards,
Joey
--
The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin
Please always Cc to me when replying to me on the lists.
Attachment:
pgp471bJLxtDC.pgp
Description: PGP signature