On Mon, Nov 01, 1999 at 02:52:17PM +0000, Philip Hands wrote:
> Edward Brocklesby <ejb@klamath.dhis.org> writes:
>
> > Please offer sensible, well considered, useful comments. Replies from
> > rude, abrasive people (you know who you are) will be ignored.
>
> How very diplomatic of you ;-)
>
> > 3. The Project Leader's Delegate(s) may decide not to admit any new
> > Developers (close the New Maintainer process), until the next
> > release of debian, provided Developers are in favour of this
> > by a 3:1 majority. New Maintainer may be reopened either when the
> > Developers agree to do so by a 3:1 majority, or the next version
> > of Debian has been released. New maintainer may be closed for longer
> > than this time only if a General Resolution is passed.
>
> This (closing n-m) is not something anyone seems to want, so codifying
> a way to make it happen seems a little pointless to me.
Odd, considering that this is exactly what some have said they want to
do, at least as far as I know..
>
> > 8.4 Composition
> >
> > 1. Any critical package or system team (e.g, the New Maintainer team,
> > the FTP Admin team, any Essential package's maintainers) must have
> > a reasonable number of active members at all times.
>
> and what happens if this condition is not met ?
Section 2 below covers this I think?
>
> > 2. If, for any reason, it is not possible for a reasonable number of
> > members of any team to be active, the Project Leader, one of
> > the Leader's Delegates, or a member of the team must appoint
> > enough members to ensure there are at least two active.
>
> how about if there are no volunteers ?
Then we do have a definite problems..
> and if there are volunteers with the right skills, why would this not
> happen naturally without the need for the above clause.
Because for some reason the team members do not feel like it, this has
happened in the past (iwj and dpkg, the new maint team)..
>
> > 3. All mailing lists for a particular team must be open, unless
> > the Developers agree that it may be closed, by a vote with a
> > majority of at least 3:1, or the Project Leader gives permission
> > for the list to be closed, and no Developers object to this.
>
> If people on a team decide that the list is better closed for some
> reason, and the project attempts to bar this, then they'll just take
> it to private email --- this is unenforcible.
If they don't want to act inside the guidelines, they should probably be
looked at closely to see if another team should be appointed to do the
job in question...
>
> > 4. An "Active" member shall mean a member who, in any given day, would
> > be able to take suitable action on any situation relating to that
> > particular team.
>
> Hm, I wonder how many ``active'' developers we have by that definition.
I'm not sure..
>
> > 5. "Reasonable number" shall mean either the amount of people required
> > to handle all issues relating to that team, or two, whichever is
> > greater.
>
> I think we generally assume that our fellow developers will act in a
> sensible manner, so writing constitutional clauses to that effect
> seems somewhat redundant.
A usually valid assumption, however when things sit for a while because
someone who is essential for the operation of debian is not around, or
is unable/unwilling to work on things, we need a backup plan..
>
> > 6. An "open" mailing list shall mean a mailing list to which anyone
> > can subscribe to and read. The list may restrict who is allowed
> > to post to it (a "moderated" list). The list must be archived
> > in a publically accessible place, for a period of at least two
> > years.
>
> Again, why on earth do we need this in the constitution ?
If you have a suggestion on a better place to put it, I'd be happy to
hear it..
>
> It strikes me that this proposal is just a way of airing your
> grievance about n-m being closed. As far as I can tell, the matter is
> in hand and will be resolved in the near future, so perhaps you should
> do us all a favour and spend your time on something constructive
> instead.
The n-m being closed is just one example, dpkg sat for a really long
time mostly unmaintained for two reasons, one is that very few people
wanted to touch the code, the other is that it was IWJ's package and
he would not give it up..
>
> <general rant>
> I generally object to anything that introduces or supports the idea
> that voting on things is a good way to run Debian.
Agreed..
> Things get done around here because people feel like doing them, not
> because we all voted and told some poor sod that they've been elected
> to do the job.
Also agreed, the problem coming when someone says that they are doing
something, and does not do it...
And in most cases even that is fine, however when it comes to
/essential/ items (packages marked Essential, n-m, ftpadmin, boot
floppys, cd generation, etc) we need to have some form of backup plan...
I wish there was another simple way, but I'm not seeing it, and lately
we have had some definite issues which remind us of this..
Zephaniah E. Hull..
(The other guy behind this proposal)
> </general rant>
>
> Was that abrasive enough for you to ignore me?
>
> Cheers, Phil.
--
PGP EA5198D1-Zephaniah E. Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
Attachment:
pgpH0AvMyMewA.pgp
Description: PGP signature