Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Reply-To: <paulo.gaspar@krankikom.de>
From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date: Mon, 4 Feb 2002 01:56:29 +0100
Message-ID: <NEBBJJIICDPIINBNIJHJKEOMNKAA.paulo.gaspar@krankikom.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <B8831FBC.D68E%geirm@optonline.net>
Importance: Normal

Answer inline:

> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Sunday, February 03, 2002 11:11 PM
>
> On 2/3/02 4:21 PM, "Paulo Gaspar" <paulo.gaspar@krankikom.de> wrote:
>
> > Amazing work on HYPOTHETICAL situations.
>
> Well, it's a valid question given the governance model we are proposing.
>
> >
> > To simplify again, I do not agree with the negation of that statement
> > either. Maybe the most balanced situation is the one we already have
> > ...until it is proved to be bad.
> >
> > Still learning here.
> >
> > I am only sure that I am not so sure that the rules of the game
> > should change.
> > =;o)
>
> Except we keep ignoring that we *did* change the rules if you grant me the
> model of Commons as a 'mini-Jakarta' :

I do not think the Commons are a mini-Jakarta.


> - where the components map to the projects.
> - and the original 'three person committee' (that we never needed) was the
> PMC
> - the committer community is the individual component committers
> as a group
>
> If we kept the same model, we would have Commons as a 'organizing place'
> where we can bring bits of existing code and productize them, bring in new
> bits of code that we need, provide the sandbox for exploration and
> experimentation, and build a community of people interested in these kinds
> of things.

The commons as an organizing place makes sense INSIDE Jakarta.


> However, in each case (except the sandbox), a component would
> have a defined
> set of committers that would be responsible for the direction and
> status of
> their component, and keep adding new committers and contributions and
> interest dictated.
>
> In our case, we did alter the model.  It's sounds great - one for all and
> all for one - but I don't see that working out in practice.  I am *not*
> suggesting it is a failure - we are still small enough that it has worked
> out well so far, but peter showed us one problem, and I expect that w/o
> addressing it, we are going to have to deal with it and like
> issues more and more often.

I was seeing the problem longer ago from Peter's earlier remarks. He
did not have to throw that -1 to have my attention.

However, the model that Costin finally made me understand might really
make sense. Maybe less rules really gives room to more creativity.
Maybe things really work out better as Costin says. He made me believe
so and I do not think I am able to explain it better than he did - and
I am not going to try, but you can go back and read it again if it
interests you.

And, again, CVS allows us to rollback things if something goes wrong.


Now, you are afraid that we are getting to big and that it will not
work so well in the future because of that. I think that you might be
right, but I also think that:
 - It is still working well now as it is;
 - We can fix it if/when the current rules don't cut it.

With software projects and organizations, a low level of bureaucracy
works better for the smaller ones and a higher level works better for
the larger ones.

So, while we are small enough, less is more - lets keep the bureaucracy
lower until we really get too big.


> geir

Have fun,
Paulo


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>