On Tue, Dec 18, 2007 at 05:50:48PM +0000, Alan Burlison wrote:
> The confusion surrounding this gives me an issue as to where my Auth
> project gate and related documents should live. I would much appreciate
> a clarification from the OGB - thanks.
This is not advice from the OGB, it's just from an OGB member. If you
want the former, it will take a while. In the meantime, I see five
choices:
I. Accept the OGB's decision and form the project in the new Website
CG. You're a Core Contributor so it should not be difficult to get
approval. Check with the project creation team, which also does CG
infrastructure setup, about getting the mailing lists going so you can
vote first. This is the most constructive option.
II. Accept the OGB's decision but ask us to restructure/reconsider. I
don't know what's changed since the decision was made that would
suggest we should make a change already, but I'm sure you'll be given
every opportunity to make such a case. If the OGB doesn't accede to
your wishes, you still have the remaining 4 options.
III. Accept the legitimacy of the OGB's decision but thwart it by
careful manipulation of the system. Specifically, you could:
- Do the same as in I,
- Get the Tools CG (or a different one in which I don't get a vote)
to "endorse" the Project,
- Remove the Website CG's endorsement,
- Get all Website CGs to resign, disbanding the CG.
This would leave you with a Project endorsed/sponsored/owned solely by
Tools - effectively your status quo ante. The OGB could, of course,
do another round of restructuring that undoes your change but, absent
project process reform, we could go round in circles forever. And
hey, who doesn't love a good bureaucratic runaround? It beats writing
code any day. If nothing else, this outcome would encourage us to fix
some loopholes, and you'd still be able to get work done.
IV. Do nothing. Work on your project privately until an OGB is
elected that is more amenable to your desires. This could be happen
days from now or never. And it's not like anyone can actually stop
you from deploying your project whenever you think it's done; only you
and a handful of others at SMI have the necessary access. This
approach may end up reducing to V but it will likely take a lot longer
to get there.
V. Continue undermining the OGB's legitimacy and wasting time on
pointless arguments until someone, out of frustration, forks the
source base somewhere without all the madness that is OpenSolaris
today. At that point you can do whatever you want because your work
will be solely for SMI's benefit, not the OpenSolaris Community's.
You'll build the world's best auth system and deploy it on a web site
no one visits. But you'll have done it your way, without the OGB's
illegitimate and invalid meddling.
As for actual advice, I'm fresh out. I've ordered these by my
personal preference but you can obviously pursue whichever strategy
you like.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
