commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject Re: Commons - TLP
Date Thu, 18 Dec 2003 20:17:05 GMT

--- Henri Yandell <bayard@generationjava.com> wrote:
> 
> Your view is very akin to mine I think.
> 
> My suggested proposal is designed to basically get
> us to agree on the idea
> then we would propose to A-Commons that they join a
> TLP Jakarta Commons
> [with the name Apache Commons] and bootstrap the
> system with the Jakarta
> Commons system. Same avail as we have, same website,
> same rules etc.

With some other details, like loosening the source
control requirements, it's a possibility if a) the
Apache-Commons PMC were to sign off on it, and b) the
PMC either adopted an immediate and aggressive policy
of granting PMC status to committers or allowed the
committers to vote on the big issues.

> We would de-java things to allow other languages in
> [ie) remove Java only
> references in charter, figure out website/cvs
> structure] but we would not
> embrace a feature-centric system and allow the Java
> community of 'ASF
> Commmons' to cling together if they wanted to.

That's one of my main points.  The Java-only
references are important; it's sound advice that
should be part of the project guidelines.  "Remov[ing]
Java only references" would be a mistake.  That's my
concern with a "language-agnostic" project: that
important details would be glossed over (as they have
been to-date) because they relate only to Java or C or
whatever. 

> As they have a lot of httpd background, I feel they
> would help us a lot on
> the formation of the initial PMC. They'll also be
> useful for moving to
> SVN, though I'd like to hear if the suggestions I've
> seen that all of
> Apache will use SVN are official or just bar-talk.

I think it's premature to require SVN conversion until
the tools catch up.  Until then, let the developers
decide.  And if it's not reasonable to maintain both
an SVN and a CVS repository, then I say we use CVS for
now, which most developers probably use both here and
at their place of work.

> I'm actually -1 to the idea that just the committers
> to one of our
> components can vote to move to A-C. The point of the
> Commons community I
> think is that we're all involved in one large
> codebase, with large
> striations, and that we'd all be a part of such a
> vote. Most of the time I
> would vote - or +0, but I think the whole Commons
> should vote.

That's your right under the voting rules.  Under these
circumstances, I wouldn't cast a vote on a component
that I haven't committed code to, but I would support
your option to vote against a component move.  I think
there are valid arguments either way, so your vote
would definitely be valid.

It's not reflected in their status document, but this
is another significant point of divergence between A-C
and J-C styles.  When the topic was broached, IIRC the
clear inclination amongst the A-C PMC was to restrict
voting priveledges according to karma.

> Ditto on [sql] moving to DB Commons.
> 
> We all vote on releases and adding new committers
> for example.

Yes absolutely.

> Hen
> 
> On Thu, 18 Dec 2003, Morgan Delagrange wrote:
> 
> > Hey all,
> >
> > I've been hesitant to join the holy war, but what
> the
> > hell.  By the way, for simplicity's sake I'll be
> > referring to Jakarta Commons, past present and
> future,
> > as a "project".  Get over it.  :)
> >
> > Regarding promoting Jakarta Commons to a top level
> > project...
> > --------------------------------------------------
> >
> > I'm neither for nor against it.  I'm satisfied
> with
> > the visibility and activity of J-C today, but if
> there
> > is sufficient interest in moving I would not be
> > opposed.  However, I believe some board members in
> > past conversations have expressed that they would
> not
> > support such a project, since they have already
> formed
> > a top level "Commons" project and would not be
> > interested in introducing another.  For my part, I
> > agree that it would be confusing to have another
> top
> > level project, although maybe there's a way to
> make it
> > work.
> >
> > Regarding moving components to Apache Commons...
> > ------------------------------------------------
> >
> > The committers for a component can vote to join
> Apache
> > Commons if they like.  Personally, I still have
> > reservations concerning A-C and at present would
> vote
> > -1 on a move.  I've expressed my views on many
> > occasions, but I'll summarize some of the points
> here.
> >
> > 1. I'm not convinced that a language-specific
> project
> > is a bad thing.  For example look at the Commons
> > charter:
> >
> >   http://jakarta.apache.org/commons/charter.html
> >
> > It contains specific details about Java coding
> > conventions, release formats, JDKs, JavaBeans,
> etc. I
> > think that in a project which encourages small,
> > well-constructed components, this level of detail
> is
> > important.  J-C had nearly all of these details
> > committed to its Charter BEFORE it was approved by
> the
> > Jakarta PMC.  A-C has yet to scratch the surface.
> >
> > 2. I don't like their component karma policy.
> >
> >   http://svn.apache.org/repos/asf/commons/STATUS
> >
> > Currently only Greg Stein has supported universal
> > karma for all Apache Commons committers, like we
> have
> > in Jakarta Commons.  All the other PMC members
> support
> > per-component karma (some with an unspecified and
> > dubious-sounding "self-chosen aggregation").  Back
> > when Apache Commons was first advocating a mass
> > migration of Jakarta Commons components to Apache
> > Commons, Peter Donald was advocating that the
> > component developers could be more selective than
> the
> > Apache Commons project itself and actually deny
> commit
> > access to their component.
> >
> > I have joined several components simply because I
> saw
> > something that needed fixing or thought of
> something
> > useful.  Raising the barriers of entry by
> requiring a
> > vote or intervention by a CVS administrator is not
> > reasonable to me.  Existing veto procedures should
> be
> > more than sufficient for the occasional rogue
> commit.
> >
> > 3. Apache Commons decision making seems too
> top-down.
> > Only PMC members can make binding decisions
> concerning
> > the makeup of the project.  At J-C all along we
> have
> > made our final decisions by majority vote, and the
> > Jakarta PMC would only intervene if there were a
> legal
> > issue or an unresolvable impasse (which IIRC has
> never
> > occurred).  When we were forming J-C we went to
> the
> > main Jakarta mailing list and actively solicited
> > volunteers to work out the details of the project,
> and
> > from that point onward IMO it has been a group
> effort.
> >
> > In comparison Apache Commons had formed its PMC
> before
> > most of us were aware of its existence, and
> certain
> > decisions concerning karma, version control etc.
> have
> > already been made by that small body.  Things will
> > probably loosen up in time, but I'd like to see
> some
> > evidence that the project management will not be
> so
> > heavy-handed before I would support a move.
> >
> > 4. I don't see sufficient benefit yet.  If making
> > Jakarta Commons a top-level project would be a lot
> of
> > effort, merging with Apache Commons would be even
> more
> > so.  Converting our code (and our developers) to
> > Subversion, creating separate karma for each
> > component, hammering out all the detail which the
> > Jakarta Commons charter already possesses, and for
> > what?  A top level domain?  Who cares.  Better
> > oversight?  I think we're doing fine.  Synergy
> with C
> > projects?  That can be accomplished without
> ripping up
> > track.
> >
> > In conclusion...
> > ----------------
> >
> > Jakarta Commons is a 2 1/2 year old project which
> had
> > (and still has) a lot of effort invested in it.  I
> > think it works well.  If we were to become a top
> level
> > project or merge with Apache Commons, I'd want to
> make
> > sure that we ended up with a better arrangement,
> not
> > one that is worse or merely different.
> >
> > - Morgan
> >
> > =====
> > Morgan Delagrange
> > http://jakarta.apache.org/commons
> > http://axion.tigris.org
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 


=====
Morgan Delagrange
http://jakarta.apache.org/commons
http://axion.tigris.org

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


Mime
View raw message