Re: Debian Re-organization proposals (was: Re: so what?)
Hi,
>>"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
constitution.
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
months.
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
fashion.
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
FHS.
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.
manoj
--
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
(alvitar@xavax.com)
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: