Re: potato late, goals for woody (IMHO)
On Thu, 4 May 2000, John Galt wrote:
>
> Needless to say, I realized that there >is< an issue that I hadn't
> explored in my idea: I had forgotten that I was dealing with an
> organization that has done it's damnedest to ensure that no volunteers
> were available to work this. Given that the reason that new-maintainers
> was open to flux was this minor issue, I do regret that I hadn't thought
> it all the way through.
I guess I can take this as a positive statement of support ;-)
>
> On Thu, 4 May 2000, Dale Scheetz wrote:
> >
> > Gag me with a spoon!!!
> >
> > Elegant? Hmm, I don't think that word means what you think it means...
>
> IAW Lord Ockham's razor...
>
> > Aside from creating a worker/slave class dichotomy, your idea of elegance
> > leaves me with a great deal of intestinal discomfort.
>
> ...as opposed to now, which is a first class citizen/no class citizen
> relationship based on when they got "into" Debian? Those that DID find a
I beg your pardon? Where did this come from? If you are a member of Debian
your role is specified in the constitution. There is no two tiered system.
> way around the flying fickle finger of fate that Debian thrust at them
> to become a maintainer in potato were in a relationship far worse than
> worker/slave. Given the alternative, I'm sure that being told to fix bugs
> in return for official recognition would've been considered a blessing.
As the one person who, it might be argued, is most responsible for the
restart of the new maintainer process, I have recent first hand knowledge
of what is acceptable in that process. This kind of requirement was
explicitly rejected.
Requiring specific behavior from an applicant is not done. Instead a range
of possible contributing tasks are offered. The acceptability of the
applicant is enhanced by adequate completion of some task from the
provided list.
The reason for this is that we did _not_ want to create a "pre-payment"
method where applicants would be required to contribute specific energy to
the group before we would accept them. This _is_ a slavery concept.
>
> > You know, if more people were actually working on a release instead of
> > talking about how to make the release mechanism better we would probably
> > release more often ;-)
>
> I've already been over this once a couple of months ago. DON'T *DARE* TO
> COMPLAIN ABOUT LACK OF MANPOWER!!!!!! New-maintainer was closed through
This was _not_ a request for more manpower. It was a deluded attempt to
redirect the energies of the manpower we currently have available, to the
task we are supposed to be working on!
> the entire development cycle of Potato. If manpower really was an issue,
> then logically there wouldn't have been an impassible barrier to
> recruitment, now would there?
I need to make two points here:
1. The new-maintainer process is still in testing, but even so, we are
currently in the process of accepting 50 applicants. Many of those
have completed the application process and are awaiting account
assignment.
There has never been an "impassable barrier" only an unavoidable
delay.
2. Your implication that there was an intentional rejection of the "non
member community" by Debian in the shutdown of NM is a slap in the
face to all those members who objected to the shutdown and have
worked very hard to get the process back on track.
So, let's talk about the manpower issue for a moment.
When I first joined Debian there were about 75 to 100 people working on
the project, delivering 200 to 300 packages. Today we have around 400
developers delivering around 2000 packages.
Over the time I have been here the population of developers has increased
by a factor of 4, but the package to maintainer ratio has gone from 3 to 1
up to 5 to 1 today. The applicants I am dealing with in the testing phase
of the new new-maintainer process are bringing their own work with them,
at least as much as they are taking over the packages of others who can no
longer deal with the workload, so I don't see the trend changing. Because
Debian is fundamentally about Freedom, we cannot reject applicants or
require that they not maintain the package that they choose because we
want to manage the workload. Debian just doesn't work that way. (I give as
a good example, the data section, which I _do_ think is a good idea.)
In addition, we have grown in the "government" department. We now elect
our leader, vote on process, and have broken up into several "working
groups" (committees) to deal with specific non-technical issues like
policy, legal questions, project philosophy, and those other things that
need doing like system administration, new maintainer, QA, Testing, etc...
All of these tasks take time (at least for me) away from development
tasks, slowing the process of producing a release (our principle goal).
Having bitched about this state of affairs, I have to admit that all of
these things are necessary, given the size and scope of the Debian project
today, and we are just going to have to pretend to be adults and learn to
live with it. I also understand that this process will eventually arrive
at the point of diminishing returns. Once past that point, none of our
"controls" will be effective, and the only alternative to heat death will
be a catastrophic rebirth. Our only hope is that we run out of software
before we run out of potential developers. Only under those circumstances
can this group stabalize its efforts. (I'm not a prophet, just a
generalist. Only time can judge my assessment.)
>
> > Don't get me wrong, I am not opposed to idea discussions, but this is just
> > not very well thought out. Aside from the fact that it would probably
> > triple the archives size, it creates, from scratch, a completely new
> > development effort with all the communications and design problems that
> > entails. Under structured conditions where bosses can insist on the
> > behavior of underlings, you might pull this off, but certainly not in the
> > asynchronous environment of Debian. There is a slim chance we could come up
> > with enough volunteers if we restricted our efforts in this regard to
> > only Standard and above packages. This would probably require that we have
> > at least 50 volunteers to manage the 200+ packages in Standard. As a
> > comparison, take the new maintainer process, which created the loudest
> > outcry for change, and produced slightly less than 30 volunteers, several
> > of whom have found themselves unable to contribute due to other
> > constraints. So, unless you get a rousing ground swell of support, this
> > scale of project is just not executable in this environment.
>
> Actually, it'll only incerease the archive size by half again in
You have failed to consider the simlink situation, which will not be
usable across this many layers. Dropping the links to stable, when a
freeze happens pulses the size of the archives. Your scheme would have
this happening at a fairly constant rate, and across yet another archives
class.
> the worst case--Debian is already split into unstable and stable at all
> times, and a third set of packages would only be an issue during what is
> now a non-freeze time, which would have another set of packages almost
> exactly the size of either stable or unstable. As far as the minor issue
> of people, I'm kind of guessing that a rousing swell of support is kind of
> out of the question in this case, considering what Debian has done with
> said support in the past. As for creating a new design effort, that's
> because the present method isn't getting the job done. This thread
This depends upon which job you are trying to do. Debian's "job" is
superior integration of free software, not timely release schedules. (This
should be historically obvious ;-)
Nobody pays us to do it this way. We do it this way because we can't seem
to do it any other way.
Arguing that more manpower will "fix" the problem, or that a better
structure to the archives will speed the process, misses the point.
The number of packages have doubled with each release for as long as I've
been a member. We all know how long that can go on.
The integration problem gets about 4 times as difficult each time you
double the number of packages, but if we keep the developer pool
increasing at the same rate we can reduce this to being proportional to
the growth. Even then, at some point the integration problem becomes
unsolvable in reasonable times.
> didn't just spontaneously generate out of thin air. So either create a
> new effort or get the present effort working. Yes, it's going to take a
> lot of people, and no, I doubt they'll be breaking down the doors to
> become developers now--they've been told to go to hell once, why should
> they try again?
As before, I object to this argumentative assessment of the NM shutdown.
The people appointed to do that job had/have valid concerns about the
usefulness of increasing our numbers. The fact that such actions make
Debian a closed shop is the primary reason such actions are unacceptable
to the group in general and resulted in a ground swell of objection to the
closure. All was not simple rejection either, and this allowed me to get
the process back on track by harnessing the energies of these objectors.
I have received many requests from the "rejected" applicants of the past,
and none of them have indicated that they thought they were told "to go to
hell". Their only concern is when the process will open up and let them
in.
>
> > Bottom line: We have never made an enforced assignment to any developer.
> > We have never said, "You must do work of this type, before you can do
> > other work."
>
> No, for the entire development cycle of potato, it was "don't call us,
> we'll call you".
>
> > If you think you can implement such a practice, I have only one word for
> > you: deluded ;-)
>
> If you think that the system now in place beats my idea, I guess I can
> wait in line for the title. (backatcha)
>
John, I know that you are not a developer. That doesn't matter to me. I
have always taken the time to read your comments on the list because, for
the most part, your thoughts are constructive and useful.
These last two paragraphs of yours are such inaccurate characterization of
the situation that I feel you have cheated me of the superior judgment I
have come to expect from you.
The first paragraph is just not true. When new maintainer closed, sponsors
sprang to the rescue, providing an avenue for outsiders to work on the
project. "entire development cycle of potato"? Give me a break.
In your second paragraph, I can only assume you mean by "the system
now" that a closed new-maintainer doesn't work and that I am somehow in
tune with that attitude. (or are we back to the release cycle? If so, I
have no solution to the release cycle that doesn't include reducing the
number of packages in the distribution.)
This completely ignores the last three months of hard work by myself and a
team of 25 volunteers to correct the problem. (or, if we are back to the
release cycle, you ignore the work of 400 developers desperate to come to
closure on this release)
If, instead, you are using the "the system now" label to include all the
current advances in the new-maintainer process, then you are suggesting
that all our hard work is for naught, and we should just pack up our balls
and go home. I can only assume that you don't mean to imply this, or I
would be forced to start throwing sharp objects in your direction ;-)
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: