[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Usage of Debian Structure Documentation, Social Contract etc

On Friday 27 February 2004 13.01, Zenaan Harkness wrote:
> To my personal mind, why would anyone choose anything other than Debian
> or Fedora (or Slackware or Gentoo for the masochists)?

I guess this was not the question at all.

Recent flamewars have shown again and again that there are people who won't 
work together - so this is one very good reason for software developers not 
to want to join Debian.

Technical decisions can be made in different ways - Debian often choses 
(rightly, IMHO, but taht's not the issue here) to be conservative (meaning: 
have a stable KDE 3.1 in testing and wait a bit before adopting KDE 3.2 etc., 
things like that). So thre's another bunch of reasons for wanting a community 
that is not Debian.

Then, of course, there's installed userbase. Until you have all the SME Server 
specific things (file locations, config tools, ...) available in Debian, why 
should a SME SErver admin not wish to continue to develop the distro he's 
used to?

Sure, reinventing the wheel (as you call it - Peter wants exactly to avoid 
that as far as he sees it is possible) wastes resources.  But unlike the 
corporate world, it could well be that the resources spent on SME server 
would *not* be spent at all for FOSS development if there was not a SME 
Server community forming now.

Peter: Iam not a Debian Developer myself,. but have chosen Debian because I 
have been annoyed too much by SuSE and RedHat. Now I stay with Debian because 
I like how things are done in Debian (well, most of the things). 

So I guess copying the Debian organisational model is certainly a possibility 
for you - and I guess you can read a bit in the recent flamewars on the 
debian-devel mailing list (and others) to learn what the main problems with 
the current Debian structure are. 

The complaints I remember hearing most frequently (I am *not* discussing if 
the complaints have some merits or not):
 - not transparent: some decisions are taken by some old-timers and not always 
communicated fast enough to the people affected.
 - long release cycles: I guess this is something that has its cause not only 
in the organisational structure, but also in the people that fill the roles. 
Most people relevant to the release process in Debian have stability as their 
top goal, and release schedules are unimportant to them. My guess is that 
when the same organisational model would be used, but with other people, the 
situation could be different.
 - package owners: most packages in Debian are owned by one person. When this 
person neglects the package, quality suffers. Group maintainership etc. are 
one possible solution to this.

Just my €.02

-- vbi
Windows: the ultimate triumph of marketing over technology.

Attachment: pgptKyGkutIht.pgp
Description: signature

Reply to: