Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 06:08:41PM +0200, Martin Michlmayr - Debian Project Leader wrote:
> I think you have to go back and read mine
> (http://www.debian.org/vote/2004/platforms/tbm), specifically the
> section about "Internal - Core Teams, Delegates, Communication,
> Transparency". Everyone in this thread who have asked me as DPL to
> add new members to existing teams or replace existing delegates
> completely should read and think about this section. As DPL, I'll do
> my best to make sure that a role is performed by members who have
> enough time, competence and can communicate. However, I can only work
> with the resources which are available. If there are no suitable
> volunteers, there is not much I can do.
Then please define what a volunteer should fulfill to be suitable. There was
already the request for a job description...
> I've been trying since I've been DPL to find more members for the
> overworked security team, and I've been looking for members for other
> teams (such as listmaster) too.
Interesting. Not that I would apply for those jobs, but I never saw a job
offer for those...
> However, it turned out to be very
> hard to actually find volunteers who're interested, have enough time,
> are competent or actually get any work done. What I found instead is
> that a large number of people are only interested in their own
> packages. If people were interested in all of Debian, we surely would
> have less RC bugs and more people attending BSPs, right? We need more
Funny... I have no packages at all and forced to turn away from Debian.
> people who are truly interested in helping with a variety of tasks,
> and not just people who complain but who're not willing to help fix
> the situation.
To say it with a german saying: "Haha... koennen vor lachen!"
> As an example, there were many people complaining
> about the speed of the NM process but very few people actually
> volunteered to help out. And some of those who actually volunteered
> found out when processing their first applicant that they don't have
> the time or interest and stopped, leaving me with the mess to clean
> up...
>
> Anyway, back to the problem at hand. Without good, capable
> volunteers, nothing can be done. In some cases (e.g. security), help
Surely. Willing volunteers are quite often discouraged. No wonder that other
people don't want to jump in.
> has been requested several times and nothing happened. In other cases,
> it has to be made more explicit what is needed and how people can help
> (I've some information from the listmasters I intend to circulate
> soon). In any case, we need people who actually volunteer and who
> approach the problem the right way. I've seen quite a few offers left
Define the "right way".
> unanswered because they were made in a suboptimal way. As I argued in
Erm, interesting... It's always been said that Debian is no company but a
collective effort by volunteers, but this sounds now as if you want a
professional job application?
> my platform, adding members to an existing team has to be done the
> right way. Just popping up without actually having done anything for
> that team before or knowing any of the members is usually a bad idea.
>
> In some cases, there is not much someone who's not a member of a team
> can do; but in the majority of the cases, people can contribute a lot.
> For example, if you want to help the ftpmaster team, one way would be
> to help with katie, the archive software tools. There is a long TODO
There's one problem: main developer of katie and other tools seem to be Mr.
Troup. Well, because he seems to be somewhat picky in regards with whom he
communicates, that will surely evolve as a problem. Might scare off some
people as well.
> list and nothing stops people from sending in patches.
... and wonder why your patches won't get included and you never receive a
mail why it was rejected....
> This would
> show the ftpmaster team that you're interested in this task, actually
> understand the software involved and can contribute, and it would be a
> first step of contact. For the security team, people can follow
> security mailing lists, forward those advisories as bugs to our BTS,
> forward patches, prepare packages with those patches, etc.
>
> I agree with some mails asking for more documentation about delegate
> roles (of their tasks, the procedures employed, etc) and I'll follow
> up on that soon. At the same time, I agree with Colin Watson's
> posting that the lack of documentation about the release has not
> stopped him from volunteering. It seems that those truly interested
> in helping out and getting involved will find a way; and maybe they
> can even document it along the way to make it easier for others. So
Same for all those m68k buildd folk and for buildd.net. And that's why there
are some docs on buildd.net describing common problems of buildds and how a
buildd work (f.e. by Wouter).
But that doesn't mean that everyone should start from the beginning and find
their own way. The wheel is not invented each time again when someone needs
one, is it?
> the question everyone here should ask themselves is what they have
> done to improve the situation.
Well, I think I'm contributing my part of improving with donating service of
buildd.net (based on the scripts and work of Rick Younie and others), but I
could be far better when there would be more will to cooperate and
communicate on the "other side". You know what I mean, for sure.
And how about the promised enhancements? The $arch@buildd.d.o lists? The
mediator for contacting Mr. Troup? Still you? Someone else? How is the
status on all those new buildds for arm, mips, mipsel & others?
--
Ciao... //
Ingo \X/
Reply to: