Date: Tue, 21 Jan 1997 19:15:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG Subject: Re: Commerical applications (was: Development and validation Message-ID: <199701220215.TAA20711@phaeton.artisoft.com> In-Reply-To: <1045.853896142@time.cdrom.com> from "Jordan K. Hubbard" at Jan 21, 97 05:22:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's not complex. I've described the process in abstract; it only
> > *looks* complex, it doesn't *act* complex.
>
> Hmmm. I remain skeptical, but for the purposes of argument... :-)
Heh.
> > All changes involving dissenting opinions. Again, the core team is
> > who you should be asking this question, since you are really asking
> > "how much control is the core team giving away?".
>
> I think you're working from a misperception. The core team doesn't
> spend its time sitting around rubbing its collective hands together
> and going "Mooohahahaha! POWER!" so it's not likely to consider this
> in terms of power loss so much as it is in terms of how much workload
> is generated.
You misapprehend my meaning when I say "power". I include "the power
to control the workload" in "power".
The salient point here is that with reduced power comes reduced
responsibility (yeah, I watched 'Spiderman' when I was a kid).
This means that workload control is no longer the resonsibility of
the core team... it probably never should have been, since they
are technical people better spent solving technical problems
than spent worrying about being buried alive by some fool with
a bottle of old French wine.
If there are a lot of things on the list, then there are a lot of
things on the list.
Probably it would be a good idea if there were a rule that you can't
make rules imposing blocking restrictions on the list content or
ordering ("We must have WINE working before we can commit any other
changes"). I suspect that type of resoloution would be voted down
anyway.
Where the core team may still come into it (this depends on how you
decide to constitute the transfer of power) is the ability to block
some items pending generation of releases. And that's really the
job of the release engineering process, be it defined as a human
named Jordan or a human named David or some process involving only
the people who are left handed and who also have commit priviledges,
provided that they own ergonomic keyboards and three button mice.
> From that perspective, it's still an open question as
> to who's going to draft bills for the system and what happens if
> everybody decides that drafting bills is too much work and they'd
> prefer to simply argue in the existing mailing lists (and there are
> many oblique ways of arguing a point which make it easy to claim later
> that you weren't attempting to circumnavigate the vote system at all).
Well, in that case, the mailing list argument isn't really worth
anything, unless you take it into a discussion phase. People might
ask "how can we implement this?" without having to decide to actually
implement it.
If people while about "Linux vs. FreeBSD", ignore them. Most likely,
a lot of the list traffic will go away, and the S/N ratio will go
up overall, with the posts being topical to advancing the project as
a whole.
> But that doesn't even raise the biggest issue, which is:
>
> > Freddy Kruger (Kruger@ElmStreet.org) has submitted the
> > following policy topic for discussion:
> >
> > > FreeBSD should move from a.out to ELF.
> > -------------------------------------------------------------------------
> > [ ... various amounts of discussion for 5 days ... ]
>
> Freddy raises the issue and 10 people vote on it, 7 feeling ELF-ish
> enough that the motion "passes."
>
> Now what? We've got this as a supposed piece of "FreeBSD Policy" now
> and users will surely expect it to be implemented or there wouldn't be
> much point in the policy or the vote, but who's going to do the work?
> The 7 voters? Does that mean that in order to vote "yes" you also
> have to be willing to do the work? I'd say most definitely yes to
> that since a vote without the rocks to back it up is rather worthless
> (Judge: "Have you reached a verdict?" "Yes, we the jury find the
> proposal good and would like someone to implement it." Judge: "Who?"
> Jury: "Uh, just someone. Hey, all you asked us to do was vote on it,
> remember?").
>
> So now the question is, if it takes a committment to actually
> implement a proposal in order to vote, are people going to jump up and
> vote all that much? If it doesn't take a comittment, what's to stop
> the peanut gallery from using up their votes on things which will
> never get implemented since there are no actual volunteers committed
> to doing the work? And what about a No vote? Do you have to be
> willing to make a counter-proposal or somehow balance your "no" in a
> meaningful way or do the "no's" become stronger than "yesses" since
> it's a lot more easy now to shoot something down than vote for it and
> get stuck actually doing it.
Well, since it isn't your responsibility to actually implement *anything*
(this is a volunteer effort), there is a distinction between "policy"
and "in the next release".
If you feel strongly that there isn't anyone to implement ELF (using
the same example) vote "No" on the poll. If it passes anyway, spend 3
vote tokens on a "No" on the Vote.
It could be constituted that resloutions "time out" after a month or two
months (or whatever time period), unless one or more people volunteer
to actually work on it. You want it back on the list? Discuss it,
Poll, it, and Vote it again. Call for a vote first thing in the
discussion to shorten the time period. If you are whining about it
and no one cares, well, you'll use up your tokens that let you whine
and we won't have to listen to it any more. Either wy, it self-corrects.
What goes on the "in the next release" page is up to the release
engineering process, though they should probably only be allowed to
suspend incomplete features (the release engineer could still be
whoever is fool enough to wear the hat, and is left handed and...).
> I don't know, I still think the exception cases outnumber the rules at
> this point, and with enough ambiguity still left over to choke a wooly
> mammoth.
Make a rule throwing out ambiguities. A rule set is just as NP complete
when it says "behaviour in this case is undefined and you aren't allowed
to define it unless you use a defined behaviour to do it". 8-) 8-).
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701220215.TAA20711>