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

Re: Unsupported Debian [was: Re: [New maintainer] Working for De



On 6 Aug 1999, Craig Brozefsky wrote:

> The pointer to Slink updates is in the release notes for Debian 2.1,
> as is the pointer to gnome packages for slink.

I couldn't find the pointer to gnome packages.

> The pointer to
> packages which may cause problems when upgrading to 2.2.X series
> kernels is also in the release notes for Slink.

I couldn't find that either.

> If this is not a suitable location, could you make a constructive
> suggestion?

I was thinking it would be nice to have notes on the Debian home page, not
a number of links deep. The security sources.list line could have been
added to /security/. A slink FAQ might have been nice.

That said, I still can't find most of that stuff in the release notes.
Oh...it's in the "Release Information" area. But not the release notes.
And I can't find the security source line anywhere; I don't even remember
where I first saw it.

> There is no royalty, there is a set of new-maintainer volounteers who
> attempt to verify the identity of new-maintainers and properly
> introduce them into the project.  They happen to be quite swamped at
> present.

I said I did understand how people get swamped or disinterested. What I
have trouble with is the fact that they haven't tried to *fix* the
problem, and instead have (secretly) set up their "swamped" state as
at least an informal policy.

> This purging which you call "proactive leadership" really won't work.
> For one, it means we need to draft policy detailing what
> responsibilities a Developer has and how failure to provide for those
> can result in dismissal from the project.

It doesn't need to be that drastic; I never intended to argue for kicking
people out of the whole project. However, more lax rules about NMUs
(perhaps only submitted by veteran developers, but allowable under more
circumstances), and more strict rules about what you have to do to keep
your packages under your control, might be useful. The fact is, people
lose interest over time. I don't know of any policies that account for
this effectively.

> I am not aware of any policy of the sort.  There was discussion of
> putting such a policy in place, but obviously discussion does not
> imply acceptance.  Could you give me a reference to this policy?  I
> have just looked at all the policy requests at:
> http://www.debian.org/Bugs/db/pa/ldebian-policy.html and did not find
> anything about this at all.

That's true. But new maintainers aren't happening. Perhaps this is one of
those things where a rumour or informal opinion takes a life on its own as
a policy statement. But...James Troup, in his post, didn't address the
issue in the thread, only whether he made his statements in IRC or not.

> It is open to the public.

Theoretically.

> Hmm, I'm wondering if we are operating with different understandings
> of the term bureaucracy, since none of the things you cite above imply
> my understanding of it.  They do detail some present shortcomings of
> the project, but could you please explain how you get "bureaurocracy"
> out of poor introductory documentation available on the website, and
> bitrot in some utilities?

It was pretty rambling, I admit. The lesson is never post when you're
about to go to bed.

What I was trying (lamely) to say is that there are a lot of effects that
can be traced to bureaucracy and a project that seems to not have as much
energy as it should.

>  How is attempting to maintain the identity
> and integrity of the project thru control of what packages are deemed
> "official" overly bureaucratic?  This is something that many projects
> do.

Sure. The issue isn't whether there is control, but how the control is
executed.

> On a personal level, a gut level, I understand your frustration, and
> have felt it many times myself.  I do not think that most of the
> complaints you have about the project are indications that it is
> becoming a gigantic bureaucracy.  That does not mean that your
> frustration is unfounded.  I think they are more like growing pains,
> were certain tasks are stretching thin our volounteer labor capacities
> at present.

Probably. Perhaps. I do wish the new-maintainer team would get other
people involved. Not even responding to applications, even with a
autoresponder script is, to be frank, impolite. Whether it's a volunteer
project or not, if they can't keep up, they can't live up to what they
agreed to do. As I said before, I can understand this, and I expect it to
happen often. I would like to see something done about it, though.

> Noone has done something like this before, technical coordination of
> several hundred volounteer developers to produce such a tightly
> integrated system of software from hundreds of sources.  Resources
> become scarce at times and things get bitrotted, people are left
> hanging, releases are postponed.  

Well, hey. I'd like to help. Seriously. But I can't right now, not in ways
that are meaningful for me. I don't use any of the orphaned packages, but
I do use packages that seem to be informally orphaned by neglect.

I switched to Debian because I hated poor quality. I've loved Debian's
setup and policies (with some exceptions) from the beginning, and I still
do, really. But to ignore the need for new blood and new energy is a huge
travesty, IMO. Typically, in the free software world, a minority of people
stay interested in a project for a long time but the majority lose
interest after a while (often when they graduate from university) and
simply stop paying attention. The only way to deal with that is to bring
in new people, give them the freedom to do what they want to do, and then
only put controls on them *if they screw up*.

In my ever-so-humble opinion, then, the new-maintainers "task" is one of
the most vital. It should not languish; the team should make it a top
priority that the turnaround time is kept short.

> Well, I'm off topic now, way off-topic.  I guess I was just trying to
> work thru why I felt some of the same frustration that you and others
> have been experiencing, and how I've tried to deal with it.  I hope it
> helps you at least a bit.

Part of what sets me off is seeing not enough communication. No
announcements that new-maintainers is stalled, policy or not. The guy I
was responding to wanted to keep pertinent information off the Debian
site. Some of the stuff you say is in the release notes, isn't (as far as
I can tell). The kicker for me is that nobody has responded to my
application with even a "sorry we're taking so long; there will be a
delay". I hate being in the dark, and you might say I've developed a moral
objection to keeping people in the dark without a really good
justification.

I don't think I'm focusing on genius as any kind of solution; I'm not that
inexperienced. I just want effective, realistic policy that compensates
for the fact that people naturally drift away over time.


Reply to: