You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Morgan Delagrange <md...@yahoo.com> on 2001/03/16 18:23:17 UTC
The Release Process
Hi all,
I think we're closer to agreement then is immediately
apparent. We seem to be battling one key set of
apparently opposing viewpoints:
1) Costin, Ignacio, etc. are concerned that the
Commons committers will incorrectly shoot down
legitimate components.
2) Craig, David, Gier, etc. believe that we need
oversight, or subprojects may introduce components
that don't meet the Commons charter.
Let's keep in mind that the core Commons committers
are _us_ (well, "we" :), and we'll be guiding the
evolution of this project. I don't think any of us
are going to reject a component that we don't
understand or that is only used by one subproject. I
myself would entertain any good contribution, even if
it was sponsored by _no_ subproject.
I think we can expect that Commons committers will
only exercise their veto if a component is not
designed for reuse, or a component is inextricably
tied to a large external framework, or the component
deviates from the Commons charter in some other
significant way. After all, like it or not we do have
a charter, and somebody has to make sure we follow it.
Some Commons components may be promoted from the
sandbox to Commons. Others, if they display
sufficient promise and maturity, may be able to bypass
the sandbox entirely. And once the component is
accepted into Commons, so are the contributors, and
they can continue to guide its destiny. This is very,
very similar to the way Taglibs has evolved, and so
far I think it's been a success.
- Morgan
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Morgan Delagrange wrote:
> > 1) Costin, Ignacio, etc. are concerned that the
> > Commons committers will incorrectly shoot down
> > legitimate components.
>
> I don't believe Costin and Ignacio are actually interested in proposing
> components to the Commons. Costin wants to use the shared CVS to host
> another model for sharing code -- "Agora". As I understand it, the
> release process here would not be controlled by the actual committers,
^^^^^^^^^^^^^^^^^
> but by the subprojects using the components.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What's the difference? Or, more precisely, what would the 'subproject
using the components' be other than a set of committers for the
component that are also involved in other projects that want to use it?
I don't see how in practice there is any reality to the notion of
'subproject using...' as different from 'actual committers'.
>
> Most of us were not interested in pursuing that model, but wanted to
> give Costin a chance to explore it further.
I still think its a good model - to me, it would have similar status as
any other Commons subproject in that the participants within make the
decisions for what goes on within.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Morgan Delagrange wrote:
> > 1) Costin, Ignacio, etc. are concerned that the
> > Commons committers will incorrectly shoot down
> > legitimate components.
>
> I don't believe Costin and Ignacio are actually interested in proposing
> components to the Commons. Costin wants to use the shared CVS to host
> another model for sharing code -- "Agora". As I understand it, the
> release process here would not be controlled by the actual committers,
^^^^^^^^^^^^^^^^^
> but by the subprojects using the components.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What's the difference? Or, more precisely, what would the 'subproject
using the components' be other than a set of committers for the
component that are also involved in other projects that want to use it?
I don't see how in practice there is any reality to the notion of
'subproject using...' as different from 'actual committers'.
>
> Most of us were not interested in pursuing that model, but wanted to
> give Costin a chance to explore it further.
I still think its a good model - to me, it would have similar status as
any other Commons subproject in that the participants within make the
decisions for what goes on within.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> We originally used the phrase "sponsored by another subproject" to
> ensure that Agora would have use of the shared CVS. Where it breaks down
> now is how the code developed in the shared CVS gets distributed. We're
> concerned that unless we are more specific, it could become a backdoor
> to distributing code under the Apache brand. I'm sure Costin would do
> the right thing, but the CVS would be open to all 90 Jakarta committers,
> so we need to more careful.
And by mentioning that the sponsored component can be either distributed
by the sponsoring subproject or by commons you are removing all the
meaning.
The proposed change makes it void - it doesn't say anything that isn't
already true. Projects can already release Apache code - so the whole
phrase is offering what we already have.
Costin
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> We originally used the phrase "sponsored by another subproject" to
> ensure that Agora would have use of the shared CVS. Where it breaks down
> now is how the code developed in the shared CVS gets distributed. We're
> concerned that unless we are more specific, it could become a backdoor
> to distributing code under the Apache brand. I'm sure Costin would do
> the right thing, but the CVS would be open to all 90 Jakarta committers,
> so we need to more careful.
And by mentioning that the sponsored component can be either distributed
by the sponsoring subproject or by commons you are removing all the
meaning.
The proposed change makes it void - it doesn't say anything that isn't
already true. Projects can already release Apache code - so the whole
phrase is offering what we already have.
Costin
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
Morgan Delagrange wrote:
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
I don't believe Costin and Ignacio are actually interested in proposing
components to the Commons. Costin wants to use the shared CVS to host
another model for sharing code -- "Agora". As I understand it, the
release process here would not be controlled by the actual committers,
but by the subprojects using the components.
Most of us were not interested in pursuing that model, but wanted to
give Costin a chance to explore it further.
We originally used the phrase "sponsored by another subproject" to
ensure that Agora would have use of the shared CVS. Where it breaks down
now is how the code developed in the shared CVS gets distributed. We're
concerned that unless we are more specific, it could become a backdoor
to distributing code under the Apache brand. I'm sure Costin would do
the right thing, but the CVS would be open to all 90 Jakarta committers,
so we need to more careful.
-Ted.
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
>
> Hi all,
>
> I think we're closer to agreement then is immediately
> apparent. We seem to be battling one key set of
> apparently opposing viewpoints:
>
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
>
> 2) Craig, David, Gier, etc. believe that we need
> oversight, or subprojects may introduce components
> that don't meet the Commons charter.
['Geir' : you know the old rule - 'i' before 'e' except after 'c', or in
'neighbor' and 'weigh', when sounding line 'a', or in 'geir'. ;) ]
I came to the conclusion last night that it may be a little more subtle,
and that is it's the *release* issue. I think that it's clear that in
Agora, things could be freely developed and worked on w/o any say by the
'Commons committers', but the bone of contention seems limited entirely
to the release groundrules.
Further, it seems to be focused on weather or not a jakarta project can
'sponsor' a component for release, bypassing the commons committers.
> Let's keep in mind that the core Commons committers
> are _us_ (well, "we" :), and we'll be guiding the
> evolution of this project. I don't think any of us
> are going to reject a component that we don't
> understand or that is only used by one subproject. I
> myself would entertain any good contribution, even if
> it was sponsored by _no_ subproject.
Right - I agree ( I will be careful about those multi-meaning +1's :)
I don't think a Jakarta project *should* sponsor - the actual committers
sponsor - they may be from multiple Jakarta projects, and that's good,
but not required...
>
> I think we can expect that Commons committers will
> only exercise their veto if a component is not
> designed for reuse, or a component is inextricably
> tied to a large external framework, or the component
> deviates from the Commons charter in some other
> significant way. After all, like it or not we do have
> a charter, and somebody has to make sure we follow it.
Yep
> Some Commons components may be promoted from the
> sandbox to Commons. Others, if they display
> sufficient promise and maturity, may be able to bypass
> the sandbox entirely. And once the component is
> accepted into Commons, so are the contributors, and
> they can continue to guide its destiny. This is very,
> very similar to the way Taglibs has evolved, and so
> far I think it's been a success.
Again - I think the commons committers should be reactive : they don't
proactively 'promote' anything out unless the people actually working on
the component want that to be so... right?
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Morgan Delagrange wrote:
>
> Hi all,
>
> I think we're closer to agreement then is immediately
> apparent. We seem to be battling one key set of
> apparently opposing viewpoints:
>
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
>
> 2) Craig, David, Gier, etc. believe that we need
> oversight, or subprojects may introduce components
> that don't meet the Commons charter.
['Geir' : you know the old rule - 'i' before 'e' except after 'c', or in
'neighbor' and 'weigh', when sounding line 'a', or in 'geir'. ;) ]
I came to the conclusion last night that it may be a little more subtle,
and that is it's the *release* issue. I think that it's clear that in
Agora, things could be freely developed and worked on w/o any say by the
'Commons committers', but the bone of contention seems limited entirely
to the release groundrules.
Further, it seems to be focused on weather or not a jakarta project can
'sponsor' a component for release, bypassing the commons committers.
> Let's keep in mind that the core Commons committers
> are _us_ (well, "we" :), and we'll be guiding the
> evolution of this project. I don't think any of us
> are going to reject a component that we don't
> understand or that is only used by one subproject. I
> myself would entertain any good contribution, even if
> it was sponsored by _no_ subproject.
Right - I agree ( I will be careful about those multi-meaning +1's :)
I don't think a Jakarta project *should* sponsor - the actual committers
sponsor - they may be from multiple Jakarta projects, and that's good,
but not required...
>
> I think we can expect that Commons committers will
> only exercise their veto if a component is not
> designed for reuse, or a component is inextricably
> tied to a large external framework, or the component
> deviates from the Commons charter in some other
> significant way. After all, like it or not we do have
> a charter, and somebody has to make sure we follow it.
Yep
> Some Commons components may be promoted from the
> sandbox to Commons. Others, if they display
> sufficient promise and maturity, may be able to bypass
> the sandbox entirely. And once the component is
> accepted into Commons, so are the contributors, and
> they can continue to guide its destiny. This is very,
> very similar to the way Taglibs has evolved, and so
> far I think it's been a success.
Again - I think the commons committers should be reactive : they don't
proactively 'promote' anything out unless the people actually working on
the component want that to be so... right?
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
Morgan Delagrange wrote:
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
I don't believe Costin and Ignacio are actually interested in proposing
components to the Commons. Costin wants to use the shared CVS to host
another model for sharing code -- "Agora". As I understand it, the
release process here would not be controlled by the actual committers,
but by the subprojects using the components.
Most of us were not interested in pursuing that model, but wanted to
give Costin a chance to explore it further.
We originally used the phrase "sponsored by another subproject" to
ensure that Agora would have use of the shared CVS. Where it breaks down
now is how the code developed in the shared CVS gets distributed. We're
concerned that unless we are more specific, it could become a backdoor
to distributing code under the Apache brand. I'm sure Costin would do
the right thing, but the CVS would be open to all 90 Jakarta committers,
so we need to more careful.
-Ted.
Re: The Release Process
Posted by cm...@yahoo.com.
On Sat, 17 Mar 2001, Peter Donald wrote:
> At 09:23 16/3/01 -0800, Morgan Delagrange wrote:
> >Let's keep in mind that the core Commons committers
> >are _us_ (well, "we" :), and we'll be guiding the
> >evolution of this project.
>
> baddabing-badda-boom - a new tribe is born.
Well, before leaving - Peter, I owe you some apologies.
I'll send you a private mail with "mea culpa" and everything
else ( when I'm back ) :-) In my view Agora was the big
difference between commons and avalon, and the fact that
the common was also trying to give "trust" to jakarta projects
and not to rule.
Costin
Re: The Release Process
Posted by cm...@yahoo.com.
On Sat, 17 Mar 2001, Peter Donald wrote:
> At 09:23 16/3/01 -0800, Morgan Delagrange wrote:
> >Let's keep in mind that the core Commons committers
> >are _us_ (well, "we" :), and we'll be guiding the
> >evolution of this project.
>
> baddabing-badda-boom - a new tribe is born.
Well, before leaving - Peter, I owe you some apologies.
I'll send you a private mail with "mea culpa" and everything
else ( when I'm back ) :-) In my view Agora was the big
difference between commons and avalon, and the fact that
the common was also trying to give "trust" to jakarta projects
and not to rule.
Costin
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 09:23 16/3/01 -0800, Morgan Delagrange wrote:
>Let's keep in mind that the core Commons committers
>are _us_ (well, "we" :), and we'll be guiding the
>evolution of this project.
baddabing-badda-boom - a new tribe is born.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 07:27 17/3/01 -0500, Ted Husted wrote:
>"23. Like all Jakarta subprojects, we adopt the Code Conventions for the
>Java Programming Language as published by Sun. In addition, we specify
>that indentation should be constructed using spaces, not tabs, so that
>CVS commit messages format correctly when sent by email."
Considering that just under half of Jakarta projects don't use the
"standard" trying to enforce it seems a little ludicrous - especially if
one of the aims of commons is to share between projects. Factor in that
only 1 of the three frameworks use it and it becomes even more obvious.
Thought polic builds catehdrals not bazaars.
>"3. Each package must have a clearly defined purpose, scope, and API --
>Do one thing well, and keep your contracts."
abstract - unenforcable except via consensus among different individuals -
thus should be largely discarded. If a package is not well defined it is
unlikely to see reuse and thus darwin will see it extinct (or adapted) soon
enough.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 09:33 17/3/01 -0500, Ted Husted wrote:
>< http://jakarta.apache.org/site/source.html >
>
>"All Java Language source code in the repository must be written in
>conformance to
>the "Code Conventions for the Java Programming Language" as published by
>Sun.
>However, some projects may decide to override these defaults and use
>their own
>defined conventions. For example, the Turbine project has its own
>defined
>conventions which are similar to the Sun standards but specifiy slightly
>different
>conventions."
>
>Given the nature of the Commons, I don't think we have the luxury of
>defining our own conventions, and so fall back to the Jakarta defaults.
>The only reason there is a #23 is to append Jon's point about the tabs
>screwing up the CVS emails. If we decide not to care about that, we can
>strike #23 completely (and then just bitch at people if they start using
>tabs;-)
Personally I would like to see a jakarta automate rejection of tabified
commits ... everything else is largely ignrable. So we would have to
convince the tomcat developers and any others who like tabs that they are
truly evil ;) If we did this I assume it would be a simple mod to perl
scripts to refuse to commit tabbified commits ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 09:33 17/3/01 -0500, Ted Husted wrote:
>< http://jakarta.apache.org/site/source.html >
>
>"All Java Language source code in the repository must be written in
>conformance to
>the "Code Conventions for the Java Programming Language" as published by
>Sun.
>However, some projects may decide to override these defaults and use
>their own
>defined conventions. For example, the Turbine project has its own
>defined
>conventions which are similar to the Sun standards but specifiy slightly
>different
>conventions."
>
>Given the nature of the Commons, I don't think we have the luxury of
>defining our own conventions, and so fall back to the Jakarta defaults.
>The only reason there is a #23 is to append Jon's point about the tabs
>screwing up the CVS emails. If we decide not to care about that, we can
>strike #23 completely (and then just bitch at people if they start using
>tabs;-)
Personally I would like to see a jakarta automate rejection of tabified
commits ... everything else is largely ignrable. So we would have to
convince the tomcat developers and any others who like tabs that they are
truly evil ;) If we did this I assume it would be a simple mod to perl
scripts to refuse to commit tabbified commits ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> I checked the calendar when I saw this - I thought it was April 1 or
> something. Peters exact point, as I read it, was that requirements like
> code formatting etc is *not* good, which is contrary to the idea of
> having a #23.
>
> (And anyway, Suns conventions are a bit goofy, I think... :)
< http://jakarta.apache.org/site/source.html >
"All Java Language source code in the repository must be written in
conformance to
the "Code Conventions for the Java Programming Language" as published by
Sun.
However, some projects may decide to override these defaults and use
their own
defined conventions. For example, the Turbine project has its own
defined
conventions which are similar to the Sun standards but specifiy slightly
different
conventions."
Given the nature of the Commons, I don't think we have the luxury of
defining our own conventions, and so fall back to the Jakarta defaults.
The only reason there is a #23 is to append Jon's point about the tabs
screwing up the CVS emails. If we decide not to care about that, we can
strike #23 completely (and then just bitch at people if they start using
tabs;-)
-Ted.
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> I checked the calendar when I saw this - I thought it was April 1 or
> something. Peters exact point, as I read it, was that requirements like
> code formatting etc is *not* good, which is contrary to the idea of
> having a #23.
>
> (And anyway, Suns conventions are a bit goofy, I think... :)
< http://jakarta.apache.org/site/source.html >
"All Java Language source code in the repository must be written in
conformance to
the "Code Conventions for the Java Programming Language" as published by
Sun.
However, some projects may decide to override these defaults and use
their own
defined conventions. For example, the Turbine project has its own
defined
conventions which are similar to the Sun standards but specifiy slightly
different
conventions."
Given the nature of the Commons, I don't think we have the luxury of
defining our own conventions, and so fall back to the Jakarta defaults.
The only reason there is a #23 is to append Jon's point about the tabs
screwing up the CVS emails. If we decide not to care about that, we can
strike #23 completely (and then just bitch at people if they start using
tabs;-)
-Ted.
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Peter Donald wrote:
> > I would hope Avalon people are *more* open than commons ;) Any project that
> > starts dictating "religious" requirements liks code formatting/structure
> > etc is bound to be more of a cathedral. A free for all where the only
> > forced "standard" is versioning and distribution scheme will see a much
> > better bazaar. SUre it may contain some crap but eventually the best would
> > bubble to the top.
>
> Good point. We should clearly justify any requirements for code format.
>
> "23. Like all Jakarta subprojects, we adopt the Code Conventions for the
> Java Programming Language as published by Sun. In addition, we specify
> that indentation should be constructed using spaces, not tabs, so that
> CVS commit messages format correctly when sent by email."
I checked the calendar when I saw this - I thought it was April 1 or
something. Peters exact point, as I read it, was that requirements like
code formatting etc is *not* good, which is contrary to the idea of
having a #23.
(And anyway, Suns conventions are a bit goofy, I think... :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Peter Donald wrote:
> > I would hope Avalon people are *more* open than commons ;) Any project that
> > starts dictating "religious" requirements liks code formatting/structure
> > etc is bound to be more of a cathedral. A free for all where the only
> > forced "standard" is versioning and distribution scheme will see a much
> > better bazaar. SUre it may contain some crap but eventually the best would
> > bubble to the top.
>
> Good point. We should clearly justify any requirements for code format.
>
> "23. Like all Jakarta subprojects, we adopt the Code Conventions for the
> Java Programming Language as published by Sun. In addition, we specify
> that indentation should be constructed using spaces, not tabs, so that
> CVS commit messages format correctly when sent by email."
I checked the calendar when I saw this - I thought it was April 1 or
something. Peters exact point, as I read it, was that requirements like
code formatting etc is *not* good, which is contrary to the idea of
having a #23.
(And anyway, Suns conventions are a bit goofy, I think... :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 07:27 17/3/01 -0500, Ted Husted wrote:
>"23. Like all Jakarta subprojects, we adopt the Code Conventions for the
>Java Programming Language as published by Sun. In addition, we specify
>that indentation should be constructed using spaces, not tabs, so that
>CVS commit messages format correctly when sent by email."
Considering that just under half of Jakarta projects don't use the
"standard" trying to enforce it seems a little ludicrous - especially if
one of the aims of commons is to share between projects. Factor in that
only 1 of the three frameworks use it and it becomes even more obvious.
Thought polic builds catehdrals not bazaars.
>"3. Each package must have a clearly defined purpose, scope, and API --
>Do one thing well, and keep your contracts."
abstract - unenforcable except via consensus among different individuals -
thus should be largely discarded. If a package is not well defined it is
unlikely to see reuse and thus darwin will see it extinct (or adapted) soon
enough.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> I would hope Avalon people are *more* open than commons ;) Any project that
> starts dictating "religious" requirements liks code formatting/structure
> etc is bound to be more of a cathedral. A free for all where the only
> forced "standard" is versioning and distribution scheme will see a much
> better bazaar. SUre it may contain some crap but eventually the best would
> bubble to the top.
Good point. We should clearly justify any requirements for code format.
"23. Like all Jakarta subprojects, we adopt the Code Conventions for the
Java Programming Language as published by Sun. In addition, we specify
that indentation should be constructed using spaces, not tabs, so that
CVS commit messages format correctly when sent by email."
The actual package requirements are:
"3. Each package must have a clearly defined purpose, scope, and API --
Do one thing well, and keep your contracts."
"4.2. Each package must clearly specify any external dependencies,
including any other Commons packages, and the earliest JDK version
required."
"4.2.2. All necessary dependencies must be recorded in the MANIFEST.MF
file of the package JAR, in the manner recommended in the JDK 1.3
documentation describing "system extensions".
"4.3 Each package must maintain a list of its active committers in its
status file."
In terms of package construction, everything else is "optional but
recommended."
-Ted.
"I am sure they are sour," said the fox.
http://www.pacificnet.net/~johnr/cgi/aesop1.cgi?2&TheFoxandtheGrapes2
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> I would hope Avalon people are *more* open than commons ;) Any project that
> starts dictating "religious" requirements liks code formatting/structure
> etc is bound to be more of a cathedral. A free for all where the only
> forced "standard" is versioning and distribution scheme will see a much
> better bazaar. SUre it may contain some crap but eventually the best would
> bubble to the top.
Good point. We should clearly justify any requirements for code format.
"23. Like all Jakarta subprojects, we adopt the Code Conventions for the
Java Programming Language as published by Sun. In addition, we specify
that indentation should be constructed using spaces, not tabs, so that
CVS commit messages format correctly when sent by email."
The actual package requirements are:
"3. Each package must have a clearly defined purpose, scope, and API --
Do one thing well, and keep your contracts."
"4.2. Each package must clearly specify any external dependencies,
including any other Commons packages, and the earliest JDK version
required."
"4.2.2. All necessary dependencies must be recorded in the MANIFEST.MF
file of the package JAR, in the manner recommended in the JDK 1.3
documentation describing "system extensions".
"4.3 Each package must maintain a list of its active committers in its
status file."
In terms of package construction, everything else is "optional but
recommended."
-Ted.
"I am sure they are sour," said the fox.
http://www.pacificnet.net/~johnr/cgi/aesop1.cgi?2&TheFoxandtheGrapes2
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 01:57 16/3/01 -0800, cmanolache@yahoo.com wrote:
>The commons are using the same model as Avalon or any other jakarta
>project - with a set of existing commiters aproving new memebers and
>controling the component. And this doesn't seem to work well for projects
>and sharing - I haven't seen too many projects moving code out of their
>workspace and into avalon for example. I'm sure Avalon people are as open
>as "commons", and will accept code and contributions that follow their
>rules.
I would hope Avalon people are *more* open than commons ;) Any project that
starts dictating "religious" requirements liks code formatting/structure
etc is bound to be more of a cathedral. A free for all where the only
forced "standard" is versioning and distribution scheme will see a much
better bazaar. SUre it may contain some crap but eventually the best would
bubble to the top.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> The only grey area I can see is what "general oversight" means. I
> understood that to be concerned with initial acceptance criteria (is the
> component really reusable, or does it drag along dependencies that hinder
> this? does, or will, the component conform to the packaging
> guidelines? does the component have an initial set of committers willing
> to support it?).
Guideline 16,
"The committers shall elect a committee of three committers to provide
general oversight, in the style of the Jakarta PMC."
simply refers to a committee that will simply take the "high view" of
the subproject, as the PMC does for Jakarta. But, as you point out, this
has nothing to do with the technical direction of package.
Unlike the PMC, this committee would not be responsible for approving
new proposals. This is voted on by all the subproject committers, as
given in 17,
"New packages may be proposed to the Commons general list, and voted on
by all subproject volunteers."
by super-majority vote.
The public release of individual packages is not specifically covered by
a guideline, since the normal Jakarta release guidelines govern this --
release plan, testing, and then a majority vote of all the subproject
committers.
Of course, all this only applies to packages people propose to the
Commons. If other subprojects develop code in the shared CVS, they would
release it with their own codebases in the usual way.
-Ted.
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> The only grey area I can see is what "general oversight" means. I
> understood that to be concerned with initial acceptance criteria (is the
> component really reusable, or does it drag along dependencies that hinder
> this? does, or will, the component conform to the packaging
> guidelines? does the component have an initial set of committers willing
> to support it?).
Guideline 16,
"The committers shall elect a committee of three committers to provide
general oversight, in the style of the Jakarta PMC."
simply refers to a committee that will simply take the "high view" of
the subproject, as the PMC does for Jakarta. But, as you point out, this
has nothing to do with the technical direction of package.
Unlike the PMC, this committee would not be responsible for approving
new proposals. This is voted on by all the subproject committers, as
given in 17,
"New packages may be proposed to the Commons general list, and voted on
by all subproject volunteers."
by super-majority vote.
The public release of individual packages is not specifically covered by
a guideline, since the normal Jakarta release guidelines govern this --
release plan, testing, and then a majority vote of all the subproject
committers.
Of course, all this only applies to packages people propose to the
Commons. If other subprojects develop code in the shared CVS, they would
release it with their own codebases in the usual way.
-Ted.
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 01:57 16/3/01 -0800, cmanolache@yahoo.com wrote:
>The commons are using the same model as Avalon or any other jakarta
>project - with a set of existing commiters aproving new memebers and
>controling the component. And this doesn't seem to work well for projects
>and sharing - I haven't seen too many projects moving code out of their
>workspace and into avalon for example. I'm sure Avalon people are as open
>as "commons", and will accept code and contributions that follow their
>rules.
I would hope Avalon people are *more* open than commons ;) Any project that
starts dictating "religious" requirements liks code formatting/structure
etc is bound to be more of a cathedral. A free for all where the only
forced "standard" is versioning and distribution scheme will see a much
better bazaar. SUre it may contain some crap but eventually the best would
bubble to the top.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Ted, if the final vote is that only "commons"-voted code can be released
> please remove my name from the proposal, I'll remain a contributor in the
> sandbox ( as regular jakarta commiter ) and a user for commons ( and I
> hope Avalon ) components.
Costin, since I don't see that anyone has ever proposed such a thing,
I'll leave your name on for now.
-Ted.
Re: The Release Process
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Ted, if the final vote is that only "commons"-voted code can be released
> please remove my name from the proposal, I'll remain a contributor in the
> sandbox ( as regular jakarta commiter ) and a user for commons ( and I
> hope Avalon ) components.
Costin, since I don't see that anyone has ever proposed such a thing,
I'll leave your name on for now.
-Ted.
Re: The Release Process
Posted by cm...@yahoo.com.
Ok, this is the last message - really ! :-)
I have to go - I'll be back on Tuesday ( I'll try to read my mail, and if
the PMC chat is open I'll try to log in ) - we don't seem to make too
much progress anyway.
Regardless of the final decision I'll contribute and work on
agora ( or sandbox ) components - and I'll use "commons" components. But
I don't want to be part of the group that rules what's right and wrong for
a component and is overruling decisions made by jakarta projects.
Ted, if the final vote is that only "commons"-voted code can be released
please remove my name from the proposal, I'll remain a contributor in the
sandbox ( as regular jakarta commiter ) and a user for commons ( and I
hope Avalon ) components.
Costin
On Fri, 16 Mar 2001 cmanolache@yahoo.com wrote:
> On Fri, 16 Mar 2001, Craig R. McClanahan wrote:
>
> > For released components, or code used in a different subproject release,
> > it seems to me that you can have Agora-style development using the Commons
> > workspace as proposed. Which specific parts of the proposal lead you to
> > believe that this is not the case?
>
>
> The difference between commons and sandbox is that sandbox is open to all
> jakarta projects and commiters.
>
> The commons are using the same model as Avalon or any other jakarta
> project - with a set of existing commiters aproving new memebers and
> controling the component. And this doesn't seem to work well for projects
> and sharing - I haven't seen too many projects moving code out of their
> workspace and into avalon for example. I'm sure Avalon people are as open
> as "commons", and will accept code and contributions that follow their
> rules.
>
> The agora uses different rules - the projects have control over the code
> they place there and they share it with other projects who decide to use
> the component. Both projects will monitor and maintain the component -
> without a "producer-consumer" relation.
>
>
> > If I believe that my component (currently part of my favorite
> > subproject) is potentially reusable, and others agree, I'm going to
> > propose it for Commons. Assuming acceptance -- and that's mostly
> > concerned with things like not dragging along dependencies on frameworks
> > that hinder reusability -- I, and the other committers who want to share
> > this component, will be the maintainers of record in the status file
> > (point 15).
>
> It's a valid action.
>
> What I would like to do is:
> If my component is reusable and others agree, I will share it with other
> projects in the agora workspace. By placing it in the agora workspace I
> agree that other projects who decide to use the components will have the
> same rights as me over the component. And I can also look at other
> components and if I find something that I need I can use it - knowing that
> I will have the same control over the component shared by another project
> as the original source. That would allow other components to have trust
> in the component I am sharing, and know that they are co-maintainers and
> don't risk that I'll make changes that will affect them later. And will
> allow me to trust components that I want to use, without risking that the
> original commiters will do changes that will affect me.
>
> Please don't tell me that the maintainers of a piece of code will preserve
> backward compatiblity - remember XmlMapper :-)
>
> Of course, I may use components from "commons" if they are stable and
> boring ( i.e. no active development happens ) - and hope the maintainers
> will not brake my code.
>
> Note that agora doesn't require active contributions to a component in
> order to have a vote ( the veto that matters when the active contributors
> are braking my code ). And that's the difference between the 2 workspaces.
>
>
> Eventually, if other projects decide to trust me and the component and
> start using it, we may need to have separate releases of the component -
> so users of jakarta-foo-7.0 and jakarta-bar-11.0 can upgrade and treat the
> component as a separate entity in both projects. But I don't want to have
> to "close" my component by moving it into commons.
>
> > If this is all according to the rules of Commons, where does it say,
> > specifically, that you cannot have the development style you like? Or,
> > where does it *not* say something that would prevent the kind of
> > interference you are worried about?
>
> The development style for components in commons is what I don't trust. I
> don't think it'll provide enough guarantees for projects who want to
> reuse. I like the style in agora/sandbox - where review is shared and
> projects have control over what they use, if they need to.
>
> Costin
>
Re: The Release Process
Posted by cm...@yahoo.com.
Ok, this is the last message - really ! :-)
I have to go - I'll be back on Tuesday ( I'll try to read my mail, and if
the PMC chat is open I'll try to log in ) - we don't seem to make too
much progress anyway.
Regardless of the final decision I'll contribute and work on
agora ( or sandbox ) components - and I'll use "commons" components. But
I don't want to be part of the group that rules what's right and wrong for
a component and is overruling decisions made by jakarta projects.
Ted, if the final vote is that only "commons"-voted code can be released
please remove my name from the proposal, I'll remain a contributor in the
sandbox ( as regular jakarta commiter ) and a user for commons ( and I
hope Avalon ) components.
Costin
On Fri, 16 Mar 2001 cmanolache@yahoo.com wrote:
> On Fri, 16 Mar 2001, Craig R. McClanahan wrote:
>
> > For released components, or code used in a different subproject release,
> > it seems to me that you can have Agora-style development using the Commons
> > workspace as proposed. Which specific parts of the proposal lead you to
> > believe that this is not the case?
>
>
> The difference between commons and sandbox is that sandbox is open to all
> jakarta projects and commiters.
>
> The commons are using the same model as Avalon or any other jakarta
> project - with a set of existing commiters aproving new memebers and
> controling the component. And this doesn't seem to work well for projects
> and sharing - I haven't seen too many projects moving code out of their
> workspace and into avalon for example. I'm sure Avalon people are as open
> as "commons", and will accept code and contributions that follow their
> rules.
>
> The agora uses different rules - the projects have control over the code
> they place there and they share it with other projects who decide to use
> the component. Both projects will monitor and maintain the component -
> without a "producer-consumer" relation.
>
>
> > If I believe that my component (currently part of my favorite
> > subproject) is potentially reusable, and others agree, I'm going to
> > propose it for Commons. Assuming acceptance -- and that's mostly
> > concerned with things like not dragging along dependencies on frameworks
> > that hinder reusability -- I, and the other committers who want to share
> > this component, will be the maintainers of record in the status file
> > (point 15).
>
> It's a valid action.
>
> What I would like to do is:
> If my component is reusable and others agree, I will share it with other
> projects in the agora workspace. By placing it in the agora workspace I
> agree that other projects who decide to use the components will have the
> same rights as me over the component. And I can also look at other
> components and if I find something that I need I can use it - knowing that
> I will have the same control over the component shared by another project
> as the original source. That would allow other components to have trust
> in the component I am sharing, and know that they are co-maintainers and
> don't risk that I'll make changes that will affect them later. And will
> allow me to trust components that I want to use, without risking that the
> original commiters will do changes that will affect me.
>
> Please don't tell me that the maintainers of a piece of code will preserve
> backward compatiblity - remember XmlMapper :-)
>
> Of course, I may use components from "commons" if they are stable and
> boring ( i.e. no active development happens ) - and hope the maintainers
> will not brake my code.
>
> Note that agora doesn't require active contributions to a component in
> order to have a vote ( the veto that matters when the active contributors
> are braking my code ). And that's the difference between the 2 workspaces.
>
>
> Eventually, if other projects decide to trust me and the component and
> start using it, we may need to have separate releases of the component -
> so users of jakarta-foo-7.0 and jakarta-bar-11.0 can upgrade and treat the
> component as a separate entity in both projects. But I don't want to have
> to "close" my component by moving it into commons.
>
> > If this is all according to the rules of Commons, where does it say,
> > specifically, that you cannot have the development style you like? Or,
> > where does it *not* say something that would prevent the kind of
> > interference you are worried about?
>
> The development style for components in commons is what I don't trust. I
> don't think it'll provide enough guarantees for projects who want to
> reuse. I like the style in agora/sandbox - where review is shared and
> projects have control over what they use, if they need to.
>
> Costin
>
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Craig R. McClanahan wrote:
> For released components, or code used in a different subproject release,
> it seems to me that you can have Agora-style development using the Commons
> workspace as proposed. Which specific parts of the proposal lead you to
> believe that this is not the case?
The difference between commons and sandbox is that sandbox is open to all
jakarta projects and commiters.
The commons are using the same model as Avalon or any other jakarta
project - with a set of existing commiters aproving new memebers and
controling the component. And this doesn't seem to work well for projects
and sharing - I haven't seen too many projects moving code out of their
workspace and into avalon for example. I'm sure Avalon people are as open
as "commons", and will accept code and contributions that follow their
rules.
The agora uses different rules - the projects have control over the code
they place there and they share it with other projects who decide to use
the component. Both projects will monitor and maintain the component -
without a "producer-consumer" relation.
> If I believe that my component (currently part of my favorite
> subproject) is potentially reusable, and others agree, I'm going to
> propose it for Commons. Assuming acceptance -- and that's mostly
> concerned with things like not dragging along dependencies on frameworks
> that hinder reusability -- I, and the other committers who want to share
> this component, will be the maintainers of record in the status file
> (point 15).
It's a valid action.
What I would like to do is:
If my component is reusable and others agree, I will share it with other
projects in the agora workspace. By placing it in the agora workspace I
agree that other projects who decide to use the components will have the
same rights as me over the component. And I can also look at other
components and if I find something that I need I can use it - knowing that
I will have the same control over the component shared by another project
as the original source. That would allow other components to have trust
in the component I am sharing, and know that they are co-maintainers and
don't risk that I'll make changes that will affect them later. And will
allow me to trust components that I want to use, without risking that the
original commiters will do changes that will affect me.
Please don't tell me that the maintainers of a piece of code will preserve
backward compatiblity - remember XmlMapper :-)
Of course, I may use components from "commons" if they are stable and
boring ( i.e. no active development happens ) - and hope the maintainers
will not brake my code.
Note that agora doesn't require active contributions to a component in
order to have a vote ( the veto that matters when the active contributors
are braking my code ). And that's the difference between the 2 workspaces.
Eventually, if other projects decide to trust me and the component and
start using it, we may need to have separate releases of the component -
so users of jakarta-foo-7.0 and jakarta-bar-11.0 can upgrade and treat the
component as a separate entity in both projects. But I don't want to have
to "close" my component by moving it into commons.
> If this is all according to the rules of Commons, where does it say,
> specifically, that you cannot have the development style you like? Or,
> where does it *not* say something that would prevent the kind of
> interference you are worried about?
The development style for components in commons is what I don't trust. I
don't think it'll provide enough guarantees for projects who want to
reuse. I like the style in agora/sandbox - where review is shared and
projects have control over what they use, if they need to.
Costin
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Craig R. McClanahan wrote:
> For released components, or code used in a different subproject release,
> it seems to me that you can have Agora-style development using the Commons
> workspace as proposed. Which specific parts of the proposal lead you to
> believe that this is not the case?
The difference between commons and sandbox is that sandbox is open to all
jakarta projects and commiters.
The commons are using the same model as Avalon or any other jakarta
project - with a set of existing commiters aproving new memebers and
controling the component. And this doesn't seem to work well for projects
and sharing - I haven't seen too many projects moving code out of their
workspace and into avalon for example. I'm sure Avalon people are as open
as "commons", and will accept code and contributions that follow their
rules.
The agora uses different rules - the projects have control over the code
they place there and they share it with other projects who decide to use
the component. Both projects will monitor and maintain the component -
without a "producer-consumer" relation.
> If I believe that my component (currently part of my favorite
> subproject) is potentially reusable, and others agree, I'm going to
> propose it for Commons. Assuming acceptance -- and that's mostly
> concerned with things like not dragging along dependencies on frameworks
> that hinder reusability -- I, and the other committers who want to share
> this component, will be the maintainers of record in the status file
> (point 15).
It's a valid action.
What I would like to do is:
If my component is reusable and others agree, I will share it with other
projects in the agora workspace. By placing it in the agora workspace I
agree that other projects who decide to use the components will have the
same rights as me over the component. And I can also look at other
components and if I find something that I need I can use it - knowing that
I will have the same control over the component shared by another project
as the original source. That would allow other components to have trust
in the component I am sharing, and know that they are co-maintainers and
don't risk that I'll make changes that will affect them later. And will
allow me to trust components that I want to use, without risking that the
original commiters will do changes that will affect me.
Please don't tell me that the maintainers of a piece of code will preserve
backward compatiblity - remember XmlMapper :-)
Of course, I may use components from "commons" if they are stable and
boring ( i.e. no active development happens ) - and hope the maintainers
will not brake my code.
Note that agora doesn't require active contributions to a component in
order to have a vote ( the veto that matters when the active contributors
are braking my code ). And that's the difference between the 2 workspaces.
Eventually, if other projects decide to trust me and the component and
start using it, we may need to have separate releases of the component -
so users of jakarta-foo-7.0 and jakarta-bar-11.0 can upgrade and treat the
component as a separate entity in both projects. But I don't want to have
to "close" my component by moving it into commons.
> If this is all according to the rules of Commons, where does it say,
> specifically, that you cannot have the development style you like? Or,
> where does it *not* say something that would prevent the kind of
> interference you are worried about?
The development style for components in commons is what I don't trust. I
don't think it'll provide enough guarantees for projects who want to
reuse. I like the style in agora/sandbox - where review is shared and
projects have control over what they use, if they need to.
Costin
Re: The Release Process
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 16 Mar 2001 cmanolache@yahoo.com wrote:
> On Fri, 16 Mar 2001, Morgan Delagrange wrote:
>
> > 1) Costin, Ignacio, etc. are concerned that the
> > Commons committers will incorrectly shoot down
> > legitimate components.
>
> No, the concern is that the "commons" will "aprove"
> or vote on decisions made by jakarta projects.
>
It seems to me that this concern is not justified based on the proposal as
currently documented (prop02.html). The only things that the Commons
committers vote on are (numbers in parentheses are points in the
guidelines):
* "General oversight" (16).
* "Accept new packages" (17).
Where does the set of commons committers as a whole, have anything to do
with technical direction, release versus not-release, or anything else
that is concerning you?
The only grey area I can see is what "general oversight" means. I
understood that to be concerned with initial acceptance criteria (is the
component really reusable, or does it drag along dependencies that hinder
this? does, or will, the component conform to the packaging
guidelines? does the component have an initial set of committers willing
to support it?).
These decisions have nothing to do with technical direction, whether the
component is ever actually "released" as a package, or anything else you
have been expressing concern over, as far as I can tell.
> And the other concern is that the code developed by
> jakarta projects in the shared workspace is treated
> in the same way as experimental code that
> is not supported by any jakarta entity.
>
Depends on which workspace we're talking about. I objected to code in the
"sandbox" (i.e. playground/experimental area), which is not visible to the
public, being included in released products (and you agreed with this
point, if I remember right). Before it's part of a product, I don't have
any problem with "experimental" or "unsupported" code being here -- it's
just a whiteboard for people to work on things that *might* turn out to be
generally useful.
For released components, or code used in a different subproject release,
it seems to me that you can have Agora-style development using the Commons
workspace as proposed. Which specific parts of the proposal lead you to
believe that this is not the case?
>
> > 2) Craig, David, Gier, etc. believe that we need
> > oversight, or subprojects may introduce components
> > that don't meet the Commons charter.
>
> I do believe we need oversight - but not commons
> oversight over code aproved and supported by projects.
> And the "commons" charter is to provide support
> for projects and facilitate development of common components,
> not to supervise the component developed in projects
> ( it's the PMC who can do that ).
>
If I believe that my component (currently part of my favorite
subproject) is potentially reusable, and others agree, I'm going to
propose it for Commons. Assuming acceptance -- and that's mostly
concerned with things like not dragging along dependencies on frameworks
that hinder reusability -- I, and the other committers who want to share
this component, will be the maintainers of record in the status file
(point 15).
Now, I can use that code in my subproject in (at least) two ways:
* Create "releases" of the component, and treat it
just like any other external dependency (i.e. like
the fact that I might need an XML parser and download
a particular version of Xerces).
* Tag the component classes that I need with my subproject's
version number, and assemble it as an integral part of my
subproject build (essentially the same as any source file
inside my subproject repository).
If this is all according to the rules of Commons, where does it say,
specifically, that you cannot have the development style you like? Or,
where does it *not* say something that would prevent the kind of
interference you are worried about?
>
> Costin
>
Craig
Re: The Release Process
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 16 Mar 2001 cmanolache@yahoo.com wrote:
> On Fri, 16 Mar 2001, Morgan Delagrange wrote:
>
> > 1) Costin, Ignacio, etc. are concerned that the
> > Commons committers will incorrectly shoot down
> > legitimate components.
>
> No, the concern is that the "commons" will "aprove"
> or vote on decisions made by jakarta projects.
>
It seems to me that this concern is not justified based on the proposal as
currently documented (prop02.html). The only things that the Commons
committers vote on are (numbers in parentheses are points in the
guidelines):
* "General oversight" (16).
* "Accept new packages" (17).
Where does the set of commons committers as a whole, have anything to do
with technical direction, release versus not-release, or anything else
that is concerning you?
The only grey area I can see is what "general oversight" means. I
understood that to be concerned with initial acceptance criteria (is the
component really reusable, or does it drag along dependencies that hinder
this? does, or will, the component conform to the packaging
guidelines? does the component have an initial set of committers willing
to support it?).
These decisions have nothing to do with technical direction, whether the
component is ever actually "released" as a package, or anything else you
have been expressing concern over, as far as I can tell.
> And the other concern is that the code developed by
> jakarta projects in the shared workspace is treated
> in the same way as experimental code that
> is not supported by any jakarta entity.
>
Depends on which workspace we're talking about. I objected to code in the
"sandbox" (i.e. playground/experimental area), which is not visible to the
public, being included in released products (and you agreed with this
point, if I remember right). Before it's part of a product, I don't have
any problem with "experimental" or "unsupported" code being here -- it's
just a whiteboard for people to work on things that *might* turn out to be
generally useful.
For released components, or code used in a different subproject release,
it seems to me that you can have Agora-style development using the Commons
workspace as proposed. Which specific parts of the proposal lead you to
believe that this is not the case?
>
> > 2) Craig, David, Gier, etc. believe that we need
> > oversight, or subprojects may introduce components
> > that don't meet the Commons charter.
>
> I do believe we need oversight - but not commons
> oversight over code aproved and supported by projects.
> And the "commons" charter is to provide support
> for projects and facilitate development of common components,
> not to supervise the component developed in projects
> ( it's the PMC who can do that ).
>
If I believe that my component (currently part of my favorite
subproject) is potentially reusable, and others agree, I'm going to
propose it for Commons. Assuming acceptance -- and that's mostly
concerned with things like not dragging along dependencies on frameworks
that hinder reusability -- I, and the other committers who want to share
this component, will be the maintainers of record in the status file
(point 15).
Now, I can use that code in my subproject in (at least) two ways:
* Create "releases" of the component, and treat it
just like any other external dependency (i.e. like
the fact that I might need an XML parser and download
a particular version of Xerces).
* Tag the component classes that I need with my subproject's
version number, and assemble it as an integral part of my
subproject build (essentially the same as any source file
inside my subproject repository).
If this is all according to the rules of Commons, where does it say,
specifically, that you cannot have the development style you like? Or,
where does it *not* say something that would prevent the kind of
interference you are worried about?
>
> Costin
>
Craig
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Morgan Delagrange wrote:
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
No, the concern is that the "commons" will "aprove"
or vote on decisions made by jakarta projects.
And the other concern is that the code developed by
jakarta projects in the shared workspace is treated
in the same way as experimental code that
is not supported by any jakarta entity.
> 2) Craig, David, Gier, etc. believe that we need
> oversight, or subprojects may introduce components
> that don't meet the Commons charter.
I do believe we need oversight - but not commons
oversight over code aproved and supported by projects.
And the "commons" charter is to provide support
for projects and facilitate development of common components,
not to supervise the component developed in projects
( it's the PMC who can do that ).
> Let's keep in mind that the core Commons committers
> are _us_ (well, "we" :), and we'll be guiding the
> evolution of this project. I don't think any of us
> are going to reject a component that we don't
> understand or that is only used by one subproject. I
> myself would entertain any good contribution, even if
> it was sponsored by _no_ subproject.
Contributions that are not sponsored by a subproject are
not the subject here.
"We" can't make decisions for code we don't write or
support - we can vote on components developed by
commiters in the playground, but if a component is supported
and developed by a jakarta project - "we" have no
authority or knowledge to judge their decision. The PMC can,
but this is not the PMC.
> Some Commons components may be promoted from the
> sandbox to Commons. Others, if they display
> sufficient promise and maturity, may be able to bypass
> the sandbox entirely. And once the component is
That's exactly my point - "promoted from sandbox to
commons" or "bypass the sandbox" or "move them from
sandbox into commons", "beeing accepted into commons"
That's perfect for playground and experimental stuff -
but for code that is supported and developed by one
or many top level jakarta projects I don't think moving
them to commons will be an evolution.
Costin
Re: The Release Process
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Morgan Delagrange wrote:
> 1) Costin, Ignacio, etc. are concerned that the
> Commons committers will incorrectly shoot down
> legitimate components.
No, the concern is that the "commons" will "aprove"
or vote on decisions made by jakarta projects.
And the other concern is that the code developed by
jakarta projects in the shared workspace is treated
in the same way as experimental code that
is not supported by any jakarta entity.
> 2) Craig, David, Gier, etc. believe that we need
> oversight, or subprojects may introduce components
> that don't meet the Commons charter.
I do believe we need oversight - but not commons
oversight over code aproved and supported by projects.
And the "commons" charter is to provide support
for projects and facilitate development of common components,
not to supervise the component developed in projects
( it's the PMC who can do that ).
> Let's keep in mind that the core Commons committers
> are _us_ (well, "we" :), and we'll be guiding the
> evolution of this project. I don't think any of us
> are going to reject a component that we don't
> understand or that is only used by one subproject. I
> myself would entertain any good contribution, even if
> it was sponsored by _no_ subproject.
Contributions that are not sponsored by a subproject are
not the subject here.
"We" can't make decisions for code we don't write or
support - we can vote on components developed by
commiters in the playground, but if a component is supported
and developed by a jakarta project - "we" have no
authority or knowledge to judge their decision. The PMC can,
but this is not the PMC.
> Some Commons components may be promoted from the
> sandbox to Commons. Others, if they display
> sufficient promise and maturity, may be able to bypass
> the sandbox entirely. And once the component is
That's exactly my point - "promoted from sandbox to
commons" or "bypass the sandbox" or "move them from
sandbox into commons", "beeing accepted into commons"
That's perfect for playground and experimental stuff -
but for code that is supported and developed by one
or many top level jakarta projects I don't think moving
them to commons will be an evolution.
Costin
Re: The Release Process
Posted by Peter Donald <do...@apache.org>.
At 09:23 16/3/01 -0800, Morgan Delagrange wrote:
>Let's keep in mind that the core Commons committers
>are _us_ (well, "we" :), and we'll be guiding the
>evolution of this project.
baddabing-badda-boom - a new tribe is born.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*