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

Re: Debian Re-organization proposals (was: Re: so what?)

>>"David" == David Engel <david@ods.com> writes:

 David> I sincerely hope you are right that something [good] will come of it.
 David> I'm still skeptical.

	Then I hope your septicism is not catching. Skeptical despair
 never lead anywhere.

 David> Reread some of my earlier messages.  I firmly believe that a
 David> lack of strong leadership has been one of the biggest
 David> contributing factors in Debian's inability to put out timely
 David> releases.

	I think that placing the blame on the leadership is a) non
 productive, and b) the easy way to duck blame. The Debian project is
 too big for one person. We need now a formalized method for
 initiating changes; and that we are getting, once we ratify the

	The formal SPR's are also a good way of documenting proposals,
 I think that we should archive formal SPR's, and all the amendments
 accepted, etc, so we do not ``forget'' the lofty goals in a few

	You are talking about the growing pains of a project that has
 gone beyond the old boys club, and can no longer operate in an ad hoc

 David> Any endeavor to put out timely releases is doomed to fail
 David> unless it has the full support of the project leader, who must
 David> be willing to step in and take action to keep things on course
 David> when they start to drift.

	In my opinion, this is thinking in the mold of the old ways,
 when a godly central project leader made or broke the project. Read
 teh constitution. We need to go beyond the dependency on one
 individual. We have the talent to discover a process, a business
 model, so to say, that enables us to put forth releases on a more
 frequent time table.

	Complaining about past slippages and asking Ian to weigh in
 with the bull whip shall lead no where. 

 David> I think we are getting way ahead of ourselves here.  The idea
 David> expressed above is an implementation strategy.  I would much rather
 David> see us start with a discussion on goals for the next release.

	I am interested in something way more fundamental to the
 project than the mere next release. Unless we thing beyond the next
 quarter, and if we fail to make more or less radical changes, we are
 doomed to repeat the pattern of past releases.

	I am interested in hammering out a methodology, a set of
 policies and practicves, that make all that possible. 

	Vision, people, just tightening up the belts and telling
 volunteers to put in longer hours is doomed to failure.

 David> Examples of the goals I think should be considered, include but is
 David> certainly not limited to the following:

 David> 	Whether or not to adopt apt.

	This depends on whether apt is ready. This underlines one of
 the flaws of the current model: packages and software under
 development have their own schedule, which rarely syncs with the
 schedule of the releases.

 David> 	Whether or not to conform to FHS.

	This need to be discussed. Certain parts of the FHS are less
 than satisfactory to people, and we may only partially conform to the

 David> 	Whether or not to adopt linuxconf.
 David> 	Choosing a target date for the release.

 David> Only after we have reached a consensus on goals, should the discussion
 David> move on to implementation strategies.

	As I said above, I think we should do precisely the reverse.

 Without a thorough understanding of tactics, there can be no
 effective strategy; therefore, any general must have a good
 foundation in the tactical aspects of warfare.  However, it is not
 necessary for a general to be an excellent swordsman, musketeer, or
 tank gunner.  It is sufficient to understand the strengths,
 weaknesses, and proper use of the forces available, and to know the
 strengths and weaknesses of your enemy. Phillip Harbison
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: