You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <fl...@gmail.com> on 2005/12/13 01:04:53 UTC
Notice of intent....
dum de dum de dum.....
Just to be public so that it doesn't look like I'm sneaking around
trying to manipulate things.
--
I'm starting to open the question of TLP on many of the Jakarta dev
mailing lists. It's with a general plan where we would see another
half a dozen subprojects move to TLP and then really leave Commons as
the main entity inside Jakarta along with some commons-like components
that are currently subprojects.
I've been talking unofficially with lots of people at ApacheCon, so
I've had a fair bit of feedback on various bits. The important part is
that the loose plan above finds a way to coalesce the Jakarta
community into a much tighter, more TLP e like project.
I've talked with a couple of board members to feel out things would
be. One question being, is it a problem if we're pushing a TLP with
just a few committers. The answer I had was that Excalibur is the
example TLP, it's rather dormant and it's not a problem.
I was also advised to be a bit more active in pushing forward. I think
this makes sense, a lot of our cross-community activity is gone
because people with high activity tend to move to TLP, so we need a
bit more drive to get things done. Thus the change of tack that I'll
be trying to pull off without getting hung :)
Please discuss, argue, wibble; but what I'm looking for are active
ways forward instead of maintaining the status quo. I don't think the
status quo is good for Jakarta as an entity, it puts strain on our
oversight because the number of subprojects stretches the chair's and
community in general's ability to keeps things covered.
*denies the blindfold and stands against the wall waiting*
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Henri,
Mostly agree with all your responses.
I want to emphasize though that Jakarta has two entry points for users
* People coming finding a general "Java @ Apache" resource. (which the
reorg helps)
* People looking for a specific resource after reading about it, hearing
word-of-mouth, etc. (there's a risk the reorg could hurt this).
For the last point, every component needs to have a distinctive name and
permanent URL. There's a lot of articles out there on Velocity (which
admittedly should be referred to as Jakarta Velocity though it generally
isn't), and also ORO, POI, taglibs, DBCP, etc. Let's not hide these popular
components behind a blank generic front. They should remain easy to find
and link to.
Cheers,
WILL
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Sent: Tuesday, January 10, 2006 8:32 AM
Subject: Re: Notice of intent.... #2
>
>
> On Wed, 11 Jan 2006, Will Glass-Husain wrote:
>
>> Thanks, Henri.
>>
>> My feedback.
>
> Thanks, very useful stuff.
>
>> * Generally positive with an aversion to anything involving significant
>> work for the sake of a "cleaner Jakarta". By this I mean that I like the
>> idea of a flatter hierarchy and a clearer message to the public as to
>> what Jakarta is about. As I noted on the Velocity list, 4 years ago I
>> discovered Velocity after identifying Jakarta as a "cool Java project
>> resource" and then browsing through every project looking for useful
>> libraries. We should encourage that.
>
> Yep. I need to post on Idea #3: Jakarta as Java federation at some point
> :) Which mainly means having links and decriptions to other Java projects
> at Apache and making general@jakarta more of a discussion list than
> Jakarta business list.
>
>> * I'm skeptical about the "common build and web site" part of your plan.
>
> Agreed that technical issues may cloud this one. Having common structure
> allows for people to work on each component more easily; but more
> importantly it forces us into a single community.
>
> It also stops components becoming component trees. ie) I'll be pushing for
> velocity-tools to be a separate component from velocity. Guess an SVN
> reorg will probably be in the works at some point :)
>
> One part of common build is that each component produces only 1
> deliverable. Not sure if that's worked perfectly in Commons, a few
> components have a couple of jars, though 1 is always the most important
> (much like velocity/velocity-tools). Producing 1 deliverable stops
> subcomponentizing.
>
>> Seems like an awful lot of reorg work for little purpose. Many sites
>> have a maven site build. Who is going to integrate all of the projects
>> so that the individually desired features appear on each site. Same for
>> building. Velocity has a mildly customized build script that compiles
>> differently under JDK 1.3 and JDK 1.4/5. If we go to a "master web site
>> and build" this will make it too difficult to introduce changes to the
>> proces and will stifle innovation. Better to keep this at the subproject
>> level. (Note:
>
> *goto jail, do not pass go* s/subproject/component/
>
> No more subprojects :)
>
>> Jakarta-wide style guidelines with common fonts, colors, logos would be a
>> great idea though).
>
> Good point. Common general l&f binds us together more.
>
>> * Also, I'm against changing the project names. Velocity (for example)
>> is a recognizable brand name. Calling it "Jakarta Template Language" or
>> something similar would be foolish.
>
> It'd be Jakarta Velocity; but it might fall in the TemplateLanguage group.
> I think we'll need groupings for sanity's sake, but we have to avoid them
> gaining character. They're just vague tags and not actual subprojects.
>
>> * On a positive note, establishing a standard template for web site
>> format and build would speed up the introduction of new subprojects. We
>> could migrate the common subprojects to a standard, and encourage new
>> subprojects to use it. But if a group wants to modify this template for
>> one piece of it - why not? (as long as they keep some common Jakarta
>> fonts, colors, etc).
>
> Right. Individual character is important. Same with the build; as long as
> it's largely the same, individual bits to handle individual issues are
> fine. We just need to have the norm be to be similar.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 11 Jan 2006, Will Glass-Husain wrote:
> Thanks, Henri.
>
> My feedback.
Thanks, very useful stuff.
> * Generally positive with an aversion to anything involving significant work
> for the sake of a "cleaner Jakarta". By this I mean that I like the idea of
> a flatter hierarchy and a clearer message to the public as to what Jakarta is
> about. As I noted on the Velocity list, 4 years ago I discovered Velocity
> after identifying Jakarta as a "cool Java project resource" and then browsing
> through every project looking for useful libraries. We should encourage
> that.
Yep. I need to post on Idea #3: Jakarta as Java federation at some point
:) Which mainly means having links and decriptions to other Java projects
at Apache and making general@jakarta more of a discussion list than
Jakarta business list.
> * I'm skeptical about the "common build and web site" part of your plan.
Agreed that technical issues may cloud this one. Having common structure
allows for people to work on each component more easily; but more
importantly it forces us into a single community.
It also stops components becoming component trees. ie) I'll be pushing for
velocity-tools to be a separate component from velocity. Guess an SVN
reorg will probably be in the works at some point :)
One part of common build is that each component produces only 1
deliverable. Not sure if that's worked perfectly in Commons, a few
components have a couple of jars, though 1 is always the most important
(much like velocity/velocity-tools). Producing 1 deliverable stops
subcomponentizing.
> Seems like an awful lot of reorg work for little purpose. Many sites have a
> maven site build. Who is going to integrate all of the projects so that the
> individually desired features appear on each site. Same for building.
> Velocity has a mildly customized build script that compiles differently under
> JDK 1.3 and JDK 1.4/5. If we go to a "master web site and build" this will
> make it too difficult to introduce changes to the proces and will stifle
> innovation. Better to keep this at the subproject level. (Note:
*goto jail, do not pass go* s/subproject/component/
No more subprojects :)
> Jakarta-wide style guidelines with common fonts, colors, logos would be a
> great idea though).
Good point. Common general l&f binds us together more.
> * Also, I'm against changing the project names. Velocity (for example) is a
> recognizable brand name. Calling it "Jakarta Template Language" or something
> similar would be foolish.
It'd be Jakarta Velocity; but it might fall in the TemplateLanguage group.
I think we'll need groupings for sanity's sake, but we have to avoid them
gaining character. They're just vague tags and not actual subprojects.
> * On a positive note, establishing a standard template for web site format
> and build would speed up the introduction of new subprojects. We could
> migrate the common subprojects to a standard, and encourage new subprojects
> to use it. But if a group wants to modify this template for one piece of it
> - why not? (as long as they keep some common Jakarta fonts, colors, etc).
Right. Individual character is important. Same with the build; as long as
it's largely the same, individual bits to handle individual issues are
fine. We just need to have the norm be to be similar.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks, Henri.
My feedback.
* Generally positive with an aversion to anything involving significant work
for the sake of a "cleaner Jakarta". By this I mean that I like the idea of
a flatter hierarchy and a clearer message to the public as to what Jakarta
is about. As I noted on the Velocity list, 4 years ago I discovered
Velocity after identifying Jakarta as a "cool Java project resource" and
then browsing through every project looking for useful libraries. We should
encourage that.
* I'm skeptical about the "common build and web site" part of your plan.
Seems like an awful lot of reorg work for little purpose. Many sites have a
maven site build. Who is going to integrate all of the projects so that the
individually desired features appear on each site. Same for building.
Velocity has a mildly customized build script that compiles differently
under JDK 1.3 and JDK 1.4/5. If we go to a "master web site and build"
this will make it too difficult to introduce changes to the proces and will
stifle innovation. Better to keep this at the subproject level. (Note:
Jakarta-wide style guidelines with common fonts, colors, logos would be a
great idea though).
* Also, I'm against changing the project names. Velocity (for example) is a
recognizable brand name. Calling it "Jakarta Template Language" or
something similar would be foolish.
* On a positive note, establishing a standard template for web site format
and build would speed up the introduction of new subprojects. We could
migrate the common subprojects to a standard, and encourage new subprojects
to use it. But if a group wants to modify this template for one piece of
it - why not? (as long as they keep some common Jakarta fonts, colors,
etc).
Best, WILL
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Sent: Tuesday, January 10, 2006 1:12 AM
Subject: Notice of intent.... #2
>
> As a second email in the Notice of intent series; here's what I think
> being a Jakarta component will be like in the future.
>
> * Jakarta is a collection of components. Hopefully all sitting at the same
> level. ie) a big bag of things.
>
> * Groups exist. These are categorically not subprojects, but a way to
> allow for slicing of the website etc. Some groups may have their own mail
> list; thus the importance of making sure they don't become subprojects. An
> important rule will probably be that they must do votes on the main list.
>
> Hopefully we can keep it at a point where the groups are really just there
> to refine the flow of mail, not to separate it. HttpComponents is an
> example of this (though not a good one as most of its components came from
> HttpClient). WebComponents (formerly hoped to be known as Silk) is another
> example.
>
> Commons would be groupalized out. Hopefully. Groupings are not vague
> names - HttpComponents good, Silk bad. CoreComponents good, Turbine bad.
> The idea with that being that boring grouping names are intentionally
> dull, no subcommunity identification.
>
> * No svn authentication beyond being in the jakarta group. Velocity coders
> have rw access to POI.
>
> * Improved Committer->PMC process. Chair's responsibility (I've failed at
> this so far) is to turn around the new committer process. A new committer
> of 6 months is effectively voted against going to the PMC, not for. Might
> not be able to make it exactly that way, but the idea being that joining
> the PMC is the exception, not the norm. Personally I'd like to see
> committership be removed if people repeatedly are not allowed onto the
> PMC.
>
> * Application of Commons thinking. Not entirely sure on this one as I
> think we've overcomplicated things in Commons a bit; but things like a
> common build system, common site system etc.
>
> * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the
> same rules as it has currently. Probably a separate mailing list.
>
> -----
>
> Shout, scream, yell :)
>
> Hen
>
> On Mon, 12 Dec 2005, Henri Yandell wrote:
>
>> dum de dum de dum.....
>>
>> Just to be public so that it doesn't look like I'm sneaking around
>> trying to manipulate things.
>>
>> --
>>
>> I'm starting to open the question of TLP on many of the Jakarta dev
>> mailing lists. It's with a general plan where we would see another
>> half a dozen subprojects move to TLP and then really leave Commons as
>> the main entity inside Jakarta along with some commons-like components
>> that are currently subprojects.
>>
>> I've been talking unofficially with lots of people at ApacheCon, so
>> I've had a fair bit of feedback on various bits. The important part is
>> that the loose plan above finds a way to coalesce the Jakarta
>> community into a much tighter, more TLP e like project.
>>
>> I've talked with a couple of board members to feel out things would
>> be. One question being, is it a problem if we're pushing a TLP with
>> just a few committers. The answer I had was that Excalibur is the
>> example TLP, it's rather dormant and it's not a problem.
>>
>> I was also advised to be a bit more active in pushing forward. I think
>> this makes sense, a lot of our cross-community activity is gone
>> because people with high activity tend to move to TLP, so we need a
>> bit more drive to get things done. Thus the change of tack that I'll
>> be trying to pull off without getting hung :)
>>
>> Please discuss, argue, wibble; but what I'm looking for are active
>> ways forward instead of maintaining the status quo. I don't think the
>> status quo is good for Jakarta as an entity, it puts strain on our
>> oversight because the number of subprojects stretches the chair's and
>> community in general's ability to keeps things covered.
>>
>> *denies the blindfold and stands against the wall waiting*
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 10 Jan 2006, robert burrell donkin wrote:
> On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote:
>> On 1/10/06, Henri Yandell <ba...@generationjava.com> wrote:
>>>
>>>
>>> * Groups exist. These are categorically not subprojects, but a way to
>>> allow for slicing of the website etc. Some groups may have their own mail
>>> list; thus the importance of making sure they don't become subprojects. An
>>> important rule will probably be that they must do votes on the main list.
>>
>>
>> I prefer the term "groupings" (which, interestingly, you switch to below ;)
>> over "groups".
>
> +1
+1. You're right, groupings is much better.
>>> * Improved Committer->PMC process. Chair's responsibility (I've failed at
>>> this so far) is to turn around the new committer process. A new committer
>>> of 6 months is effectively voted against going to the PMC, not for. Might
>>> not be able to make it exactly that way, but the idea being that joining
>>> the PMC is the exception, not the norm. Personally I'd like to see
>>> committership be removed if people repeatedly are not allowed onto the
>>> PMC.
>>
>>
>> Well, except that the process is that the PMC has to vote in a new committer
>> to the PMC and then notify the board of that vote. I'm definitely not in
>> favour of magic notifications to the board when the six months are up,
>> without an associated vote.
>
> i don't like the idea of magic notifications (to the board) but
> something needs to be done: ATM we're dysfunctional. just take a look at
> the nominations per nominator over the last year or two: nomination
> hasn't become ingrained in the culture.
>
> ATM we're slipping up but maybe statistics and reminders may be better
> for the moment than automatic nomination...
+1 to reminder. The board list has a reminder to chairs to submit their
report. We should have a similar thing, a reminder to pmc@jakarta that the
following people should be considered for the pmc.
Easiest method is to have something that compares svn structure for
jakarta (easier when we have only one auth) and the committee-info.txt
file. Doesn't catch new committers who are not in svn yet, but a good
80/20.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-01-10 at 10:20 -0800, Martin Cooper wrote:
> On 1/10/06, Henri Yandell <ba...@generationjava.com> wrote:
> >
> >
> > As a second email in the Notice of intent series; here's what I think
> > being a Jakarta component will be like in the future.
> >
> > * Jakarta is a collection of components. Hopefully all sitting at the same
> > level. ie) a big bag of things.
> >
> > * Groups exist. These are categorically not subprojects, but a way to
> > allow for slicing of the website etc. Some groups may have their own mail
> > list; thus the importance of making sure they don't become subprojects. An
> > important rule will probably be that they must do votes on the main list.
>
>
> I prefer the term "groupings" (which, interestingly, you switch to below ;)
> over "groups".
+1
gave up groups (topological or even finite simple) when i left uni ;)
> I also think we should allow the component:grouping
> relationship to be 1:N, since not all components will fit tidily into a
> single grouping. As a corollary, I don't believe groupings should have their
> own mailing lists.
not sure
i like the idea of fuzzy groupings with 1-N
components need to be mapped 1-1 to dev mailing lists but 1-N would work
fine on user lists. might be possible to factor 1-1 dev lists (for
traffic purposes) whilst retaining fuzzy users lists.
> Hopefully we can keep it at a point where the groups are really just there
> > to refine the flow of mail, not to separate it. HttpComponents is an
> > example of this (though not a good one as most of its components came from
> > HttpClient). WebComponents (formerly hoped to be known as Silk) is another
> > example.
> >
> > Commons would be groupalized out. Hopefully. Groupings are not vague names
> > - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The
> > idea with that being that boring grouping names are intentionally dull, no
> > subcommunity identification.
> >
> > * No svn authentication beyond being in the jakarta group. Velocity coders
> > have rw access to POI.
> >
> > * Improved Committer->PMC process. Chair's responsibility (I've failed at
> > this so far) is to turn around the new committer process. A new committer
> > of 6 months is effectively voted against going to the PMC, not for. Might
> > not be able to make it exactly that way, but the idea being that joining
> > the PMC is the exception, not the norm. Personally I'd like to see
> > committership be removed if people repeatedly are not allowed onto the
> > PMC.
>
>
> Well, except that the process is that the PMC has to vote in a new committer
> to the PMC and then notify the board of that vote. I'm definitely not in
> favour of magic notifications to the board when the six months are up,
> without an associated vote.
i don't like the idea of magic notifications (to the board) but
something needs to be done: ATM we're dysfunctional. just take a look at
the nominations per nominator over the last year or two: nomination
hasn't become ingrained in the culture.
ATM we're slipping up but maybe statistics and reminders may be better
for the moment than automatic nomination...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Martin Cooper <ma...@apache.org>.
On 1/10/06, Henri Yandell <ba...@generationjava.com> wrote:
>
>
> As a second email in the Notice of intent series; here's what I think
> being a Jakarta component will be like in the future.
>
> * Jakarta is a collection of components. Hopefully all sitting at the same
> level. ie) a big bag of things.
>
> * Groups exist. These are categorically not subprojects, but a way to
> allow for slicing of the website etc. Some groups may have their own mail
> list; thus the importance of making sure they don't become subprojects. An
> important rule will probably be that they must do votes on the main list.
I prefer the term "groupings" (which, interestingly, you switch to below ;)
over "groups". I also think we should allow the component:grouping
relationship to be 1:N, since not all components will fit tidily into a
single grouping. As a corollary, I don't believe groupings should have their
own mailing lists.
Hopefully we can keep it at a point where the groups are really just there
> to refine the flow of mail, not to separate it. HttpComponents is an
> example of this (though not a good one as most of its components came from
> HttpClient). WebComponents (formerly hoped to be known as Silk) is another
> example.
>
> Commons would be groupalized out. Hopefully. Groupings are not vague names
> - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The
> idea with that being that boring grouping names are intentionally dull, no
> subcommunity identification.
>
> * No svn authentication beyond being in the jakarta group. Velocity coders
> have rw access to POI.
>
> * Improved Committer->PMC process. Chair's responsibility (I've failed at
> this so far) is to turn around the new committer process. A new committer
> of 6 months is effectively voted against going to the PMC, not for. Might
> not be able to make it exactly that way, but the idea being that joining
> the PMC is the exception, not the norm. Personally I'd like to see
> committership be removed if people repeatedly are not allowed onto the
> PMC.
Well, except that the process is that the PMC has to vote in a new committer
to the PMC and then notify the board of that vote. I'm definitely not in
favour of magic notifications to the board when the six months are up,
without an associated vote.
* Application of Commons thinking. Not entirely sure on this one as I
> think we've overcomplicated things in Commons a bit; but things like a
> common build system, common site system etc.
>
> * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the
> same rules as it has currently. Probably a separate mailing list.
A separate mailing list for the sandbox would be a double-edged sword.Yes,
it would keep the noise out of other mailing lists, but it also, at least,
partially condemns sandbox components to death, by limiting their exposure
much more than now. And if everyone has to subscribe to the sandbox list
anyway, to know what's happening, then a separate list is of limited
utility.
--
Martin Cooper
-----
>
> Shout, scream, yell :)
>
> Hen
>
> On Mon, 12 Dec 2005, Henri Yandell wrote:
>
> > dum de dum de dum.....
> >
> > Just to be public so that it doesn't look like I'm sneaking around
> > trying to manipulate things.
> >
> > --
> >
> > I'm starting to open the question of TLP on many of the Jakarta dev
> > mailing lists. It's with a general plan where we would see another
> > half a dozen subprojects move to TLP and then really leave Commons as
> > the main entity inside Jakarta along with some commons-like components
> > that are currently subprojects.
> >
> > I've been talking unofficially with lots of people at ApacheCon, so
> > I've had a fair bit of feedback on various bits. The important part is
> > that the loose plan above finds a way to coalesce the Jakarta
> > community into a much tighter, more TLP e like project.
> >
> > I've talked with a couple of board members to feel out things would
> > be. One question being, is it a problem if we're pushing a TLP with
> > just a few committers. The answer I had was that Excalibur is the
> > example TLP, it's rather dormant and it's not a problem.
> >
> > I was also advised to be a bit more active in pushing forward. I think
> > this makes sense, a lot of our cross-community activity is gone
> > because people with high activity tend to move to TLP, so we need a
> > bit more drive to get things done. Thus the change of tack that I'll
> > be trying to pull off without getting hung :)
> >
> > Please discuss, argue, wibble; but what I'm looking for are active
> > ways forward instead of maintaining the status quo. I don't think the
> > status quo is good for Jakarta as an entity, it puts strain on our
> > oversight because the number of subprojects stretches the chair's and
> > community in general's ability to keeps things covered.
> >
> > *denies the blindfold and stands against the wall waiting*
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: Notice of intent.... #2
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 10 Jan 2006, Martin van den Bemt wrote:
> Almost completely +1.
>
> One thing first : http://java.apache.org, redirects to archive.apache.org,
> while I still know people that are think java stuff stuff on apache.org is
> happening there, so maybe a redirect to a more friendly page could take place
> there ? (though this could be something for infrastructure/board).
Hmm. I'll mention it, there might be legal issues in active use of the
name.
> Henri Yandell wrote:
>>
>> * Improved Committer->PMC process. Chair's responsibility (I've failed at
>> this so far) is to turn around the new committer process. A new committer
>> of 6 months is effectively voted against going to the PMC, not for. Might
>> not be able to make it exactly that way, but the idea being that joining
>> the PMC is the exception, not the norm. Personally I'd like to see
>> committership be removed if people repeatedly are not allowed onto the PMC.
>>
>
> Just to make sure I get what you are saying : If you become a committer on
> jakarta, a vote will be helt automatically after 6 months (initiated by
> you/the Chair?), but not to accept the committer, but to not accept the
> committer becoming a member of the PMC ?
That's effectively the level I'd like to take it to. Really drive home the
'everyone should be on the PMC' meme. It's not much different than what
could exist today; ie) the chair calling votes based on time since
committership; so it's not a biggy - the important part is making a smooth
pipeline to the PMC.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Martin van den Bemt <ml...@mvdb.net>.
Almost completely +1.
One thing first : http://java.apache.org, redirects to archive.apache.org, while I still know people
that are think java stuff stuff on apache.org is happening there, so maybe a redirect to a more
friendly page could take place there ? (though this could be something for infrastructure/board).
Henri Yandell wrote:
>
> * Improved Committer->PMC process. Chair's responsibility (I've failed
> at this so far) is to turn around the new committer process. A new
> committer of 6 months is effectively voted against going to the PMC, not
> for. Might not be able to make it exactly that way, but the idea being
> that joining the PMC is the exception, not the norm. Personally I'd like
> to see committership be removed if people repeatedly are not allowed
> onto the PMC.
>
Just to make sure I get what you are saying : If you become a committer on jakarta, a vote will be
helt automatically after 6 months (initiated by you/the Chair?), but not to accept the committer,
but to not accept the committer becoming a member of the PMC ?
Mvgr,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Tim OBrien wrote:
> --- Stephen Colebourne <sc...@btopenworld.com>
>>For example:
>>- HttpComponents
>>- WebComponents
>>- LibraryComponents (narrowAPI-deep)
>>- BaseComponents (broadAPI-shallow)
>
> Explain that narrowAPI-deep, braodAPI-shallow
> business.
BroadAPI-Shallow
The principal API of the component is broad. That is, it consists of
lots of methods.
Each of those methods is Shallow. That is, each method does relatively
little processing.
Typically, these will not have config files.
Typically, these wil not have dependencies.
For example, a static Utils class.
For example, commons-lang, commons-io.
NarrowAPI-Deep
The principal API of the component is narrow. That is, there are
relatively few methods in the whole javadoc that most users should call.
Each of those 'external' methods is Deep. That is, each external method
performs a lot of internal work to achieve its goal.
Typically, these will have config files.
Typically, these wil have dependencies.
For example, commons-jxpath, oro.
I sugest these as groupings as I believe there is a difference in skills
in creating these two types of libraries. With NarrowDeep its all about
the making that narrow API as simple to understand, yet powerful, as
possible. With BroadShallow, there is a lot of work defining the method
exactly and in naming. (Plus lots of overap in skills too...)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Tim OBrien <to...@discursive.com>.
--- Stephen Colebourne <sc...@btopenworld.com>
wrote:
> For example:
> - HttpComponents
> - WebComponents
> - LibraryComponents (narrowAPI-deep)
> - BaseComponents (broadAPI-shallow)
Explain that narrowAPI-deep, braodAPI-shallow
business.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
>> Hopefully we can keep it at a point where the groups are really just
>> there to refine the flow of mail, not to separate it. HttpComponents
>> is an example of this (though not a good one as most of its components
>> came from HttpClient). WebComponents (formerly hoped to be known as
>> Silk) is another example.
>>
>> Commons would be groupalized out.
>
> Not sure I understand exactly what you mean here, but if it means
> breaking commons up - even the list - I think we should think very
> carefully about that. From what may be a selfish perspective - and
> which I will back off from if the rest of the community feels otherwise
> - I think getting feedback from the full group of commons committers and
> voluneers *really* helps those of us who work on commons components. I
> am afraid that if we break up the dev list and we don't all just agree
> to subscribe to all of the sublists (really defeating the purpose), we
> will both have a harder time building community around components and we
> will lose some valuable feedback. We will also have less collective
> energy to apply to things like the site, how we think about versioning
> and releases, etc. We are developing a pretty good body of collective
> experience developing small java components and I think that if we
> "split up" now we may be losing something.
I believe that this plan only works if we are prepared to have multiple
mailing lists. Try merging velocity, httpclient, taglibs,... all into
the commons list and its just ridiculous.
The question is how to break down the groupings. And how big should they
be. One rule would be that a component is only in one grouping.
For example:
- HttpComponents
- WebComponents
- LibraryComponents (narrowAPI-deep)
- BaseComponents (broadAPI-shallow)
site and build discussions can occur on a shared list.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent.... #2
Posted by Phil Steitz <ph...@steitz.com>.
Henri Yandell wrote:
>
> As a second email in the Notice of intent series; here's what I think
> being a Jakarta component will be like in the future.
>
> * Jakarta is a collection of components. Hopefully all sitting at the
> same level. ie) a big bag of things.
How are you defining "component"? Something reusable? Something you
build applications with? Something like a commons component? If that
is the case, then Jmeter, Cactus, Velocity et al would have to go TLP.
Is that part of the plan?
>
> * Groups exist. These are categorically not subprojects, but a way to
> allow for slicing of the website etc. Some groups may have their own
> mail list; thus the importance of making sure they don't become
> subprojects. An important rule will probably be that they must do
> votes on the main list.
>
> Hopefully we can keep it at a point where the groups are really just
> there to refine the flow of mail, not to separate it. HttpComponents
> is an example of this (though not a good one as most of its components
> came from HttpClient). WebComponents (formerly hoped to be known as
> Silk) is another example.
>
> Commons would be groupalized out.
Not sure I understand exactly what you mean here, but if it means
breaking commons up - even the list - I think we should think very
carefully about that. From what may be a selfish perspective - and
which I will back off from if the rest of the community feels otherwise
- I think getting feedback from the full group of commons committers and
voluneers *really* helps those of us who work on commons components. I
am afraid that if we break up the dev list and we don't all just agree
to subscribe to all of the sublists (really defeating the purpose), we
will both have a harder time building community around components and we
will lose some valuable feedback. We will also have less collective
energy to apply to things like the site, how we think about versioning
and releases, etc. We are developing a pretty good body of collective
experience developing small java components and I think that if we
"split up" now we may be losing something.
> Hopefully. Groupings are not vague names - HttpComponents good, Silk
> bad. CoreComponents good, Turbine bad. The idea with that being that
> boring grouping names are intentionally dull, no subcommunity
> identification.
+1 - as we at least used to state in the commons charter ;-)
>
> * No svn authentication beyond being in the jakarta group. Velocity
> coders have rw access to POI.
+1
>
> * Improved Committer->PMC process. Chair's responsibility (I've failed
> at this so far) is to turn around the new committer process. A new
> committer of 6 months is effectively voted against going to the PMC,
> not for. Might not be able to make it exactly that way, but the idea
> being that joining the PMC is the exception, not the norm. Personally
> I'd like to see committership be removed if people repeatedly are not
> allowed onto the PMC.
Not sure about this one. I am OK with kicking off the nomination more
or less automatically, but would prefer that it be a postive vote.
>
> * Application of Commons thinking. Not entirely sure on this one as I
> think we've overcomplicated things in Commons a bit; but things like a
> common build system, common site system etc.
>
> * Sandbox becomes a Jakarta resource, not a Commons resource. Much of
> the same rules as it has currently. Probably a separate mailing list.
I agree with Martin's comment on this.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Notice of intent.... #2
Posted by Henri Yandell <ba...@generationjava.com>.
As a second email in the Notice of intent series; here's what I think
being a Jakarta component will be like in the future.
* Jakarta is a collection of components. Hopefully all sitting at the same
level. ie) a big bag of things.
* Groups exist. These are categorically not subprojects, but a way to
allow for slicing of the website etc. Some groups may have their own mail
list; thus the importance of making sure they don't become subprojects. An
important rule will probably be that they must do votes on the main list.
Hopefully we can keep it at a point where the groups are really just there
to refine the flow of mail, not to separate it. HttpComponents is an
example of this (though not a good one as most of its components came from
HttpClient). WebComponents (formerly hoped to be known as Silk) is another
example.
Commons would be groupalized out. Hopefully. Groupings are not vague names
- HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The
idea with that being that boring grouping names are intentionally dull, no
subcommunity identification.
* No svn authentication beyond being in the jakarta group. Velocity coders
have rw access to POI.
* Improved Committer->PMC process. Chair's responsibility (I've failed at
this so far) is to turn around the new committer process. A new committer
of 6 months is effectively voted against going to the PMC, not for. Might
not be able to make it exactly that way, but the idea being that joining
the PMC is the exception, not the norm. Personally I'd like to see
committership be removed if people repeatedly are not allowed onto the
PMC.
* Application of Commons thinking. Not entirely sure on this one as I
think we've overcomplicated things in Commons a bit; but things like a
common build system, common site system etc.
* Sandbox becomes a Jakarta resource, not a Commons resource. Much of the
same rules as it has currently. Probably a separate mailing list.
-----
Shout, scream, yell :)
Hen
On Mon, 12 Dec 2005, Henri Yandell wrote:
> dum de dum de dum.....
>
> Just to be public so that it doesn't look like I'm sneaking around
> trying to manipulate things.
>
> --
>
> I'm starting to open the question of TLP on many of the Jakarta dev
> mailing lists. It's with a general plan where we would see another
> half a dozen subprojects move to TLP and then really leave Commons as
> the main entity inside Jakarta along with some commons-like components
> that are currently subprojects.
>
> I've been talking unofficially with lots of people at ApacheCon, so
> I've had a fair bit of feedback on various bits. The important part is
> that the loose plan above finds a way to coalesce the Jakarta
> community into a much tighter, more TLP e like project.
>
> I've talked with a couple of board members to feel out things would
> be. One question being, is it a problem if we're pushing a TLP with
> just a few committers. The answer I had was that Excalibur is the
> example TLP, it's rather dormant and it's not a problem.
>
> I was also advised to be a bit more active in pushing forward. I think
> this makes sense, a lot of our cross-community activity is gone
> because people with high activity tend to move to TLP, so we need a
> bit more drive to get things done. Thus the change of tack that I'll
> be trying to pull off without getting hung :)
>
> Please discuss, argue, wibble; but what I'm looking for are active
> ways forward instead of maintaining the status quo. I don't think the
> status quo is good for Jakarta as an entity, it puts strain on our
> oversight because the number of subprojects stretches the chair's and
> community in general's ability to keeps things covered.
>
> *denies the blindfold and stands against the wall waiting*
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Notice of intent....
Posted by Henri Yandell <ba...@generationjava.com>.
Wanted to state publically. Tapestry is definitely on my list of
subprojects that would make good TLPs (in fact it's top), and they've in
fact already talked about it before. However they seem to be in a final
release process, so I'm being a little gentle.
Just wanted to make sure no one thinks I'm forgetting them. :)
Hen
On Mon, 12 Dec 2005, Henri Yandell wrote:
> dum de dum de dum.....
>
> Just to be public so that it doesn't look like I'm sneaking around
> trying to manipulate things.
>
> --
>
> I'm starting to open the question of TLP on many of the Jakarta dev
> mailing lists. It's with a general plan where we would see another
> half a dozen subprojects move to TLP and then really leave Commons as
> the main entity inside Jakarta along with some commons-like components
> that are currently subprojects.
>
> I've been talking unofficially with lots of people at ApacheCon, so
> I've had a fair bit of feedback on various bits. The important part is
> that the loose plan above finds a way to coalesce the Jakarta
> community into a much tighter, more TLP e like project.
>
> I've talked with a couple of board members to feel out things would
> be. One question being, is it a problem if we're pushing a TLP with
> just a few committers. The answer I had was that Excalibur is the
> example TLP, it's rather dormant and it's not a problem.
>
> I was also advised to be a bit more active in pushing forward. I think
> this makes sense, a lot of our cross-community activity is gone
> because people with high activity tend to move to TLP, so we need a
> bit more drive to get things done. Thus the change of tack that I'll
> be trying to pull off without getting hung :)
>
> Please discuss, argue, wibble; but what I'm looking for are active
> ways forward instead of maintaining the status quo. I don't think the
> status quo is good for Jakarta as an entity, it puts strain on our
> oversight because the number of subprojects stretches the chair's and
> community in general's ability to keeps things covered.
>
> *denies the blindfold and stands against the wall waiting*
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org