You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/10/24 22:28:11 UTC
Structuring A-C internally by language or concern?
The current status document states that it is resolved that a-c is language
agnostic. There is no statement however about how a-c will manage the
multiple languages. So I've been musing...
1) One sub-project of a-c for each language, with each component effectively
a sub-sub-project within the language (eg.
commons.apache.org/java/collections)
2) One sub-project for each component ignoring language (eg.
commons.apache.org/collections). But then what happens if that component is
implemented in two languages?
This affects many things - how the mailing lists are structured, how the
website is structured, how the communities will form, etc.
I would like to see some clarification on this. The key aspect to me seems
to be the mailing list one:
Does it help to have C/C#/D/Perl/PHP/Java components on a shared mailing
list?
Or is per language better?
Or maybe we should have more mailing lists?
For example new mailing list groups could be formed along these lines:
a) Collections, IO, Lang, Pattern, Util, BeanUtils components from j-c (a
'Java core' list)
b) Betwixt, Digester from j-c, and components from XML-Commons (an 'XML'
list)
c) HttpClient and Net from j-c (a 'Networking' list)
d) Catch all for smaller components and the sandbox
(please don't debate the details of which component is in which (yet), its
an example!)
Now, I'm still only considering Java in these examples. This is because I
have real difficulty processing how non-Java code will fit in. Perhaps for
(a) it doesn't as thats very Java specific, but maybe for (b) and (c) it
does, because XML and Networking are more cross language concerns?
(To declare an interest for those who don't know, group (a) would be that
which would most affect me. Thus my proposal avoids me dealing with
non-java. But I'm proposing it because it seems to make some sense, not for
personal reasons)
IMHO, the good part about commons is the shared mailing list, but its also
the bad part. It strikes me that separation into smaller mailing lists
earlier in j-c's life might have been beneficial, even though the sense of
community seems to bind everyone to a single larger list.
And with mailing lists follows committer privileges, CVS structure, voting,
management etc etc.
Stephen
Re: [VOTE: commons lists]
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
oh gosh... per concept...please :-)
Greg Stein wrote:
>On Thu, Oct 24, 2002 at 05:15:10PM -0500, B. W. Fitzpatrick wrote:
>
>
>>[Somebody forgot to change the subject. Tsk. Tsk. :-) ]
>>
>>
>>
>>> [X] One mother general@ list, with specific breakouts when needed
>>> [ ] Per-concept mailing lists (define "concept" however)
>>> [ ] Per-language mailing lists
>>> [ ] ____________________________________________
>>>
>>>
>>The incubator PMC is going to have to keep an eye on things in the
>>main list and help breakout as necessary.
>>
>>
>
>s/incubator/commons/ I presume?
>
>And my vote:
>
> [X] Per-concept mailing lists (define "concept" however)
>
>
>Cheers,
>-g
>
>
>
Re: [VOTE: commons lists] - Bindingness?
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Oct 24, 2002 at 11:36:48PM +0100, Stephen Colebourne wrote:
> BTW: Whose votes are binding? or is this just indicative?
> Stephen
I personally would like to find out what everyone on this list thinks
about every vote or every issue. In one possible case, the people on
this list can make referendums that are ratified by the PMC. So, please
vote and voice your opinion.
-aaron
Re: [VOTE: commons lists] - Bindingness?
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Oct 24, 2002 at 06:19:44PM -0500, Michael A. Smith wrote:
> Just as an observation, one of the things that occurs in jakarta, is
> that there is hardly any discussion (that I know of) on the pmc@ mailing
> list. Instead, the Jakarta PMC elects to have their discussions on the
> general@ mailing list to ensure that all can have their voice heard.
In general I agree. One thing that I won't budge on is votes for a new
PMC member or committer. IMHO, those must happen on the PMC list.
> > I believe the list of initial committers to 'commons' (note: this doesn't
> > imply eventual commit privs on components) would be something like:
> >
> > sanders, scoleburne, mas, bayard, morgand
>
> Another observation: Each of these are jakarta-commons committers. :)
Please speak up, and feel free to nominate others. :)
-aaron
Re: [VOTE: commons lists] - Bindingness?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Greg Stein wrote:
[...]
> And we may as well start on recognizing certain committers, too. I'll start
> that discussion in the pmc@. We don't have any decision rules yet...
>
> I believe the list of initial committers to 'commons' (note: this doesn't
> imply eventual commit privs on components) would be something like:
>
> sanders, scoleburne, mas, bayard, morgand
>
> If I didn't list you, then please send in your name :-)
nicolaken
I've contacted the Turbine and Avalon lists about the creation of a
commmon repository of Avalon Components/Services here, and would like to
help the effort.
I'm also willing to help on the site, being a Forrest dev.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE: commons lists] - Bindingness?
Posted by Martin van den Bemt <ml...@mvdb.net>.
mvdb..
Mvgr,
Martin
On Fri, 2002-10-25 at 01:07, Greg Stein wrote:
> On Thu, Oct 24, 2002 at 03:51:44PM -0700, Scott Sanders wrote:
> > On Thu, Oct 24, 2002 at 03:44:05PM -0700, Greg Stein wrote:
> > > IMO, all the participants on this list are casting binding votes for the
> > > structure. The PMC would reserve the right to prevent "destructive" choices,
> > > but I can't see how poor mailing list organization could truly be labelled
> > > as destructive :-)
> > >
> > > As a matter of fact, I'm recording these votes right now in the STATUS
> > > document. In there, I'd consider the organizational aspects to be voted on
> > > by the affected community. However, I believe the PMC has the only binding
> > > votes for the charter (what is a "proper" component to be managed by this
> > > Project); you may note that I listed 'mas' as non-binding for one of the
> > > votes.
> >
> > Shall I just submit a patch with my name all over it then?
>
> Yup. That would work for now.
>
> And we may as well start on recognizing certain committers, too. I'll start
> that discussion in the pmc@. We don't have any decision rules yet...
>
> I believe the list of initial committers to 'commons' (note: this doesn't
> imply eventual commit privs on components) would be something like:
>
> sanders, scoleburne, mas, bayard, morgand
>
> If I didn't list you, then please send in your name :-)
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
Re: [VOTE: commons lists] - Bindingness?
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 24 Oct 2002, Greg Stein wrote:
> And we may as well start on recognizing certain committers, too. I'll start
> that discussion in the pmc@. We don't have any decision rules yet...
Just as an observation, one of the things that occurs in jakarta, is
that there is hardly any discussion (that I know of) on the pmc@ mailing
list. Instead, the Jakarta PMC elects to have their discussions on the
general@ mailing list to ensure that all can have their voice heard.
> I believe the list of initial committers to 'commons' (note: this doesn't
> imply eventual commit privs on components) would be something like:
>
> sanders, scoleburne, mas, bayard, morgand
Another observation: Each of these are jakarta-commons committers. :)
regards,
michael
--
Michael A. Smith
mas@apache.org
Re: [VOTE: commons lists] - Bindingness?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 24, 2002 at 03:51:44PM -0700, Scott Sanders wrote:
> On Thu, Oct 24, 2002 at 03:44:05PM -0700, Greg Stein wrote:
> > IMO, all the participants on this list are casting binding votes for the
> > structure. The PMC would reserve the right to prevent "destructive" choices,
> > but I can't see how poor mailing list organization could truly be labelled
> > as destructive :-)
> >
> > As a matter of fact, I'm recording these votes right now in the STATUS
> > document. In there, I'd consider the organizational aspects to be voted on
> > by the affected community. However, I believe the PMC has the only binding
> > votes for the charter (what is a "proper" component to be managed by this
> > Project); you may note that I listed 'mas' as non-binding for one of the
> > votes.
>
> Shall I just submit a patch with my name all over it then?
Yup. That would work for now.
And we may as well start on recognizing certain committers, too. I'll start
that discussion in the pmc@. We don't have any decision rules yet...
I believe the list of initial committers to 'commons' (note: this doesn't
imply eventual commit privs on components) would be something like:
sanders, scoleburne, mas, bayard, morgand
If I didn't list you, then please send in your name :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [VOTE: commons lists] - Bindingness?
Posted by Scott Sanders <sa...@apache.org>.
On Thu, Oct 24, 2002 at 03:44:05PM -0700, Greg Stein wrote:
> IMO, all the participants on this list are casting binding votes for the
> structure. The PMC would reserve the right to prevent "destructive" choices,
> but I can't see how poor mailing list organization could truly be labelled
> as destructive :-)
>
> As a matter of fact, I'm recording these votes right now in the STATUS
> document. In there, I'd consider the organizational aspects to be voted on
> by the affected community. However, I believe the PMC has the only binding
> votes for the charter (what is a "proper" component to be managed by this
> Project); you may note that I listed 'mas' as non-binding for one of the
> votes.
>
Shall I just submit a patch with my name all over it then?
--
Scott Sanders - sanders@apache.org
Re: [VOTE: commons lists] - Bindingness?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rodent of Unusual Size wrote:
>
> <chair hat="on">
>
> no. at the moment, only the pmc votes are binding. others are
> advisory/indicative, will most probably be followed if they appear
> objects, and certainly won't be ignored in any event, but i'm not
s/objects/objective/
Re: [VOTE: commons lists] - Bindingness?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> IMO, all the participants on this list are casting binding votes for the
> structure.
<chair hat="on">
no. at the moment, only the pmc votes are binding. others are
advisory/indicative, will most probably be followed if they appear
objects, and certainly won't be ignored in any event, but i'm not
going to permit this to start off with any particular group being
able to landslide any issues just by virtue of having more people.
</chair>
Re: [VOTE: commons lists] - Bindingness?
Posted by Greg Stein <gs...@lyra.org>.
IMO, all the participants on this list are casting binding votes for the
structure. The PMC would reserve the right to prevent "destructive" choices,
but I can't see how poor mailing list organization could truly be labelled
as destructive :-)
As a matter of fact, I'm recording these votes right now in the STATUS
document. In there, I'd consider the organizational aspects to be voted on
by the affected community. However, I believe the PMC has the only binding
votes for the charter (what is a "proper" component to be managed by this
Project); you may note that I listed 'mas' as non-binding for one of the
votes.
Cheers,
-g
On Thu, Oct 24, 2002 at 11:36:48PM +0100, Stephen Colebourne wrote:
> BTW: Whose votes are binding? or is this just indicative?
> Stephen
>
> ----- Original Message -----
> From: "Greg Stein" <gs...@lyra.org>
> To: <ge...@commons.apache.org>
> Sent: Thursday, October 24, 2002 11:32 PM
> Subject: Re: [VOTE: commons lists]
>
>
> > On Thu, Oct 24, 2002 at 05:15:10PM -0500, B. W. Fitzpatrick wrote:
> > >
> > > [Somebody forgot to change the subject. Tsk. Tsk. :-) ]
> > >
> > > > [X] One mother general@ list, with specific breakouts when needed
> > > > [ ] Per-concept mailing lists (define "concept" however)
> > > > [ ] Per-language mailing lists
> > > > [ ] ____________________________________________
> > >
> > > The incubator PMC is going to have to keep an eye on things in the
> > > main list and help breakout as necessary.
> >
> > s/incubator/commons/ I presume?
> >
> > And my vote:
> >
> > [X] Per-concept mailing lists (define "concept" however)
> >
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> > For additional commands, e-mail: general-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
--
Greg Stein, http://www.lyra.org/
Re: [VOTE: commons lists] - Bindingness?
Posted by Martin van den Bemt <ml...@mvdb.net>.
On Fri, 2002-10-25 at 00:36, Stephen Colebourne wrote:
> > >
> > > > [X] One mother general@ list, with specific breakouts when needed
> > > > [ ] Per-concept mailing lists (define "concept" however)
> > > > [ ] Per-language mailing lists
> > > > [ ] ____________________________________________
> > >
My vote too..
Mvgr,
Martin
Re: [VOTE: commons lists] - Bindingness?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
BTW: Whose votes are binding? or is this just indicative?
Stephen
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: <ge...@commons.apache.org>
Sent: Thursday, October 24, 2002 11:32 PM
Subject: Re: [VOTE: commons lists]
> On Thu, Oct 24, 2002 at 05:15:10PM -0500, B. W. Fitzpatrick wrote:
> >
> > [Somebody forgot to change the subject. Tsk. Tsk. :-) ]
> >
> > > [X] One mother general@ list, with specific breakouts when needed
> > > [ ] Per-concept mailing lists (define "concept" however)
> > > [ ] Per-language mailing lists
> > > [ ] ____________________________________________
> >
> > The incubator PMC is going to have to keep an eye on things in the
> > main list and help breakout as necessary.
>
> s/incubator/commons/ I presume?
>
> And my vote:
>
> [X] Per-concept mailing lists (define "concept" however)
>
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
Re: [VOTE: commons lists]
Posted by robert burrell donkin <rd...@apache.org>.
On Friday, October 25, 2002, at 09:12 AM, Sander Striker wrote:
> [ ] One mother general@ list, with specific breakouts when needed
> [X] Per-concept mailing lists (define "concept" however)
the only way that the jakarta-commons dev mailing list can function is
through the 'prefix rule' that is, all posts should be prefixed. in the
jakarta-commons we have well-established components all of which are peers.
so, you prefix with the component name eg. 'subject: [digester] how about
a new release?'.
it would not be possible to cope with the traffic with this rule. (indeed,
i don't think that i'll be able to cope with the traffic on this list for
much longer without being able to filter on subject prefix.)
i'd like to suggest this rule is adopted here with a slight variation. we
try concept prefixes (as well as component ones). breakouts from the
commons-dev happen because it's easy to spot which components are
generating a lot of traffic. when a component becomes too popular, it's
moved to it's own list. but this also ensures that this list will be
successful since it'll have a critical mass of email posts.
prefixing is a more flexible approach than simply creating concept based
mailing lists. popular concepts would be easy to identify and new concepts
would be easy to create. of course, we'd need a list of official concepts
but that'd be easier to maintain than physical mailing lists.
if we do go down the concept-based approach, i'd also like to see
components broken out with their concepts. so if [http client] concept
becomes to popular for the mother list, then components closely associated
with the concept should be broken out as well.
- robert
RE: [VOTE: commons lists]
Posted by Sander Striker <st...@apache.org>.
[ ] One mother general@ list, with specific breakouts when needed
[X] Per-concept mailing lists (define "concept" however)
[ ] Per-language mailing lists
[ ] ____________________________________________
Sander
Re: [VOTE: commons lists]
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 24, 2002 at 05:15:10PM -0500, B. W. Fitzpatrick wrote:
>
> [Somebody forgot to change the subject. Tsk. Tsk. :-) ]
>
> > [X] One mother general@ list, with specific breakouts when needed
> > [ ] Per-concept mailing lists (define "concept" however)
> > [ ] Per-language mailing lists
> > [ ] ____________________________________________
>
> The incubator PMC is going to have to keep an eye on things in the
> main list and help breakout as necessary.
s/incubator/commons/ I presume?
And my vote:
[X] Per-concept mailing lists (define "concept" however)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Structuring A-C internally by language or concern?
Posted by Henri Yandell <ba...@generationjava.com>.
> > [X] One mother general@ list, with specific breakouts when needed
> > [ ] Per-concept mailing lists (define "concept" however)
> > [ ] Per-language mailing lists
> > [ ] ____________________________________________
> >
Re: Structuring A-C internally by language or concern?
Posted by Scott Sanders <sa...@apache.org>.
On Thu, Oct 24, 2002 at 03:10:59PM -0700, Greg Stein wrote:
> Here we go:
>
> [X] One mother general@ list, with specific breakouts when needed
> [ ] Per-concept mailing lists (define "concept" however)
> [ ] Per-language mailing lists
> [ ] ____________________________________________
>
>
--
Scott Sanders - sanders@apache.org
Re: [VOTE: commons lists]
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 4 Nov 2002, Scott Sanders wrote:
> On Mon, Nov 04, 2002 at 09:03:22AM -0500, Henri Yandell wrote:
> > On Mon, 4 Nov 2002, Geir Magnusson Jr. wrote:
> > > -1 on mandatory enforcement, but +1 on encouragement.
> > >
> > > You'll find that with the slosh of messages for unrelated projects on the
> > > commons list, having a hint of what to read or dump is very helpful.
> >
> > Still, it will lead to an increase of the number of times [d] has to be
> > hit. Would be nice to have a mail-agent in which I can hit 'D' or
> > something and it will kill anything in that thread.
> >
>
> Already done. http://www.mutt.org. Exactly the reason I use mutt is the threading capability.
>
I will repeat my efforts to move to mutt. Have tried before and it so
blows up my existing system [copies inbox to a new location, sorts the
actual file and not just the view] that I run away each time.
Having a feature to go there for might help, so I'll try again.
Thanks,
Hen
Re: [VOTE: commons lists]
Posted by Scott Sanders <sa...@apache.org>.
On Mon, Nov 04, 2002 at 09:03:22AM -0500, Henri Yandell wrote:
> On Mon, 4 Nov 2002, Geir Magnusson Jr. wrote:
> > -1 on mandatory enforcement, but +1 on encouragement.
> >
> > You'll find that with the slosh of messages for unrelated projects on the
> > commons list, having a hint of what to read or dump is very helpful.
>
> Still, it will lead to an increase of the number of times [d] has to be
> hit. Would be nice to have a mail-agent in which I can hit 'D' or
> something and it will kill anything in that thread.
>
Already done. http://www.mutt.org. Exactly the reason I use mutt is the threading capability.
--
Scott Sanders - sanders@apache.org
Re: [VOTE: commons lists]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Aaron Bannert wrote:
>
> You can always filter on the List-Post: headers. Please don't
> clutter up my subject line. :)
the problem being that a single large list will have a single
list-post header field.. that's why hen suggested frobbing the
subject line.
Re: [VOTE: commons lists]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Aaron Bannert wrote:
>
> My mistake. I thought we were talking about putting automated
> [fooproject] entries in our subject lines. If we are
> considering voluntarily putting [fooproject] in the subject
> when talking about a subproject on a shared list, then that
> seems obvious to me and I'm confused why we are talking about
> this.
hen suggested configuring the mlm so that it would reject any
messages that *didn't* have a '[.*]' in the subject line. thus
making semi-focussed target audiences required. or something
like that.
Re: [VOTE: commons lists]
Posted by Aaron Bannert <aa...@clove.org>.
My mistake. I thought we were talking about putting automated [fooproject]
entries in our subject lines. If we are considering voluntarily putting
[fooproject] in the subject when talking about a subproject on a shared
list, then that seems obvious to me and I'm confused why we are talking
about this. You're not going to get your filter to be perfect when humans
are involved, however.
-aaron
On Mon, Nov 04, 2002 at 12:21:10PM -0800, John McNally wrote:
> How can specifying the code you are talking about be considered clutter,
> are you objecting to using delimiters such as []?
Re: [VOTE: commons lists]
Posted by John McNally <jm...@collab.net>.
How can specifying the code you are talking about be considered clutter,
are you objecting to using delimiters such as []?
On Mon, 2002-11-04 at 11:51, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 09:03:22AM -0500, Henri Yandell wrote:
> > > > Personally, I don't think adding such fields to the subject line is a
> > > > good idea. IMHO, a far better thing is to just have meaningful
> > > > subject lines in the first place. -- justin
> >
> > I'm fine with the sentiment, but mail filters don't deal with meaningful
> > subject lines.
>
> You can always filter on the List-Post: headers. Please don't clutter
> up my subject line. :)
>
> -aaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
Re: [VOTE: commons lists]
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 09:03:22AM -0500, Henri Yandell wrote:
> > > Personally, I don't think adding such fields to the subject line is a
> > > good idea. IMHO, a far better thing is to just have meaningful
> > > subject lines in the first place. -- justin
>
> I'm fine with the sentiment, but mail filters don't deal with meaningful
> subject lines.
You can always filter on the List-Post: headers. Please don't clutter
up my subject line. :)
-aaron
Re: [VOTE: commons lists]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
* On 2002-11-04 at 09:46,
Sander Striker <st...@apache.org> excited the electrons to say:
>
> I don't see what it helps us to put all msgs in one list if people
> are (going to be) filtering them out by subject anyway.
it's the issue of choice. in the above case, people == 'some people'.
if the issues are split out, people == 'all people' because we're
forcing the filtering on them. do not make the mistake of equating
the two scenaria.
RE: [VOTE: commons lists]
Posted by Sander Striker <st...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: 04 November 2002 15:03
> On Mon, 4 Nov 2002, Geir Magnusson Jr. wrote:
>
> > On 11/3/02 10:41 PM, "Justin Erenkrantz" <je...@apache.org> wrote:
> >
> > > --On Sunday, November 3, 2002 7:33 PM -0500 Henri Yandell
> > > <ba...@generationjava.com> wrote:
> > >
> > >> Exactly [regex bit]. Commons and Jakarta-Taglibs both work well when
> > >> people obey this convention [with [general] as an 'everyone' one],
> > >> but enforcing it would stop the frequent times when a new user to
> > >> the Dev list has to be given the speech.
> > >>
> > >> Also stops us forgetting too :)
> > >
> > > -1 on mandatory enforcement of this.
> > >
> > > If people want to have this as a convention fine, but this should not
> > > be required.
> > >
> > > Personally, I don't think adding such fields to the subject line is a
> > > good idea. IMHO, a far better thing is to just have meaningful
> > > subject lines in the first place. -- justin
>
> I'm fine with the sentiment, but mail filters don't deal with meaningful
> subject lines.
I don't see what it helps us to put all msgs in one list if people
are (going to be) filtering them out by subject anyway. We might aswell
split lists (to hold related projects?) and have a bigmother@ list subscribed
to all lists, so that the people who wish to see all traffic can do so by
only subscribing to bigmother@.
Sander
Re: [VOTE: commons lists]
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 4 Nov 2002, Geir Magnusson Jr. wrote:
> On 11/3/02 10:41 PM, "Justin Erenkrantz" <je...@apache.org> wrote:
>
> > --On Sunday, November 3, 2002 7:33 PM -0500 Henri Yandell
> > <ba...@generationjava.com> wrote:
> >
> >> Exactly [regex bit]. Commons and Jakarta-Taglibs both work well when
> >> people obey this convention [with [general] as an 'everyone' one],
> >> but enforcing it would stop the frequent times when a new user to
> >> the Dev list has to be given the speech.
> >>
> >> Also stops us forgetting too :)
> >
> > -1 on mandatory enforcement of this.
> >
> > If people want to have this as a convention fine, but this should not
> > be required.
> >
> > Personally, I don't think adding such fields to the subject line is a
> > good idea. IMHO, a far better thing is to just have meaningful
> > subject lines in the first place. -- justin
I'm fine with the sentiment, but mail filters don't deal with meaningful
subject lines.
> -1 on mandatory enforcement, but +1 on encouragement.
>
> You'll find that with the slosh of messages for unrelated projects on the
> commons list, having a hint of what to read or dump is very helpful.
Still, it will lead to an increase of the number of times [d] has to be
hit. Would be nice to have a mail-agent in which I can hit 'D' or
something and it will kill anything in that thread.
Hen
Re: [VOTE: commons lists]
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 11/3/02 10:41 PM, "Justin Erenkrantz" <je...@apache.org> wrote:
> --On Sunday, November 3, 2002 7:33 PM -0500 Henri Yandell
> <ba...@generationjava.com> wrote:
>
>> Exactly [regex bit]. Commons and Jakarta-Taglibs both work well when
>> people obey this convention [with [general] as an 'everyone' one],
>> but enforcing it would stop the frequent times when a new user to
>> the Dev list has to be given the speech.
>>
>> Also stops us forgetting too :)
>
> -1 on mandatory enforcement of this.
>
> If people want to have this as a convention fine, but this should not
> be required.
>
> Personally, I don't think adding such fields to the subject line is a
> good idea. IMHO, a far better thing is to just have meaningful
> subject lines in the first place. -- justin
-1 on mandatory enforcement, but +1 on encouragement.
You'll find that with the slosh of messages for unrelated projects on the
commons list, having a hint of what to read or dump is very helpful.
geir
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
Re: [VOTE: commons lists]
Posted by Justin Erenkrantz <je...@apache.org>.
--On Sunday, November 3, 2002 7:33 PM -0500 Henri Yandell
<ba...@generationjava.com> wrote:
> Exactly [regex bit]. Commons and Jakarta-Taglibs both work well when
> people obey this convention [with [general] as an 'everyone' one],
> but enforcing it would stop the frequent times when a new user to
> the Dev list has to be given the speech.
>
> Also stops us forgetting too :)
-1 on mandatory enforcement of this.
If people want to have this as a convention fine, but this should not
be required.
Personally, I don't think adding such fields to the subject line is a
good idea. IMHO, a far better thing is to just have meaningful
subject lines in the first place. -- justin
Re: [VOTE: commons lists]
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 3 Nov 2002, Rodent of Unusual Size wrote:
> Henri Yandell wrote:
> >
> > Is it possible for the list itself to refuse any mail which does not have
> > a [..] in the title?
>
> probably; i'd have to check. you like as in requiring every post to
> have something like '[java-regex]' or '[c-regex]' in the subject?
> yes, my suggestion to filter things didn't provide much to work
> from, did it. :-/
Exactly [regex bit]. Commons and Jakarta-Taglibs both work well when
people obey this convention [with [general] as an 'everyone' one], but
enforcing it would stop the frequent times when a new user to the Dev list
has to be given the speech.
Also stops us forgetting too :)
Hen
Re: [VOTE: commons lists]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Henri Yandell wrote:
>
> Is it possible for the list itself to refuse any mail which does not have
> a [..] in the title?
probably; i'd have to check. you like as in requiring every post to
have something like '[java-regex]' or '[c-regex]' in the subject?
yes, my suggestion to filter things didn't provide much to work
from, did it. :-/
Re: [VOTE: commons lists]
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 3 Nov 2002, Rodent of Unusual Size wrote:
> [+1] One mother general@ list, with specific breakouts when needed
> [-1] Per-concept mailing lists (define "concept" however)
> [-1] Per-language mailing lists
>
> i'm bothered by the 'i don't want to see what the <other-foo> people
> are working on' syndrome i've seen some people express here. well,
> maybe you aren't -- so filter it out.
Is it possible for the list itself to refuse any mail which does not have
a [..] in the title?
Hen
Re: [VOTE: commons lists]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
[+1] One mother general@ list, with specific breakouts when needed
[-1] Per-concept mailing lists (define "concept" however)
[-1] Per-language mailing lists
i'm bothered by the 'i don't want to see what the <other-foo> people
are working on' syndrome i've seen some people express here. well,
maybe you aren't -- so filter it out. *they* may want to see *yours*.
and before someone says 'then let them subscribe to the <my-foo> list',
i'll say that's bogus. they need to know a) that the list exists, and
b) that there might be stuff that's useful/instructive to them on it.
i want to see us practise inclusion by default, not exclusion.
maybe the language constructs in java may not be useful to c people --
but the algorithms and concepts may be.
Re: Structuring A-C internally by language or concern?
Posted by Peter Donald <pe...@apache.org>.
On Fri, 25 Oct 2002 08:56, Greg Stein wrote:
> As a Granter of Karma (ba-boom...), I don't mind this. I really don't think
> the addition of committers is all that frequent. *Maybe* one a week? (after
> the initial onslaught) If it gets problematic, then we have two approaches:
>
> 1) use tools to ease karma management
> 2) remove karma commit restrictions and move to "adult" mode
>
> I'd take option (1). A while ago (geez, maybe just a day or two? :-), I
> thought that using the "we're all adults" mode would be workable. But then
> I realized that it actually isn't. A non-committer might commit "just that
> teeny little patch; what's the problem?" Do that a couple more times. But
> then, some day, commit one that is just on the boundary of Right. At that
> point, it then becomes real ugly. "but I've committed little patches
> before" "but that one wasn't Right" "huh? it is a little change!" etc etc
>
> As a result, I think that a more drawn out line might be important.
+1
--
Cheers,
Peter Donald
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
Re: Structuring A-C internally by language or concern?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 24, 2002 at 11:21:35PM +0100, Stephen Colebourne wrote:
>...
> My concepts are logically related groups of components. Core, Networking,
> XML, DB, GUI, Testing, Building. I'm trying to avoid listing too many, as
> that defeats the purpose of per-concept.
>
> (The purpose being that as small components, shared lists build a greater
> community)
That is precisely my thinking, too. !!
> After some thought, I would accept cross language mailing lists, although I
> would prefer separate ones. It may be a case of starting with a cross
> language Networking list, and if the traffic gets too high splitting into
> per language lists. It might b a good way to get the community going.
Agreed. I believe cross-language should be the default. We apply our normal
rules of "is a component's traffic swamping others? if so, break it out"
> > > The exception comes if two languages share a mailing list. In that case
> CVS
> > > commit priveledges should probably be separated by language.
> >
> > I think commit privs should be per-component.
>
> I don't mind this. I just think its a big burden on those who can grant
> karma.
As a Granter of Karma (ba-boom...), I don't mind this. I really don't think
the addition of committers is all that frequent. *Maybe* one a week? (after
the initial onslaught) If it gets problematic, then we have two approaches:
1) use tools to ease karma management
2) remove karma commit restrictions and move to "adult" mode
I'd take option (1). A while ago (geez, maybe just a day or two? :-), I
thought that using the "we're all adults" mode would be workable. But then I
realized that it actually isn't. A non-committer might commit "just that
teeny little patch; what's the problem?" Do that a couple more times. But
then, some day, commit one that is just on the boundary of Right. At that
point, it then becomes real ugly. "but I've committed little patches before"
"but that one wasn't Right" "huh? it is a little change!" etc etc
As a result, I think that a more drawn out line might be important.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Structuring A-C internally by language or concern?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Greg Stein" <gs...@lyra.org>
> Let's plan out the *style* of multiple lists. But until we actually get
the
> components to fall into those lists, then let's defer their creation and
> final specification. Stephen listed a bunch of components and a possible
> breakdown, but we can't choose that UNTIL we know those components will
> transfer themselves. And who knows what is going to arrive? I have zero
> visibility into the assortment of Avalon, J-C, and XML reusable
components.
>
> So I'm advocating "figure them out on-demand *as* new components arrive".
>
> Here we go:
>
> [ ] One mother general@ list, with specific breakouts when needed
> [X] Per-concept mailing lists (define "concept" however)
> [ ] Per-language mailing lists
> [ ] ____________________________________________
My concepts are logically related groups of components. Core, Networking,
XML, DB, GUI, Testing, Building. I'm trying to avoid listing too many, as
that defeats the purpose of per-concept.
(The purpose being that as small components, shared lists build a greater
community)
After some thought, I would accept cross language mailing lists, although I
would prefer separate ones. It may be a case of starting with a cross
language Networking list, and if the traffic gets too high splitting into
per language lists. It might b a good way to get the community going.
> > The exception comes if two languages share a mailing list. In that case
CVS
> > commit priveledges should probably be separated by language.
>
> I think commit privs should be per-component.
I don't mind this. I just think its a big burden on those who can grant
karma.
Stephen
Re: Structuring A-C internally by language or concern?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 24, 2002 at 10:28:40PM +0100, Stephen Colebourne wrote:
> From: "Justin Erenkrantz" <je...@apache.org>
> > As we have discussed before, I believe we are going to stick with a
> > single email list for all of commons. If/when a particular group
> > takes over the mailing list, someone could suggest a new mailing list
> > to be created. (I'd say majority of the participants on the list get
> > to decide if the new list should be created.)
> >
> > I prefer that we evolve the infrastructure rather than hash out an
> > infrastructure from the beginning. -- justin
Right. Forward motion good. Blocking bad.
> Please, noooo ;-)
>
> The j-c commons mailing list is already very, very busy. A reorg of this
> nature is the time to think about breaking that down into smaller lists. if
> done correctly, the committers on the mailing lists naturally fall out to be
> those that should have access to that part of the CVS, very much like j-c
> current (pretty successful) model, but with more controls.
Let's plan out the *style* of multiple lists. But until we actually get the
components to fall into those lists, then let's defer their creation and
final specification. Stephen listed a bunch of components and a possible
breakdown, but we can't choose that UNTIL we know those components will
transfer themselves. And who knows what is going to arrive? I have zero
visibility into the assortment of Avalon, J-C, and XML reusable components.
So I'm advocating "figure them out on-demand *as* new components arrive".
Here we go:
[ ] One mother general@ list, with specific breakouts when needed
[ ] Per-concept mailing lists (define "concept" however)
[ ] Per-language mailing lists
[ ] ____________________________________________
> The exception comes if two languages share a mailing list. In that case CVS
> commit priveledges should probably be separated by language.
I think commit privs should be per-component. That easily solves the
per-language issue above, and it also solves the cross-concept-domain
problem (e.g. there is no way a Xerces developer should have commit access
to the HTTP client code (C or Java!) unless they demonstrated commitment
and competency).
I'll also state: the "per-component" rule should be the default. There is
*NOTHING* preventing multiple components from sharing the same set of
committers. If 5 components want to aggregate their committer maintenance,
then fine. It is up to those 5 to choose that.
[ and the Commons PMC should be defining ways to enable this and make it
easy for the components to self-organize ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Structuring A-C internally by language or concern?
Posted by Henri Yandell <ba...@generationjava.com>.
But at the same time there's been a lot of +ve talk for having a general
commons list which allows components to become aware of each other.
Without it projects would vanish away into their own receptacles.
So we need both? Top level mail list for general things [this list?] and
then a bottom level one per component. And then one per category
[language/functionality/colour-hair]?
Hen
On Thu, 24 Oct 2002, Andrew C. Oliver wrote:
> Yeah... J-C is a PAIN because of this. Its impracticle to build a
> community with all the other communities talking over you.
>
> Stephen Colebourne wrote:
>
> >----- Original Message -----
> >From: "Justin Erenkrantz" <je...@apache.org>
> >
> >
> >>As we have discussed before, I believe we are going to stick with a
> >>single email list for all of commons. If/when a particular group
> >>takes over the mailing list, someone could suggest a new mailing list
> >>to be created. (I'd say majority of the participants on the list get
> >>to decide if the new list should be created.)
> >>
> >>I prefer that we evolve the infrastructure rather than hash out an
> >>infrastructure from the beginning. -- justin
> >>
> >>
> >
> >Please, noooo ;-)
> >
> >The j-c commons mailing list is already very, very busy. A reorg of this
> >nature is the time to think about breaking that down into smaller lists. if
> >done correctly, the committers on the mailing lists naturally fall out to be
> >those that should have access to that part of the CVS, very much like j-c
> >current (pretty successful) model, but with more controls.
> >
> >The exception comes if two languages share a mailing list. In that case CVS
> >commit priveledges should probably be separated by language.
> >
> >Stephen
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> >For additional commands, e-mail: general-help@commons.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
Re: Structuring A-C internally by language or concern?
Posted by "Andrew C. Oliver" <an...@superlinksoftware.com>.
Yeah... J-C is a PAIN because of this. Its impracticle to build a
community with all the other communities talking over you.
Stephen Colebourne wrote:
>----- Original Message -----
>From: "Justin Erenkrantz" <je...@apache.org>
>
>
>>As we have discussed before, I believe we are going to stick with a
>>single email list for all of commons. If/when a particular group
>>takes over the mailing list, someone could suggest a new mailing list
>>to be created. (I'd say majority of the participants on the list get
>>to decide if the new list should be created.)
>>
>>I prefer that we evolve the infrastructure rather than hash out an
>>infrastructure from the beginning. -- justin
>>
>>
>
>Please, noooo ;-)
>
>The j-c commons mailing list is already very, very busy. A reorg of this
>nature is the time to think about breaking that down into smaller lists. if
>done correctly, the committers on the mailing lists naturally fall out to be
>those that should have access to that part of the CVS, very much like j-c
>current (pretty successful) model, but with more controls.
>
>The exception comes if two languages share a mailing list. In that case CVS
>commit priveledges should probably be separated by language.
>
>Stephen
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
>For additional commands, e-mail: general-help@commons.apache.org
>
>
>
>
Re: Structuring A-C internally by language or concern?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
----- Original Message -----
From: "Justin Erenkrantz" <je...@apache.org>
> As we have discussed before, I believe we are going to stick with a
> single email list for all of commons. If/when a particular group
> takes over the mailing list, someone could suggest a new mailing list
> to be created. (I'd say majority of the participants on the list get
> to decide if the new list should be created.)
>
> I prefer that we evolve the infrastructure rather than hash out an
> infrastructure from the beginning. -- justin
Please, noooo ;-)
The j-c commons mailing list is already very, very busy. A reorg of this
nature is the time to think about breaking that down into smaller lists. if
done correctly, the committers on the mailing lists naturally fall out to be
those that should have access to that part of the CVS, very much like j-c
current (pretty successful) model, but with more controls.
The exception comes if two languages share a mailing list. In that case CVS
commit priveledges should probably be separated by language.
Stephen
Re: Structuring A-C internally by language or concern?
Posted by Peter Donald <pe...@apache.org>.
On Fri, 25 Oct 2002 07:05, Justin Erenkrantz wrote:
> (A SCM that supported moving of directories and files would be real
> nice. Heh. I wonder...)
+1 +1 +1 +1 ... oh wait ... you didn't propose anything .. .yet ;)
> I prefer that we evolve the infrastructure rather than hash out an
> infrastructure from the beginning. -- justin
+1
--
Cheers,
Peter Donald
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
Re: Structuring A-C internally by language or concern?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 24 Oct 2002, Justin Erenkrantz wrote:
> --On Thursday, October 24, 2002 9:28 PM +0100 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
> > 2) One sub-project for each component ignoring language (eg.
> > commons.apache.org/collections). But then what happens if that
> > component is implemented in two languages?
>
> IMHO, it would then be up to the component to create divisions
> internally based on language.
>
> That is:
>
> commons/httpclient
>
> could initiallty start out with the codebase from apr-serf. If the
> httpclient from Jakarta wants to come over, then the serf committers
> and the httpclient committers can duke it out. But, the httpclient
> is their collective place to play. It's their responsibility to sort
> out the code divisions. (I would probably suggest
> commons/httpclient/serf, commons/httpclient/java, but I don't really
> care to think about it until it happens.)
This seems bad. Each component will have to tackle the same cross-language
problems over and over again. We'll end up with an enourmous mess of a
system in which crossing from one component to another will involve
learning a new setup/system.
It seems all your doing is turning the current system of components being
organised for a language but with no sharing of functionality into a
system in which components are ordered by functionality but with no sharing of
language.
Even worse, each component will immediately become a fiefdom. The first to
the commons.apache.org/xxx/java will give it a definite java feel. the
first to commons.apache.org/xxx/c will not.
Another thing is raised by the serf/httpclient thing. How will they be
named. In this example we're merging APR-Serf and Jakarta-HttpClient. Your
suggestion of:
commons.apache.org/httpclient/serf
............................./java
seems unbalanced. To be pure flamebait, serf should rename to C or
httpclient should not be the top level name etc :)
To be less flamebait, this naming problem will happen as well. The first
project in will name the category and then the following projects will
hesitate to join. However there's no reason to say that components will be
split on language. Take regexp. It's gonna have to fit at least 2 Java
implementations in.
If these are just allowed to float, you're going to have an anarchy of a
mess on your hands.
Hen
Re: Structuring A-C internally by language or concern?
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
robert burrell donkin wrote:
>
> therefore, i'd prefer to see each component language specific and managed
> as a separate releasable unit. so, in this case, i think that the java and
> c versions of httpclient should exist as separate components which can
> have their own release cycles etc.
absolutely. no particular component is going to be forced to/prevented from
releasing because another-language implementation of the same component is/isn't
ready. for example, releases of a java http client (or a c regex library) will
not be dependent in any way upon any other implentations in progress elsewhere
in commons.
unless, of course, there is an actual code dependency. :-)
Re: Structuring A-C internally by language or concern?
Posted by robert burrell donkin <rd...@apache.org>.
On Thursday, October 24, 2002, at 10:05 PM, Justin Erenkrantz wrote:
> --On Thursday, October 24, 2002 9:28 PM +0100 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
>> 2) One sub-project for each component ignoring language (eg.
>> commons.apache.org/collections). But then what happens if that
>> component is implemented in two languages?
>
> IMHO, it would then be up to the component to create divisions internally
> based on language.
>
> That is:
>
> commons/httpclient
>
> could initiallty start out with the codebase from apr-serf. If the
> httpclient from Jakarta wants to come over, then the serf committers and
> the httpclient committers can duke it out. But, the httpclient is their
> collective place to play. It's their responsibility to sort out the code
> divisions. (I would probably suggest commons/httpclient/serf,
> commons/httpclient/java, but I don't really care to think about it until
> it happens.)
from my experience in jakarta-commons, i'd say that small, focused
components are the way to go.
therefore, i'd prefer to see each component language specific and managed
as a separate releasable unit. so, in this case, i think that the java and
c versions of httpclient should exist as separate components which can
have their own release cycles etc.
in terms of namespaces, i think here jakarta (and the other
maybe-federations) could be used to our advantage. if the java version is
namespaced jakarta-httpclient then there would be no confusion with
apr-httpclient (or serf-httpclient).
- robert
Re: Structuring A-C internally by language or concern?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Thursday, October 24, 2002 9:28 PM +0100 Stephen Colebourne
<sc...@btopenworld.com> wrote:
> 2) One sub-project for each component ignoring language (eg.
> commons.apache.org/collections). But then what happens if that
> component is implemented in two languages?
IMHO, it would then be up to the component to create divisions
internally based on language.
That is:
commons/httpclient
could initiallty start out with the codebase from apr-serf. If the
httpclient from Jakarta wants to come over, then the serf committers
and the httpclient committers can duke it out. But, the httpclient
is their collective place to play. It's their responsibility to sort
out the code divisions. (I would probably suggest
commons/httpclient/serf, commons/httpclient/java, but I don't really
care to think about it until it happens.)
(A SCM that supported moving of directories and files would be real
nice. Heh. I wonder...)
> This affects many things - how the mailing lists are structured,
> how the website is structured, how the communities will form, etc.
As we have discussed before, I believe we are going to stick with a
single email list for all of commons. If/when a particular group
takes over the mailing list, someone could suggest a new mailing list
to be created. (I'd say majority of the participants on the list get
to decide if the new list should be created.)
I prefer that we evolve the infrastructure rather than hash out an
infrastructure from the beginning. -- justin
Re: Structuring A-C internally by language or concern?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 24 Oct 2002, Scott Sanders wrote:
> On Thu, Oct 24, 2002 at 09:28:11PM +0100, Stephen Colebourne wrote:
>
> > 2) One sub-project for each component ignoring language (eg.
> > commons.apache.org/collections). But then what happens if that component is
> > implemented in two languages?
> >
>
> Why not 3) concern areas, like your mailing list suggestions: xml
> serialization, http clients, language libraries (the biggest thing
> that is missing in most languages), etc?
I think if we're to try and think as A-Cers and not J-Cers, this makes the
most sense. My instinct is that language libraries [like Stephen I'm
predominately interested in this] will not share much, but then I think
about it a bit. C and Java will share very little, however C# and Java
will pratically clone each other. In fact C# Commons should be whispering
to Java Commons about things in the C#-SDK and vice-versa. Same for other
Java-like libraries.
Equally, when templates are added to Java in 1.5 [hopefully], the C++
Commons ought to be able to step in with a lot of ideas already.
So I'm warming to the idea of cross-language community. When I thought of
it as C and Java it was just too extreme, but if I hypothesis new
languages at Apache then it makes more interesting sense.
> > This affects many things - how the mailing lists are structured, how the
> > website is structured, how the communities will form, etc.
> >
> > I would like to see some clarification on this. The key aspect to me seems
> > to be the mailing list one:
> >
> > Does it help to have C/C#/D/Perl/PHP/Java components on a shared mailing
> > list?
>
> IMHO it does from the standpoint that for instance, NTLM
> authentication affects both serf and httpclient, and I have seen
> myself learning things from those people well-versed in other
> languages on algorithms and such.
Matrix of mail lists. Language and functionality group.
Of course that brings in the wonder of cross-posting... hmm :) Maybe James
could help out here?
I'd mail to library-java@apache.org and it'd goto library@apache.org
and java@apache.org ? I guess a normal mail server could do it actually.
> > Or is per language better? -0.9 I would rather see no division
> (first preference), or a division not along language boundaries.
> But, then again, I might just be smoking the really good fairy dust :)
I'd like some of that fairy crack. But I'm also not sure if language
boundaries hurts or improves. Will just have to try it. It does mean
opening ASF up to lots of new things. ie) A language-agnostic commons is
worthless if the chief languages are C and Java. We need to fill the
spectrum in rather than just have the ones at each end.
> > For example new mailing list groups could be formed along these lines:
> > a) Collections, IO, Lang, Pattern, Util, BeanUtils components from j-c (a
> > 'Java core' list)
> > b) Betwixt, Digester from j-c, and components from XML-Commons (an 'XML'
> > list)
> > c) HttpClient and Net from j-c (a 'Networking' list)
> > d) Catch all for smaller components and the sandbox
> > (please don't debate the details of which component is in which (yet), its
> > an example!)
>
> This is a pretty good idea, IMHO. Just throw the language-agnostic
> stuff in, and you are good to go :)
+1. I like this idea.
Network. Library. XML. (and then DB. GUI. etc)
There's also the fact that we might want to use Categories within a
project. ie) Apache-Commons is a top level project which contains a Java
Category and a Language-Library Category.
However, although Commons Lang belongs to these, it also belongs to Apache
Jakarta-Core category which is a federation of Lang/IO/Collection etc,
this categories sole job being to produce a unified jar, etc etc.
Hen
Re: Structuring A-C internally by language or concern?
Posted by Scott Sanders <sa...@apache.org>.
On Thu, Oct 24, 2002 at 09:28:11PM +0100, Stephen Colebourne wrote:
> The current status document states that it is resolved that a-c is language
> agnostic. There is no statement however about how a-c will manage the
> multiple languages. So I've been musing...
>
> 1) One sub-project of a-c for each language, with each component effectively
> a sub-sub-project within the language (eg.
> commons.apache.org/java/collections)
>
I think this will ultimately end up in more little fiefdoms, but I could and probably am wrong.
> 2) One sub-project for each component ignoring language (eg.
> commons.apache.org/collections). But then what happens if that component is
> implemented in two languages?
>
Why not 3) concern areas, like your mailing list suggestions: xml serialization, http clients, language libraries (the biggest thing that is missing in most languages), etc?
> This affects many things - how the mailing lists are structured, how the
> website is structured, how the communities will form, etc.
>
> I would like to see some clarification on this. The key aspect to me seems
> to be the mailing list one:
>
> Does it help to have C/C#/D/Perl/PHP/Java components on a shared mailing
> list?
IMHO it does from the standpoint that for instance, NTLM authentication affects both serf and httpclient, and I have seen myself learning things from those people well-versed in other languages on algorithms and such.
> Or is per language better?
-0.9 I would rather see no division (first preference), or a division not along language boundaries. But, then again, I might just be smoking the really good fairy dust :)
> Or maybe we should have more mailing lists?
A possibility, but then cross-posting might go up when the subject slightly shifts. -0 here.
>
> For example new mailing list groups could be formed along these lines:
> a) Collections, IO, Lang, Pattern, Util, BeanUtils components from j-c (a
> 'Java core' list)
> b) Betwixt, Digester from j-c, and components from XML-Commons (an 'XML'
> list)
> c) HttpClient and Net from j-c (a 'Networking' list)
> d) Catch all for smaller components and the sandbox
> (please don't debate the details of which component is in which (yet), its
> an example!)
This is a pretty good idea, IMHO. Just throw the language-agnostic stuff in, and you are good to go :)
--
Scott Sanders - sanders@apache.org