You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/03/14 12:53:09 UTC
[VOTE] "prop02"
In anticipation of the upcoming PMC meeting, I'd like to propose that we
make
< http://husted.com/about/commons/prop02.html >
The official "reference copy" of our pending proposal.
This includes minor tweaks that came up on the General list. Changes are
indicated with strikethrough and a colored font.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
+1, looks great to me.
David
On Wed, 14 Mar 2001, Ted Husted wrote:
> In anticipation of the upcoming PMC meeting, I'd like to propose that we
> make
>
> < http://husted.com/about/commons/prop02.html >
>
> The official "reference copy" of our pending proposal.
>
> This includes minor tweaks that came up on the General list. Changes are
> indicated with strikethrough and a colored font.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
+1, looks great to me.
David
On Wed, 14 Mar 2001, Ted Husted wrote:
> In anticipation of the upcoming PMC meeting, I'd like to propose that we
> make
>
> < http://husted.com/about/commons/prop02.html >
>
> The official "reference copy" of our pending proposal.
>
> This includes minor tweaks that came up on the General list. Changes are
> indicated with strikethrough and a colored font.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
> The two ideas are:
>
> (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> work on whatever they like there. No questions asked.
>
> (2) A codebase developed in the sandbox can't be released to the public
> from the sandbox. To release the code to the public, you would have to
> move it to another Jakarta CVS, where a subproject could vote to release
> it.
"move" doesn't necesarily means a physical move, I hope.
( the code will continue to "live" in the common workspace, and be
used/shared by multiple projects ).
It can't have a public release without either beeing accepted ( voted ) as
a library project - i.e a general purpose utility that is maintained by
library, or included in an existing jakarta project - in which
case it will be exposed to the public anyway. If the component is included
in a project - that means it goes through testing, etc as part of the
project and is maintained as part of the project - so it should be ok to
be tagged and can be distributed "standalone" too.
AFAIK the reason for not exposing it to the public is that the component
may not have the support and quality that is needed. That's why a vote is
needed before releasing anything. I think support from jakarta-xxx for a
component is as good as support from jakarta-library.
Since the sandbox is open to all jakarta commiters, moving it to another
repository will make it more restrictive - I don't think this is a good
idea.
That's my understanding at least.
Costin
>
> The sandbox could just as easily be part of the Jakarta backbone site,
> but it making it part of the Commons proposal seemed like a convenient
> way to set it up.
>
> "Craig R. McClanahan" wrote:
>
> > In point 20, I understand how a sandbox project can get accepted by the
> > Commons (see 17), but what does "or sponsored by another Jakarta
> > subproject" mean? Does that mean I can bypass the voting in 17 if my
> > subproject's committers are willing to support the code, or what?
> >
> > Craig
>
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> > ....
> > >
> > > That's why we need the extra " or sponsored by a jakarta subproject".
> >
> > I don't think so. I think that additional phrase will lead us back to
> > the current situation. As one of the problems that I hope Commons would
> > solve is making sure that 'released' components are documented,
> > installable and supported. If it's just a tagged set of classes in the
> > sandbox, we are back to the same problem we have already - released code
> > that a project depends upon that is not the projects main 'deliverable'
> > is undocumented, not independantly buildable, testable, and installable,
> > and largely hidden from public view because it's not separated and
> > promoted.
>
> Than what's the problem ??? You think the problem the commons would
> resolve is "released" components - you have that.
Quite frankly, I am not 100% sure the commons would solve that, but I
want to try.
The problem that I was addressing was that 'sponsored by a Jakarta
subproject' is vague to me, and seems pointless - if a project, say
Velocity, wantd to use the 'unreleased' code in a velocity release, I
assume we would just include the code we needed. I can't see other ways
that would be practical for the end-user.
I gotta do this line by line :
> Why don't you let other people to try a different thing ?
Why do you believe I want to stop you? I don't. I respect and support
the idea, your idea, of Agora/playpen/sandbox, for what its worth. And
even if I did, I can't.
And anyway, I thought my point above was limited in scope to the simple
phrase "or sponsored...".
> I am interested
> in sharing the work on some common components -
As I am - the problem that led me here is that we have code duplicated
throughout jakarta, and having some way of getting the separate groups
to work on common basic things would be great.
> I don't care too much
> about releasing the components, it is not my main goal.
Ah. There we differ, and I think it doesn't matter - if you don't want
to release, don't release. You can't be forced to release, except by
your own collaborators, and thats between you and them.
I do think that releasing components would be a good thing - certainly
every other Jakarta project seems to believe that releasing software for
others to use, predictably, is a good thing. So I will try to release
anything I work on that I think is good and valuable to others. You
don't have to.
>I think this will
> happen as a side effect, because the code will be subject to a bigger
> community and in direct contact with the projects using it.
I am not trying to stop anything you want to do, and I wish you would
explain to me how I would be stopping you.
I think that if we look back, while I have been very concerned about
getting the things I want into this, it hasn't been to the exclusion of
other approaches.
On this specific issue, release, I think that the status quo *isn't*
*working*, and depending upon the release process to come out as a 'side
effect' might be unsatisfactory. That's what I saw when I went looking
for a DBCP - Turbine has one, buried. Struts has one - less buried, but
still, if not hidden, certainly 'unemphasized'. They aren't going to
release those parts as separate entities.
I think that if you have a component, and you want to 'release' it, if
it isn't released via inclusion in another jakarta project, it should be
done via commons - that is one of the purposes of the project.
>
> But the fundamental issue is this intolerance I find again and again and
> again in jakarta - why does everyone things that there is only one
> solution and one way to do something ?
Why do you say that? (I assume you are addressing this to me
directly...)
> It is very likely that agora will fail - as far as I can tell intolerance
> is the rule here, and Agora's can't succeed in such environment. But we
> can try - maybe there are people who can repect other's ideas and not try
> to impose their will and solution.
>
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
<sigh> I hope you really don't think I believe that. To me, and I
haven't been around here that long, the Jakarta projects are entities
that serve their specific charter, and produce software for the public
that meets that charter. In the course of that mission, the Jakarta
projects appear to develop building blocks that are necessary for their
mission, but incidental to their 'product'. They therefore do not
package and release the building blocks in a way that is immediately
accessable and useful outside of their specific deliverable.
The DBCP is a great example - everyone needs one, seems like everyone
wrote one, but no one made it so you could just take it and use it (See
Poolman as the great counterexample).
That's what I want to see come out of this - joint development and
productization of common shared components and parts. Note, that is NOT
TO THE EXCLUSION OF OTHER THINGS, LIKE AGORA.
> Your development model is wonderful - but it's not the only one.
I don't think it's wonderful, nor do I think it's the only one. But
some of the ones I see now aren't meeting a need, hence the endless time
spent here trying to get this going....
geir
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
+1
--- Ted Husted <ne...@husted.com> wrote:
> cmanolache@yahoo.com wrote:
> > "Point of distribution" ? I suppose the project(s)
> that vote to release a
> > component will be the point of distribution.
>
> Then we're fine. The underlying concern was that the
> shared CVS could
> become a backdoor where code might be released under
> the Apache brand
> without the usual peer review by a subproject.
> (While I know * you *
> would never do this, we have to write this for
> everyone.)
>
> > And of course, the current proposal that was voted
> include the option for
> > jakarta projects to sponsor sub-components - and I
> don't think you can
> > change that without invalidating the original
> vote.
>
> We've simply been been asked to clarify "sponsor",
> just as we have
> clarified some other points.
>
> I think we may now be down to
>
> "20. A CVS repository will be available to all
> Jakarta committers as a
> workplace for new packages or other projects. Before
> release�to the
> public, code or documentation developed here must be
> accepted into the
> Commons or sponsored by another Jakarta�subproject.
> The sponsoring
> subproject(s) will distribute the code or
> documentation along with the
> rest of their codebase."
>
> Does that seem OK?
>
> -Ted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by Peter Donald <do...@apache.org>.
At 08:53 16/3/01 -0800, Morgan Delagrange wrote:
>It's a good theory, but I don't buy it entirely. We
>can suppose that natural selection will weed out
>poorly designed components, but I think we can, and
>should, take some responsibility and encourage
>refactoring of code that does not meet the Commons charter.
What about that is not hosted under Apache? Say Bob decides to write
component Husherizer and publish it in CJAN. He is not part of Apache and
thus how does anyone take responsibility for the component?
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: [VOTE] "prop02"
Posted by Peter Donald <do...@apache.org>.
At 08:53 16/3/01 -0800, Morgan Delagrange wrote:
>It's a good theory, but I don't buy it entirely. We
>can suppose that natural selection will weed out
>poorly designed components, but I think we can, and
>should, take some responsibility and encourage
>refactoring of code that does not meet the Commons charter.
What about that is not hosted under Apache? Say Bob decides to write
component Husherizer and publish it in CJAN. He is not part of Apache and
thus how does anyone take responsibility for the component?
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: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Peter Donald <do...@apache.org> wrote:
> It's ironic that what I predicted is coming true -
> and the project hasn't
> even started - yea.
>
> At 10:18 15/3/01 -0800, Morgan Delagrange wrote:
> >This is to prevent other subprojects from adding
> >components that are not really designed for general
> >use to the Commons. For example, we want one or
> two
> >really good connection pools of general use, not
> the
> >Struts database pool and the Turbine database pool
> and
> >the Foo database pool and the Bar database pool.
> >Somebody has to make sure that other subprojects
> leave
> >their baggage at the door and design with reuse in
> >mind.
>
> Why?
> Thats one of the mistakes I believe Avalon made. Why
> not just have a
> complete directory - good components will be reused
> while bad ones will be
> ignored. Simple. Especially when the external code
> bases are added to
> directory. No one will be able to do that extensive
> supporting/validating
> these components.
It's a good theory, but I don't buy it entirely. We
can suppose that natural selection will weed out
poorly designed components, but I think we can, and
should, take some responsibility and encourage
refactoring of code that does not meet the Commons charter.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Peter Donald <do...@apache.org> wrote:
> It's ironic that what I predicted is coming true -
> and the project hasn't
> even started - yea.
>
> At 10:18 15/3/01 -0800, Morgan Delagrange wrote:
> >This is to prevent other subprojects from adding
> >components that are not really designed for general
> >use to the Commons. For example, we want one or
> two
> >really good connection pools of general use, not
> the
> >Struts database pool and the Turbine database pool
> and
> >the Foo database pool and the Bar database pool.
> >Somebody has to make sure that other subprojects
> leave
> >their baggage at the door and design with reuse in
> >mind.
>
> Why?
> Thats one of the mistakes I believe Avalon made. Why
> not just have a
> complete directory - good components will be reused
> while bad ones will be
> ignored. Simple. Especially when the external code
> bases are added to
> directory. No one will be able to do that extensive
> supporting/validating
> these components.
It's a good theory, but I don't buy it entirely. We
can suppose that natural selection will weed out
poorly designed components, but I think we can, and
should, take some responsibility and encourage
refactoring of code that does not meet the Commons charter.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: [VOTE] "prop02"
Posted by Peter Donald <do...@apache.org>.
It's ironic that what I predicted is coming true - and the project hasn't
even started - yea.
At 10:18 15/3/01 -0800, Morgan Delagrange wrote:
>This is to prevent other subprojects from adding
>components that are not really designed for general
>use to the Commons. For example, we want one or two
>really good connection pools of general use, not the
>Struts database pool and the Turbine database pool and
>the Foo database pool and the Bar database pool.
>Somebody has to make sure that other subprojects leave
>their baggage at the door and design with reuse in
>mind.
Why?
Thats one of the mistakes I believe Avalon made. Why not just have a
complete directory - good components will be reused while bad ones will be
ignored. Simple. Especially when the external code bases are added to
directory. No one will be able to do that extensive supporting/validating
these components.
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: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> We've been over the Agora concept several times. Two of us here (you and
> Ignacio) are behind it. As far as I can tell, the other 8 committers are
> skeptical as to how it would work in practice. As a courtesy, we have
> been trying to patch the shared repository in the Commons so that you
> and Ignacio can use it to try Agora. But, the shared repository is not
> meant to be solely for the use of the Agora initiative.
And after we voted and agreed on a solution that would allow both Agora,
the sandbox and the commons you decide we should make a small change that
will remove Agora.
With the pretext that jakarta projects are not able to decide what to
release - and only commons is entitled to release shared code.
> If you now feel that use of the Commons shared repository is inadequate
> to your needs, then I would suggest that you reduce your ideas about
> Agora to a proposal that people can vote on.
The use of the shared repository as in the voted proposal is ok for my
needs.
Doing a small change in the proposal that will turn the common repository
is not.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> We've been over the Agora concept several times. Two of us here (you and
> Ignacio) are behind it. As far as I can tell, the other 8 committers are
> skeptical as to how it would work in practice. As a courtesy, we have
> been trying to patch the shared repository in the Commons so that you
> and Ignacio can use it to try Agora. But, the shared repository is not
> meant to be solely for the use of the Agora initiative.
And after we voted and agreed on a solution that would allow both Agora,
the sandbox and the commons you decide we should make a small change that
will remove Agora.
With the pretext that jakarta projects are not able to decide what to
release - and only commons is entitled to release shared code.
> If you now feel that use of the Commons shared repository is inadequate
> to your needs, then I would suggest that you reduce your ideas about
> Agora to a proposal that people can vote on.
The use of the shared repository as in the voted proposal is ok for my
needs.
Doing a small change in the proposal that will turn the common repository
is not.
Costin
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
Costin,
We've been over the Agora concept several times. Two of us here (you and
Ignacio) are behind it. As far as I can tell, the other 8 committers are
skeptical as to how it would work in practice. As a courtesy, we have
been trying to patch the shared repository in the Commons so that you
and Ignacio can use it to try Agora. But, the shared repository is not
meant to be solely for the use of the Agora initiative.
If you now feel that use of the Commons shared repository is inadequate
to your needs, then I would suggest that you reduce your ideas about
Agora to a proposal that people can vote on.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
Costin,
We've been over the Agora concept several times. Two of us here (you and
Ignacio) are behind it. As far as I can tell, the other 8 committers are
skeptical as to how it would work in practice. As a courtesy, we have
been trying to patch the shared repository in the Commons so that you
and Ignacio can use it to try Agora. But, the shared repository is not
meant to be solely for the use of the Agora initiative.
If you now feel that use of the Commons shared repository is inadequate
to your needs, then I would suggest that you reduce your ideas about
Agora to a proposal that people can vote on.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: [VOTE] "prop02"
Posted by Peter Donald <do...@apache.org>.
It's ironic that what I predicted is coming true - and the project hasn't
even started - yea.
At 10:18 15/3/01 -0800, Morgan Delagrange wrote:
>This is to prevent other subprojects from adding
>components that are not really designed for general
>use to the Commons. For example, we want one or two
>really good connection pools of general use, not the
>Struts database pool and the Turbine database pool and
>the Foo database pool and the Bar database pool.
>Somebody has to make sure that other subprojects leave
>their baggage at the door and design with reuse in
>mind.
Why?
Thats one of the mistakes I believe Avalon made. Why not just have a
complete directory - good components will be reused while bad ones will be
ignored. Simple. Especially when the external code bases are added to
directory. No one will be able to do that extensive supporting/validating
these components.
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: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Ted Husted wrote:
>
> > cmanolache@yahoo.com wrote:
> > > "Point of distribution" ? I suppose the
> project(s) that vote to release a
> > > component will be the point of distribution.
> >
> > Then we're fine. The underlying concern was that
> the shared CVS could
> > become a backdoor where code might be released
> under the Apache brand
> > without the usual peer review by a subproject.
> (While I know * you *
> > would never do this, we have to write this for
> everyone.)
>
> Ted, if this is the concern than the rule that
> "jakarta projects that have
> the component as part of their release" is much more
> powerfull and
> provides more peer review than the rule that
> "commons will vote on each
> component release".
I don't think that's what we're saying. We're saying
that the Commons committers will vote whether or not
sandbox code has demonstrated sufficient progress and
independence to be moved into the Commons project,
along with its committers. The component committers
still have control both while in the sandbox and
(essentially) when in the Commons, but the Commons
committers have to decide if a project is appropriate
to move from the sandbox to Commons.
This is to prevent other subprojects from adding
components that are not really designed for general
use to the Commons. For example, we want one or two
really good connection pools of general use, not the
Struts database pool and the Turbine database pool and
the Foo database pool and the Bar database pool.
Somebody has to make sure that other subprojects leave
their baggage at the door and design with reuse in
mind.
> Read my previous mail - I would be more concerned
> about "commons" voting
> on component they don't know and are developed by
> small subgroups than on
> jakarat projects voting on component they use and
> have to support ( and
> maybe share with other jakarta projects).
I think this is a misconception. The same component
developers involved in the sandbox development will,
by and large, be involved in the Commons development.
The whole group of Commons committers only vote on
whether or not to induct a component into the Commons
repository.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Ted Husted wrote:
>
> > cmanolache@yahoo.com wrote:
> > > "Point of distribution" ? I suppose the
> project(s) that vote to release a
> > > component will be the point of distribution.
> >
> > Then we're fine. The underlying concern was that
> the shared CVS could
> > become a backdoor where code might be released
> under the Apache brand
> > without the usual peer review by a subproject.
> (While I know * you *
> > would never do this, we have to write this for
> everyone.)
>
> Ted, if this is the concern than the rule that
> "jakarta projects that have
> the component as part of their release" is much more
> powerfull and
> provides more peer review than the rule that
> "commons will vote on each
> component release".
I don't think that's what we're saying. We're saying
that the Commons committers will vote whether or not
sandbox code has demonstrated sufficient progress and
independence to be moved into the Commons project,
along with its committers. The component committers
still have control both while in the sandbox and
(essentially) when in the Commons, but the Commons
committers have to decide if a project is appropriate
to move from the sandbox to Commons.
This is to prevent other subprojects from adding
components that are not really designed for general
use to the Commons. For example, we want one or two
really good connection pools of general use, not the
Struts database pool and the Turbine database pool and
the Foo database pool and the Bar database pool.
Somebody has to make sure that other subprojects leave
their baggage at the door and design with reuse in
mind.
> Read my previous mail - I would be more concerned
> about "commons" voting
> on component they don't know and are developed by
> small subgroups than on
> jakarat projects voting on component they use and
> have to support ( and
> maybe share with other jakarta projects).
I think this is a misconception. The same component
developers involved in the sandbox development will,
by and large, be involved in the Commons development.
The whole group of Commons committers only vote on
whether or not to induct a component into the Commons
repository.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > "Point of distribution" ? I suppose the project(s) that vote to release a
> > component will be the point of distribution.
>
> Then we're fine. The underlying concern was that the shared CVS could
> become a backdoor where code might be released under the Apache brand
> without the usual peer review by a subproject. (While I know * you *
> would never do this, we have to write this for everyone.)
Ted, if this is the concern than the rule that "jakarta projects that have
the component as part of their release" is much more powerfull and
provides more peer review than the rule that "commons will vote on each
component release".
Read my previous mail - I would be more concerned about "commons" voting
on component they don't know and are developed by small subgroups than on
jakarat projects voting on component they use and have to support ( and
maybe share with other jakarta projects).
Costin
>
> > And of course, the current proposal that was voted include the option for
> > jakarta projects to sponsor sub-components - and I don't think you can
> > change that without invalidating the original vote.
>
> We've simply been been asked to clarify "sponsor", just as we have
> clarified some other points.
>
> I think we may now be down to
>
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
>
> Does that seem OK?
>
> -Ted.
>
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
+1
--- Ted Husted <ne...@husted.com> wrote:
> cmanolache@yahoo.com wrote:
> > "Point of distribution" ? I suppose the project(s)
> that vote to release a
> > component will be the point of distribution.
>
> Then we're fine. The underlying concern was that the
> shared CVS could
> become a backdoor where code might be released under
> the Apache brand
> without the usual peer review by a subproject.
> (While I know * you *
> would never do this, we have to write this for
> everyone.)
>
> > And of course, the current proposal that was voted
> include the option for
> > jakarta projects to sponsor sub-components - and I
> don't think you can
> > change that without invalidating the original
> vote.
>
> We've simply been been asked to clarify "sponsor",
> just as we have
> clarified some other points.
>
> I think we may now be down to
>
> "20. A CVS repository will be available to all
> Jakarta committers as a
> workplace for new packages or other projects. Before
> release�to the
> public, code or documentation developed here must be
> accepted into the
> Commons or sponsored by another Jakarta�subproject.
> The sponsoring
> subproject(s) will distribute the code or
> documentation along with the
> rest of their codebase."
>
> Does that seem OK?
>
> -Ted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > "Point of distribution" ? I suppose the project(s) that vote to release a
> > component will be the point of distribution.
>
> Then we're fine. The underlying concern was that the shared CVS could
> become a backdoor where code might be released under the Apache brand
> without the usual peer review by a subproject. (While I know * you *
> would never do this, we have to write this for everyone.)
Ted, if this is the concern than the rule that "jakarta projects that have
the component as part of their release" is much more powerfull and
provides more peer review than the rule that "commons will vote on each
component release".
Read my previous mail - I would be more concerned about "commons" voting
on component they don't know and are developed by small subgroups than on
jakarat projects voting on component they use and have to support ( and
maybe share with other jakarta projects).
Costin
>
> > And of course, the current proposal that was voted include the option for
> > jakarta projects to sponsor sub-components - and I don't think you can
> > change that without invalidating the original vote.
>
> We've simply been been asked to clarify "sponsor", just as we have
> clarified some other points.
>
> I think we may now be down to
>
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
>
> Does that seem OK?
>
> -Ted.
>
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> "Point of distribution" ? I suppose the project(s) that vote to release a
> component will be the point of distribution.
Then we're fine. The underlying concern was that the shared CVS could
become a backdoor where code might be released under the Apache brand
without the usual peer review by a subproject. (While I know * you *
would never do this, we have to write this for everyone.)
> And of course, the current proposal that was voted include the option for
> jakarta projects to sponsor sub-components - and I don't think you can
> change that without invalidating the original vote.
We've simply been been asked to clarify "sponsor", just as we have
clarified some other points.
I think we may now be down to
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
Does that seem OK?
-Ted.
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
>
> Thats why I don't think that the phrase about the sponsoring project
> releasing is inappropriate.
Man, I'm tired... double negatives - sorry... y'all know what I
mean...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
>
> Thats why I don't think that the phrase about the sponsoring project
> releasing is inappropriate.
Man, I'm tired... double negatives - sorry... y'all know what I
mean...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> >
> > > In commons you have groups of people each working on few components and
> > > asked to vote for a component they are not directly involved with - this
> > > doesn't sound too good for the quality of the product, does it ?
> >
> > I understand what you are saying, but I think that the judgement will be
> > more about making the component a standalone mini-project under Commons
> > - answering the question 'is this subject appropriate' - rather than
> > some vote of merit. Darwain will take care of the quality issue, I
> > think. No one would use it if of low quality...
> >
> > The committers who built it would still be making the decisions about
> > the component - I can't see how or why you would want to take that away.
>
> Geir, I do agree with that - but read today's mail again...
>
> This whole debate started because some people believe what you are saying
> here can apply only if the "commiters who are making the decision" are the
> commons commiters.
Which decision? The decision to release? To be clear, I think that the
committers who make the decision to release are the component
committers, or another way, the collaborators : the people who are
working on that specific component.
Now, they way I interpreted things, they are really making the decision
to 'apply to commons to accept their component as a separate entity that
those collaborators will support'.
It was up to commons to accept or refuse that 'application'. If
accepted that same group of people would continue on their path...
> A component that is built by a project as part of the sandbox/agora isn't
> supposed to be released to the public - because of quality concerns.
Wait - where did 'because of quality concerns' come from? While I guess
it really depends on how one defines 'released', my interpretation was
that it wasn't supposed to be released for other reasons, such as :
1) there was no visibility. If a tree falls...
2) we decided for a common structure for released components, including
docs, build process, etc - there is no way to have that if it's just
living in the sandbox.
> Yet a
> component that is accepted by commons commiters can be released, even if
> it has a smaller set of commiters and less review.
I think this comes down again to causality - the only way a component
can be accepted by the 'commons committers' and therefore released is IF
and ONLY IF the collaborators of the component (committers for that
component) decide they want to release and THEN ask the 'commons
committers' for a vote.
> I don't have anything against "playground" or against releasing a
> component if it has at least one commited developer behind it. Darwin will
> take care, and users will select.
>
> I have a problem with the playground beeing used as an argument that agora
> is a place for experiments where code can't be released ( even if a top
> level project is supporting it), and I have a problem with arguing that
> a project that wants to release a stand-alone component out of
> sandbox needs to get the aproval of commons.
Well, there are a few things there, I will try to give my opinion of
them individually, and then I am going to bed :)
1) I think it depends upon what a 'released component' is wrt Commons :
if we define a 'released component' as something separate and standalone
with documentation, build proc, etc, and has been approved by the
commons committers as appropriate, the by definition it can't be still
living in the agora. That doesn't negate or diminish Agora - it just
means that 'released in Agora' contradicts the [convenient for me :)]
definition of 'released in the Commons'.
2) What does it mean that a project releases a stand-alone component?
Commons is a project that would be a peer to the 'sponsoring project',
so I don't think that its right that the sponsoring project can
'release' a component w/in commons by fiat. The sponsoring project
could petition commons, like any other component collaborator(s), and if
not approved, could simply take the code and 'release' in the environs
of the sponsoring project.
Thats why I don't think that the phrase about the sponsoring project
releasing is inappropriate.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> >
> > > In commons you have groups of people each working on few components and
> > > asked to vote for a component they are not directly involved with - this
> > > doesn't sound too good for the quality of the product, does it ?
> >
> > I understand what you are saying, but I think that the judgement will be
> > more about making the component a standalone mini-project under Commons
> > - answering the question 'is this subject appropriate' - rather than
> > some vote of merit. Darwain will take care of the quality issue, I
> > think. No one would use it if of low quality...
> >
> > The committers who built it would still be making the decisions about
> > the component - I can't see how or why you would want to take that away.
>
> Geir, I do agree with that - but read today's mail again...
>
> This whole debate started because some people believe what you are saying
> here can apply only if the "commiters who are making the decision" are the
> commons commiters.
Which decision? The decision to release? To be clear, I think that the
committers who make the decision to release are the component
committers, or another way, the collaborators : the people who are
working on that specific component.
Now, they way I interpreted things, they are really making the decision
to 'apply to commons to accept their component as a separate entity that
those collaborators will support'.
It was up to commons to accept or refuse that 'application'. If
accepted that same group of people would continue on their path...
> A component that is built by a project as part of the sandbox/agora isn't
> supposed to be released to the public - because of quality concerns.
Wait - where did 'because of quality concerns' come from? While I guess
it really depends on how one defines 'released', my interpretation was
that it wasn't supposed to be released for other reasons, such as :
1) there was no visibility. If a tree falls...
2) we decided for a common structure for released components, including
docs, build process, etc - there is no way to have that if it's just
living in the sandbox.
> Yet a
> component that is accepted by commons commiters can be released, even if
> it has a smaller set of commiters and less review.
I think this comes down again to causality - the only way a component
can be accepted by the 'commons committers' and therefore released is IF
and ONLY IF the collaborators of the component (committers for that
component) decide they want to release and THEN ask the 'commons
committers' for a vote.
> I don't have anything against "playground" or against releasing a
> component if it has at least one commited developer behind it. Darwin will
> take care, and users will select.
>
> I have a problem with the playground beeing used as an argument that agora
> is a place for experiments where code can't be released ( even if a top
> level project is supporting it), and I have a problem with arguing that
> a project that wants to release a stand-alone component out of
> sandbox needs to get the aproval of commons.
Well, there are a few things there, I will try to give my opinion of
them individually, and then I am going to bed :)
1) I think it depends upon what a 'released component' is wrt Commons :
if we define a 'released component' as something separate and standalone
with documentation, build proc, etc, and has been approved by the
commons committers as appropriate, the by definition it can't be still
living in the agora. That doesn't negate or diminish Agora - it just
means that 'released in Agora' contradicts the [convenient for me :)]
definition of 'released in the Commons'.
2) What does it mean that a project releases a stand-alone component?
Commons is a project that would be a peer to the 'sponsoring project',
so I don't think that its right that the sponsoring project can
'release' a component w/in commons by fiat. The sponsoring project
could petition commons, like any other component collaborator(s), and if
not approved, could simply take the code and 'release' in the environs
of the sponsoring project.
Thats why I don't think that the phrase about the sponsoring project
releasing is inappropriate.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> cmanolache@yahoo.com wrote:
>
> > In commons you have groups of people each working on few components and
> > asked to vote for a component they are not directly involved with - this
> > doesn't sound too good for the quality of the product, does it ?
>
> I understand what you are saying, but I think that the judgement will be
> more about making the component a standalone mini-project under Commons
> - answering the question 'is this subject appropriate' - rather than
> some vote of merit. Darwain will take care of the quality issue, I
> think. No one would use it if of low quality...
>
> The committers who built it would still be making the decisions about
> the component - I can't see how or why you would want to take that away.
Geir, I do agree with that - but read today's mail again...
This whole debate started because some people believe what you are saying
here can apply only if the "commiters who are making the decision" are the
commons commiters.
A component that is built by a project as part of the sandbox/agora isn't
supposed to be released to the public - because of quality concerns. Yet a
component that is accepted by commons commiters can be released, even if
it has a smaller set of commiters and less review.
I don't have anything against "playground" or against releasing a
component if it has at least one commited developer behind it. Darwin will
take care, and users will select.
I have a problem with the playground beeing used as an argument that agora
is a place for experiments where code can't be released ( even if a top
level project is supporting it), and I have a problem with arguing that
a project that wants to release a stand-alone component out of
sandbox needs to get the aproval of commons.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> cmanolache@yahoo.com wrote:
>
> > In commons you have groups of people each working on few components and
> > asked to vote for a component they are not directly involved with - this
> > doesn't sound too good for the quality of the product, does it ?
>
> I understand what you are saying, but I think that the judgement will be
> more about making the component a standalone mini-project under Commons
> - answering the question 'is this subject appropriate' - rather than
> some vote of merit. Darwain will take care of the quality issue, I
> think. No one would use it if of low quality...
>
> The committers who built it would still be making the decisions about
> the component - I can't see how or why you would want to take that away.
Geir, I do agree with that - but read today's mail again...
This whole debate started because some people believe what you are saying
here can apply only if the "commiters who are making the decision" are the
commons commiters.
A component that is built by a project as part of the sandbox/agora isn't
supposed to be released to the public - because of quality concerns. Yet a
component that is accepted by commons commiters can be released, even if
it has a smaller set of commiters and less review.
I don't have anything against "playground" or against releasing a
component if it has at least one commited developer behind it. Darwin will
take care, and users will select.
I have a problem with the playground beeing used as an argument that agora
is a place for experiments where code can't be released ( even if a top
level project is supporting it), and I have a problem with arguing that
a project that wants to release a stand-alone component out of
sandbox needs to get the aproval of commons.
Costin
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> In commons you have groups of people each working on few components and
> asked to vote for a component they are not directly involved with - this
> doesn't sound too good for the quality of the product, does it ?
I understand what you are saying, but I think that the judgement will be
more about making the component a standalone mini-project under Commons
- answering the question 'is this subject appropriate' - rather than
some vote of merit. Darwain will take care of the quality issue, I
think. No one would use it if of low quality...
The committers who built it would still be making the decisions about
the component - I can't see how or why you would want to take that away.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> "Point of distribution" ? I suppose the project(s) that vote to release a
> component will be the point of distribution.
Then we're fine. The underlying concern was that the shared CVS could
become a backdoor where code might be released under the Apache brand
without the usual peer review by a subproject. (While I know * you *
would never do this, we have to write this for everyone.)
> And of course, the current proposal that was voted include the option for
> jakarta projects to sponsor sub-components - and I don't think you can
> change that without invalidating the original vote.
We've simply been been asked to clarify "sponsor", just as we have
clarified some other points.
I think we may now be down to
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
Does that seem OK?
-Ted.
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> In commons you have groups of people each working on few components and
> asked to vote for a component they are not directly involved with - this
> doesn't sound too good for the quality of the product, does it ?
I understand what you are saying, but I think that the judgement will be
more about making the component a standalone mini-project under Commons
- answering the question 'is this subject appropriate' - rather than
some vote of merit. Darwain will take care of the quality issue, I
think. No one would use it if of low quality...
The committers who built it would still be making the decisions about
the component - I can't see how or why you would want to take that away.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > What's the problem ? Is the library the guardian of Apache quality, the
> > only absolut experts in components ? Are jakarta projects some stupid
> > entities who can't be trusted to release something to the public ?
>
> The problem is that the sandbox is not a subproject, it is a CVS
> repository.
>
> The ASF has deputized Jakarta subprojects to release products using the
> Apache brand.
Ok, and that's exactly what's in the proposal - that Jakarta subprojects
could release products they are developing.
> Before a product is released to the public, it must receive majority
> approval of all the committers to that product. This is our fail-safe.
>
> In the Commons, packages are being developed in small groups, but the
> entire subproject still has to sign-off on a release. The packages will
> be versioned, and safe to use by other products.
In Agora, packages are developed by big groups - and most likely multiple
jakarta subprojects will work togheter and sign-off on a release.
It seems to be a bit more than the commons is offering - not to mention
more testing, and much more review.
Rember that for shared components all subprojects using it have a vote and
are reviewing the code to make sure it works with that project - so
releases will have far more coverage.
In commons you have groups of people each working on few components and
asked to vote for a component they are not directly involved with - this
doesn't sound too good for the quality of the product, does it ?
> If the codebases you want to develop here are to be released and
> distributed by one or more subprojects, as part of their codebase, then
> I believe everyone is fine. But I believe the point of distribution has
> to be one (or more) of the subprojects, or this may not be a legal use
> of the Apache brand.
"Point of distribution" ? I suppose the project(s) that vote to release a
component will be the point of distribution.
> Of course, if Roy Fielding were to say otherwise, then I would have no
> qualm.
And of course, the current proposal that was voted include the option for
jakarta projects to sponsor sub-components - and I don't think you can
change that without invalidating the original vote.
Costin
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> Well, after a bit more thinking - I do agree that something is wrong in
> the proposal.
>
> But that's the fact that the commons commiters can vote and release to the
> public a component that is developed by a small group, and the vote
> involves people who can't provide any guarantee for the quality of the
> product or the future maintainance.
But I think you are inverting the picture here a little, because I can't
imagine that the commons committers can *proactively* do that, go grab
something and release it. I would imagine that vote by the commons
committers would be *reactive* : only after a group of component
developers decided *they* want to release (and are willing to continue
to be responsible), only then would the commons committers vote on the
appropriateness of that component to the Commons / Jakarta charter.
By asking the Commons committers to vote on the 'separation' of their
component into a distinct entity in Commons, the component committers
are declaring their intent to continue to support the component.
>
> So if you are worried about the Apache brand - probably we should remove
> the possibility for commons to release components - the only people that
> can vote for a components are those involved in the development and
> maintainance of the component.
Again, the distinction should be :
1) Only the people that are involved in the development and maintenance
of the component can decide to ask that it become a separate component
under Commons.
2) Then the Commons must decide if it is an appropriate thing to as a
separate entity, and if the vote is positive, then it is up to the set
of people in 1) to continue to work and support the component.
> On the other side jakarata projects who use a component and support it as
> part of their product do have the knowledge and can insure the quality of
> the product.
>
> If you work on a DBCP I don't see how can you vote and promise support for
> a ThreadPool - since commons will be composed of many subprojects you
> can't expect everyone to be involved with all components.
It's my interpretation that you wouldn't - the same people would
continue.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> Well, after a bit more thinking - I do agree that something is wrong in
> the proposal.
>
> But that's the fact that the commons commiters can vote and release to the
> public a component that is developed by a small group, and the vote
> involves people who can't provide any guarantee for the quality of the
> product or the future maintainance.
But I think you are inverting the picture here a little, because I can't
imagine that the commons committers can *proactively* do that, go grab
something and release it. I would imagine that vote by the commons
committers would be *reactive* : only after a group of component
developers decided *they* want to release (and are willing to continue
to be responsible), only then would the commons committers vote on the
appropriateness of that component to the Commons / Jakarta charter.
By asking the Commons committers to vote on the 'separation' of their
component into a distinct entity in Commons, the component committers
are declaring their intent to continue to support the component.
>
> So if you are worried about the Apache brand - probably we should remove
> the possibility for commons to release components - the only people that
> can vote for a components are those involved in the development and
> maintainance of the component.
Again, the distinction should be :
1) Only the people that are involved in the development and maintenance
of the component can decide to ask that it become a separate component
under Commons.
2) Then the Commons must decide if it is an appropriate thing to as a
separate entity, and if the vote is positive, then it is up to the set
of people in 1) to continue to work and support the component.
> On the other side jakarata projects who use a component and support it as
> part of their product do have the knowledge and can insure the quality of
> the product.
>
> If you work on a DBCP I don't see how can you vote and promise support for
> a ThreadPool - since commons will be composed of many subprojects you
> can't expect everyone to be involved with all components.
It's my interpretation that you wouldn't - the same people would
continue.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Well, after a bit more thinking - I do agree that something is wrong in
the proposal.
But that's the fact that the commons commiters can vote and release to the
public a component that is developed by a small group, and the vote
involves people who can't provide any guarantee for the quality of the
product or the future maintainance.
So if you are worried about the Apache brand - probably we should remove
the possibility for commons to release components - the only people that
can vote for a components are those involved in the development and
maintainance of the component.
On the other side jakarata projects who use a component and support it as
part of their product do have the knowledge and can insure the quality of
the product.
If you work on a DBCP I don't see how can you vote and promise support for
a ThreadPool - since commons will be composed of many subprojects you
can't expect everyone to be involved with all components.
Costin
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > What's the problem ? Is the library the guardian of Apache quality, the
> > only absolut experts in components ? Are jakarta projects some stupid
> > entities who can't be trusted to release something to the public ?
>
> The problem is that the sandbox is not a subproject, it is a CVS
> repository.
>
> The ASF has deputized Jakarta subprojects to release products using the
> Apache brand.
>
> Before a product is released to the public, it must receive majority
> approval of all the committers to that product. This is our fail-safe.
>
> In the Commons, packages are being developed in small groups, but the
> entire subproject still has to sign-off on a release. The packages will
> be versioned, and safe to use by other products.
>
> If the codebases you want to develop here are to be released and
> distributed by one or more subprojects, as part of their codebase, then
> I believe everyone is fine. But I believe the point of distribution has
> to be one (or more) of the subprojects, or this may not be a legal use
> of the Apache brand.
>
> Of course, if Roy Fielding were to say otherwise, then I would have no
> qualm.
>
> -Ted.
>
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > What's the problem ? Is the library the guardian of Apache quality, the
> > only absolut experts in components ? Are jakarta projects some stupid
> > entities who can't be trusted to release something to the public ?
>
> The problem is that the sandbox is not a subproject, it is a CVS
> repository.
>
> The ASF has deputized Jakarta subprojects to release products using the
> Apache brand.
Ok, and that's exactly what's in the proposal - that Jakarta subprojects
could release products they are developing.
> Before a product is released to the public, it must receive majority
> approval of all the committers to that product. This is our fail-safe.
>
> In the Commons, packages are being developed in small groups, but the
> entire subproject still has to sign-off on a release. The packages will
> be versioned, and safe to use by other products.
In Agora, packages are developed by big groups - and most likely multiple
jakarta subprojects will work togheter and sign-off on a release.
It seems to be a bit more than the commons is offering - not to mention
more testing, and much more review.
Rember that for shared components all subprojects using it have a vote and
are reviewing the code to make sure it works with that project - so
releases will have far more coverage.
In commons you have groups of people each working on few components and
asked to vote for a component they are not directly involved with - this
doesn't sound too good for the quality of the product, does it ?
> If the codebases you want to develop here are to be released and
> distributed by one or more subprojects, as part of their codebase, then
> I believe everyone is fine. But I believe the point of distribution has
> to be one (or more) of the subprojects, or this may not be a legal use
> of the Apache brand.
"Point of distribution" ? I suppose the project(s) that vote to release a
component will be the point of distribution.
> Of course, if Roy Fielding were to say otherwise, then I would have no
> qualm.
And of course, the current proposal that was voted include the option for
jakarta projects to sponsor sub-components - and I don't think you can
change that without invalidating the original vote.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Well, after a bit more thinking - I do agree that something is wrong in
the proposal.
But that's the fact that the commons commiters can vote and release to the
public a component that is developed by a small group, and the vote
involves people who can't provide any guarantee for the quality of the
product or the future maintainance.
So if you are worried about the Apache brand - probably we should remove
the possibility for commons to release components - the only people that
can vote for a components are those involved in the development and
maintainance of the component.
On the other side jakarata projects who use a component and support it as
part of their product do have the knowledge and can insure the quality of
the product.
If you work on a DBCP I don't see how can you vote and promise support for
a ThreadPool - since commons will be composed of many subprojects you
can't expect everyone to be involved with all components.
Costin
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > What's the problem ? Is the library the guardian of Apache quality, the
> > only absolut experts in components ? Are jakarta projects some stupid
> > entities who can't be trusted to release something to the public ?
>
> The problem is that the sandbox is not a subproject, it is a CVS
> repository.
>
> The ASF has deputized Jakarta subprojects to release products using the
> Apache brand.
>
> Before a product is released to the public, it must receive majority
> approval of all the committers to that product. This is our fail-safe.
>
> In the Commons, packages are being developed in small groups, but the
> entire subproject still has to sign-off on a release. The packages will
> be versioned, and safe to use by other products.
>
> If the codebases you want to develop here are to be released and
> distributed by one or more subprojects, as part of their codebase, then
> I believe everyone is fine. But I believe the point of distribution has
> to be one (or more) of the subprojects, or this may not be a legal use
> of the Apache brand.
>
> Of course, if Roy Fielding were to say otherwise, then I would have no
> qualm.
>
> -Ted.
>
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
The problem is that the sandbox is not a subproject, it is a CVS
repository.
The ASF has deputized Jakarta subprojects to release products using the
Apache brand.
Before a product is released to the public, it must receive majority
approval of all the committers to that product. This is our fail-safe.
In the Commons, packages are being developed in small groups, but the
entire subproject still has to sign-off on a release. The packages will
be versioned, and safe to use by other products.
If the codebases you want to develop here are to be released and
distributed by one or more subprojects, as part of their codebase, then
I believe everyone is fine. But I believe the point of distribution has
to be one (or more) of the subprojects, or this may not be a legal use
of the Apache brand.
Of course, if Roy Fielding were to say otherwise, then I would have no
qualm.
-Ted.
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> > ....
> > >
> > > That's why we need the extra " or sponsored by a jakarta subproject".
> >
> > I don't think so. I think that additional phrase will lead us back to
> > the current situation. As one of the problems that I hope Commons would
> > solve is making sure that 'released' components are documented,
> > installable and supported. If it's just a tagged set of classes in the
> > sandbox, we are back to the same problem we have already - released code
> > that a project depends upon that is not the projects main 'deliverable'
> > is undocumented, not independantly buildable, testable, and installable,
> > and largely hidden from public view because it's not separated and
> > promoted.
>
> Than what's the problem ??? You think the problem the commons would
> resolve is "released" components - you have that.
Quite frankly, I am not 100% sure the commons would solve that, but I
want to try.
The problem that I was addressing was that 'sponsored by a Jakarta
subproject' is vague to me, and seems pointless - if a project, say
Velocity, wantd to use the 'unreleased' code in a velocity release, I
assume we would just include the code we needed. I can't see other ways
that would be practical for the end-user.
I gotta do this line by line :
> Why don't you let other people to try a different thing ?
Why do you believe I want to stop you? I don't. I respect and support
the idea, your idea, of Agora/playpen/sandbox, for what its worth. And
even if I did, I can't.
And anyway, I thought my point above was limited in scope to the simple
phrase "or sponsored...".
> I am interested
> in sharing the work on some common components -
As I am - the problem that led me here is that we have code duplicated
throughout jakarta, and having some way of getting the separate groups
to work on common basic things would be great.
> I don't care too much
> about releasing the components, it is not my main goal.
Ah. There we differ, and I think it doesn't matter - if you don't want
to release, don't release. You can't be forced to release, except by
your own collaborators, and thats between you and them.
I do think that releasing components would be a good thing - certainly
every other Jakarta project seems to believe that releasing software for
others to use, predictably, is a good thing. So I will try to release
anything I work on that I think is good and valuable to others. You
don't have to.
>I think this will
> happen as a side effect, because the code will be subject to a bigger
> community and in direct contact with the projects using it.
I am not trying to stop anything you want to do, and I wish you would
explain to me how I would be stopping you.
I think that if we look back, while I have been very concerned about
getting the things I want into this, it hasn't been to the exclusion of
other approaches.
On this specific issue, release, I think that the status quo *isn't*
*working*, and depending upon the release process to come out as a 'side
effect' might be unsatisfactory. That's what I saw when I went looking
for a DBCP - Turbine has one, buried. Struts has one - less buried, but
still, if not hidden, certainly 'unemphasized'. They aren't going to
release those parts as separate entities.
I think that if you have a component, and you want to 'release' it, if
it isn't released via inclusion in another jakarta project, it should be
done via commons - that is one of the purposes of the project.
>
> But the fundamental issue is this intolerance I find again and again and
> again in jakarta - why does everyone things that there is only one
> solution and one way to do something ?
Why do you say that? (I assume you are addressing this to me
directly...)
> It is very likely that agora will fail - as far as I can tell intolerance
> is the rule here, and Agora's can't succeed in such environment. But we
> can try - maybe there are people who can repect other's ideas and not try
> to impose their will and solution.
>
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
<sigh> I hope you really don't think I believe that. To me, and I
haven't been around here that long, the Jakarta projects are entities
that serve their specific charter, and produce software for the public
that meets that charter. In the course of that mission, the Jakarta
projects appear to develop building blocks that are necessary for their
mission, but incidental to their 'product'. They therefore do not
package and release the building blocks in a way that is immediately
accessable and useful outside of their specific deliverable.
The DBCP is a great example - everyone needs one, seems like everyone
wrote one, but no one made it so you could just take it and use it (See
Poolman as the great counterexample).
That's what I want to see come out of this - joint development and
productization of common shared components and parts. Note, that is NOT
TO THE EXCLUSION OF OTHER THINGS, LIKE AGORA.
> Your development model is wonderful - but it's not the only one.
I don't think it's wonderful, nor do I think it's the only one. But
some of the ones I see now aren't meeting a need, hence the endless time
spent here trying to get this going....
geir
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
The problem is that the sandbox is not a subproject, it is a CVS
repository.
The ASF has deputized Jakarta subprojects to release products using the
Apache brand.
Before a product is released to the public, it must receive majority
approval of all the committers to that product. This is our fail-safe.
In the Commons, packages are being developed in small groups, but the
entire subproject still has to sign-off on a release. The packages will
be versioned, and safe to use by other products.
If the codebases you want to develop here are to be released and
distributed by one or more subprojects, as part of their codebase, then
I believe everyone is fine. But I believe the point of distribution has
to be one (or more) of the subprojects, or this may not be a legal use
of the Apache brand.
Of course, if Roy Fielding were to say otherwise, then I would have no
qualm.
-Ted.
Re: End - Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> > "20. A CVS repository will be available to all Jakarta committers as a
> > workplace for new packages or other projects. Before release to the
> > public, code or documentation developed here must be accepted into the
> > Commons or sponsored by another Jakarta subproject. The sponsoring
> > subproject(s) will distribute the code or documentation along with the
> > rest of their codebase."
>
> What about:
>
> "The sponsoring project will maintain, support the distributed component
> along with their codebase"
>
> If 2 projects share a component it may be better to have a single point of
> distribution for the component.
> ( they may decide not to place it in commons, but keep it an
> agora component )
I think then one of the subprojects might want to serve as point.
Or, if this takes off, Agora can be proposed on its own, with a separate
CVS.
But a fundamental groundrule is that if you're working on something in
the shared CVS, and release it through another subproject, then what you
do with the codebase is not the concern of the Commons subproject. This
would hold true for any development model people want to try, including
Agora.
-Ted.
Re: End - Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> > "20. A CVS repository will be available to all Jakarta committers as a
> > workplace for new packages or other projects. Before release to the
> > public, code or documentation developed here must be accepted into the
> > Commons or sponsored by another Jakarta subproject. The sponsoring
> > subproject(s) will distribute the code or documentation along with the
> > rest of their codebase."
>
> What about:
>
> "The sponsoring project will maintain, support the distributed component
> along with their codebase"
>
> If 2 projects share a component it may be better to have a single point of
> distribution for the component.
> ( they may decide not to place it in commons, but keep it an
> agora component )
I think then one of the subprojects might want to serve as point.
Or, if this takes off, Agora can be proposed on its own, with a separate
CVS.
But a fundamental groundrule is that if you're working on something in
the shared CVS, and release it through another subproject, then what you
do with the codebase is not the concern of the Commons subproject. This
would hold true for any development model people want to try, including
Agora.
-Ted.
Re: End - Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Please don't missunderstand me - I will probably participate in the
sandbox and contribute code.
But I have too much work to do and this debate is eating too much time -
and I don't think it's worth it.
I don't want to be part of the "commons" commiters if this is another
tribe who decide what's right and wrong for the components. I think the
projects need to have ( and feel they have ) a lot of control over the
components in order to participate.
The concern is that the "commons" will be involved in decisions without
having the right knowledge about it - the subprojects that are sharing
some code or developing it in the common place are the best to judge the
quality and the only that can provide the right support.
The concern is that this will turn into another round of debeate each time
someone will decide that a component is too "J2EE-ish" or duplicates
another component or they don't like something else. And the projects will
prefer to avoid this and keep the component private.
( don't tell me this will not happen - look at the current thread where
most people that are interested in developing components
jakarta-style argue pasionately about what should happen in the agora
side, and give all kind of arguments about why this shouldn't be allowed )
It's already difficult to go along with another project and share
something - even if you have a clear common goal in a component - add a
group of even more diverse people and put them in charge of deciding
what's good for the shared component.
So that's my concern - that we'll keep fighting about what's right and
wrong instead of letting the jakarta projects that are supposed to share
decide what's good or bad for themself.
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
What about:
"The sponsoring project will maintain, support the distributed component
along with their codebase"
If 2 projects share a component it may be better to have a single point of
distribution for the component.
( they may decide not to place it in commons, but keep it an
agora component )
Costin
Re: End - Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Please don't missunderstand me - I will probably participate in the
sandbox and contribute code.
But I have too much work to do and this debate is eating too much time -
and I don't think it's worth it.
I don't want to be part of the "commons" commiters if this is another
tribe who decide what's right and wrong for the components. I think the
projects need to have ( and feel they have ) a lot of control over the
components in order to participate.
The concern is that the "commons" will be involved in decisions without
having the right knowledge about it - the subprojects that are sharing
some code or developing it in the common place are the best to judge the
quality and the only that can provide the right support.
The concern is that this will turn into another round of debeate each time
someone will decide that a component is too "J2EE-ish" or duplicates
another component or they don't like something else. And the projects will
prefer to avoid this and keep the component private.
( don't tell me this will not happen - look at the current thread where
most people that are interested in developing components
jakarta-style argue pasionately about what should happen in the agora
side, and give all kind of arguments about why this shouldn't be allowed )
It's already difficult to go along with another project and share
something - even if you have a clear common goal in a component - add a
group of even more diverse people and put them in charge of deciding
what's good for the shared component.
So that's my concern - that we'll keep fighting about what's right and
wrong instead of letting the jakarta projects that are supposed to share
decide what's good or bad for themself.
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
What about:
"The sponsoring project will maintain, support the distributed component
along with their codebase"
If 2 projects share a component it may be better to have a single point of
distribution for the component.
( they may decide not to place it in commons, but keep it an
agora component )
Costin
Re: End - Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Ok, I had enough. Ted - if you change the proposal please be kind and
> remove my name from the list.
That's your prerogative, Costin.
Though I honestly believe we have tried to make room for what you
yourself have characterized as the "minority" opinion.
I also honestly believe that the following represents what you have been
saying would happen with Agora code.
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
I would trust you to do the Right Thing, but this CVS repository will be
open to * all * the Jakarta committers, and so we must be sure the
guideline is clear.
-Ted.
Re: End - Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Ok, I had enough. Ted - if you change the proposal please be kind and
> remove my name from the list.
That's your prerogative, Costin.
Though I honestly believe we have tried to make room for what you
yourself have characterized as the "minority" opinion.
I also honestly believe that the following represents what you have been
saying would happen with Agora code.
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
I would trust you to do the Right Thing, but this CVS repository will be
open to * all * the Jakarta committers, and so we must be sure the
guideline is clear.
-Ted.
Re: End - Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
I'm sorry I didn't include you in the earlier message to Ignacio,
everything I said there about Ignacio being necessary for this project
to succeed goes for you as well. Your input has kept this project on track
and helped us avoid some serious future problems, we need your viewpoint,
even if we might not always agree, and especially when we ( okay I'm
talking about myself here ) are too dense to get the point the first few
times around. And again, I say 'please reconsider'.
Now is as good a time as any to put the brakes on and clarify this
together, and if what Craig states in his email is a correct
interpretation of your concerns then this *does* have to be
resolved/clarified. If what Craig stated isn't the right
interpretation of your concerns than I think it is even more
important that we keep hashing this out.
David
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
>
> Ok, I had enough. Ted - if you change the proposal please be kind and
> remove my name from the list.
>
>
>
> Costin
>
>
>
Re: End - Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
I'm sorry I didn't include you in the earlier message to Ignacio,
everything I said there about Ignacio being necessary for this project
to succeed goes for you as well. Your input has kept this project on track
and helped us avoid some serious future problems, we need your viewpoint,
even if we might not always agree, and especially when we ( okay I'm
talking about myself here ) are too dense to get the point the first few
times around. And again, I say 'please reconsider'.
Now is as good a time as any to put the brakes on and clarify this
together, and if what Craig states in his email is a correct
interpretation of your concerns then this *does* have to be
resolved/clarified. If what Craig stated isn't the right
interpretation of your concerns than I think it is even more
important that we keep hashing this out.
David
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
>
> Ok, I had enough. Ted - if you change the proposal please be kind and
> remove my name from the list.
>
>
>
> Costin
>
>
>
End - Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ok, I had enough. Ted - if you change the proposal please be kind and
remove my name from the list.
Costin
End - Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ok, I had enough. Ted - if you change the proposal please be kind and
remove my name from the list.
Costin
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@cx1002407-c.escnd1.sdca.home.com>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> > ....
> > >
> > > That's why we need the extra " or sponsored by a jakarta subproject".
> >
> > I don't think so. I think that additional phrase will lead us back to
> > the current situation. As one of the problems that I hope Commons would
> > solve is making sure that 'released' components are documented,
> > installable and supported. If it's just a tagged set of classes in the
> > sandbox, we are back to the same problem we have already - released code
> > that a project depends upon that is not the projects main 'deliverable'
> > is undocumented, not independantly buildable, testable, and installable,
> > and largely hidden from public view because it's not separated and
> > promoted.
>
> Than what's the problem ??? You think the problem the commons would
> resolve is "released" components - you have that.
>
> Why don't you let other people to try a different thing ? I am interested
> in sharing the work on some common components - I don't care too much
> about releasing the components, it is not my main goal. I think this will
> happen as a side effect, because the code will be subject to a bigger
> community and in direct contact with the projects using it.
>
Why does this have to be one or the other? You don't care about releasing
the components, but others may. The work that will be done here can
benefit those who want to release components and those who desire to put
the common code back in their projects for release inside the
project. Again this comes down to the 'One and Only Acceptable Goal for
the Project' argument, which I think is counterproductive and not
neccessary.
> But the fundamental issue is this intolerance I find again and again and
> again in jakarta - why does everyone things that there is only one
> solution and one way to do something ?
>
> It is very likely that agora will fail - as far as I can tell intolerance
> is the rule here, and Agora's can't succeed in such environment. But we
> can try - maybe there are people who can repect other's ideas and not try
> to impose their will and solution.
>
Intolerance is a problem, but please understand that trying to limit the
project to your exact need/vision is yet another form of intolerance.
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
>
Again, we don't need a set of tribes within the project. The library is
intended to allow those people who want to put the extra effort into
making a component a 'product' to do so. This existing does not exclude
having a common CVS or whatever other goals you want. Please don't attach
or impose a perceived 'judgement' or 'attitude' where one doesn't exist.
> Your development model is wonderful - but it's not the only one.
>
That works both ways. If we insist that this can only work for strict
interpretation of a singular goal, that doesn't say much about building
community or assisting in cooperation.
> Costin
>
>
>
> >
> > > Removing this option will alter the original proposal in a significant way
> > > - those words were added to reach a compromise, and by transforming the
> > > agora into a play-ground the whole thing changes.
> >
> > Why? There isn't much real difference between 'play-ground' and 'place
> > to collaborate on unreleased components' as far as I can tell. It's a
> > subjective distinction, isn't it?
> >
> > > In which case I think we are back to the initial position - as the
> > > original vote on library-dev was based on the assumption that jakarta
> > > subprojects can release and cooperate on sandbox projects, and the sandbox
> > > was supposed to be an sharing place, not a playground.
> >
> > Right - but there should be something to release - just tagging a
> > collection of classes doesn't a release make, for the purposes of the
> > Commons project.
> >
> > geir
> >
> >
>
>
David
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@cx1002407-c.escnd1.sdca.home.com>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > cmanolache@yahoo.com wrote:
> > ....
> > >
> > > That's why we need the extra " or sponsored by a jakarta subproject".
> >
> > I don't think so. I think that additional phrase will lead us back to
> > the current situation. As one of the problems that I hope Commons would
> > solve is making sure that 'released' components are documented,
> > installable and supported. If it's just a tagged set of classes in the
> > sandbox, we are back to the same problem we have already - released code
> > that a project depends upon that is not the projects main 'deliverable'
> > is undocumented, not independantly buildable, testable, and installable,
> > and largely hidden from public view because it's not separated and
> > promoted.
>
> Than what's the problem ??? You think the problem the commons would
> resolve is "released" components - you have that.
>
> Why don't you let other people to try a different thing ? I am interested
> in sharing the work on some common components - I don't care too much
> about releasing the components, it is not my main goal. I think this will
> happen as a side effect, because the code will be subject to a bigger
> community and in direct contact with the projects using it.
>
Why does this have to be one or the other? You don't care about releasing
the components, but others may. The work that will be done here can
benefit those who want to release components and those who desire to put
the common code back in their projects for release inside the
project. Again this comes down to the 'One and Only Acceptable Goal for
the Project' argument, which I think is counterproductive and not
neccessary.
> But the fundamental issue is this intolerance I find again and again and
> again in jakarta - why does everyone things that there is only one
> solution and one way to do something ?
>
> It is very likely that agora will fail - as far as I can tell intolerance
> is the rule here, and Agora's can't succeed in such environment. But we
> can try - maybe there are people who can repect other's ideas and not try
> to impose their will and solution.
>
Intolerance is a problem, but please understand that trying to limit the
project to your exact need/vision is yet another form of intolerance.
> What's the problem ? Is the library the guardian of Apache quality, the
> only absolut experts in components ? Are jakarta projects some stupid
> entities who can't be trusted to release something to the public ?
>
Again, we don't need a set of tribes within the project. The library is
intended to allow those people who want to put the extra effort into
making a component a 'product' to do so. This existing does not exclude
having a common CVS or whatever other goals you want. Please don't attach
or impose a perceived 'judgement' or 'attitude' where one doesn't exist.
> Your development model is wonderful - but it's not the only one.
>
That works both ways. If we insist that this can only work for strict
interpretation of a singular goal, that doesn't say much about building
community or assisting in cooperation.
> Costin
>
>
>
> >
> > > Removing this option will alter the original proposal in a significant way
> > > - those words were added to reach a compromise, and by transforming the
> > > agora into a play-ground the whole thing changes.
> >
> > Why? There isn't much real difference between 'play-ground' and 'place
> > to collaborate on unreleased components' as far as I can tell. It's a
> > subjective distinction, isn't it?
> >
> > > In which case I think we are back to the initial position - as the
> > > original vote on library-dev was based on the assumption that jakarta
> > > subprojects can release and cooperate on sandbox projects, and the sandbox
> > > was supposed to be an sharing place, not a playground.
> >
> > Right - but there should be something to release - just tagging a
> > collection of classes doesn't a release make, for the purposes of the
> > Commons project.
> >
> > geir
> >
> >
>
>
David
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
> cmanolache@yahoo.com wrote:
> ....
> >
> > That's why we need the extra " or sponsored by a jakarta subproject".
>
> I don't think so. I think that additional phrase will lead us back to
> the current situation. As one of the problems that I hope Commons would
> solve is making sure that 'released' components are documented,
> installable and supported. If it's just a tagged set of classes in the
> sandbox, we are back to the same problem we have already - released code
> that a project depends upon that is not the projects main 'deliverable'
> is undocumented, not independantly buildable, testable, and installable,
> and largely hidden from public view because it's not separated and
> promoted.
Than what's the problem ??? You think the problem the commons would
resolve is "released" components - you have that.
Why don't you let other people to try a different thing ? I am interested
in sharing the work on some common components - I don't care too much
about releasing the components, it is not my main goal. I think this will
happen as a side effect, because the code will be subject to a bigger
community and in direct contact with the projects using it.
But the fundamental issue is this intolerance I find again and again and
again in jakarta - why does everyone things that there is only one
solution and one way to do something ?
It is very likely that agora will fail - as far as I can tell intolerance
is the rule here, and Agora's can't succeed in such environment. But we
can try - maybe there are people who can repect other's ideas and not try
to impose their will and solution.
What's the problem ? Is the library the guardian of Apache quality, the
only absolut experts in components ? Are jakarta projects some stupid
entities who can't be trusted to release something to the public ?
Your development model is wonderful - but it's not the only one.
Costin
>
> > Removing this option will alter the original proposal in a significant way
> > - those words were added to reach a compromise, and by transforming the
> > agora into a play-ground the whole thing changes.
>
> Why? There isn't much real difference between 'play-ground' and 'place
> to collaborate on unreleased components' as far as I can tell. It's a
> subjective distinction, isn't it?
>
> > In which case I think we are back to the initial position - as the
> > original vote on library-dev was based on the assumption that jakarta
> > subprojects can release and cooperate on sandbox projects, and the sandbox
> > was supposed to be an sharing place, not a playground.
>
> Right - but there should be something to release - just tagging a
> collection of classes doesn't a release make, for the purposes of the
> Commons project.
>
> geir
>
>
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
> cmanolache@yahoo.com wrote:
> ....
> >
> > That's why we need the extra " or sponsored by a jakarta subproject".
>
> I don't think so. I think that additional phrase will lead us back to
> the current situation. As one of the problems that I hope Commons would
> solve is making sure that 'released' components are documented,
> installable and supported. If it's just a tagged set of classes in the
> sandbox, we are back to the same problem we have already - released code
> that a project depends upon that is not the projects main 'deliverable'
> is undocumented, not independantly buildable, testable, and installable,
> and largely hidden from public view because it's not separated and
> promoted.
Than what's the problem ??? You think the problem the commons would
resolve is "released" components - you have that.
Why don't you let other people to try a different thing ? I am interested
in sharing the work on some common components - I don't care too much
about releasing the components, it is not my main goal. I think this will
happen as a side effect, because the code will be subject to a bigger
community and in direct contact with the projects using it.
But the fundamental issue is this intolerance I find again and again and
again in jakarta - why does everyone things that there is only one
solution and one way to do something ?
It is very likely that agora will fail - as far as I can tell intolerance
is the rule here, and Agora's can't succeed in such environment. But we
can try - maybe there are people who can repect other's ideas and not try
to impose their will and solution.
What's the problem ? Is the library the guardian of Apache quality, the
only absolut experts in components ? Are jakarta projects some stupid
entities who can't be trusted to release something to the public ?
Your development model is wonderful - but it's not the only one.
Costin
>
> > Removing this option will alter the original proposal in a significant way
> > - those words were added to reach a compromise, and by transforming the
> > agora into a play-ground the whole thing changes.
>
> Why? There isn't much real difference between 'play-ground' and 'place
> to collaborate on unreleased components' as far as I can tell. It's a
> subjective distinction, isn't it?
>
> > In which case I think we are back to the initial position - as the
> > original vote on library-dev was based on the assumption that jakarta
> > subprojects can release and cooperate on sandbox projects, and the sandbox
> > was supposed to be an sharing place, not a playground.
>
> Right - but there should be something to release - just tagging a
> collection of classes doesn't a release make, for the purposes of the
> Commons project.
>
> geir
>
>
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> > It would seem better to me that a subproject wanting to use sandbox code
> > in a release should do one of the following:
> >
> > * Propose the code to Commons, with the associated willingness to
> > support it.
> >
> > * Take the code to be released back into its own CVS repository
> > until such time as it is proposed to, and accepted by, Commons.
> >
> > This is also more consistent with the restriction in (1.5.1) that sandbox
> > code cannot be "released to the public" until accepted by Commons. To me,
> > including that code in a subproject release counts as "released to the
> > public".
>
> That's why we need the extra " or sponsored by a jakarta subproject".
I don't think so. I think that additional phrase will lead us back to
the current situation. As one of the problems that I hope Commons would
solve is making sure that 'released' components are documented,
installable and supported. If it's just a tagged set of classes in the
sandbox, we are back to the same problem we have already - released code
that a project depends upon that is not the projects main 'deliverable'
is undocumented, not independantly buildable, testable, and installable,
and largely hidden from public view because it's not separated and
promoted.
> Removing this option will alter the original proposal in a significant way
> - those words were added to reach a compromise, and by transforming the
> agora into a play-ground the whole thing changes.
Why? There isn't much real difference between 'play-ground' and 'place
to collaborate on unreleased components' as far as I can tell. It's a
subjective distinction, isn't it?
> In which case I think we are back to the initial position - as the
> original vote on library-dev was based on the assumption that jakarta
> subprojects can release and cooperate on sandbox projects, and the sandbox
> was supposed to be an sharing place, not a playground.
Right - but there should be something to release - just tagging a
collection of classes doesn't a release make, for the purposes of the
Commons project.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> > It would seem better to me that a subproject wanting to use sandbox code
> > in a release should do one of the following:
> >
> > * Propose the code to Commons, with the associated willingness to
> > support it.
> >
> > * Take the code to be released back into its own CVS repository
> > until such time as it is proposed to, and accepted by, Commons.
> >
> > This is also more consistent with the restriction in (1.5.1) that sandbox
> > code cannot be "released to the public" until accepted by Commons. To me,
> > including that code in a subproject release counts as "released to the
> > public".
>
> That's why we need the extra " or sponsored by a jakarta subproject".
I don't think so. I think that additional phrase will lead us back to
the current situation. As one of the problems that I hope Commons would
solve is making sure that 'released' components are documented,
installable and supported. If it's just a tagged set of classes in the
sandbox, we are back to the same problem we have already - released code
that a project depends upon that is not the projects main 'deliverable'
is undocumented, not independantly buildable, testable, and installable,
and largely hidden from public view because it's not separated and
promoted.
> Removing this option will alter the original proposal in a significant way
> - those words were added to reach a compromise, and by transforming the
> agora into a play-ground the whole thing changes.
Why? There isn't much real difference between 'play-ground' and 'place
to collaborate on unreleased components' as far as I can tell. It's a
subjective distinction, isn't it?
> In which case I think we are back to the initial position - as the
> original vote on library-dev was based on the assumption that jakarta
> subprojects can release and cooperate on sandbox projects, and the sandbox
> was supposed to be an sharing place, not a playground.
Right - but there should be something to release - just tagging a
collection of classes doesn't a release make, for the purposes of the
Commons project.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The mechanics are simple - make it as open as possible to the needs of
> > jakarta subprojects. Don't force any pre-set solution, but let them choose
> > how to use the commons. After all, we are talking about clearly defined
> > entities that have the right to choose on their own.
>
> I believe the only area of concern are the points of public release.
>
That's a valid point of concern, but that is not the problem that *I* have
with the current proposal.
> As long as we are agreed that the sandbox CVS is
>
> (1) Open to all Jakarta Committers, and
> (2) Closed to the public
>
I'm in agreement on these two points.
> then I think everything else falls into place for all of us.
>
Except for the ambiguity pointed out in my previous message -- is the
sandbox code just experimental, or is it released? Costin's proposal is
that it could be either (if a subproject elected to tag some sandbox code
and include it in their release).
I can also guarantee you, from personal experience, that this will trigger
more "Building XYZ is Hard!" complaints because of the extra dependencies
it creates when people want to build subprojects from CVS.
> -Ted.
>
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The mechanics are simple - make it as open as possible to the needs of
> > jakarta subprojects. Don't force any pre-set solution, but let them choose
> > how to use the commons. After all, we are talking about clearly defined
> > entities that have the right to choose on their own.
>
> I believe the only area of concern are the points of public release.
>
That's a valid point of concern, but that is not the problem that *I* have
with the current proposal.
> As long as we are agreed that the sandbox CVS is
>
> (1) Open to all Jakarta Committers, and
> (2) Closed to the public
>
I'm in agreement on these two points.
> then I think everything else falls into place for all of us.
>
Except for the ambiguity pointed out in my previous message -- is the
sandbox code just experimental, or is it released? Costin's proposal is
that it could be either (if a subproject elected to tag some sandbox code
and include it in their release).
I can also guarantee you, from personal experience, that this will trigger
more "Building XYZ is Hard!" complaints because of the extra dependencies
it creates when people want to build subprojects from CVS.
> -Ted.
>
Craig
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> [Responding to Ted:]
>
> It's obvious you prefer one development model, with components developed
> by a group of commiters who control it's fate.
>
> I prefer another - where control is shared by the different projects that
> are using the component.
What is the difference? Wouldn't that shared control be effectively a
group of people, committers, who control it's fate? So what if they
come from different projects - they still are the committers that work
on the component...
Is there really a difference?
> And the issue here is that people who prefer the first model are not
> willing to tolerate other solutions.
Sorry, I don't buy that assertion, mainly because the only 'other
solution' you offered is operationally the same as the first.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> [Responding to Ted:]
>
> It's obvious you prefer one development model, with components developed
> by a group of commiters who control it's fate.
>
> I prefer another - where control is shared by the different projects that
> are using the component.
What is the difference? Wouldn't that shared control be effectively a
group of people, committers, who control it's fate? So what if they
come from different projects - they still are the committers that work
on the component...
Is there really a difference?
> And the issue here is that people who prefer the first model are not
> willing to tolerate other solutions.
Sorry, I don't buy that assertion, mainly because the only 'other
solution' you offered is operationally the same as the first.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > Depends on how do you define "closed to the public".
> >
> > Something can't get out of the sandbox on "it's own" - you can't just
> > start something and then release it to public. I agree with that.
> >
> > But in the same way as a component can be released as result of a vote
> > of library commiters ( who assume the responsibilty to maintain it and
> > insure the quality ), it can be as well released by the result of a vote
> > of another project.
>
> Agreed.
>
> But after they vote to release it, is the public going to be able to
> download it separately?
>
> Or is it only going to be available as part of the build for the
> respective products using the codebase?
It's a choice to be made by the project - not a pre-determined answer.
The commons is not the only project that can release components ( after
all Avalon is doing exactly that ).
But this is the whole point - to let projects decide how to use and share
components.
>
> cmanolache@yahoo.com wrote:
> > The goal is to keep the code in a common place so more projects
> > can cooperate on it, and that's why we need a common repository where all
> > projects have equal access.
>
> Where this all break down for me is that subprojects are a workgroup
> tasked to create and maintain a particular product. Committers can and
> do work on multiple products. The focus needs to be on helping
> * committers * cooperate regardless of what product they happen to be
> working on
>
> The Commons model is designed so that volunteers can work together on a
> package that can be used by more than one product. The difference
> between this and Agora seems to be that subprojects are being promoted
> to entities with some kind of a vote. I don't believe that this is wise.
> The code belongs to the committers, who work together on products. We
> need
> to think in terms of committers who build products, and avoid
> reinforcing the idea that Jakarta is a collection of competing tribes.
One more and I'll give up...
It's obvious you prefer one development model, with components developed
by a group of commiters who control it's fate.
I prefer another - where control is shared by the different projects that
are using the component.
And the issue here is that people who prefer the first model are not
willing to tolerate other solutions.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > Depends on how do you define "closed to the public".
> >
> > Something can't get out of the sandbox on "it's own" - you can't just
> > start something and then release it to public. I agree with that.
> >
> > But in the same way as a component can be released as result of a vote
> > of library commiters ( who assume the responsibilty to maintain it and
> > insure the quality ), it can be as well released by the result of a vote
> > of another project.
>
> Agreed.
>
> But after they vote to release it, is the public going to be able to
> download it separately?
>
> Or is it only going to be available as part of the build for the
> respective products using the codebase?
It's a choice to be made by the project - not a pre-determined answer.
The commons is not the only project that can release components ( after
all Avalon is doing exactly that ).
But this is the whole point - to let projects decide how to use and share
components.
>
> cmanolache@yahoo.com wrote:
> > The goal is to keep the code in a common place so more projects
> > can cooperate on it, and that's why we need a common repository where all
> > projects have equal access.
>
> Where this all break down for me is that subprojects are a workgroup
> tasked to create and maintain a particular product. Committers can and
> do work on multiple products. The focus needs to be on helping
> * committers * cooperate regardless of what product they happen to be
> working on
>
> The Commons model is designed so that volunteers can work together on a
> package that can be used by more than one product. The difference
> between this and Agora seems to be that subprojects are being promoted
> to entities with some kind of a vote. I don't believe that this is wise.
> The code belongs to the committers, who work together on products. We
> need
> to think in terms of committers who build products, and avoid
> reinforcing the idea that Jakarta is a collection of competing tribes.
One more and I'll give up...
It's obvious you prefer one development model, with components developed
by a group of commiters who control it's fate.
I prefer another - where control is shared by the different projects that
are using the component.
And the issue here is that people who prefer the first model are not
willing to tolerate other solutions.
Costin
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Depends on how do you define "closed to the public".
>
> Something can't get out of the sandbox on "it's own" - you can't just
> start something and then release it to public. I agree with that.
>
> But in the same way as a component can be released as result of a vote
> of library commiters ( who assume the responsibilty to maintain it and
> insure the quality ), it can be as well released by the result of a vote
> of another project.
Agreed.
But after they vote to release it, is the public going to be able to
download it separately?
Or is it only going to be available as part of the build for the
respective products using the codebase?
cmanolache@yahoo.com wrote:
> The goal is to keep the code in a common place so more projects
> can cooperate on it, and that's why we need a common repository where all
> projects have equal access.
Where this all break down for me is that subprojects are a workgroup
tasked to create and maintain a particular product. Committers can and
do work on multiple products. The focus needs to be on helping
* committers * cooperate regardless of what product they happen to be
working on.
The Commons model is designed so that volunteers can work together on a
package that can be used by more than one product. The difference
between this and Agora seems to be that subprojects are being promoted
to entities with some kind of a vote. I don't believe that this is wise.
The code belongs to the committers, who work together on products. We
need
to think in terms of committers who build products, and avoid
reinforcing the idea that Jakarta is a collection of competing tribes.
-Ted.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Depends on how do you define "closed to the public".
>
> Something can't get out of the sandbox on "it's own" - you can't just
> start something and then release it to public. I agree with that.
>
> But in the same way as a component can be released as result of a vote
> of library commiters ( who assume the responsibilty to maintain it and
> insure the quality ), it can be as well released by the result of a vote
> of another project.
Agreed.
But after they vote to release it, is the public going to be able to
download it separately?
Or is it only going to be available as part of the build for the
respective products using the codebase?
cmanolache@yahoo.com wrote:
> The goal is to keep the code in a common place so more projects
> can cooperate on it, and that's why we need a common repository where all
> projects have equal access.
Where this all break down for me is that subprojects are a workgroup
tasked to create and maintain a particular product. Committers can and
do work on multiple products. The focus needs to be on helping
* committers * cooperate regardless of what product they happen to be
working on.
The Commons model is designed so that volunteers can work together on a
package that can be used by more than one product. The difference
between this and Agora seems to be that subprojects are being promoted
to entities with some kind of a vote. I don't believe that this is wise.
The code belongs to the committers, who work together on products. We
need
to think in terms of committers who build products, and avoid
reinforcing the idea that Jakarta is a collection of competing tribes.
-Ted.
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The mechanics are simple - make it as open as possible to the needs of
> > jakarta subprojects. Don't force any pre-set solution, but let them choose
> > how to use the commons. After all, we are talking about clearly defined
> > entities that have the right to choose on their own.
>
> I believe the only area of concern are the points of public release.
>
> As long as we are agreed that the sandbox CVS is
>
> (1) Open to all Jakarta Committers, and
> (2) Closed to the public
>
> then I think everything else falls into place for all of us.
Depends on how do you define "closed to the public".
Something can't get out of the sandbox on "it's own" - you can't just
start something and then release it to public. I agree with that.
But in the same way as a component can be released as result of a vote
of library commiters ( who assume the responsibilty to maintain it and
insure the quality ), it can be as well released by the result of a vote
of another project.
I think Craig is right in one aspect - the current proposal combines the
"playground" with "agora" into that "sandbox" - and this is the real
problem.
I'm not interested in the playground - if a commiter wants to play he can
use a proposal/ space in his project or use source forge. Having something
open to all commiters is not intended to allow them to play, but to allow
projects to cooperate freely on common code.
For Agora - where most of the code is supported by at least one jakarta
project, and the goal is to get multiple projects behind each package - I
think the code should be available to the public ( and will be as part of
the projects anyway - nobody can't stop that ). If the projects are
willing to support it as standalone componente ( maybe because it'll be
easier to upgrade or distribute localized fixes ) - than they should be
able to do so.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The mechanics are simple - make it as open as possible to the needs of
> > jakarta subprojects. Don't force any pre-set solution, but let them choose
> > how to use the commons. After all, we are talking about clearly defined
> > entities that have the right to choose on their own.
>
> I believe the only area of concern are the points of public release.
>
> As long as we are agreed that the sandbox CVS is
>
> (1) Open to all Jakarta Committers, and
> (2) Closed to the public
>
> then I think everything else falls into place for all of us.
Depends on how do you define "closed to the public".
Something can't get out of the sandbox on "it's own" - you can't just
start something and then release it to public. I agree with that.
But in the same way as a component can be released as result of a vote
of library commiters ( who assume the responsibilty to maintain it and
insure the quality ), it can be as well released by the result of a vote
of another project.
I think Craig is right in one aspect - the current proposal combines the
"playground" with "agora" into that "sandbox" - and this is the real
problem.
I'm not interested in the playground - if a commiter wants to play he can
use a proposal/ space in his project or use source forge. Having something
open to all commiters is not intended to allow them to play, but to allow
projects to cooperate freely on common code.
For Agora - where most of the code is supported by at least one jakarta
project, and the goal is to get multiple projects behind each package - I
think the code should be available to the public ( and will be as part of
the projects anyway - nobody can't stop that ). If the projects are
willing to support it as standalone componente ( maybe because it'll be
easier to upgrade or distribute localized fixes ) - than they should be
able to do so.
Costin
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> The mechanics are simple - make it as open as possible to the needs of
> jakarta subprojects. Don't force any pre-set solution, but let them choose
> how to use the commons. After all, we are talking about clearly defined
> entities that have the right to choose on their own.
I believe the only area of concern are the points of public release.
As long as we are agreed that the sandbox CVS is
(1) Open to all Jakarta Committers, and
(2) Closed to the public
then I think everything else falls into place for all of us.
-Ted.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> The mechanics are simple - make it as open as possible to the needs of
> jakarta subprojects. Don't force any pre-set solution, but let them choose
> how to use the commons. After all, we are talking about clearly defined
> entities that have the right to choose on their own.
I believe the only area of concern are the points of public release.
As long as we are agreed that the sandbox CVS is
(1) Open to all Jakarta Committers, and
(2) Closed to the public
then I think everything else falls into place for all of us.
-Ted.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
+1
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> "Craig R. McClanahan" wrote:
>
> > I don't like the ambiguity of what code in sandbox
> means
> > under this scenario. Alternatives to solve the
> problem include:
> >
> > (a) If a project wants to release something that
> includes code in the
> > sandbox, it must either get it accepted into
> commons, or copy the
> > code back into its own repository.
>
> +1
+1 for me as well. I think there needs to be a
gatekeeper (the Commons committers) who decide if a
sandbox component is truly in keeping with the Commons
charter. We should take the responsibility to insure
that released code is stable, good quality, and not
intrinsically tied to another subproject (in which
case it should probably live elsewhere). If a sandbox
component meets those criteria, we'll vote to release
the component in Commons and grant karma to its
commmitters. If a subproject cannot meet the
guidelines of the Commons charter, it should not be accepted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> > I thought we reached a compromise after many weeks of emails and
> > I was happy that we were able to agree on something that would work for
> > all of us, and sudenly this morning we're back in a fury of emails and
> > with a proposal to change the wording - just a little bit.
>
> Yes, it was amazing. I was trying to stay out, but I see that the
> biggest problem I was trying to solve *was* the notion of release -
> having a place where people who *want* to release 'small things' can
> live.
Well, I am trying to stay out as well. Each main I send is the "last one".
> release and support, is an important one. And that 'sponsored by a
> Jakarta project' phrase could be interpreted to really change the
> meaning of commons - while it would get people from different projects
> collaborating, they would still have these 'hidden' gems that no one
> could easily find and use, other than the Jakarta projects involved.
Geir - if a group of people want to release a component in commons - they
are not affected in any way by the fact that a jakarata project can also
release components.
I understand your concern - but at least it will be one big step forward
compared with the today situation - the "hidden" gems will be in a common
place, clearly separated from the project and reusable ( and maybe
shared).
Not allowing projects to release standalone componets and requiring them
to get aproval from commons does change a lot in how agora will be
perceived.
> But the notion of 'release' in such an environment is sort of tenuous,
> right? If you moved out to a separate entity once ready, then it's even
> easier for more people to share and use, not just the dparticipating
> projects. They would still 'own' it.... it's just easier for others to
> find and use.
I agree. In time I hope most components will follow this path - but I
don't want this to be mandatory.
And the main reason is that forcing this through a commons vote will:
1. Promote the idea that the code in agora is "second class",
experimental, etc
2. Create tensions and conflicts. Commons are a very diverse group, with
many strong opinions and it seems inclined to arguments. Some components
may conflict with or duplicate existing components, etc.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> > I thought we reached a compromise after many weeks of emails and
> > I was happy that we were able to agree on something that would work for
> > all of us, and sudenly this morning we're back in a fury of emails and
> > with a proposal to change the wording - just a little bit.
>
> Yes, it was amazing. I was trying to stay out, but I see that the
> biggest problem I was trying to solve *was* the notion of release -
> having a place where people who *want* to release 'small things' can
> live.
Well, I am trying to stay out as well. Each main I send is the "last one".
> release and support, is an important one. And that 'sponsored by a
> Jakarta project' phrase could be interpreted to really change the
> meaning of commons - while it would get people from different projects
> collaborating, they would still have these 'hidden' gems that no one
> could easily find and use, other than the Jakarta projects involved.
Geir - if a group of people want to release a component in commons - they
are not affected in any way by the fact that a jakarata project can also
release components.
I understand your concern - but at least it will be one big step forward
compared with the today situation - the "hidden" gems will be in a common
place, clearly separated from the project and reusable ( and maybe
shared).
Not allowing projects to release standalone componets and requiring them
to get aproval from commons does change a lot in how agora will be
perceived.
> But the notion of 'release' in such an environment is sort of tenuous,
> right? If you moved out to a separate entity once ready, then it's even
> easier for more people to share and use, not just the dparticipating
> projects. They would still 'own' it.... it's just easier for others to
> find and use.
I agree. In time I hope most components will follow this path - but I
don't want this to be mandatory.
And the main reason is that forcing this through a commons vote will:
1. Promote the idea that the code in agora is "second class",
experimental, etc
2. Create tensions and conflicts. Commons are a very diverse group, with
many strong opinions and it seems inclined to arguments. Some components
may conflict with or duplicate existing components, etc.
Costin
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
>
> > > > +1
> > >
> > > In other words - your development model is ok, nothing else should be
> > > accepted.
>
> Geir, apologies again - the reply was not intended to you but to the whole
> thread...
I was hoping so, but it did appear direct.
> I thought we reached a compromise after many weeks of emails and
> I was happy that we were able to agree on something that would work for
> all of us, and sudenly this morning we're back in a fury of emails and
> with a proposal to change the wording - just a little bit.
Yes, it was amazing. I was trying to stay out, but I see that the
biggest problem I was trying to solve *was* the notion of release -
having a place where people who *want* to release 'small things' can
live.
The sharing / collaboration is very good to have, and I think that it
could work just fine in parallel with 'released things'.
> I realize it is a small issue ( that can be resolved later or worked
> around ), but most of the emails are making the sandbox equivalent with a
> playground for untested code.
Well, in some ways, that's a practical interpretation. But I think I do
understand the purpose clearly - I just see that formalizing the bit
about release, when a group of 'collaborators' decides they want to
release and support, is an important one. And that 'sponsored by a
Jakarta project' phrase could be interpreted to really change the
meaning of commons - while it would get people from different projects
collaborating, they would still have these 'hidden' gems that no one
could easily find and use, other than the Jakarta projects involved.
> >From a place where projects can share code that is released, tested and
> supported by one or more jakarta projects it suddenly became a place where
> the components are not ready for release.
But the notion of 'release' in such an environment is sort of tenuous,
right? If you moved out to a separate entity once ready, then it's even
easier for more people to share and use, not just the dparticipating
projects. They would still 'own' it.... it's just easier for others to
find and use.
Or at least that is my interpretation and belief.
> I'm sorry if I over reacted, but today's mail was very painful for me, and
> very unexpected.
No worries. I have to say I enjoyed riffing on what +1 could mean...
:)
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by Remy Maucherat <rm...@home.com>.
> On Fri, 16 Mar 2001, Ted Husted wrote:
>
> > > A component that is built by a project as part of the sandbox/agora
isn't
> > > supposed to be released to the public - because of quality concerns.
Yet a
> > > component that is accepted by commons commiters can be released, even
if
> > > it has a smaller set of commiters and less review.
> >
> > Code or documentation cannot be released to the public directly from the
> > shared CVS for *legal* concerns regarding use of the Apache brand. All
> > anyone has asked is that one of subprojects using this code release it
> > with their own codebase. And that is all the clarified #20 says.
>
> Can you explain a bit more - what are the legal concerns ? Most of
> us are programmers, and I just can't get it - how the same piece of code
> is "legal" if it is distributed as part of a jakarta project, but it is
> ilegal if it is distributed standalone.
>
> Does that mean that if tomcat is using a threadpool component it can't
> release an upgrade of only the thread pool ? But it become legal if the
> same package is distributed out of commons ?
>
> And how is Apache brand protected by releasing code under a project where
> most voter don't know what they vote on ( since they were not involved in
> the development ), but it's not protected if the code is
> released by a vote of the people who support and test it ?
>
> Did we had any complaint from Sam or Roy regarding this process ? Is this
> based on a lawyer advice - or just guessing ?
I totally agree with Costin here. I can't figure out how there can be a
problem since :
- the code was already distributed and available as part of another Jakarta
project
- it's just a matter of moving the code to somewhere else and repackaging it
differently, and anyone outside the ASF can do that (take the threadpool
from TC 3, repackage it standalone, and distribute it)
Remy
Re: Agora and the Shared CVS
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
> The last 47 messages have been about adding exactly this sentence to
> guideline #20:
>
> "The sponsoring subproject will distribute the code or documentation
> along with the rest of their codebase."
here's #48 -
Yes, I agree - but, since they can do this anyway, since the code is
APL'ed, I don't quite see why we have to state it.
I am not against stating it - it just appears obvious.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
> The last 47 messages have been about adding exactly this sentence to
> guideline #20:
>
> "The sponsoring subproject will distribute the code or documentation
> along with the rest of their codebase."
here's #48 -
Yes, I agree - but, since they can do this anyway, since the code is
APL'ed, I don't quite see why we have to state it.
I am not against stating it - it just appears obvious.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
Remy Maucherat wrote:
> Since the code already exists as part of another ASF project, and since it
> has already been approved according to the ASF rules, I don't see why it
> should be considered "experimental" here, and subject to additional review /
> approval. If the component is bad, nobody will use it, and that's it.
> Sharing code should be as painless as possible, or nobody (including me)
> will share code.
It's not subject to additional review, Remy. We're just want to state
clearly that some subproject somewhere has to release it to the public.
> For components which were outside the Jakarta project, they should indeed be
> subject to approval (but I thought the original mission of commons was to
> share code between the Jakarta projects).
We're talking about the shared CVS here, which is only available to
Jakarta committers (every Jakarta committer).
The last 47 messages have been about adding exactly this sentence to
guideline #20:
"The sponsoring subproject will distribute the code or documentation
along with the rest of their codebase."
-Ted.
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
Remy Maucherat wrote:
> Since the code already exists as part of another ASF project, and since it
> has already been approved according to the ASF rules, I don't see why it
> should be considered "experimental" here, and subject to additional review /
> approval. If the component is bad, nobody will use it, and that's it.
> Sharing code should be as painless as possible, or nobody (including me)
> will share code.
It's not subject to additional review, Remy. We're just want to state
clearly that some subproject somewhere has to release it to the public.
> For components which were outside the Jakarta project, they should indeed be
> subject to approval (but I thought the original mission of commons was to
> share code between the Jakarta projects).
We're talking about the shared CVS here, which is only available to
Jakarta committers (every Jakarta committer).
The last 47 messages have been about adding exactly this sentence to
guideline #20:
"The sponsoring subproject will distribute the code or documentation
along with the rest of their codebase."
-Ted.
Re: Agora and the Shared CVS
Posted by Remy Maucherat <rm...@home.com>.
> cmanolache@yahoo.com wrote:
> > Did we had any complaint from Sam or Roy regarding this process ? Is
this
> > based on a lawyer advice - or just guessing ?
>
> For now, I am suggesting that we propose to do what we know is safe. I
> mentioned before that if Roy said it was OK, then I would have no qualm.
>
> Roy made it very clear that the PMC's first responsibility was the
> legality of what the programmers are doing.
>
> Right now, the only release process we have is that a subproject votes
> on a specific code base and takes responsibility for distributing and
> supporting the product. Having a shared CVS doesn't change that.
>
> If you would like to propose an alternate release process, I would
> suggest you put something in a proposal that people can vote on, and the
> ASF board can approve.
>
> This is not about Agora. We must cope with any and all committers who
> might use the shared CVS to develop code, and then want to distribute it
> under the Apache brand.
>
> > It's scary that a proposal can be "edited" or "clarified" in such a
> > significant way after it was finalized and without a vote.
>
> This whole thread started as a vote Costin. So far there are five
> positive votes (Craig, Geir, Morgan, David and me), and two negative
> (you and Ignacio).
>
> We haven't made the change yet, since Remy, Rodney, and Conor have not
> voted.
-1.
Since the code already exists as part of another ASF project, and since it
has already been approved according to the ASF rules, I don't see why it
should be considered "experimental" here, and subject to additional review /
approval. If the component is bad, nobody will use it, and that's it.
Sharing code should be as painless as possible, or nobody (including me)
will share code.
For components which were outside the Jakarta project, they should indeed be
subject to approval (but I thought the original mission of commons was to
share code between the Jakarta projects).
Remy
Re: Agora and the Shared CVS
Posted by Remy Maucherat <rm...@home.com>.
> cmanolache@yahoo.com wrote:
> > Did we had any complaint from Sam or Roy regarding this process ? Is
this
> > based on a lawyer advice - or just guessing ?
>
> For now, I am suggesting that we propose to do what we know is safe. I
> mentioned before that if Roy said it was OK, then I would have no qualm.
>
> Roy made it very clear that the PMC's first responsibility was the
> legality of what the programmers are doing.
>
> Right now, the only release process we have is that a subproject votes
> on a specific code base and takes responsibility for distributing and
> supporting the product. Having a shared CVS doesn't change that.
>
> If you would like to propose an alternate release process, I would
> suggest you put something in a proposal that people can vote on, and the
> ASF board can approve.
>
> This is not about Agora. We must cope with any and all committers who
> might use the shared CVS to develop code, and then want to distribute it
> under the Apache brand.
>
> > It's scary that a proposal can be "edited" or "clarified" in such a
> > significant way after it was finalized and without a vote.
>
> This whole thread started as a vote Costin. So far there are five
> positive votes (Craig, Geir, Morgan, David and me), and two negative
> (you and Ignacio).
>
> We haven't made the change yet, since Remy, Rodney, and Conor have not
> voted.
-1.
Since the code already exists as part of another ASF project, and since it
has already been approved according to the ASF rules, I don't see why it
should be considered "experimental" here, and subject to additional review /
approval. If the component is bad, nobody will use it, and that's it.
Sharing code should be as painless as possible, or nobody (including me)
will share code.
For components which were outside the Jakarta project, they should indeed be
subject to approval (but I thought the original mission of commons was to
share code between the Jakarta projects).
Remy
Re: Agora and the Shared CVS
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> cmanolache@yahoo.com wrote:
> > Yes, that's exactly what I said - a jakarta subproject should be able to
> > vote and take responsibility for distributing a product - it can be
> > developed in it's own workspace or in a shared CVS.
>
> I just don't understand what the problem is, Costin. Doesn't the
> proposed #20 say that?
>
> If it makes any difference, we could probably strike "the accepted to
> the commons part", and just say
>
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be sponsored by a
> Jakarta subproject. The sponsoring subproject will distribute the code
> or documentation along with the rest of their codebase."
That seems to solve it all - If Commons is that subproject, then
Commons would have to approve accepting it as part of its
'distributables'. Further, it places no restrictions on the activities
within that CVS repository...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> cmanolache@yahoo.com wrote:
> > Yes, that's exactly what I said - a jakarta subproject should be able to
> > vote and take responsibility for distributing a product - it can be
> > developed in it's own workspace or in a shared CVS.
>
> I just don't understand what the problem is, Costin. Doesn't the
> proposed #20 say that?
>
> If it makes any difference, we could probably strike "the accepted to
> the commons part", and just say
>
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be sponsored by a
> Jakarta subproject. The sponsoring subproject will distribute the code
> or documentation along with the rest of their codebase."
That seems to solve it all - If Commons is that subproject, then
Commons would have to approve accepting it as part of its
'distributables'. Further, it places no restrictions on the activities
within that CVS repository...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Yes, that's exactly what I said - a jakarta subproject should be able to
> vote and take responsibility for distributing a product - it can be
> developed in it's own workspace or in a shared CVS.
I just don't understand what the problem is, Costin. Doesn't the
proposed #20 say that?
If it makes any difference, we could probably strike "the accepted to
the commons part", and just say
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be sponsored by a
Jakarta subproject. The sponsoring subproject will distribute the code
or documentation along with the rest of their codebase."
-Ted.
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Yes, that's exactly what I said - a jakarta subproject should be able to
> vote and take responsibility for distributing a product - it can be
> developed in it's own workspace or in a shared CVS.
I just don't understand what the problem is, Costin. Doesn't the
proposed #20 say that?
If it makes any difference, we could probably strike "the accepted to
the commons part", and just say
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be sponsored by a
Jakarta subproject. The sponsoring subproject will distribute the code
or documentation along with the rest of their codebase."
-Ted.
Re: Agora and the Shared CVS
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > Did we had any complaint from Sam or Roy regarding this process ? Is this
> > based on a lawyer advice - or just guessing ?
>
> For now, I am suggesting that we propose to do what we know is safe. I
> mentioned before that if Roy said it was OK, then I would have no qualm.
>
> Roy made it very clear that the PMC's first responsibility was the
> legality of what the programmers are doing.
We are talking about commons - which is not the PMC. And the discussion is
about whether a jakarta project can release a standalone component or not
- with you assuming that only the commons project can do that. Insuring
the legality and the "brand" is shared by all jakarta projects - the
commons are not different in this aspect from any other project ( except
that they'll make decisions about code bases they are not involved with )
> Right now, the only release process we have is that a subproject votes
> on a specific code base and takes responsibility for distributing and
> supporting the product. Having a shared CVS doesn't change that.
Yes, that's exactly what I said - a jakarta subproject should be able to
vote and take responsibility for distributing a product - it can be
developed in it's own workspace or in a shared CVS.
> This is not about Agora. We must cope with any and all committers who
> might use the shared CVS to develop code, and then want to distribute it
> under the Apache brand.
Well - it is about agora, since the change you want to make doesn't affect
or have anything to do with the code developed in the shared workspace by
random developers.
It is about code supported by top-level jakarta projects,
and you restrict their ability to distribute common code, forcing all
components to be under the control of "commons".
Yes, all commiters can develop in the shared workspace - but your change
doesn't have anything to do with that - it's about how jakarta projects
can ( or cannot ) release components.
> > It's scary that a proposal can be "edited" or "clarified" in such a
> > significant way after it was finalized and without a vote.
>
> This whole thread started as a vote Costin. So far there are five
> positive votes (Craig, Geir, Morgan, David and me), and two negative
> (you and Ignacio).
Well, what I said was that I don't want my name associated with a proposal
that makes the code developed and shared by jakarta projects "second
class" and controled by an entity that has nothing to do with it's
development or support.
I didn't realized it was a vote ( it looked to me more like a discussion,
not a formal proposal ), but if this is the case please remove my name
from the proposal. And I must say this is very unfair - we had an
agreement and compromise and then you change it to a no-op ( since
projects are allowed anyway to release apache code - the whole phrase is
just stating what is already aproved and well-known).
> We haven't made the change yet, since Remy, Rodney, and Conor have not
> voted.
Costin
Re: Agora and the Shared CVS
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > Did we had any complaint from Sam or Roy regarding this process ? Is this
> > based on a lawyer advice - or just guessing ?
>
> For now, I am suggesting that we propose to do what we know is safe. I
> mentioned before that if Roy said it was OK, then I would have no qualm.
>
> Roy made it very clear that the PMC's first responsibility was the
> legality of what the programmers are doing.
We are talking about commons - which is not the PMC. And the discussion is
about whether a jakarta project can release a standalone component or not
- with you assuming that only the commons project can do that. Insuring
the legality and the "brand" is shared by all jakarta projects - the
commons are not different in this aspect from any other project ( except
that they'll make decisions about code bases they are not involved with )
> Right now, the only release process we have is that a subproject votes
> on a specific code base and takes responsibility for distributing and
> supporting the product. Having a shared CVS doesn't change that.
Yes, that's exactly what I said - a jakarta subproject should be able to
vote and take responsibility for distributing a product - it can be
developed in it's own workspace or in a shared CVS.
> This is not about Agora. We must cope with any and all committers who
> might use the shared CVS to develop code, and then want to distribute it
> under the Apache brand.
Well - it is about agora, since the change you want to make doesn't affect
or have anything to do with the code developed in the shared workspace by
random developers.
It is about code supported by top-level jakarta projects,
and you restrict their ability to distribute common code, forcing all
components to be under the control of "commons".
Yes, all commiters can develop in the shared workspace - but your change
doesn't have anything to do with that - it's about how jakarta projects
can ( or cannot ) release components.
> > It's scary that a proposal can be "edited" or "clarified" in such a
> > significant way after it was finalized and without a vote.
>
> This whole thread started as a vote Costin. So far there are five
> positive votes (Craig, Geir, Morgan, David and me), and two negative
> (you and Ignacio).
Well, what I said was that I don't want my name associated with a proposal
that makes the code developed and shared by jakarta projects "second
class" and controled by an entity that has nothing to do with it's
development or support.
I didn't realized it was a vote ( it looked to me more like a discussion,
not a formal proposal ), but if this is the case please remove my name
from the proposal. And I must say this is very unfair - we had an
agreement and compromise and then you change it to a no-op ( since
projects are allowed anyway to release apache code - the whole phrase is
just stating what is already aproved and well-known).
> We haven't made the change yet, since Remy, Rodney, and Conor have not
> voted.
Costin
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Did we had any complaint from Sam or Roy regarding this process ? Is this
> based on a lawyer advice - or just guessing ?
For now, I am suggesting that we propose to do what we know is safe. I
mentioned before that if Roy said it was OK, then I would have no qualm.
Roy made it very clear that the PMC's first responsibility was the
legality of what the programmers are doing.
Right now, the only release process we have is that a subproject votes
on a specific code base and takes responsibility for distributing and
supporting the product. Having a shared CVS doesn't change that.
If you would like to propose an alternate release process, I would
suggest you put something in a proposal that people can vote on, and the
ASF board can approve.
This is not about Agora. We must cope with any and all committers who
might use the shared CVS to develop code, and then want to distribute it
under the Apache brand.
> It's scary that a proposal can be "edited" or "clarified" in such a
> significant way after it was finalized and without a vote.
This whole thread started as a vote Costin. So far there are five
positive votes (Craig, Geir, Morgan, David and me), and two negative
(you and Ignacio).
We haven't made the change yet, since Remy, Rodney, and Conor have not
voted.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> Did we had any complaint from Sam or Roy regarding this process ? Is this
> based on a lawyer advice - or just guessing ?
For now, I am suggesting that we propose to do what we know is safe. I
mentioned before that if Roy said it was OK, then I would have no qualm.
Roy made it very clear that the PMC's first responsibility was the
legality of what the programmers are doing.
Right now, the only release process we have is that a subproject votes
on a specific code base and takes responsibility for distributing and
supporting the product. Having a shared CVS doesn't change that.
If you would like to propose an alternate release process, I would
suggest you put something in a proposal that people can vote on, and the
ASF board can approve.
This is not about Agora. We must cope with any and all committers who
might use the shared CVS to develop code, and then want to distribute it
under the Apache brand.
> It's scary that a proposal can be "edited" or "clarified" in such a
> significant way after it was finalized and without a vote.
This whole thread started as a vote Costin. So far there are five
positive votes (Craig, Geir, Morgan, David and me), and two negative
(you and Ignacio).
We haven't made the change yet, since Remy, Rodney, and Conor have not
voted.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
Re: Agora and the Shared CVS
Posted by Remy Maucherat <rm...@home.com>.
> On Fri, 16 Mar 2001, Ted Husted wrote:
>
> > > A component that is built by a project as part of the sandbox/agora
isn't
> > > supposed to be released to the public - because of quality concerns.
Yet a
> > > component that is accepted by commons commiters can be released, even
if
> > > it has a smaller set of commiters and less review.
> >
> > Code or documentation cannot be released to the public directly from the
> > shared CVS for *legal* concerns regarding use of the Apache brand. All
> > anyone has asked is that one of subprojects using this code release it
> > with their own codebase. And that is all the clarified #20 says.
>
> Can you explain a bit more - what are the legal concerns ? Most of
> us are programmers, and I just can't get it - how the same piece of code
> is "legal" if it is distributed as part of a jakarta project, but it is
> ilegal if it is distributed standalone.
>
> Does that mean that if tomcat is using a threadpool component it can't
> release an upgrade of only the thread pool ? But it become legal if the
> same package is distributed out of commons ?
>
> And how is Apache brand protected by releasing code under a project where
> most voter don't know what they vote on ( since they were not involved in
> the development ), but it's not protected if the code is
> released by a vote of the people who support and test it ?
>
> Did we had any complaint from Sam or Roy regarding this process ? Is this
> based on a lawyer advice - or just guessing ?
I totally agree with Costin here. I can't figure out how there can be a
problem since :
- the code was already distributed and available as part of another Jakarta
project
- it's just a matter of moving the code to somewhere else and repackaging it
differently, and anyone outside the ASF can do that (take the threadpool
from TC 3, repackage it standalone, and distribute it)
Remy
Re: Agora and the Shared CVS
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> > A component that is built by a project as part of the sandbox/agora isn't
> > supposed to be released to the public - because of quality concerns. Yet a
> > component that is accepted by commons commiters can be released, even if
> > it has a smaller set of commiters and less review.
>
> Code or documentation cannot be released to the public directly from the
> shared CVS for *legal* concerns regarding use of the Apache brand. All
> anyone has asked is that one of subprojects using this code release it
> with their own codebase. And that is all the clarified #20 says.
Can you explain a bit more - what are the legal concerns ? Most of
us are programmers, and I just can't get it - how the same piece of code
is "legal" if it is distributed as part of a jakarta project, but it is
ilegal if it is distributed standalone.
Does that mean that if tomcat is using a threadpool component it can't
release an upgrade of only the thread pool ? But it become legal if the
same package is distributed out of commons ?
And how is Apache brand protected by releasing code under a project where
most voter don't know what they vote on ( since they were not involved in
the development ), but it's not protected if the code is
released by a vote of the people who support and test it ?
Did we had any complaint from Sam or Roy regarding this process ? Is this
based on a lawyer advice - or just guessing ?
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
>
> Again, this not just about Agora. We need to write this to apply to
> everyone who might also want to use the shared CVS to promote a new
> development model. Or work on any type of cross-product material,
> whether for submission to the Commons or not.
Again - I don't understand. "Agora" is when a jakarta project is
developing the code in the common repository and is taking responsibility
for it ( with other jakarta projects maybe ).
Other development models ( like experimental code, etc ) is not sponsored
by a project - if there is a project that supports and maintain the code
we are in Agora case. So how adding a restriction on Agora ( the case
where the code is developed by a project in common ) will affect the
case of "experimental" or "everyone" case.
> The shared CVS in the Commons is not meant to be Agora. We have tried to
> add language so it could be used like Agora, along with other things. At
> the time, the operative phrase was "close enough".
And now you basically change the language that was "close enough", with a
change that affects only Agora anyway.
( the clarification doesn't affect anything else - only the code that is
developed and supported by jakarta projects - for experimental code you
didn't added any change ).
> > and I have a problem with arguing that
> > a project that wants to release a stand-alone component out of
> > sandbox needs to get the aproval of commons.
>
> If the code were accepted into the Commons it would be moved to the
> Commons CVS. The guideline is the same for everyone.
And if a project would want to continue to develop the code in the common
workspace it'll not be able to distribute it standalone, and imply that
any component should be under the control of commons.
I'm sorry, but I don't think this was part of the proposal or is a correct
interpretation of the proposal I voted on ( since it had the explicit
mention that project can sponsor a component ). It may be valid in the
modified proposal - where "they can develop the component but must release
it as part of the project release " - but that's not what was agreed on.
It's scary that a proposal can be "edited" or "clarified" in such a
significant way after it was finalized and without a vote.
Costin
Re: Agora and the Shared CVS
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Ted Husted wrote:
> > A component that is built by a project as part of the sandbox/agora isn't
> > supposed to be released to the public - because of quality concerns. Yet a
> > component that is accepted by commons commiters can be released, even if
> > it has a smaller set of commiters and less review.
>
> Code or documentation cannot be released to the public directly from the
> shared CVS for *legal* concerns regarding use of the Apache brand. All
> anyone has asked is that one of subprojects using this code release it
> with their own codebase. And that is all the clarified #20 says.
Can you explain a bit more - what are the legal concerns ? Most of
us are programmers, and I just can't get it - how the same piece of code
is "legal" if it is distributed as part of a jakarta project, but it is
ilegal if it is distributed standalone.
Does that mean that if tomcat is using a threadpool component it can't
release an upgrade of only the thread pool ? But it become legal if the
same package is distributed out of commons ?
And how is Apache brand protected by releasing code under a project where
most voter don't know what they vote on ( since they were not involved in
the development ), but it's not protected if the code is
released by a vote of the people who support and test it ?
Did we had any complaint from Sam or Roy regarding this process ? Is this
based on a lawyer advice - or just guessing ?
> "20. A CVS repository will be available to all Jakarta committers as a
> workplace for new packages or other projects. Before release to the
> public, code or documentation developed here must be accepted into the
> Commons or sponsored by another Jakarta subproject. The sponsoring
> subproject(s) will distribute the code or documentation along with the
> rest of their codebase."
>
> Again, this not just about Agora. We need to write this to apply to
> everyone who might also want to use the shared CVS to promote a new
> development model. Or work on any type of cross-product material,
> whether for submission to the Commons or not.
Again - I don't understand. "Agora" is when a jakarta project is
developing the code in the common repository and is taking responsibility
for it ( with other jakarta projects maybe ).
Other development models ( like experimental code, etc ) is not sponsored
by a project - if there is a project that supports and maintain the code
we are in Agora case. So how adding a restriction on Agora ( the case
where the code is developed by a project in common ) will affect the
case of "experimental" or "everyone" case.
> The shared CVS in the Commons is not meant to be Agora. We have tried to
> add language so it could be used like Agora, along with other things. At
> the time, the operative phrase was "close enough".
And now you basically change the language that was "close enough", with a
change that affects only Agora anyway.
( the clarification doesn't affect anything else - only the code that is
developed and supported by jakarta projects - for experimental code you
didn't added any change ).
> > and I have a problem with arguing that
> > a project that wants to release a stand-alone component out of
> > sandbox needs to get the aproval of commons.
>
> If the code were accepted into the Commons it would be moved to the
> Commons CVS. The guideline is the same for everyone.
And if a project would want to continue to develop the code in the common
workspace it'll not be able to distribute it standalone, and imply that
any component should be under the control of commons.
I'm sorry, but I don't think this was part of the proposal or is a correct
interpretation of the proposal I voted on ( since it had the explicit
mention that project can sponsor a component ). It may be valid in the
modified proposal - where "they can develop the component but must release
it as part of the project release " - but that's not what was agreed on.
It's scary that a proposal can be "edited" or "clarified" in such a
significant way after it was finalized and without a vote.
Costin
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> I realize it is a small issue ( that can be resolved later or worked
> around ), but most of the emails are making the sandbox equivalent with a
> playground for untested code.
Some people may use it that way. Others may not. It is a place designed
for tolerance and varied viewpoints. A DMZ for revolutions.
> A component that is built by a project as part of the sandbox/agora isn't
> supposed to be released to the public - because of quality concerns. Yet a
> component that is accepted by commons commiters can be released, even if
> it has a smaller set of commiters and less review.
Code or documentation cannot be released to the public directly from the
shared CVS for *legal* concerns regarding use of the Apache brand. All
anyone has asked is that one of subprojects using this code release it
with their own codebase. And that is all the clarified #20 says.
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
Again, this not just about Agora. We need to write this to apply to
everyone who might also want to use the shared CVS to promote a new
development model. Or work on any type of cross-product material,
whether for submission to the Commons or not.
Once there is Agora code on the table, it's possible that you could
setup an Agora section on the Jakarta Web site, where this code could be
distributed. There could even be an Agora CVS so you would not have to
rub shoulders with "experimental" branches.
The point is that we are trying to make a place where ideas like Agora
can be proved, and once proved, fully deployed.
You're not getting everything you wanted for Agora. Neither Geir nor I
got everything we wanted for the Commons library. (At least not yet;-)
But that's all part of working within a group.
The shared CVS in the Commons is not meant to be Agora. We have tried to
add language so it could be used like Agora, along with other things. At
the time, the operative phrase was "close enough".
<
http://www.mail-archive.com/library-dev@jakarta.apache.org/msg00178.html
>
> and I have a problem with arguing that
> a project that wants to release a stand-alone component out of
> sandbox needs to get the aproval of commons.
If the code were accepted into the Commons it would be moved to the
Commons CVS. The guideline is the same for everyone.
-Ted.
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
>
> > > > +1
> > >
> > > In other words - your development model is ok, nothing else should be
> > > accepted.
>
> Geir, apologies again - the reply was not intended to you but to the whole
> thread...
I was hoping so, but it did appear direct.
> I thought we reached a compromise after many weeks of emails and
> I was happy that we were able to agree on something that would work for
> all of us, and sudenly this morning we're back in a fury of emails and
> with a proposal to change the wording - just a little bit.
Yes, it was amazing. I was trying to stay out, but I see that the
biggest problem I was trying to solve *was* the notion of release -
having a place where people who *want* to release 'small things' can
live.
The sharing / collaboration is very good to have, and I think that it
could work just fine in parallel with 'released things'.
> I realize it is a small issue ( that can be resolved later or worked
> around ), but most of the emails are making the sandbox equivalent with a
> playground for untested code.
Well, in some ways, that's a practical interpretation. But I think I do
understand the purpose clearly - I just see that formalizing the bit
about release, when a group of 'collaborators' decides they want to
release and support, is an important one. And that 'sponsored by a
Jakarta project' phrase could be interpreted to really change the
meaning of commons - while it would get people from different projects
collaborating, they would still have these 'hidden' gems that no one
could easily find and use, other than the Jakarta projects involved.
> >From a place where projects can share code that is released, tested and
> supported by one or more jakarta projects it suddenly became a place where
> the components are not ready for release.
But the notion of 'release' in such an environment is sort of tenuous,
right? If you moved out to a separate entity once ready, then it's even
easier for more people to share and use, not just the dparticipating
projects. They would still 'own' it.... it's just easier for others to
find and use.
Or at least that is my interpretation and belief.
> I'm sorry if I over reacted, but today's mail was very painful for me, and
> very unexpected.
No worries. I have to say I enjoyed riffing on what +1 could mean...
:)
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Agora and the Shared CVS
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> I realize it is a small issue ( that can be resolved later or worked
> around ), but most of the emails are making the sandbox equivalent with a
> playground for untested code.
Some people may use it that way. Others may not. It is a place designed
for tolerance and varied viewpoints. A DMZ for revolutions.
> A component that is built by a project as part of the sandbox/agora isn't
> supposed to be released to the public - because of quality concerns. Yet a
> component that is accepted by commons commiters can be released, even if
> it has a smaller set of commiters and less review.
Code or documentation cannot be released to the public directly from the
shared CVS for *legal* concerns regarding use of the Apache brand. All
anyone has asked is that one of subprojects using this code release it
with their own codebase. And that is all the clarified #20 says.
"20. A CVS repository will be available to all Jakarta committers as a
workplace for new packages or other projects. Before release to the
public, code or documentation developed here must be accepted into the
Commons or sponsored by another Jakarta subproject. The sponsoring
subproject(s) will distribute the code or documentation along with the
rest of their codebase."
Again, this not just about Agora. We need to write this to apply to
everyone who might also want to use the shared CVS to promote a new
development model. Or work on any type of cross-product material,
whether for submission to the Commons or not.
Once there is Agora code on the table, it's possible that you could
setup an Agora section on the Jakarta Web site, where this code could be
distributed. There could even be an Agora CVS so you would not have to
rub shoulders with "experimental" branches.
The point is that we are trying to make a place where ideas like Agora
can be proved, and once proved, fully deployed.
You're not getting everything you wanted for Agora. Neither Geir nor I
got everything we wanted for the Commons library. (At least not yet;-)
But that's all part of working within a group.
The shared CVS in the Commons is not meant to be Agora. We have tried to
add language so it could be used like Agora, along with other things. At
the time, the operative phrase was "close enough".
<
http://www.mail-archive.com/library-dev@jakarta.apache.org/msg00178.html
>
> and I have a problem with arguing that
> a project that wants to release a stand-alone component out of
> sandbox needs to get the aproval of commons.
If the code were accepted into the Commons it would be moved to the
Commons CVS. The guideline is the same for everyone.
-Ted.
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> > > +1
> >
> > In other words - your development model is ok, nothing else should be
> > accepted.
Geir, apologies again - the reply was not intended to you but to the whole
thread...
I thought we reached a compromise after many weeks of emails and
I was happy that we were able to agree on something that would work for
all of us, and sudenly this morning we're back in a fury of emails and
with a proposal to change the wording - just a little bit.
I realize it is a small issue ( that can be resolved later or worked
around ), but most of the emails are making the sandbox equivalent with a
playground for untested code.
>From a place where projects can share code that is released, tested and
supported by one or more jakarta projects it suddenly became a place where
the components are not ready for release.
I'm sorry if I over reacted, but today's mail was very painful for me, and
very unexpected.
Costin
>
> Yes. That's *exactly* what I was attempting to convey as I was trying
> to catch up on this long email chain that we have to get right and get
> right soon.
>
> I got back from a long day away from email, was reading through and said
> to myself
>
> "Hmm. I want to say that only my development model is ok, and nothing
> else should be accepted, especially something from Costin. But what is
> the most efficient way to say that?"
>
> So I looked into the main Jarkarta site, and there it was :
>
> "Section 2.1 : Although normally used for voting, the +1 / -1 convention
> can both be used as shorthand to express feelings of support for an idea
> or to say 'My development model is ok, nothing else should be accepted'.
> "
>
> Of course, it doesn't say anything about the '...especially something
> from Costin' part, but hey - there's a PMC meeting tomorrow - I'll bring
> it up then...
>
> Sorry - it's almost 1 a.m., it's been a long week....
>
> ----
>
> Costin, come on... First, what I am thinking about here is the release
> model, not the development model. I am *for* having more than one
> approach for participation contained in Commons, if you recall.
>
> All I was saying is that I, as a singular individual with no more voting
> power than you, agree with the notion that for something qualified to be
> a Jakarta release, it should be moved out of the sandbox/agora/playpen
> and into a mini-project of it's own so it can be documented, supported,
> etc...
>
> I noticed there as another msg, so I will finish there...
>
> geir
>
>
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Fri, 16 Mar 2001, Geir Magnusson Jr. wrote:
> > > +1
> >
> > In other words - your development model is ok, nothing else should be
> > accepted.
Geir, apologies again - the reply was not intended to you but to the whole
thread...
I thought we reached a compromise after many weeks of emails and
I was happy that we were able to agree on something that would work for
all of us, and sudenly this morning we're back in a fury of emails and
with a proposal to change the wording - just a little bit.
I realize it is a small issue ( that can be resolved later or worked
around ), but most of the emails are making the sandbox equivalent with a
playground for untested code.
From a place where projects can share code that is released, tested and
supported by one or more jakarta projects it suddenly became a place where
the components are not ready for release.
I'm sorry if I over reacted, but today's mail was very painful for me, and
very unexpected.
Costin
>
> Yes. That's *exactly* what I was attempting to convey as I was trying
> to catch up on this long email chain that we have to get right and get
> right soon.
>
> I got back from a long day away from email, was reading through and said
> to myself
>
> "Hmm. I want to say that only my development model is ok, and nothing
> else should be accepted, especially something from Costin. But what is
> the most efficient way to say that?"
>
> So I looked into the main Jarkarta site, and there it was :
>
> "Section 2.1 : Although normally used for voting, the +1 / -1 convention
> can both be used as shorthand to express feelings of support for an idea
> or to say 'My development model is ok, nothing else should be accepted'.
> "
>
> Of course, it doesn't say anything about the '...especially something
> from Costin' part, but hey - there's a PMC meeting tomorrow - I'll bring
> it up then...
>
> Sorry - it's almost 1 a.m., it's been a long week....
>
> ----
>
> Costin, come on... First, what I am thinking about here is the release
> model, not the development model. I am *for* having more than one
> approach for participation contained in Commons, if you recall.
>
> All I was saying is that I, as a singular individual with no more voting
> power than you, agree with the notion that for something qualified to be
> a Jakarta release, it should be moved out of the sandbox/agora/playpen
> and into a mini-project of it's own so it can be documented, supported,
> etc...
>
> I noticed there as another msg, so I will finish there...
>
> geir
>
>
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > I don't like the ambiguity of what code in sandbox means
> > > under this scenario. Alternatives to solve the problem include:
> > >
> > > (a) If a project wants to release something that includes code in the
> > > sandbox, it must either get it accepted into commons, or copy the
> > > code back into its own repository.
> >
> > +1
>
> In other words - your development model is ok, nothing else should be
> accepted.
Yes. That's *exactly* what I was attempting to convey as I was trying
to catch up on this long email chain that we have to get right and get
right soon.
I got back from a long day away from email, was reading through and said
to myself
"Hmm. I want to say that only my development model is ok, and nothing
else should be accepted, especially something from Costin. But what is
the most efficient way to say that?"
So I looked into the main Jarkarta site, and there it was :
"Section 2.1 : Although normally used for voting, the +1 / -1 convention
can both be used as shorthand to express feelings of support for an idea
or to say 'My development model is ok, nothing else should be accepted'.
"
Of course, it doesn't say anything about the '...especially something
from Costin' part, but hey - there's a PMC meeting tomorrow - I'll bring
it up then...
Sorry - it's almost 1 a.m., it's been a long week....
----
Costin, come on... First, what I am thinking about here is the release
model, not the development model. I am *for* having more than one
approach for participation contained in Commons, if you recall.
All I was saying is that I, as a singular individual with no more voting
power than you, agree with the notion that for something qualified to be
a Jakarta release, it should be moved out of the sandbox/agora/playpen
and into a mini-project of it's own so it can be documented, supported,
etc...
I noticed there as another msg, so I will finish there...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > I don't like the ambiguity of what code in sandbox means
> > > under this scenario. Alternatives to solve the problem include:
> > >
> > > (a) If a project wants to release something that includes code in the
> > > sandbox, it must either get it accepted into commons, or copy the
> > > code back into its own repository.
> >
> > +1
>
> In other words - your development model is ok, nothing else should be
> accepted.
Yes. That's *exactly* what I was attempting to convey as I was trying
to catch up on this long email chain that we have to get right and get
right soon.
I got back from a long day away from email, was reading through and said
to myself
"Hmm. I want to say that only my development model is ok, and nothing
else should be accepted, especially something from Costin. But what is
the most efficient way to say that?"
So I looked into the main Jarkarta site, and there it was :
"Section 2.1 : Although normally used for voting, the +1 / -1 convention
can both be used as shorthand to express feelings of support for an idea
or to say 'My development model is ok, nothing else should be accepted'.
"
Of course, it doesn't say anything about the '...especially something
from Costin' part, but hey - there's a PMC meeting tomorrow - I'll bring
it up then...
Sorry - it's almost 1 a.m., it's been a long week....
----
Costin, come on... First, what I am thinking about here is the release
model, not the development model. I am *for* having more than one
approach for participation contained in Commons, if you recall.
All I was saying is that I, as a singular individual with no more voting
power than you, agree with the notion that for something qualified to be
a Jakarta release, it should be moved out of the sandbox/agora/playpen
and into a mini-project of it's own so it can be documented, supported,
etc...
I noticed there as another msg, so I will finish there...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > I don't like the ambiguity of what code in sandbox means
> > > under this scenario. Alternatives to solve the problem include:
> > >
> > > (a) If a project wants to release something that includes code in the
> > > sandbox, it must either get it accepted into commons, or copy the
> > > code back into its own repository.
> >
> > +1
>
> In other words - your development model is ok, nothing else should be
> accepted.
>
Seems to me that you are advocating exactly the same "intolerance" :-).
Seriously Costin, just because *you* don't want a playground where people
can experiment together doesn't mean that *other* people don't. Why
should we have to go to SourceForge just to have folks from multiple
projects get together and see if we can create a common Foo. If it works,
great -- it gets turned into a Commons project and used. If it doesn't
work, oh well, the practice of working together was still worthwhile (and
saved duplicated efforts as well).
I want a playground, in addition to whatever else that the library
subproject offers me. If you don't want to use it, that's fine -- that's
your right. But you're going to get -1'd if you try to take that away
from people who want it.
You want a place where code that is actually being shared and released as
part of Jakarta subprojects is collaborated on and maintained. I do too
-- my contention (and the part of this we agree on) is that this should
*not* be done in the same place as the playground. That theme seems to be
commonly accepted. So where do we go next?
Your option (3), taking away the playground, is not going to fly. Thus,
we're back to two choices:
(1) Require that any code used in part of a release by either
in Commons or in the project's CVS repository (i.e. no release
of code from a playground).
(2) Add a third repository for code that is being maintained and
released in one or more subprojects, but is not in Commons.
As I stated before, I prefer (1), but could be persuaded to (2) if there
were rational reasons for it. I haven't heard any yet. And I haven't
heard a third alternative that has a chance of getting approved.
>
>
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
>
> > "Craig R. McClanahan" wrote:
> >
> > > I don't like the ambiguity of what code in sandbox means
> > > under this scenario. Alternatives to solve the problem include:
> > >
> > > (a) If a project wants to release something that includes code in the
> > > sandbox, it must either get it accepted into commons, or copy the
> > > code back into its own repository.
> >
> > +1
>
> In other words - your development model is ok, nothing else should be
> accepted.
>
Seems to me that you are advocating exactly the same "intolerance" :-).
Seriously Costin, just because *you* don't want a playground where people
can experiment together doesn't mean that *other* people don't. Why
should we have to go to SourceForge just to have folks from multiple
projects get together and see if we can create a common Foo. If it works,
great -- it gets turned into a Commons project and used. If it doesn't
work, oh well, the practice of working together was still worthwhile (and
saved duplicated efforts as well).
I want a playground, in addition to whatever else that the library
subproject offers me. If you don't want to use it, that's fine -- that's
your right. But you're going to get -1'd if you try to take that away
from people who want it.
You want a place where code that is actually being shared and released as
part of Jakarta subprojects is collaborated on and maintained. I do too
-- my contention (and the part of this we agree on) is that this should
*not* be done in the same place as the playground. That theme seems to be
commonly accepted. So where do we go next?
Your option (3), taking away the playground, is not going to fly. Thus,
we're back to two choices:
(1) Require that any code used in part of a release by either
in Commons or in the project's CVS repository (i.e. no release
of code from a playground).
(2) Add a third repository for code that is being maintained and
released in one or more subprojects, but is not in Commons.
As I stated before, I prefer (1), but could be persuaded to (2) if there
were rational reasons for it. I haven't heard any yet. And I haven't
heard a third alternative that has a chance of getting approved.
>
>
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
> "Craig R. McClanahan" wrote:
>
> > I don't like the ambiguity of what code in sandbox means
> > under this scenario. Alternatives to solve the problem include:
> >
> > (a) If a project wants to release something that includes code in the
> > sandbox, it must either get it accepted into commons, or copy the
> > code back into its own repository.
>
> +1
In other words - your development model is ok, nothing else should be
accepted.
Costin
Re: [VOTE] "prop02"
Posted by Morgan Delagrange <md...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> "Craig R. McClanahan" wrote:
>
> > I don't like the ambiguity of what code in sandbox
> means
> > under this scenario. Alternatives to solve the
> problem include:
> >
> > (a) If a project wants to release something that
> includes code in the
> > sandbox, it must either get it accepted into
> commons, or copy the
> > code back into its own repository.
>
> +1
+1 for me as well. I think there needs to be a
gatekeeper (the Commons committers) who decide if a
sandbox component is truly in keeping with the Commons
charter. We should take the responsibility to insure
that released code is stable, good quality, and not
intrinsically tied to another subproject (in which
case it should probably live elsewhere). If a sandbox
component meets those criteria, we'll vote to release
the component in Commons and grant karma to its
commmitters. If a subproject cannot meet the
guidelines of the Commons charter, it should not be accepted.
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Geir Magnusson Jr. wrote:
> "Craig R. McClanahan" wrote:
>
> > I don't like the ambiguity of what code in sandbox means
> > under this scenario. Alternatives to solve the problem include:
> >
> > (a) If a project wants to release something that includes code in the
> > sandbox, it must either get it accepted into commons, or copy the
> > code back into its own repository.
>
> +1
In other words - your development model is ok, nothing else should be
accepted.
Costin
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Craig R. McClanahan" wrote:
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
+1
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
+1
Re: [VOTE] "prop02"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Craig R. McClanahan" wrote:
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
+1
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
(Trimming down to the nuts and bolts to try to help us come to consensus):
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> > Why can't they do that in the Commons? Those packages are going to be
> > maintained, and enhanced, and released, as well. What's the difference?
>
> Control. Who decides the future and changes of the component. Who supports
> it.
>
> Some may prefer to use components supported by a dedicated group (
> commons, avalon, a project ). Some may prefer to use components in Agora,
> where they have control over the evolution of the component.
>
OK, now I see where Costin is coming from (sorry for being dense :-).
Costin, is it fair to say that your concern is the following scenario?
a) Through Agora-style collaboration, people from 2+ projects
create a useful Foo in the sandbox.
b) Things look good, so they propose it to be added to Commons
c) Commons (as a whole) accepts the code.
d) Original developers continue to work on it, and use the result
in a release of their subprojects.
e) Commons (as a whole) decides to take this code in a different
direction than the original developers wanted it :-(
f) Original developers feel backstabbed.
OK, that's a valid thing to worry about. However, I don't see it
happening in reality, for the following reasons:
* The commons developers as a whole only vote to accept a particular
package in the first place -- they don't determine technical direction
* The original package is still maintained by the original collaborators
(or others who add themselves into the mix on that package). It is
released only when the active developers say so, not on any global
schedule determined by Commons (as a whole).
* Even if someone did want to take the shared Foo in a different
direction, they can fork and create Foo-prime (possibly based on Foo,
possibly not depending on circumstances).
Experience with taglibs to date (which follows a model somewhat like
Commons) says that people really don't step on each other when you know
it's a shared use environment.
Does this alleviate your concern? If not, can we make the language about
how Commons works stronger to make sure that this scenario cannot happen?
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
(Trimming down to the nuts and bolts to try to help us come to consensus):
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> > Why can't they do that in the Commons? Those packages are going to be
> > maintained, and enhanced, and released, as well. What's the difference?
>
> Control. Who decides the future and changes of the component. Who supports
> it.
>
> Some may prefer to use components supported by a dedicated group (
> commons, avalon, a project ). Some may prefer to use components in Agora,
> where they have control over the evolution of the component.
>
OK, now I see where Costin is coming from (sorry for being dense :-).
Costin, is it fair to say that your concern is the following scenario?
a) Through Agora-style collaboration, people from 2+ projects
create a useful Foo in the sandbox.
b) Things look good, so they propose it to be added to Commons
c) Commons (as a whole) accepts the code.
d) Original developers continue to work on it, and use the result
in a release of their subprojects.
e) Commons (as a whole) decides to take this code in a different
direction than the original developers wanted it :-(
f) Original developers feel backstabbed.
OK, that's a valid thing to worry about. However, I don't see it
happening in reality, for the following reasons:
* The commons developers as a whole only vote to accept a particular
package in the first place -- they don't determine technical direction
* The original package is still maintained by the original collaborators
(or others who add themselves into the mix on that package). It is
released only when the active developers say so, not on any global
schedule determined by Commons (as a whole).
* Even if someone did want to take the shared Foo in a different
direction, they can fork and create Foo-prime (possibly based on Foo,
possibly not depending on circumstances).
Experience with taglibs to date (which follows a model somewhat like
Commons) says that people really don't step on each other when you know
it's a shared use environment.
Does this alleviate your concern? If not, can we make the language about
how Commons works stronger to make sure that this scenario cannot happen?
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Craig R. McClanahan wrote:
> > The experimental code is experimental - when it starts to be used in a
> > stable release of a project it's no longer experimental.
> >
>
> Agreed ... hence the need for a clear distinction in how non-experimental
> code is organized and handled.
Agora was not intended for experimental code. This is something that was
added - and I'm ok with removing it ( i.e. keep the sandbox for the code
that is shared and used in real products ).
This would make things much cleaner - the code in agora that is included
in a released project does have the testing and support of (at least) one
project.
Agora is intended to allow projects to make the decisions that are best
for themself - so we shouldn't force any particular solution.
> > > (2) Code that has been released as part of a subproject (but does
> > > not have a released state of its own).
> >
> > That's what I'm interested in and what Agora is supposed to do.
> > Put this code in a place where other projects can share and use without
> > any barier.
> >
>
> Costin, how is your view of this use case different from (3) below? Why
> would it not just be proposed to the Commons, and set up with its own
> formal release structure?
>
> Even if only one subproject makes use of it initially, making the code
> available for reuse seems to be the whole point of why we are here.
Yes - and there are 2 ways to do that. One is to try to create a package
and maintain in ( the commons), and one is to co-develop the component
with other projects.
It's about control to the component - I think the main problem and the
reason for the current duplication is exactly that.
In a way, that was the problem with Avalon - and I don't see anything
different in the commons. There is a community ( avalon, commons,
individual projects, etc) that maintains some components. Of course, we
all claim we are open and listen to the users and don't do incompatible
changes - but as you know sometimes ( or most of the times ) this is not
true - more features are added to the component, etc.
Repeating Avalon will not change anything. The Agora is supposed to be
different in the fact that the components are "owned" by the projects that
are using it. It's a whole different thing.
Example: a thread pool. It may be used in tc3.3, tc4.0, other projects.
If it's part of the commons, it's commiters may decide to optimize it or
add some features. This will result in tensions, and probably each project
will decide it's better to implement a thread pool they control.
If it's in agora, the commiters for the thread pool are the projects that
are using it - a change will have to be aproved by all affected people (
even if they are not the thread pool developers ).
> Why can't they do that in the Commons? Those packages are going to be
> maintained, and enhanced, and released, as well. What's the difference?
Control. Who decides the future and changes of the component. Who supports
it.
Some may prefer to use components supported by a dedicated group (
commons, avalon, a project ). Some may prefer to use components in Agora,
where they have control over the evolution of the component.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Thu, 15 Mar 2001, Craig R. McClanahan wrote:
> > The experimental code is experimental - when it starts to be used in a
> > stable release of a project it's no longer experimental.
> >
>
> Agreed ... hence the need for a clear distinction in how non-experimental
> code is organized and handled.
Agora was not intended for experimental code. This is something that was
added - and I'm ok with removing it ( i.e. keep the sandbox for the code
that is shared and used in real products ).
This would make things much cleaner - the code in agora that is included
in a released project does have the testing and support of (at least) one
project.
Agora is intended to allow projects to make the decisions that are best
for themself - so we shouldn't force any particular solution.
> > > (2) Code that has been released as part of a subproject (but does
> > > not have a released state of its own).
> >
> > That's what I'm interested in and what Agora is supposed to do.
> > Put this code in a place where other projects can share and use without
> > any barier.
> >
>
> Costin, how is your view of this use case different from (3) below? Why
> would it not just be proposed to the Commons, and set up with its own
> formal release structure?
>
> Even if only one subproject makes use of it initially, making the code
> available for reuse seems to be the whole point of why we are here.
Yes - and there are 2 ways to do that. One is to try to create a package
and maintain in ( the commons), and one is to co-develop the component
with other projects.
It's about control to the component - I think the main problem and the
reason for the current duplication is exactly that.
In a way, that was the problem with Avalon - and I don't see anything
different in the commons. There is a community ( avalon, commons,
individual projects, etc) that maintains some components. Of course, we
all claim we are open and listen to the users and don't do incompatible
changes - but as you know sometimes ( or most of the times ) this is not
true - more features are added to the component, etc.
Repeating Avalon will not change anything. The Agora is supposed to be
different in the fact that the components are "owned" by the projects that
are using it. It's a whole different thing.
Example: a thread pool. It may be used in tc3.3, tc4.0, other projects.
If it's part of the commons, it's commiters may decide to optimize it or
add some features. This will result in tensions, and probably each project
will decide it's better to implement a thread pool they control.
If it's in agora, the commiters for the thread pool are the projects that
are using it - a change will have to be aproved by all affected people (
even if they are not the thread pool developers ).
> Why can't they do that in the Commons? Those packages are going to be
> maintained, and enhanced, and released, as well. What's the difference?
Control. Who decides the future and changes of the component. Who supports
it.
Some may prefer to use components supported by a dedicated group (
commons, avalon, a project ). Some may prefer to use components in Agora,
where they have control over the evolution of the component.
Costin
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> >
> > I'm all for setting things up so that people can do what they need. My
> > discomfort is the current proposal combines three use cases:
>
> I agree with that - I'm also uncomfortable with the current wording ( and
> the fact that "agora" + "playground" = "sandbox").
>
>
>
> > (1) New experimental code that is not available to the public (and
> > is not subject to releases or versioning).
>
> This is not my concern, and it was not part of my proposal for agora - we
> can have this as "jakarta-playground" if we want, or each commiter can use
> a proposals/ in his project.
>
> But we can use jakarat-agora/proposals or something for this kind of
> code - it'll be in the same situation with experimental code that is
> checked into any jakarta project.
>
> The experimental code is experimental - when it starts to be used in a
> stable release of a project it's no longer experimental.
>
Agreed ... hence the need for a clear distinction in how non-experimental
code is organized and handled.
> > (2) Code that has been released as part of a subproject (but does
> > not have a released state of its own).
>
> That's what I'm interested in and what Agora is supposed to do.
> Put this code in a place where other projects can share and use without
> any barier.
>
Costin, how is your view of this use case different from (3) below? Why
would it not just be proposed to the Commons, and set up with its own
formal release structure?
Even if only one subproject makes use of it initially, making the code
available for reuse seems to be the whole point of why we are here.
> The idea that "all jakarta commiters are commiters in agora" was intended
> exactly for that - we share components, we agree other projects and
> commiters with different goals and opinions will have the same right with
> us, even if we are the original authors. It was not intended as "we are
> all commiters, we can play and do what we want".
>
>
> > (3) Code that has been accepted into the Commons (and therefore has
> > its own release schedule and versioning).
>
> That's again well defined, and it's a clear part of the library.
>
> >
> > into only two places where the code might live:
> >
> > (A) sandbox - for cases 1 and 2.
> >
> > (B) commons - for case 3.
>
> > I don't like the ambiguity of what code in sandbox means
> > under this scenario. Alternatives to solve the problem include:
> >
> > (a) If a project wants to release something that includes code in the
> > sandbox, it must either get it accepted into commons, or copy the
> > code back into its own repository.
> >
> > (b) Add a third reposiory (I guess it would be agora according to the
> > current vocabulary) for use case 2.
>
> I would prefer (b) - or
>
> (c) Rename "sandbox" to "agora", make clear that experimental code is
> allowed using the same rules that are used for any other jakarta
> project. We can have a jakarat-agora/sandbox directory for this kind of
> experiments if someone really wants that.
>
Changing only the name doesn't resolve my issue with two use cases in one
repository.
> The goal is to keep the code in a common place so more projects
> can cooperate on it, and that's why we need a common repository where all
> projects have equal access.
>
> We want to promote comunication between projects - not to copy code back
> and forth.
>
> Of course, some code will mature and become part of "commons" ( with it's
> own maintainers), but some code will continue to be developed and
> maintained by the projects that are using it.
>
Why can't they do that in the Commons? Those packages are going to be
maintained, and enhanced, and released, as well. What's the difference?
>
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> >
> > I'm all for setting things up so that people can do what they need. My
> > discomfort is the current proposal combines three use cases:
>
> I agree with that - I'm also uncomfortable with the current wording ( and
> the fact that "agora" + "playground" = "sandbox").
>
>
>
> > (1) New experimental code that is not available to the public (and
> > is not subject to releases or versioning).
>
> This is not my concern, and it was not part of my proposal for agora - we
> can have this as "jakarta-playground" if we want, or each commiter can use
> a proposals/ in his project.
>
> But we can use jakarat-agora/proposals or something for this kind of
> code - it'll be in the same situation with experimental code that is
> checked into any jakarta project.
>
> The experimental code is experimental - when it starts to be used in a
> stable release of a project it's no longer experimental.
>
Agreed ... hence the need for a clear distinction in how non-experimental
code is organized and handled.
> > (2) Code that has been released as part of a subproject (but does
> > not have a released state of its own).
>
> That's what I'm interested in and what Agora is supposed to do.
> Put this code in a place where other projects can share and use without
> any barier.
>
Costin, how is your view of this use case different from (3) below? Why
would it not just be proposed to the Commons, and set up with its own
formal release structure?
Even if only one subproject makes use of it initially, making the code
available for reuse seems to be the whole point of why we are here.
> The idea that "all jakarta commiters are commiters in agora" was intended
> exactly for that - we share components, we agree other projects and
> commiters with different goals and opinions will have the same right with
> us, even if we are the original authors. It was not intended as "we are
> all commiters, we can play and do what we want".
>
>
> > (3) Code that has been accepted into the Commons (and therefore has
> > its own release schedule and versioning).
>
> That's again well defined, and it's a clear part of the library.
>
> >
> > into only two places where the code might live:
> >
> > (A) sandbox - for cases 1 and 2.
> >
> > (B) commons - for case 3.
>
> > I don't like the ambiguity of what code in sandbox means
> > under this scenario. Alternatives to solve the problem include:
> >
> > (a) If a project wants to release something that includes code in the
> > sandbox, it must either get it accepted into commons, or copy the
> > code back into its own repository.
> >
> > (b) Add a third reposiory (I guess it would be agora according to the
> > current vocabulary) for use case 2.
>
> I would prefer (b) - or
>
> (c) Rename "sandbox" to "agora", make clear that experimental code is
> allowed using the same rules that are used for any other jakarta
> project. We can have a jakarat-agora/sandbox directory for this kind of
> experiments if someone really wants that.
>
Changing only the name doesn't resolve my issue with two use cases in one
repository.
> The goal is to keep the code in a common place so more projects
> can cooperate on it, and that's why we need a common repository where all
> projects have equal access.
>
> We want to promote comunication between projects - not to copy code back
> and forth.
>
> Of course, some code will mature and become part of "commons" ( with it's
> own maintainers), but some code will continue to be developed and
> maintained by the projects that are using it.
>
Why can't they do that in the Commons? Those packages are going to be
maintained, and enhanced, and released, as well. What's the difference?
>
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> I'm all for setting things up so that people can do what they need. My
> discomfort is the current proposal combines three use cases:
I agree with that - I'm also uncomfortable with the current wording ( and
the fact that "agora" + "playground" = "sandbox").
> (1) New experimental code that is not available to the public (and
> is not subject to releases or versioning).
This is not my concern, and it was not part of my proposal for agora - we
can have this as "jakarta-playground" if we want, or each commiter can use
a proposals/ in his project.
But we can use jakarat-agora/proposals or something for this kind of
code - it'll be in the same situation with experimental code that is
checked into any jakarta project.
The experimental code is experimental - when it starts to be used in a
stable release of a project it's no longer experimental.
> (2) Code that has been released as part of a subproject (but does
> not have a released state of its own).
That's what I'm interested in and what Agora is supposed to do.
Put this code in a place where other projects can share and use without
any barier.
The idea that "all jakarta commiters are commiters in agora" was intended
exactly for that - we share components, we agree other projects and
commiters with different goals and opinions will have the same right with
us, even if we are the original authors. It was not intended as "we are
all commiters, we can play and do what we want".
> (3) Code that has been accepted into the Commons (and therefore has
> its own release schedule and versioning).
That's again well defined, and it's a clear part of the library.
>
> into only two places where the code might live:
>
> (A) sandbox - for cases 1 and 2.
>
> (B) commons - for case 3.
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
>
> (b) Add a third reposiory (I guess it would be agora according to the
> current vocabulary) for use case 2.
I would prefer (b) - or
(c) Rename "sandbox" to "agora", make clear that experimental code is
allowed using the same rules that are used for any other jakarta
project. We can have a jakarat-agora/sandbox directory for this kind of
experiments if someone really wants that.
The goal is to keep the code in a common place so more projects
can cooperate on it, and that's why we need a common repository where all
projects have equal access.
We want to promote comunication between projects - not to copy code back
and forth.
Of course, some code will mature and become part of "commons" ( with it's
own maintainers), but some code will continue to be developed and
maintained by the projects that are using it.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> I'm all for setting things up so that people can do what they need. My
> discomfort is the current proposal combines three use cases:
I agree with that - I'm also uncomfortable with the current wording ( and
the fact that "agora" + "playground" = "sandbox").
> (1) New experimental code that is not available to the public (and
> is not subject to releases or versioning).
This is not my concern, and it was not part of my proposal for agora - we
can have this as "jakarta-playground" if we want, or each commiter can use
a proposals/ in his project.
But we can use jakarat-agora/proposals or something for this kind of
code - it'll be in the same situation with experimental code that is
checked into any jakarta project.
The experimental code is experimental - when it starts to be used in a
stable release of a project it's no longer experimental.
> (2) Code that has been released as part of a subproject (but does
> not have a released state of its own).
That's what I'm interested in and what Agora is supposed to do.
Put this code in a place where other projects can share and use without
any barier.
The idea that "all jakarta commiters are commiters in agora" was intended
exactly for that - we share components, we agree other projects and
commiters with different goals and opinions will have the same right with
us, even if we are the original authors. It was not intended as "we are
all commiters, we can play and do what we want".
> (3) Code that has been accepted into the Commons (and therefore has
> its own release schedule and versioning).
That's again well defined, and it's a clear part of the library.
>
> into only two places where the code might live:
>
> (A) sandbox - for cases 1 and 2.
>
> (B) commons - for case 3.
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
>
> (b) Add a third reposiory (I guess it would be agora according to the
> current vocabulary) for use case 2.
I would prefer (b) - or
(c) Rename "sandbox" to "agora", make clear that experimental code is
allowed using the same rules that are used for any other jakarta
project. We can have a jakarat-agora/sandbox directory for this kind of
experiments if someone really wants that.
The goal is to keep the code in a common place so more projects
can cooperate on it, and that's why we need a common repository where all
projects have equal access.
We want to promote comunication between projects - not to copy code back
and forth.
Of course, some code will mature and become part of "commons" ( with it's
own maintainers), but some code will continue to be developed and
maintained by the projects that are using it.
Costin
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@cx1002407-c.escnd1.sdca.home.com>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> Ok, I think I need to clarify:
>
> Experimental code can happen in any project, including commons - as part
> of a proposals/ directory. Nobody complained so far that they can't do
> experiments, and the library wasn't started to provide place for
> experimental code, but to create components with a clear goal and
> community ( the library side ) and to create a place where projects can
> cooperate on common components ( the agora side ).
>
Perhaps we are interpreting 'experimental' in different ways. Let me
rephrase a bit more clearly. The 'experimental' I am referring to is the
case where a need has been identified ( lets stick with DBCP for a simple
case ), and multiple projects have agreed to work on a common solution. At
some point the existing code from the different projects will be mashed
together in some way or tested to find the code that fits the need best.
I think you are interpreting 'experimental' as "someone has a new idea and
implements it alone from scratch". While I agree that this isn't the
immediate purpose of <insert name of project here>, to be blunt, why the
hell not? If a group of committers see a need for a
tool/component/whatever that doesn't yet exist, why shouldn't they develop
it together?
>
> Given the current confusion I would really like to change the name/scope
> of the sandbox and make it closed to experimental code ( as in the
> original proposal ) - only code that is contributed from an existing
> project should be accepted, at least in the initial stage.
>
Why dump more limitations on this from the start? Setting a 'rule' and
changing it later is much more confusing than allowing the committers to
start with general guidelines and get more specific as a need arises.
>
> On Wed, 14 Mar 2001, David Weinrich wrote:
>
> > I have to agree with you on this one, the case where a code is in the
> > state of (2) above seems to invite problems. What seems to be a decent
> > compromise to me is to allow a status to be attached to each a component:
>
> We didn't spend all those weeks of discussion just to come with a
> playground for experimental code - anyone can do experiments on
> SourceForge or in a proposal directory in any project.
>
Again, I think the difference in interpretation of 'experimental' has
caused the confusion here.
> Mixing experimental code in Agora can only create problems and confusion.
>
>
> > 1) What can be done to prevent the situation Craig describes above, where
> > one or more jakarta project(s) use different versions of code from <insert
> > name of shared CVS here>?
>
> If the projects are sharing the component ( i.e. they are all equaly
> involved in the development of the component ) it's less likely to happen
> than in the case when the component is developed outside the projects.
>
> The problem is when there are incompatiblities and you can't use the
> latest version - but that's the whole idea behind giving a vote to all
> projects that are involved and are using the shared code.
>
>
> > 2) In what cases would people work together on code, but not want to go
> > the extra ten miles to release the code as a 'product' or 'component' ( or
> > any other suitable word)?
>
> Tools ? Most of the components are tools that help us construct a product
> ( like tomcat ). We have goals - and if you get distracted in creating
> products out of the tools you use you may not get your main goal.
>
The need for reliable tools is there as well.
> There are many people who are involved in the library because they want to
> create components. And I'm sure many of those common packages will become
> top-level components and will get their own maintainers.
>
> But my interest is in sharing code among projects - if the shared code
> will be componentized that's great, but it's not the primary goal.
>
One of the common ideas ( no pun intended ) during these discussions has
been that this project could suit different purposes for different
people. The common thread ( ok, that was a bad one as well ) is that the
different needs/uses for having an area/project for committers to share
work benefit from existing in one 'place'. Putting up strict limitations
to fit the project to one particular interest is once again building
walls.
>
> > 3) What should be the criteria for what is considered 'fit for public
> > consumption' code?
>
> That's simple to answer - when all commiters of a jakarta project are
> happy with a piece of code.
>
> It's a simple vote - and this happens quite often, so no need to worry
> about that.
>
+999 on that, a question I didn't have to ask, sorry ;)
>
> Costin
>
>
David
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@cx1002407-c.escnd1.sdca.home.com>.
On Thu, 15 Mar 2001 cmanolache@yahoo.com wrote:
> Ok, I think I need to clarify:
>
> Experimental code can happen in any project, including commons - as part
> of a proposals/ directory. Nobody complained so far that they can't do
> experiments, and the library wasn't started to provide place for
> experimental code, but to create components with a clear goal and
> community ( the library side ) and to create a place where projects can
> cooperate on common components ( the agora side ).
>
Perhaps we are interpreting 'experimental' in different ways. Let me
rephrase a bit more clearly. The 'experimental' I am referring to is the
case where a need has been identified ( lets stick with DBCP for a simple
case ), and multiple projects have agreed to work on a common solution. At
some point the existing code from the different projects will be mashed
together in some way or tested to find the code that fits the need best.
I think you are interpreting 'experimental' as "someone has a new idea and
implements it alone from scratch". While I agree that this isn't the
immediate purpose of <insert name of project here>, to be blunt, why the
hell not? If a group of committers see a need for a
tool/component/whatever that doesn't yet exist, why shouldn't they develop
it together?
>
> Given the current confusion I would really like to change the name/scope
> of the sandbox and make it closed to experimental code ( as in the
> original proposal ) - only code that is contributed from an existing
> project should be accepted, at least in the initial stage.
>
Why dump more limitations on this from the start? Setting a 'rule' and
changing it later is much more confusing than allowing the committers to
start with general guidelines and get more specific as a need arises.
>
> On Wed, 14 Mar 2001, David Weinrich wrote:
>
> > I have to agree with you on this one, the case where a code is in the
> > state of (2) above seems to invite problems. What seems to be a decent
> > compromise to me is to allow a status to be attached to each a component:
>
> We didn't spend all those weeks of discussion just to come with a
> playground for experimental code - anyone can do experiments on
> SourceForge or in a proposal directory in any project.
>
Again, I think the difference in interpretation of 'experimental' has
caused the confusion here.
> Mixing experimental code in Agora can only create problems and confusion.
>
>
> > 1) What can be done to prevent the situation Craig describes above, where
> > one or more jakarta project(s) use different versions of code from <insert
> > name of shared CVS here>?
>
> If the projects are sharing the component ( i.e. they are all equaly
> involved in the development of the component ) it's less likely to happen
> than in the case when the component is developed outside the projects.
>
> The problem is when there are incompatiblities and you can't use the
> latest version - but that's the whole idea behind giving a vote to all
> projects that are involved and are using the shared code.
>
>
> > 2) In what cases would people work together on code, but not want to go
> > the extra ten miles to release the code as a 'product' or 'component' ( or
> > any other suitable word)?
>
> Tools ? Most of the components are tools that help us construct a product
> ( like tomcat ). We have goals - and if you get distracted in creating
> products out of the tools you use you may not get your main goal.
>
The need for reliable tools is there as well.
> There are many people who are involved in the library because they want to
> create components. And I'm sure many of those common packages will become
> top-level components and will get their own maintainers.
>
> But my interest is in sharing code among projects - if the shared code
> will be componentized that's great, but it's not the primary goal.
>
One of the common ideas ( no pun intended ) during these discussions has
been that this project could suit different purposes for different
people. The common thread ( ok, that was a bad one as well ) is that the
different needs/uses for having an area/project for committers to share
work benefit from existing in one 'place'. Putting up strict limitations
to fit the project to one particular interest is once again building
walls.
>
> > 3) What should be the criteria for what is considered 'fit for public
> > consumption' code?
>
> That's simple to answer - when all commiters of a jakarta project are
> happy with a piece of code.
>
> It's a simple vote - and this happens quite often, so no need to worry
> about that.
>
+999 on that, a question I didn't have to ask, sorry ;)
>
> Costin
>
>
David
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ok, I think I need to clarify:
Experimental code can happen in any project, including commons - as part
of a proposals/ directory. Nobody complained so far that they can't do
experiments, and the library wasn't started to provide place for
experimental code, but to create components with a clear goal and
community ( the library side ) and to create a place where projects can
cooperate on common components ( the agora side ).
Given the current confusion I would really like to change the name/scope
of the sandbox and make it closed to experimental code ( as in the
original proposal ) - only code that is contributed from an existing
project should be accepted, at least in the initial stage.
On Wed, 14 Mar 2001, David Weinrich wrote:
> I have to agree with you on this one, the case where a code is in the
> state of (2) above seems to invite problems. What seems to be a decent
> compromise to me is to allow a status to be attached to each a component:
We didn't spend all those weeks of discussion just to come with a
playground for experimental code - anyone can do experiments on
SourceForge or in a proposal directory in any project.
Mixing experimental code in Agora can only create problems and confusion.
> 1) What can be done to prevent the situation Craig describes above, where
> one or more jakarta project(s) use different versions of code from <insert
> name of shared CVS here>?
If the projects are sharing the component ( i.e. they are all equaly
involved in the development of the component ) it's less likely to happen
than in the case when the component is developed outside the projects.
The problem is when there are incompatiblities and you can't use the
latest version - but that's the whole idea behind giving a vote to all
projects that are involved and are using the shared code.
> 2) In what cases would people work together on code, but not want to go
> the extra ten miles to release the code as a 'product' or 'component' ( or
> any other suitable word)?
Tools ? Most of the components are tools that help us construct a product
( like tomcat ). We have goals - and if you get distracted in creating
products out of the tools you use you may not get your main goal.
There are many people who are involved in the library because they want to
create components. And I'm sure many of those common packages will become
top-level components and will get their own maintainers.
But my interest is in sharing code among projects - if the shared code
will be componentized that's great, but it's not the primary goal.
> 3) What should be the criteria for what is considered 'fit for public
> consumption' code?
That's simple to answer - when all commiters of a jakarta project are
happy with a piece of code.
It's a simple vote - and this happens quite often, so no need to worry
about that.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ok, I think I need to clarify:
Experimental code can happen in any project, including commons - as part
of a proposals/ directory. Nobody complained so far that they can't do
experiments, and the library wasn't started to provide place for
experimental code, but to create components with a clear goal and
community ( the library side ) and to create a place where projects can
cooperate on common components ( the agora side ).
Given the current confusion I would really like to change the name/scope
of the sandbox and make it closed to experimental code ( as in the
original proposal ) - only code that is contributed from an existing
project should be accepted, at least in the initial stage.
On Wed, 14 Mar 2001, David Weinrich wrote:
> I have to agree with you on this one, the case where a code is in the
> state of (2) above seems to invite problems. What seems to be a decent
> compromise to me is to allow a status to be attached to each a component:
We didn't spend all those weeks of discussion just to come with a
playground for experimental code - anyone can do experiments on
SourceForge or in a proposal directory in any project.
Mixing experimental code in Agora can only create problems and confusion.
> 1) What can be done to prevent the situation Craig describes above, where
> one or more jakarta project(s) use different versions of code from <insert
> name of shared CVS here>?
If the projects are sharing the component ( i.e. they are all equaly
involved in the development of the component ) it's less likely to happen
than in the case when the component is developed outside the projects.
The problem is when there are incompatiblities and you can't use the
latest version - but that's the whole idea behind giving a vote to all
projects that are involved and are using the shared code.
> 2) In what cases would people work together on code, but not want to go
> the extra ten miles to release the code as a 'product' or 'component' ( or
> any other suitable word)?
Tools ? Most of the components are tools that help us construct a product
( like tomcat ). We have goals - and if you get distracted in creating
products out of the tools you use you may not get your main goal.
There are many people who are involved in the library because they want to
create components. And I'm sure many of those common packages will become
top-level components and will get their own maintainers.
But my interest is in sharing code among projects - if the shared code
will be componentized that's great, but it's not the primary goal.
> 3) What should be the criteria for what is considered 'fit for public
> consumption' code?
That's simple to answer - when all commiters of a jakarta project are
happy with a piece of code.
It's a simple vote - and this happens quite often, so no need to worry
about that.
Costin
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
...snipped for no good reason...
>
> I'm all for setting things up so that people can do what they need. My
> discomfort is the current proposal combines three use cases:
>
> (1) New experimental code that is not available to the public (and
> is not subject to releases or versioning).
>
> (2) Code that has been released as part of a subproject (but does
> not have a released state of its own).
>
> (3) Code that has been accepted into the Commons (and therefore has
> its own release schedule and versioning).
>
> into only two places where the code might live:
>
> (A) sandbox - for cases 1 and 2.
>
> (B) commons - for case 3.
>
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
>
> (b) Add a third reposiory (I guess it would be agora according to the
> current vocabulary) for use case 2.
>
> I would prefer we choose (a), although I could live with (b).
>
> > Costin
> >
> >
>
> Craig
>
I have to agree with you on this one, the case where a code is in the
state of (2) above seems to invite problems. What seems to be a decent
compromise to me is to allow a status to be attached to each a component:
experimental: not fit for public consumption. Code that is in the process
of being tested and matured.
current: Code that has reached a reasonable amount of stability. It would
almost be reasonable for a project to include this version of code with a
pre-beta product, with assumptions similar to (a) above.
stable/beta: Code that has a stable api and is nearing release quality. It
would again be reasonable for a project to include this code in the
beta-release of a product, with assumptions that reaching a release state
on this code ( either rolling the code into the product if only one
project uses it or putting it in the library ) is something of a
prerequisite for completing the beta-testing of the product.
release: Code that is or will be used in one or more released versions of
a jakarta product. I'm guessing most code in this state will be entered
into the library.
( pardon the FreeBSD-ish wordings, that model seemed to fit this
discussion well )
Now my questions are these:
1) What can be done to prevent the situation Craig describes above, where
one or more jakarta project(s) use different versions of code from <insert
name of shared CVS here>?
2) In what cases would people work together on code, but not want to go
the extra ten miles to release the code as a 'product' or 'component' ( or
any other suitable word)?
3) What should be the criteria for what is considered 'fit for public
consumption' code?
These are the issues that cloud my understanding of the issue right now,
so I am trying to understand how people ( with more experience ;)
interpret and would solve those questions.
As far as names go, sandbox was a word chosen fairly quickly, and I agree
that it has too many meanings. Agora would be a good name for the shared CVS.
David
Re: [VOTE] "prop02"
Posted by David Weinrich <dw...@home.com>.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
...snipped for no good reason...
>
> I'm all for setting things up so that people can do what they need. My
> discomfort is the current proposal combines three use cases:
>
> (1) New experimental code that is not available to the public (and
> is not subject to releases or versioning).
>
> (2) Code that has been released as part of a subproject (but does
> not have a released state of its own).
>
> (3) Code that has been accepted into the Commons (and therefore has
> its own release schedule and versioning).
>
> into only two places where the code might live:
>
> (A) sandbox - for cases 1 and 2.
>
> (B) commons - for case 3.
>
> I don't like the ambiguity of what code in sandbox means
> under this scenario. Alternatives to solve the problem include:
>
> (a) If a project wants to release something that includes code in the
> sandbox, it must either get it accepted into commons, or copy the
> code back into its own repository.
>
> (b) Add a third reposiory (I guess it would be agora according to the
> current vocabulary) for use case 2.
>
> I would prefer we choose (a), although I could live with (b).
>
> > Costin
> >
> >
>
> Craig
>
I have to agree with you on this one, the case where a code is in the
state of (2) above seems to invite problems. What seems to be a decent
compromise to me is to allow a status to be attached to each a component:
experimental: not fit for public consumption. Code that is in the process
of being tested and matured.
current: Code that has reached a reasonable amount of stability. It would
almost be reasonable for a project to include this version of code with a
pre-beta product, with assumptions similar to (a) above.
stable/beta: Code that has a stable api and is nearing release quality. It
would again be reasonable for a project to include this code in the
beta-release of a product, with assumptions that reaching a release state
on this code ( either rolling the code into the product if only one
project uses it or putting it in the library ) is something of a
prerequisite for completing the beta-testing of the product.
release: Code that is or will be used in one or more released versions of
a jakarta product. I'm guessing most code in this state will be entered
into the library.
( pardon the FreeBSD-ish wordings, that model seemed to fit this
discussion well )
Now my questions are these:
1) What can be done to prevent the situation Craig describes above, where
one or more jakarta project(s) use different versions of code from <insert
name of shared CVS here>?
2) In what cases would people work together on code, but not want to go
the extra ten miles to release the code as a 'product' or 'component' ( or
any other suitable word)?
3) What should be the criteria for what is considered 'fit for public
consumption' code?
These are the issues that cloud my understanding of the issue right now,
so I am trying to understand how people ( with more experience ;)
interpret and would solve those questions.
As far as names go, sandbox was a word chosen fairly quickly, and I agree
that it has too many meanings. Agora would be a good name for the shared CVS.
David
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See below.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> On Wed, 14 Mar 2001, Ted Husted wrote:
>
> > cmanolache@yahoo.com wrote:
> > > The current rule is that a jakarta project can "sponsor" a component in
> > > the sandbox/agora. The components in the sandbox/agora are developed by
> > > jakarta commiters, and may included in multiple jakarta projects - so
> > > probably they have a higher quality standard and more review than
> > > most components that will be developed and maintained by 3-4 library
> > > developers.
> >
> > How does the code get out of the sandbox and into the multiple products?
>
> Each product can take it outside of the box and include it.
>
>
> > Before when we talked about it being released as part of the product, I
> > thought that meant the code would be placed in the product's CVS, and
> > made part of the product's distribution. That's what I meant by
> > sponsored.
>
> That's one way.
>
> Or the project may tag all the components that it uses and build a
> snapshot ( say threadpool.jar ) and then include this jar in the project
> distribution.
>
> It can do that either by combining it in the project jar.
>
> Or the project may decide it's better to include a separate jar, and maybe
> later on, if the component improves or gets bugfixes, the project may
> choose to tag again the workspace and release an "update" for that
> component.
>
> There are other choices - but it's the project that is using the component
> that makes the decision about what's best for it.
>
> Most of the time the components are not tightly-coupled in the project -
> and releasing updates is a very valid choice for a project. In which case
> it may need to make the component available as a separate (
> "update" ) jar.
>
>
>
> >
> > For the Commons, each package would have a separate root branch, with
> > it's own build, along with ready-to-run JARs, that could be downloaded
> > via the catalog.
> >
> > Is that what you planned to do with Agora?
>
> No - I didn't planned anything with Agora. Or I planned that no plan
> should be pre-set for Agora - the component can be packaged as a separate
> entity and proposed in the commons, or jakarta projects may decide a
> distribution mechanism that fits it's goals.
>
> What is important is that the rules for Agora should be open to the needs
> and decisions of jakarta projects.
>
> IMPROTANT. That doesn't mean "anyone" can release components or the
> quality will be affected - this is clearly specified that a jakarta
> project can vote and release different components that it co-develops with
> other projects.
>
> A vote in a project ( like tomcat or ant ) is as good and involves as much
> responsibility as a vote in the library project.
>
> IMHO a component that is released this way will have more review and
> support than a regular library - since people from other projects will
> monitor this as well.
>
>
> > I believe that there has to be a clear, documented vote before we can
> > release the code under the Apache brand.
> >
> > So after getting the build for Tomcat, do I then have to get the build
> > for the entire sandbox, or would the tagged branch be available
> > separately?
>
> Tomcat commiters will decide what's best in each case, and chose what's
> easier/better for tomcat users.
>
> > If the tagged branch is available separately, then can one or more
> > of the subprojects vote specifically on that branch before it is
> > released to the public?
>
> I suppose so.
>
> >
> > Part of the problem is that I don't grasp the mechanics of Agora.
>
> The mechanics are simple - make it as open as possible to the needs of
> jakarta subprojects. Don't force any pre-set solution, but let them choose
> how to use the commons. After all, we are talking about clearly defined
> entities that have the right to choose on their own.
>
I'm all for setting things up so that people can do what they need. My
discomfort is the current proposal combines three use cases:
(1) New experimental code that is not available to the public (and
is not subject to releases or versioning).
(2) Code that has been released as part of a subproject (but does
not have a released state of its own).
(3) Code that has been accepted into the Commons (and therefore has
its own release schedule and versioning).
into only two places where the code might live:
(A) sandbox - for cases 1 and 2.
(B) commons - for case 3.
I don't like the ambiguity of what code in sandbox means
under this scenario. Alternatives to solve the problem include:
(a) If a project wants to release something that includes code in the
sandbox, it must either get it accepted into commons, or copy the
code back into its own repository.
(b) Add a third reposiory (I guess it would be agora according to the
current vocabulary) for use case 2.
I would prefer we choose (a), although I could live with (b).
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See below.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> On Wed, 14 Mar 2001, Ted Husted wrote:
>
> > cmanolache@yahoo.com wrote:
> > > The current rule is that a jakarta project can "sponsor" a component in
> > > the sandbox/agora. The components in the sandbox/agora are developed by
> > > jakarta commiters, and may included in multiple jakarta projects - so
> > > probably they have a higher quality standard and more review than
> > > most components that will be developed and maintained by 3-4 library
> > > developers.
> >
> > How does the code get out of the sandbox and into the multiple products?
>
> Each product can take it outside of the box and include it.
>
>
> > Before when we talked about it being released as part of the product, I
> > thought that meant the code would be placed in the product's CVS, and
> > made part of the product's distribution. That's what I meant by
> > sponsored.
>
> That's one way.
>
> Or the project may tag all the components that it uses and build a
> snapshot ( say threadpool.jar ) and then include this jar in the project
> distribution.
>
> It can do that either by combining it in the project jar.
>
> Or the project may decide it's better to include a separate jar, and maybe
> later on, if the component improves or gets bugfixes, the project may
> choose to tag again the workspace and release an "update" for that
> component.
>
> There are other choices - but it's the project that is using the component
> that makes the decision about what's best for it.
>
> Most of the time the components are not tightly-coupled in the project -
> and releasing updates is a very valid choice for a project. In which case
> it may need to make the component available as a separate (
> "update" ) jar.
>
>
>
> >
> > For the Commons, each package would have a separate root branch, with
> > it's own build, along with ready-to-run JARs, that could be downloaded
> > via the catalog.
> >
> > Is that what you planned to do with Agora?
>
> No - I didn't planned anything with Agora. Or I planned that no plan
> should be pre-set for Agora - the component can be packaged as a separate
> entity and proposed in the commons, or jakarta projects may decide a
> distribution mechanism that fits it's goals.
>
> What is important is that the rules for Agora should be open to the needs
> and decisions of jakarta projects.
>
> IMPROTANT. That doesn't mean "anyone" can release components or the
> quality will be affected - this is clearly specified that a jakarta
> project can vote and release different components that it co-develops with
> other projects.
>
> A vote in a project ( like tomcat or ant ) is as good and involves as much
> responsibility as a vote in the library project.
>
> IMHO a component that is released this way will have more review and
> support than a regular library - since people from other projects will
> monitor this as well.
>
>
> > I believe that there has to be a clear, documented vote before we can
> > release the code under the Apache brand.
> >
> > So after getting the build for Tomcat, do I then have to get the build
> > for the entire sandbox, or would the tagged branch be available
> > separately?
>
> Tomcat commiters will decide what's best in each case, and chose what's
> easier/better for tomcat users.
>
> > If the tagged branch is available separately, then can one or more
> > of the subprojects vote specifically on that branch before it is
> > released to the public?
>
> I suppose so.
>
> >
> > Part of the problem is that I don't grasp the mechanics of Agora.
>
> The mechanics are simple - make it as open as possible to the needs of
> jakarta subprojects. Don't force any pre-set solution, but let them choose
> how to use the commons. After all, we are talking about clearly defined
> entities that have the right to choose on their own.
>
I'm all for setting things up so that people can do what they need. My
discomfort is the current proposal combines three use cases:
(1) New experimental code that is not available to the public (and
is not subject to releases or versioning).
(2) Code that has been released as part of a subproject (but does
not have a released state of its own).
(3) Code that has been accepted into the Commons (and therefore has
its own release schedule and versioning).
into only two places where the code might live:
(A) sandbox - for cases 1 and 2.
(B) commons - for case 3.
I don't like the ambiguity of what code in sandbox means
under this scenario. Alternatives to solve the problem include:
(a) If a project wants to release something that includes code in the
sandbox, it must either get it accepted into commons, or copy the
code back into its own repository.
(b) Add a third reposiory (I guess it would be agora according to the
current vocabulary) for use case 2.
I would prefer we choose (a), although I could live with (b).
> Costin
>
>
Craig
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The current rule is that a jakarta project can "sponsor" a component in
> > the sandbox/agora. The components in the sandbox/agora are developed by
> > jakarta commiters, and may included in multiple jakarta projects - so
> > probably they have a higher quality standard and more review than
> > most components that will be developed and maintained by 3-4 library
> > developers.
>
> How does the code get out of the sandbox and into the multiple products?
Each product can take it outside of the box and include it.
> Before when we talked about it being released as part of the product, I
> thought that meant the code would be placed in the product's CVS, and
> made part of the product's distribution. That's what I meant by
> sponsored.
That's one way.
Or the project may tag all the components that it uses and build a
snapshot ( say threadpool.jar ) and then include this jar in the project
distribution.
It can do that either by combining it in the project jar.
Or the project may decide it's better to include a separate jar, and maybe
later on, if the component improves or gets bugfixes, the project may
choose to tag again the workspace and release an "update" for that
component.
There are other choices - but it's the project that is using the component
that makes the decision about what's best for it.
Most of the time the components are not tightly-coupled in the project -
and releasing updates is a very valid choice for a project. In which case
it may need to make the component available as a separate (
"update" ) jar.
>
> For the Commons, each package would have a separate root branch, with
> it's own build, along with ready-to-run JARs, that could be downloaded
> via the catalog.
>
> Is that what you planned to do with Agora?
No - I didn't planned anything with Agora. Or I planned that no plan
should be pre-set for Agora - the component can be packaged as a separate
entity and proposed in the commons, or jakarta projects may decide a
distribution mechanism that fits it's goals.
What is important is that the rules for Agora should be open to the needs
and decisions of jakarta projects.
IMPROTANT. That doesn't mean "anyone" can release components or the
quality will be affected - this is clearly specified that a jakarta
project can vote and release different components that it co-develops with
other projects.
A vote in a project ( like tomcat or ant ) is as good and involves as much
responsibility as a vote in the library project.
IMHO a component that is released this way will have more review and
support than a regular library - since people from other projects will
monitor this as well.
> I believe that there has to be a clear, documented vote before we can
> release the code under the Apache brand.
>
> So after getting the build for Tomcat, do I then have to get the build
> for the entire sandbox, or would the tagged branch be available
> separately?
Tomcat commiters will decide what's best in each case, and chose what's
easier/better for tomcat users.
> If the tagged branch is available separately, then can one or more
> of the subprojects vote specifically on that branch before it is
> released to the public?
I suppose so.
>
> Part of the problem is that I don't grasp the mechanics of Agora.
The mechanics are simple - make it as open as possible to the needs of
jakarta subprojects. Don't force any pre-set solution, but let them choose
how to use the commons. After all, we are talking about clearly defined
entities that have the right to choose on their own.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > The current rule is that a jakarta project can "sponsor" a component in
> > the sandbox/agora. The components in the sandbox/agora are developed by
> > jakarta commiters, and may included in multiple jakarta projects - so
> > probably they have a higher quality standard and more review than
> > most components that will be developed and maintained by 3-4 library
> > developers.
>
> How does the code get out of the sandbox and into the multiple products?
Each product can take it outside of the box and include it.
> Before when we talked about it being released as part of the product, I
> thought that meant the code would be placed in the product's CVS, and
> made part of the product's distribution. That's what I meant by
> sponsored.
That's one way.
Or the project may tag all the components that it uses and build a
snapshot ( say threadpool.jar ) and then include this jar in the project
distribution.
It can do that either by combining it in the project jar.
Or the project may decide it's better to include a separate jar, and maybe
later on, if the component improves or gets bugfixes, the project may
choose to tag again the workspace and release an "update" for that
component.
There are other choices - but it's the project that is using the component
that makes the decision about what's best for it.
Most of the time the components are not tightly-coupled in the project -
and releasing updates is a very valid choice for a project. In which case
it may need to make the component available as a separate (
"update" ) jar.
>
> For the Commons, each package would have a separate root branch, with
> it's own build, along with ready-to-run JARs, that could be downloaded
> via the catalog.
>
> Is that what you planned to do with Agora?
No - I didn't planned anything with Agora. Or I planned that no plan
should be pre-set for Agora - the component can be packaged as a separate
entity and proposed in the commons, or jakarta projects may decide a
distribution mechanism that fits it's goals.
What is important is that the rules for Agora should be open to the needs
and decisions of jakarta projects.
IMPROTANT. That doesn't mean "anyone" can release components or the
quality will be affected - this is clearly specified that a jakarta
project can vote and release different components that it co-develops with
other projects.
A vote in a project ( like tomcat or ant ) is as good and involves as much
responsibility as a vote in the library project.
IMHO a component that is released this way will have more review and
support than a regular library - since people from other projects will
monitor this as well.
> I believe that there has to be a clear, documented vote before we can
> release the code under the Apache brand.
>
> So after getting the build for Tomcat, do I then have to get the build
> for the entire sandbox, or would the tagged branch be available
> separately?
Tomcat commiters will decide what's best in each case, and chose what's
easier/better for tomcat users.
> If the tagged branch is available separately, then can one or more
> of the subprojects vote specifically on that branch before it is
> released to the public?
I suppose so.
>
> Part of the problem is that I don't grasp the mechanics of Agora.
The mechanics are simple - make it as open as possible to the needs of
jakarta subprojects. Don't force any pre-set solution, but let them choose
how to use the commons. After all, we are talking about clearly defined
entities that have the right to choose on their own.
Costin
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> The current rule is that a jakarta project can "sponsor" a component in
> the sandbox/agora. The components in the sandbox/agora are developed by
> jakarta commiters, and may included in multiple jakarta projects - so
> probably they have a higher quality standard and more review than
> most components that will be developed and maintained by 3-4 library
> developers.
How does the code get out of the sandbox and into the multiple products?
Before when we talked about it being released as part of the product, I
thought that meant the code would be placed in the product's CVS, and
made part of the product's distribution. That's what I meant by
sponsored.
For the Commons, each package would have a separate root branch, with
it's own build, along with ready-to-run JARs, that could be downloaded
via the catalog.
Is that what you planned to do with Agora?
I believe that there has to be a clear, documented vote before we can
release the code under the Apache brand.
So after getting the build for Tomcat, do I then have to get the build
for the entire sandbox, or would the tagged branch be available
separately?
If the tagged branch is available separately, then can one or more
of the subprojects vote specifically on that branch before it is
released to the public?
Part of the problem is that I don't grasp the mechanics of Agora.
-Ted.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> The current rule is that a jakarta project can "sponsor" a component in
> the sandbox/agora. The components in the sandbox/agora are developed by
> jakarta commiters, and may included in multiple jakarta projects - so
> probably they have a higher quality standard and more review than
> most components that will be developed and maintained by 3-4 library
> developers.
How does the code get out of the sandbox and into the multiple products?
Before when we talked about it being released as part of the product, I
thought that meant the code would be placed in the product's CVS, and
made part of the product's distribution. That's what I meant by
sponsored.
For the Commons, each package would have a separate root branch, with
it's own build, along with ready-to-run JARs, that could be downloaded
via the catalog.
Is that what you planned to do with Agora?
I believe that there has to be a clear, documented vote before we can
release the code under the Apache brand.
So after getting the build for Tomcat, do I then have to get the build
for the entire sandbox, or would the tagged branch be available
separately?
If the tagged branch is available separately, then can one or more
of the subprojects vote specifically on that branch before it is
released to the public?
Part of the problem is that I don't grasp the mechanics of Agora.
-Ted.
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ted,
The proposal as is today was voted and agreed upon. That includes the
option that a jakarta project can vote and support a sandbox package.
If you remove this - and add additional restrictions on the agora side -
then the whole proposal changes. I'm -1( veto ) on this kind of changes.
I don't think it's fair to agree with something ( that agora should be
part of the library ) and then do "small" changes that will turn agora
into something else.
The current rule is that a jakarta project can "sponsor" a component in
the sandbox/agora. The components in the sandbox/agora are developed by
jakarta commiters, and may included in multiple jakarta projects - so
probably they have a higher quality standard and more review than
most components that will be developed and maintained by 3-4 library
developers.
The libarry has 3 components - the catalog, the mini-jakarta components
developed by groups of library commiters, and the agora/sandbox.
The sandbox is supposed to allow projects to cooperate on
components.
If you want a "playground" - I'm +1 on adding a jakarta-playground to the
proposal.
If you want to fix something - I would propose to rename "sandbox" back to
"agora" - to avoid further confusion. The "sandbox" seems to look more
like a "bazaar" - and there is a big difference between the 2.
Costin
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > In which case I think we are back to the initial position - as the
> > original vote on library-dev was based on the assumption that jakarta
> > subprojects can release and cooperate on sandbox projects, and the sandbox
> > was supposed to be an sharing place, not a playground.
>
> I believe Jakarta needs an unattached CVS where people can work on code
> before proposing it somewhere else.
>
> This would allow people to develop packages like the DBCP pool first,
> and then propose it to the Commons once they had something to show.
>
> This would also be a useful place for people to work on cross-project
> code. Or draft entirely new subprojects without have to go off to
> SourceForge.
>
> But, I don't believe non-committers should have access to this area. If
> we did permit public access, then politics regarding Apache
> quality-control would kick in, and start to defeat the purpose.
>
> So, to release the code, something developed in the sandbox would have
> to be placed in a CVS where the public does have access, and ultimately
> voted on by the committers for that subproject CVS.
>
> I do truly believe that the functionality of Agora will be available
> through the Commons. Committers from different subprojects can work
> on a common package, and issue a stable release as needed. Each of
> their subprojects can then use that release, the way Jetspeed uses
> releases of Turbine and Velocity.
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
Ted,
The proposal as is today was voted and agreed upon. That includes the
option that a jakarta project can vote and support a sandbox package.
If you remove this - and add additional restrictions on the agora side -
then the whole proposal changes. I'm -1( veto ) on this kind of changes.
I don't think it's fair to agree with something ( that agora should be
part of the library ) and then do "small" changes that will turn agora
into something else.
The current rule is that a jakarta project can "sponsor" a component in
the sandbox/agora. The components in the sandbox/agora are developed by
jakarta commiters, and may included in multiple jakarta projects - so
probably they have a higher quality standard and more review than
most components that will be developed and maintained by 3-4 library
developers.
The libarry has 3 components - the catalog, the mini-jakarta components
developed by groups of library commiters, and the agora/sandbox.
The sandbox is supposed to allow projects to cooperate on
components.
If you want a "playground" - I'm +1 on adding a jakarta-playground to the
proposal.
If you want to fix something - I would propose to rename "sandbox" back to
"agora" - to avoid further confusion. The "sandbox" seems to look more
like a "bazaar" - and there is a big difference between the 2.
Costin
On Wed, 14 Mar 2001, Ted Husted wrote:
> cmanolache@yahoo.com wrote:
> > In which case I think we are back to the initial position - as the
> > original vote on library-dev was based on the assumption that jakarta
> > subprojects can release and cooperate on sandbox projects, and the sandbox
> > was supposed to be an sharing place, not a playground.
>
> I believe Jakarta needs an unattached CVS where people can work on code
> before proposing it somewhere else.
>
> This would allow people to develop packages like the DBCP pool first,
> and then propose it to the Commons once they had something to show.
>
> This would also be a useful place for people to work on cross-project
> code. Or draft entirely new subprojects without have to go off to
> SourceForge.
>
> But, I don't believe non-committers should have access to this area. If
> we did permit public access, then politics regarding Apache
> quality-control would kick in, and start to defeat the purpose.
>
> So, to release the code, something developed in the sandbox would have
> to be placed in a CVS where the public does have access, and ultimately
> voted on by the committers for that subproject CVS.
>
> I do truly believe that the functionality of Agora will be available
> through the Commons. Committers from different subprojects can work
> on a common package, and issue a stable release as needed. Each of
> their subprojects can then use that release, the way Jetspeed uses
> releases of Turbine and Velocity.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In which case I think we are back to the initial position - as the
> original vote on library-dev was based on the assumption that jakarta
> subprojects can release and cooperate on sandbox projects, and the sandbox
> was supposed to be an sharing place, not a playground.
I believe Jakarta needs an unattached CVS where people can work on code
before proposing it somewhere else.
This would allow people to develop packages like the DBCP pool first,
and then propose it to the Commons once they had something to show.
This would also be a useful place for people to work on cross-project
code. Or draft entirely new subprojects without have to go off to
SourceForge.
But, I don't believe non-committers should have access to this area. If
we did permit public access, then politics regarding Apache
quality-control would kick in, and start to defeat the purpose.
So, to release the code, something developed in the sandbox would have
to be placed in a CVS where the public does have access, and ultimately
voted on by the committers for that subproject CVS.
I do truly believe that the functionality of Agora will be available
through the Commons. Committers from different subprojects can work
on a common package, and issue a stable release as needed. Each of
their subprojects can then use that release, the way Jetspeed uses
releases of Turbine and Velocity.
-Ted.
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
cmanolache@yahoo.com wrote:
> In which case I think we are back to the initial position - as the
> original vote on library-dev was based on the assumption that jakarta
> subprojects can release and cooperate on sandbox projects, and the sandbox
> was supposed to be an sharing place, not a playground.
I believe Jakarta needs an unattached CVS where people can work on code
before proposing it somewhere else.
This would allow people to develop packages like the DBCP pool first,
and then propose it to the Commons once they had something to show.
This would also be a useful place for people to work on cross-project
code. Or draft entirely new subprojects without have to go off to
SourceForge.
But, I don't believe non-committers should have access to this area. If
we did permit public access, then politics regarding Apache
quality-control would kick in, and start to defeat the purpose.
So, to release the code, something developed in the sandbox would have
to be placed in a CVS where the public does have access, and ultimately
voted on by the committers for that subproject CVS.
I do truly believe that the functionality of Agora will be available
through the Commons. Committers from different subprojects can work
on a common package, and issue a stable release as needed. Each of
their subprojects can then use that release, the way Jetspeed uses
releases of Turbine and Velocity.
-Ted.
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> Hmm, it seems to me that this is going to create ambiguity about the code
> in the sandbox, because there will be (at least) two flavors:
>
> * Code being experimented with, played with, evaluated, but not
> yet used anywhere (i.e. what I had understood the sandbox was for).
>
> * Code being experimented with, played with, evaluated, AND released
> as part of another subproject, even though it has not been proposed
> to (or accepted by) Commons.
That's the result of merging the "agora" into "sandbox".
I agree, this is confusing with respect to the intentions of the proposal
that resulted in this wording.
The workspace that we discussed about ( and is now called sandbox ) was
not supposed to be a place where people can play, but a place where
projects and commiters can share code in a common environment.
For experiment and play each can use his own local directory.
I think the second "flavor" is consistent with the intentions in the agora
proposal.
Is it to late to rename "sandbox" to agora ? AFAIK "commons" was found as
a better name for the overal project, but I don't remember a decision to
call the shared workspace as a "sandbox" - and I agree with Craig that
this is confusing in many ways.
> It would seem better to me that a subproject wanting to use sandbox code
> in a release should do one of the following:
>
> * Propose the code to Commons, with the associated willingness to
> support it.
>
> * Take the code to be released back into its own CVS repository
> until such time as it is proposed to, and accepted by, Commons.
>
> This is also more consistent with the restriction in (1.5.1) that sandbox
> code cannot be "released to the public" until accepted by Commons. To me,
> including that code in a subproject release counts as "released to the
> public".
That's why we need the extra " or sponsored by a jakarta subproject".
Removing this option will alter the original proposal in a significant way
- those words were added to reach a compromise, and by transforming the
agora into a play-ground the whole thing changes.
In which case I think we are back to the initial position - as the
original vote on library-dev was based on the assumption that jakarta
subprojects can release and cooperate on sandbox projects, and the sandbox
was supposed to be an sharing place, not a playground.
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
On Wed, 14 Mar 2001, Craig R. McClanahan wrote:
>
> Hmm, it seems to me that this is going to create ambiguity about the code
> in the sandbox, because there will be (at least) two flavors:
>
> * Code being experimented with, played with, evaluated, but not
> yet used anywhere (i.e. what I had understood the sandbox was for).
>
> * Code being experimented with, played with, evaluated, AND released
> as part of another subproject, even though it has not been proposed
> to (or accepted by) Commons.
That's the result of merging the "agora" into "sandbox".
I agree, this is confusing with respect to the intentions of the proposal
that resulted in this wording.
The workspace that we discussed about ( and is now called sandbox ) was
not supposed to be a place where people can play, but a place where
projects and commiters can share code in a common environment.
For experiment and play each can use his own local directory.
I think the second "flavor" is consistent with the intentions in the agora
proposal.
Is it to late to rename "sandbox" to agora ? AFAIK "commons" was found as
a better name for the overal project, but I don't remember a decision to
call the shared workspace as a "sandbox" - and I agree with Craig that
this is confusing in many ways.
> It would seem better to me that a subproject wanting to use sandbox code
> in a release should do one of the following:
>
> * Propose the code to Commons, with the associated willingness to
> support it.
>
> * Take the code to be released back into its own CVS repository
> until such time as it is proposed to, and accepted by, Commons.
>
> This is also more consistent with the restriction in (1.5.1) that sandbox
> code cannot be "released to the public" until accepted by Commons. To me,
> including that code in a subproject release counts as "released to the
> public".
That's why we need the extra " or sponsored by a jakarta subproject".
Removing this option will alter the original proposal in a significant way
- those words were added to reach a compromise, and by transforming the
agora into a play-ground the whole thing changes.
In which case I think we are back to the initial position - as the
original vote on library-dev was based on the assumption that jakarta
subprojects can release and cooperate on sandbox projects, and the sandbox
was supposed to be an sharing place, not a playground.
Costin
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> > > (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> > > work on whatever they like there. No questions asked.
> > >
> > > (2) A codebase developed in the sandbox can't be released to the public
> > > from the sandbox. To release the code to the public, you would have to
> > > move it to another Jakarta CVS, where a subproject could vote to release
> > > it.
> > >
> > > The sandbox could just as easily be part of the Jakarta backbone site,
> > > but it making it part of the Commons proposal seemed like a convenient
> > > way to set it up.
> > >
> >
> > The "sandbox" part, and not being available to the public, was the part I
> > understood. However, point 20 of the revised proposal reads (caps
> > identify the part I'm having a problem with):
> >
> > A cvs repository will be available to all Jakarta
> > committers as a sandbox for new packges. Before
> > release to the public, the sandbox package must be
> > accepted to the commons, OR SPONSORED BY ANOTHER
> > JAKARTA SUBPROJECT.
> >
> > What does "sponsored by another Jakarta subproject" mean? It looks from
> > the wording of 20 that you can bypass the acceptance to the commons that
> > is described in 17. Is that actually the case?
>
> That was the intention - or at least what I proposed.
>
> The idea was that a project can start using a sandbox package - in this
> case when the project is preparing for a release it needs to tag the
> workspace and support a specific version of the common.
>
> Say we have a "thread pool" package, developed in sandbox space, and maybe
> used in common by few jakarta projects. And one of the projects is
> preparing for a release. At this point it can request a release of each
> component it uses - so the project release will depend only on stable
> code. This shouldn't be dependent on library aproval.
>
> ( well, a jakarta project can decide to release whatever it wants as part
> of that project - but IMHO it's important to make this clear and explicit
> )
>
> Costin
>
>
Hmm, it seems to me that this is going to create ambiguity about the code
in the sandbox, because there will be (at least) two flavors:
* Code being experimented with, played with, evaluated, but not
yet used anywhere (i.e. what I had understood the sandbox was for).
* Code being experimented with, played with, evaluated, AND released
as part of another subproject, even though it has not been proposed
to (or accepted by) Commons.
It would seem better to me that a subproject wanting to use sandbox code
in a release should do one of the following:
* Propose the code to Commons, with the associated willingness to
support it.
* Take the code to be released back into its own CVS repository
until such time as it is proposed to, and accepted by, Commons.
This is also more consistent with the restriction in (1.5.1) that sandbox
code cannot be "released to the public" until accepted by Commons. To me,
including that code in a subproject release counts as "released to the
public".
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001 cmanolache@yahoo.com wrote:
> > > (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> > > work on whatever they like there. No questions asked.
> > >
> > > (2) A codebase developed in the sandbox can't be released to the public
> > > from the sandbox. To release the code to the public, you would have to
> > > move it to another Jakarta CVS, where a subproject could vote to release
> > > it.
> > >
> > > The sandbox could just as easily be part of the Jakarta backbone site,
> > > but it making it part of the Commons proposal seemed like a convenient
> > > way to set it up.
> > >
> >
> > The "sandbox" part, and not being available to the public, was the part I
> > understood. However, point 20 of the revised proposal reads (caps
> > identify the part I'm having a problem with):
> >
> > A cvs repository will be available to all Jakarta
> > committers as a sandbox for new packges. Before
> > release to the public, the sandbox package must be
> > accepted to the commons, OR SPONSORED BY ANOTHER
> > JAKARTA SUBPROJECT.
> >
> > What does "sponsored by another Jakarta subproject" mean? It looks from
> > the wording of 20 that you can bypass the acceptance to the commons that
> > is described in 17. Is that actually the case?
>
> That was the intention - or at least what I proposed.
>
> The idea was that a project can start using a sandbox package - in this
> case when the project is preparing for a release it needs to tag the
> workspace and support a specific version of the common.
>
> Say we have a "thread pool" package, developed in sandbox space, and maybe
> used in common by few jakarta projects. And one of the projects is
> preparing for a release. At this point it can request a release of each
> component it uses - so the project release will depend only on stable
> code. This shouldn't be dependent on library aproval.
>
> ( well, a jakarta project can decide to release whatever it wants as part
> of that project - but IMHO it's important to make this clear and explicit
> )
>
> Costin
>
>
Hmm, it seems to me that this is going to create ambiguity about the code
in the sandbox, because there will be (at least) two flavors:
* Code being experimented with, played with, evaluated, but not
yet used anywhere (i.e. what I had understood the sandbox was for).
* Code being experimented with, played with, evaluated, AND released
as part of another subproject, even though it has not been proposed
to (or accepted by) Commons.
It would seem better to me that a subproject wanting to use sandbox code
in a release should do one of the following:
* Propose the code to Commons, with the associated willingness to
support it.
* Take the code to be released back into its own CVS repository
until such time as it is proposed to, and accepted by, Commons.
This is also more consistent with the restriction in (1.5.1) that sandbox
code cannot be "released to the public" until accepted by Commons. To me,
including that code in a subproject release counts as "released to the
public".
Craig
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
> > (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> > work on whatever they like there. No questions asked.
> >
> > (2) A codebase developed in the sandbox can't be released to the public
> > from the sandbox. To release the code to the public, you would have to
> > move it to another Jakarta CVS, where a subproject could vote to release
> > it.
> >
> > The sandbox could just as easily be part of the Jakarta backbone site,
> > but it making it part of the Commons proposal seemed like a convenient
> > way to set it up.
> >
>
> The "sandbox" part, and not being available to the public, was the part I
> understood. However, point 20 of the revised proposal reads (caps
> identify the part I'm having a problem with):
>
> A cvs repository will be available to all Jakarta
> committers as a sandbox for new packges. Before
> release to the public, the sandbox package must be
> accepted to the commons, OR SPONSORED BY ANOTHER
> JAKARTA SUBPROJECT.
>
> What does "sponsored by another Jakarta subproject" mean? It looks from
> the wording of 20 that you can bypass the acceptance to the commons that
> is described in 17. Is that actually the case?
That was the intention - or at least what I proposed.
The idea was that a project can start using a sandbox package - in this
case when the project is preparing for a release it needs to tag the
workspace and support a specific version of the common.
Say we have a "thread pool" package, developed in sandbox space, and maybe
used in common by few jakarta projects. And one of the projects is
preparing for a release. At this point it can request a release of each
component it uses - so the project release will depend only on stable
code. This shouldn't be dependent on library aproval.
( well, a jakarta project can decide to release whatever it wants as part
of that project - but IMHO it's important to make this clear and explicit
)
Costin
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
> > (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> > work on whatever they like there. No questions asked.
> >
> > (2) A codebase developed in the sandbox can't be released to the public
> > from the sandbox. To release the code to the public, you would have to
> > move it to another Jakarta CVS, where a subproject could vote to release
> > it.
> >
> > The sandbox could just as easily be part of the Jakarta backbone site,
> > but it making it part of the Commons proposal seemed like a convenient
> > way to set it up.
> >
>
> The "sandbox" part, and not being available to the public, was the part I
> understood. However, point 20 of the revised proposal reads (caps
> identify the part I'm having a problem with):
>
> A cvs repository will be available to all Jakarta
> committers as a sandbox for new packges. Before
> release to the public, the sandbox package must be
> accepted to the commons, OR SPONSORED BY ANOTHER
> JAKARTA SUBPROJECT.
>
> What does "sponsored by another Jakarta subproject" mean? It looks from
> the wording of 20 that you can bypass the acceptance to the commons that
> is described in 17. Is that actually the case?
That was the intention - or at least what I proposed.
The idea was that a project can start using a sandbox package - in this
case when the project is preparing for a release it needs to tag the
workspace and support a specific version of the common.
Say we have a "thread pool" package, developed in sandbox space, and maybe
used in common by few jakarta projects. And one of the projects is
preparing for a release. At this point it can request a release of each
component it uses - so the project release will depend only on stable
code. This shouldn't be dependent on library aproval.
( well, a jakarta project can decide to release whatever it wants as part
of that project - but IMHO it's important to make this clear and explicit
)
Costin
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> The two ideas are:
>
> (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> work on whatever they like there. No questions asked.
>
> (2) A codebase developed in the sandbox can't be released to the public
> from the sandbox. To release the code to the public, you would have to
> move it to another Jakarta CVS, where a subproject could vote to release
> it.
>
> The sandbox could just as easily be part of the Jakarta backbone site,
> but it making it part of the Commons proposal seemed like a convenient
> way to set it up.
>
The "sandbox" part, and not being available to the public, was the part I
understood. However, point 20 of the revised proposal reads (caps
identify the part I'm having a problem with):
A cvs repository will be available to all Jakarta
committers as a sandbox for new packges. Before
release to the public, the sandbox package must be
accepted to the commons, OR SPONSORED BY ANOTHER
JAKARTA SUBPROJECT.
What does "sponsored by another Jakarta subproject" mean? It looks from
the wording of 20 that you can bypass the acceptance to the commons that
is described in 17. Is that actually the case?
Craig
> "Craig R. McClanahan" wrote:
>
> > In point 20, I understand how a sandbox project can get accepted by the
> > Commons (see 17), but what does "or sponsored by another Jakarta
> > subproject" mean? Does that mean I can bypass the voting in 17 if my
> > subproject's committers are willing to support the code, or what?
> >
> > Craig
>
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> The two ideas are:
>
> (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> work on whatever they like there. No questions asked.
>
> (2) A codebase developed in the sandbox can't be released to the public
> from the sandbox. To release the code to the public, you would have to
> move it to another Jakarta CVS, where a subproject could vote to release
> it.
>
> The sandbox could just as easily be part of the Jakarta backbone site,
> but it making it part of the Commons proposal seemed like a convenient
> way to set it up.
>
The "sandbox" part, and not being available to the public, was the part I
understood. However, point 20 of the revised proposal reads (caps
identify the part I'm having a problem with):
A cvs repository will be available to all Jakarta
committers as a sandbox for new packges. Before
release to the public, the sandbox package must be
accepted to the commons, OR SPONSORED BY ANOTHER
JAKARTA SUBPROJECT.
What does "sponsored by another Jakarta subproject" mean? It looks from
the wording of 20 that you can bypass the acceptance to the commons that
is described in 17. Is that actually the case?
Craig
> "Craig R. McClanahan" wrote:
>
> > In point 20, I understand how a sandbox project can get accepted by the
> > Commons (see 17), but what does "or sponsored by another Jakarta
> > subproject" mean? Does that mean I can bypass the voting in 17 if my
> > subproject's committers are willing to support the code, or what?
> >
> > Craig
>
Re: [VOTE] "prop02"
Posted by cm...@yahoo.com.
> The two ideas are:
>
> (1) Any Jakarta committer is entitled to karma to the sandbox, and can
> work on whatever they like there. No questions asked.
>
> (2) A codebase developed in the sandbox can't be released to the public
> from the sandbox. To release the code to the public, you would have to
> move it to another Jakarta CVS, where a subproject could vote to release
> it.
"move" doesn't necesarily means a physical move, I hope.
( the code will continue to "live" in the common workspace, and be
used/shared by multiple projects ).
It can't have a public release without either beeing accepted ( voted ) as
a library project - i.e a general purpose utility that is maintained by
library, or included in an existing jakarta project - in which
case it will be exposed to the public anyway. If the component is included
in a project - that means it goes through testing, etc as part of the
project and is maintained as part of the project - so it should be ok to
be tagged and can be distributed "standalone" too.
AFAIK the reason for not exposing it to the public is that the component
may not have the support and quality that is needed. That's why a vote is
needed before releasing anything. I think support from jakarta-xxx for a
component is as good as support from jakarta-library.
Since the sandbox is open to all jakarta commiters, moving it to another
repository will make it more restrictive - I don't think this is a good
idea.
That's my understanding at least.
Costin
>
> The sandbox could just as easily be part of the Jakarta backbone site,
> but it making it part of the Commons proposal seemed like a convenient
> way to set it up.
>
> "Craig R. McClanahan" wrote:
>
> > In point 20, I understand how a sandbox project can get accepted by the
> > Commons (see 17), but what does "or sponsored by another Jakarta
> > subproject" mean? Does that mean I can bypass the voting in 17 if my
> > subproject's committers are willing to support the code, or what?
> >
> > Craig
>
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
The two ideas are:
(1) Any Jakarta committer is entitled to karma to the sandbox, and can
work on whatever they like there. No questions asked.
(2) A codebase developed in the sandbox can't be released to the public
from the sandbox. To release the code to the public, you would have to
move it to another Jakarta CVS, where a subproject could vote to release
it.
The sandbox could just as easily be part of the Jakarta backbone site,
but it making it part of the Commons proposal seemed like a convenient
way to set it up.
"Craig R. McClanahan" wrote:
> In point 20, I understand how a sandbox project can get accepted by the
> Commons (see 17), but what does "or sponsored by another Jakarta
> subproject" mean? Does that mean I can bypass the voting in 17 if my
> subproject's committers are willing to support the code, or what?
>
> Craig
Re: [VOTE] "prop02"
Posted by Ted Husted <ne...@husted.com>.
The two ideas are:
(1) Any Jakarta committer is entitled to karma to the sandbox, and can
work on whatever they like there. No questions asked.
(2) A codebase developed in the sandbox can't be released to the public
from the sandbox. To release the code to the public, you would have to
move it to another Jakarta CVS, where a subproject could vote to release
it.
The sandbox could just as easily be part of the Jakarta backbone site,
but it making it part of the Commons proposal seemed like a convenient
way to set it up.
"Craig R. McClanahan" wrote:
> In point 20, I understand how a sandbox project can get accepted by the
> Commons (see 17), but what does "or sponsored by another Jakarta
> subproject" mean? Does that mean I can bypass the voting in 17 if my
> subproject's committers are willing to support the code, or what?
>
> Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> In anticipation of the upcoming PMC meeting, I'd like to propose that we
> make
>
> < http://husted.com/about/commons/prop02.html >
>
> The official "reference copy" of our pending proposal.
>
> This includes minor tweaks that came up on the General list. Changes are
> indicated with strikethrough and a colored font.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
+1, but I've got a quick question (forgive me if this has been covered
before).
In point 20, I understand how a sandbox project can get accepted by the
Commons (see 17), but what does "or sponsored by another Jakarta
subproject" mean? Does that mean I can bypass the voting in 17 if my
subproject's committers are willing to support the code, or what?
Craig
Re: [VOTE] "prop02"
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Mar 2001, Ted Husted wrote:
> In anticipation of the upcoming PMC meeting, I'd like to propose that we
> make
>
> < http://husted.com/about/commons/prop02.html >
>
> The official "reference copy" of our pending proposal.
>
> This includes minor tweaks that came up on the General list. Changes are
> indicated with strikethrough and a colored font.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
+1, but I've got a quick question (forgive me if this has been covered
before).
In point 20, I understand how a sandbox project can get accepted by the
Commons (see 17), but what does "or sponsored by another Jakarta
subproject" mean? Does that mean I can bypass the voting in 17 if my
subproject's committers are willing to support the code, or what?
Craig