You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2003/02/26 10:39:21 UTC
Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
...
> Other projects have now decided to create a sandbox, and it works quite
> well. It has some advantages over the scratchpad:
>
> - it does not "pollute" the main repository space
> - it does not force others to download it
>
> The drawbacks are still present:
>
> - it hides the works a bit more than with scratchpad
> - it does not get tested as with current scratchpad
>
> Actually, if we think aboyt it, it does not really hide things much more
> than scratchpad. And as Stefano said, if one thing should be in Cocoon,
> it has to be integrated in the core ASAP, I agree.
>
> So, to try and bring together all positions, by fulfilling the *needs*
> with a new implementation, I would propose (taking some points from
> Jeff's proposal):
>
> - Cocoon moves scratchpad to a new CVS module cocoon-sandbox
> under cocoon-sandbox/src/java/**
> - We move all alpha blocks to cocoon-sandbox/src/blocks/**
> - we add Forrest-based documantation to teh scratchpad and
> each block
> - for every piece of alpha-quality code (block, scratchpad segment),
> we could have a status file (as Tony Collen suggested) in the
> documentation indicating things like:
>
> - code proposal initiators
> - description (eg links to mailing list discussions)
> - lease expiry
>
>
> This will IMHO:
>
> - make alpha code clearly marked (I'm happy)
> - keep possibility of sperimenting out of the core
> (Jeff, Ovidiu and I are happy)
> - keep sandbox out of main CVS module and make code
> not rot (Stefano's happy)
How about making one modification to this proposal...
Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it
cocoon-contrib or something.
Why? Because then anyone can participate. It tears down any perceived
barrier between cocoon-dev and cocoon-users. Best of all, when code
eventually is 'promoted', there is a strong possibility of gaining new
Cocoon developers. Think of it as housing "alpha committers" as well as
"alpha code".
The root problem is that Cocoon has more code than code maintainers. The
long-term solution is not to juggle the code more effectively, but to
gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
would be a win in the long run.
Thoughts?
--Jeff
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> Agreed. Just like Sourceforge, there will be a lot of crud, but equally,
> there will be a few gems. That's the point: provide an open "sandbox",
> and pick the quality ones for inclusion in Cocoon.
Please don't forget that in SF, there are also 'project owners' opening
up the gates to willing committers and giving them access. Who would do
that in your 'open sandbox' scenario? Or would you let anyone join?
People can always ask for their own project at SF. What is the value of
an orchestrated project?
Just asking, really. I'm trying to find the difference between what you
suggest and what cocoondev.org (already/somehow) provides.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 26, 2003 at 12:44:28PM +0100, Stefano Mazzocchi wrote:
> Jeff Turner wrote:
> >On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
<snip scratchpad ideas/>
<snip consensus on alpha blocks/>
> This leaves us with the alpha core stuff.
>
> Many of you say that Schecoon would not have happened if it wasn't for
> the scratchpad. I don't see this. Nobody helped Ovidiu and the scheme
> syntax argument was discussed over email, not CVS. He proposed, we
> commented, some disliked, some liked, some ignored, some backed up. The
> fact that code development happened on our CVS did it really made a
> difference?
>
> Only one: we saw commit messages. We followed development.
>
> Now, did you guys ever heard about a nice CVS concept called
> "branching"? Ovidiu wanted to work on some cocoon internals, wanted to
> have a place to try things and didn't want to step on our toes, so he
> should have asked for a branch and we would have given it to him.
So you're saying that for core development, people should use branches
instead of the scratchpad?
So when someone comes up with an alpha SuperDuperProcessingPipeline
class, what is the process? Do they tag the whole of CVS? Tag just the
subset they modify?
I've been down the tag-a-subset road before. I developed Excalibur's
horrible dependency-checking build system on a branch over a few months.
The HALF_BRANCHING.txt file in Excalibur describes the hoops one needs to
jump through to use branching for a set of files. It's not fun.
> the scratchpad is a lazy version of the same concept, too bad that when
> developers use branches the tend to go quickly to the point where they
> can merge it with HEAD, unlike the scratchpad that is *already* in head,
> so it will be picked up anyway by the release, even if marked sideways.
>
> I want people to work on HEAD so that they feel the pressure and do a
> better job.
That is clear. It's not clear how a branch is better than a separate
directory.
> If I refactored the build on a branch (or even worse, on another CVS
> module), how many of you would have tried it out and debug it?
Now it seems you don't like branches.. if not, how would Schecoon have
come into existence? What should happen to the current 'core' classes in
the scratchpad?
> Martin Holz wrote:
> > P.S : Improving the build system is really worth some temporary
> > inconvenience. Thank you very much.
>
> See?
>
> Now, about the alpha-committers: the scratchpad creates one-man-shows
> even if we know that our committers have an extensive log of being able
> to work with others.
*Everything* starts off as a one-man show. Innovation comes from
individuals pursuing ideas. The issue is where the one-man shows take
place:
a) Cocoon src/java/*
b) Cocoon branch
c) Cocoon scratchpad
d) Cocoon sandbox module
e) Sourceforge sandbox
f) in private
> If you open up the gates to everyone, do you really think that this will
> help finding new developers for this community? I strongly doubt it.
>
> I'm positive it will generate tons of half-baked concepts and components
> mockups, but it will reduce the filtering that community performs and
> will remove the incentive for them to work harder to gain access to CVS.
>
> The overall quality of code will be much lower and they will feel
> confortable with this since nobody will (could) complain for political
> correctness.
>
> The result will be that we won't ship anything from that since we will
> fear of insulting some of those one-man-shows.
>
> So, at the end, you have simply created a poor-quality collection of
> one-man dumped and half-baked efforts. Also known as the result of the
> "Sourceforge Effect".
Agreed. Just like Sourceforge, there will be a lot of crud, but equally,
there will be a few gems. That's the point: provide an open "sandbox",
and pick the quality ones for inclusion in Cocoon.
There are two more points to consider:
1) Irrespective of whether an open Cocoon sandbox improves Cocoon, it
will benefit *users*, who will have a place to share code. Just like
the Wiki helps users, irrespective of whether it results in better
xdocs.
2) If the sandbox participants choose to implement a "lease" idea, then
it won't be the Sourceforge effect; old code will be culled.
> Sure, one of a thousands might be worth considering. But somebody will
> have to spend his energy finding out which one of these is worthwile and
> since cocoon users and devs will concentrate here, the amount of energy
> to screen those efforts will be very low.
See point #1 above; if stuff doesn't migrate to Cocoon, that is not of
huge concern. The intention is to get Wiki-like community involvement in
the process of writing new code, and as a side-effect, gaining an
incubator for potential new committers.
--Jeff
> - 0 -
>
> I continue to propose to kill the scratchpad for alpha core code without
> creating an alternative.
>
> --
> Stefano Mazzocchi <st...@apache.org>
> Pluralitas non est ponenda sine necessitate [William of Ockham]
> --------------------------------------------------------------------
>
>
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 26/02/2003 12.44:
> Jeff Turner wrote:
...
> I want the scratchpad out of the main cocoon CVS module (now
> xml-cocoon2, in the future just 'cocoon').
>
> Why? because I want to reduce the number of core dependencies we have
> since the whole thing it's becoming unmanageable.
core dependencies? It's a separate jar, separate build, separate
dependencies. This comment doesn't stand.
> There are two sort of things in the scratchpad:
>
> - alpha blocks
> - alpha core stuff
>
> I think we all agree in moving the scratchpad alpha blocks in the blocks
> directory and mark them as alpha. we'll add a block descriptor file that
> indicates their status and we'll be happy.
I won't. I'm not sure there is consensus.
> This leaves us with the alpha core stuff.
>
> Many of you say that Schecoon would not have happened if it wasn't for
> the scratchpad. I don't see this. Nobody helped Ovidiu and the scheme
> syntax argument was discussed over email, not CVS. He proposed, we
> commented, some disliked, some liked, some ignored, some backed up. The
> fact that code development happened on our CVS did it really made a
> difference?
>
> Only one: we saw commit messages. We followed development.
And that's not much?
> Now, did you guys ever heard about a nice CVS concept called
> "branching"? Ovidiu wanted to work on some cocoon internals, wanted to
> have a place to try things and didn't want to step on our toes, so he
> should have asked for a branch and we would have given it to him.
IIRC, you were the one that wanted the scratchpad instead of branching.
Or is my memory weak...
> the scratchpad is a lazy version of the same concept, too bad that when
> developers use branches the tend to go quickly to the point where they
> can merge it with HEAD, unlike the scratchpad that is *already* in head,
> so it will be picked up anyway by the release, even if marked sideways.
>
> I want people to work on HEAD so that they feel the pressure and do a
> better job.
>
> If I refactored the build on a branch (or even worse, on another CVS
> module), how many of you would have tried it out and debug it?
It's not the same thing. Sand on Sand... if we keep piling alpha stuff
on the main branch we will remain alpha. And branches in CVS are a PITA!
> Martin Holz wrote:
> > P.S : Improving the build system is really worth some temporary
> > inconvenience. Thank you very much.
>
> See?
>
> Now, about the alpha-committers: the scratchpad creates one-man-shows
> even if we know that our committers have an extensive log of being able
> to work with others.
>
> If you open up the gates to everyone, do you really think that this will
> help finding new developers for this community? I strongly doubt it.
>
> I'm positive it will generate tons of half-baked concepts and components
> mockups, but it will reduce the filtering that community performs and
> will remove the incentive for them to work harder to gain access to CVS.
>
> The overall quality of code will be much lower and they will feel
> confortable with this since nobody will (could) complain for political
> correctness.
>
> The result will be that we won't ship anything from that since we will
> fear of insulting some of those one-man-shows.
>
> So, at the end, you have simply created a poor-quality collection of
> one-man dumped and half-baked efforts. Also known as the result of the
> "Sourceforge Effect".
>
> Sure, one of a thousands might be worth considering. But somebody will
> have to spend his energy finding out which one of these is worthwile and
> since cocoon users and devs will concentrate here, the amount of energy
> to screen those efforts will be very low.
>
> - 0 -
>
> I continue to propose to kill the scratchpad for alpha core code without
> creating an alternative.
Keep pushing then. You haven't tackled my concerns a bit yet though.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeff Turner wrote:
> On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
> ...
>
>>Other projects have now decided to create a sandbox, and it works quite
>>well. It has some advantages over the scratchpad:
>>
>> - it does not "pollute" the main repository space
>> - it does not force others to download it
>>
>>The drawbacks are still present:
>>
>> - it hides the works a bit more than with scratchpad
>> - it does not get tested as with current scratchpad
>>
>>Actually, if we think aboyt it, it does not really hide things much more
>>than scratchpad. And as Stefano said, if one thing should be in Cocoon,
>>it has to be integrated in the core ASAP, I agree.
>>
>>So, to try and bring together all positions, by fulfilling the *needs*
>>with a new implementation, I would propose (taking some points from
>>Jeff's proposal):
>>
>> - Cocoon moves scratchpad to a new CVS module cocoon-sandbox
>> under cocoon-sandbox/src/java/**
>> - We move all alpha blocks to cocoon-sandbox/src/blocks/**
>> - we add Forrest-based documantation to teh scratchpad and
>> each block
>> - for every piece of alpha-quality code (block, scratchpad segment),
>> we could have a status file (as Tony Collen suggested) in the
>> documentation indicating things like:
>>
>> - code proposal initiators
>> - description (eg links to mailing list discussions)
>> - lease expiry
>>
>>
>>This will IMHO:
>>
>> - make alpha code clearly marked (I'm happy)
>> - keep possibility of sperimenting out of the core
>> (Jeff, Ovidiu and I are happy)
>> - keep sandbox out of main CVS module and make code
>> not rot (Stefano's happy)
>
>
> How about making one modification to this proposal...
>
> Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it
> cocoon-contrib or something.
>
> Why? Because then anyone can participate. It tears down any perceived
> barrier between cocoon-dev and cocoon-users. Best of all, when code
> eventually is 'promoted', there is a strong possibility of gaining new
> Cocoon developers. Think of it as housing "alpha committers" as well as
> "alpha code".
>
> The root problem is that Cocoon has more code than code maintainers. The
> long-term solution is not to juggle the code more effectively, but to
> gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
> would be a win in the long run.
>
> Thoughts?
Wow, it's the first time I see FS applied to community dynamics. You
guys keep surprising me :)
I want the scratchpad out of the main cocoon CVS module (now
xml-cocoon2, in the future just 'cocoon').
Why? because I want to reduce the number of core dependencies we have
since the whole thing it's becoming unmanageable.
There are two sort of things in the scratchpad:
- alpha blocks
- alpha core stuff
I think we all agree in moving the scratchpad alpha blocks in the blocks
directory and mark them as alpha. we'll add a block descriptor file that
indicates their status and we'll be happy.
This leaves us with the alpha core stuff.
Many of you say that Schecoon would not have happened if it wasn't for
the scratchpad. I don't see this. Nobody helped Ovidiu and the scheme
syntax argument was discussed over email, not CVS. He proposed, we
commented, some disliked, some liked, some ignored, some backed up. The
fact that code development happened on our CVS did it really made a
difference?
Only one: we saw commit messages. We followed development.
Now, did you guys ever heard about a nice CVS concept called
"branching"? Ovidiu wanted to work on some cocoon internals, wanted to
have a place to try things and didn't want to step on our toes, so he
should have asked for a branch and we would have given it to him.
the scratchpad is a lazy version of the same concept, too bad that when
developers use branches the tend to go quickly to the point where they
can merge it with HEAD, unlike the scratchpad that is *already* in head,
so it will be picked up anyway by the release, even if marked sideways.
I want people to work on HEAD so that they feel the pressure and do a
better job.
If I refactored the build on a branch (or even worse, on another CVS
module), how many of you would have tried it out and debug it?
Martin Holz wrote:
> P.S : Improving the build system is really worth some temporary
> inconvenience. Thank you very much.
See?
Now, about the alpha-committers: the scratchpad creates one-man-shows
even if we know that our committers have an extensive log of being able
to work with others.
If you open up the gates to everyone, do you really think that this will
help finding new developers for this community? I strongly doubt it.
I'm positive it will generate tons of half-baked concepts and components
mockups, but it will reduce the filtering that community performs and
will remove the incentive for them to work harder to gain access to CVS.
The overall quality of code will be much lower and they will feel
confortable with this since nobody will (could) complain for political
correctness.
The result will be that we won't ship anything from that since we will
fear of insulting some of those one-man-shows.
So, at the end, you have simply created a poor-quality collection of
one-man dumped and half-baked efforts. Also known as the result of the
"Sourceforge Effect".
Sure, one of a thousands might be worth considering. But somebody will
have to spend his energy finding out which one of these is worthwile and
since cocoon users and devs will concentrate here, the amount of energy
to screen those efforts will be very low.
- 0 -
I continue to propose to kill the scratchpad for alpha core code without
creating an alternative.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
>>Hm... don't like this. The scratchpad would be to distant from the
>>cocoon itself.
>
> Yes, just like the Wiki docs are distant from the xdocs. Just like the
> Wiki, it could benefit from much wider participation.
agreed
<snip/>
>>Hm... don't understand why other rules should apply for the scratchpad
>>than for the "core project"?
>
> The core project's central rule is: only established committers can play.
> Nothing wrong with applying that to the scratchpad, if all you want to do
> is incubate code.
>
> I'm thinking, why not discard that rule for the sandbox, and use it to
> incubate *committers* as well as code?
Hm...
>>I mean - everyone can start a sourceforge project and see if it works
>>out and later contribute/offer the code to the cocoon project.
>
> Yes. Imagine if someone on cocoon-users started an umbrella project on
> SF for useful Cocoon snippets. Wouldn't this also be a logical place for
> alpha Cocoon stuff?
Well, depends if we still would have a scratchpad/sandbox at apache ;)
>>>sandbox.cocoondev.org?
>>
>>I think the scratchpad/sandbox should remain in the apache cvs!
>
> :) Just throwing around ideas..
:)
But what I fear is that the relation to the cocoon project is much
looser and less visible. People will tend to forget about this area even
more. And opening the scratchpad to a wider audience means more people
and (at least) *could* result in even a bigger mess. And this is not
because of the people but due to the nature the scratchpad code. It's
code that is not yet ready for prime time and that usually was started
as a one man show. It is not felt as community code therefor has a much
higher probability to end up as dead code.
The only difference that I see is that this mess will not be inside the
cocoon repo.
If the relation would not matter.. Why did everyone put/kept the stuff
in scratchpad and did not move it over to cocoon-apps?
I see the scratchpad a little like a blackboard - the only thing we have
to do is to wipe it out from time to time ;)
--
Torsten
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 26, 2003 at 12:04:32PM +0100, Torsten Curdt wrote:
> <snip/>
>
> >>How about making one modification to this proposal...
> >>
> >>Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it
> >>cocoon-contrib or something.
> >
> >Hmmm...
>
> Hm... don't like this. The scratchpad would be to distant from the
> cocoon itself.
Yes, just like the Wiki docs are distant from the xdocs. Just like the
Wiki, it could benefit from much wider participation.
> >>Why? Because then anyone can participate. It tears down any perceived
> >>barrier between cocoon-dev and cocoon-users. Best of all, when code
> >>eventually is 'promoted', there is a strong possibility of gaining new
> >>Cocoon developers. Think of it as housing "alpha committers" as well as
> >>"alpha code".
>
> Hm... don't understand why other rules should apply for the scratchpad
> than for the "core project"?
The core project's central rule is: only established committers can play.
Nothing wrong with applying that to the scratchpad, if all you want to do
is incubate code.
I'm thinking, why not discard that rule for the sandbox, and use it to
incubate *committers* as well as code?
> >>The root problem is that Cocoon has more code than code maintainers. The
> >>long-term solution is not to juggle the code more effectively, but to
> >>gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
> >>would be a win in the long run.
>
> I mean - everyone can start a sourceforge project and see if it works
> out and later contribute/offer the code to the cocoon project.
Yes. Imagine if someone on cocoon-users started an umbrella project on
SF for useful Cocoon snippets. Wouldn't this also be a logical place for
alpha Cocoon stuff?
> >sandbox.cocoondev.org?
>
> I think the scratchpad/sandbox should remain in the apache cvs!
:) Just throwing around ideas..
--Jeff
> -1
> --
> Torsten
>
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
>> How about making one modification to this proposal...
>>
>> Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it
>> cocoon-contrib or something.
>
> Hmmm...
Hm... don't like this. The scratchpad would be to distant from the
cocoon itself.
>> Why? Because then anyone can participate. It tears down any perceived
>> barrier between cocoon-dev and cocoon-users. Best of all, when code
>> eventually is 'promoted', there is a strong possibility of gaining new
>> Cocoon developers. Think of it as housing "alpha committers" as well as
>> "alpha code".
Hm... don't understand why other rules should apply for the scratchpad
than for the "core project"?
>> The root problem is that Cocoon has more code than code maintainers. The
>> long-term solution is not to juggle the code more effectively, but to
>> gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
>> would be a win in the long run.
I mean - everyone can start a sourceforge project and see if it works
out and later contribute/offer the code to the cocoon project.
> sandbox.cocoondev.org?
I think the scratchpad/sandbox should remain in the apache cvs!
-1
--
Torsten
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 26/02/2003 10.39:
> On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
...
>>So, to try and bring together all positions, by fulfilling the *needs*
>>with a new implementation, I would propose (taking some points from
>>Jeff's proposal):
>>
>> - Cocoon moves scratchpad to a new CVS module cocoon-sandbox
>> under cocoon-sandbox/src/java/**
>> - We move all alpha blocks to cocoon-sandbox/src/blocks/**
>> - we add Forrest-based documantation to teh scratchpad and
>> each block
>> - for every piece of alpha-quality code (block, scratchpad segment),
>> we could have a status file (as Tony Collen suggested) in the
>> documentation indicating things like:
>>
>> - code proposal initiators
>> - description (eg links to mailing list discussions)
>> - lease expiry
>>
>>
>>This will IMHO:
>>
>> - make alpha code clearly marked (I'm happy)
>> - keep possibility of sperimenting out of the core
>> (Jeff, Ovidiu and I are happy)
>> - keep sandbox out of main CVS module and make code
>> not rot (Stefano's happy)
>
>
> How about making one modification to this proposal...
>
> Host the Cocoon sandbox at Sourceforge, instead of Apache. Call it
> cocoon-contrib or something.
Hmmm...
> Why? Because then anyone can participate. It tears down any perceived
> barrier between cocoon-dev and cocoon-users. Best of all, when code
> eventually is 'promoted', there is a strong possibility of gaining new
> Cocoon developers. Think of it as housing "alpha committers" as well as
> "alpha code".
It seems very interesting.
> The root problem is that Cocoon has more code than code maintainers. The
> long-term solution is not to juggle the code more effectively, but to
> gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
> would be a win in the long run.
>
> Thoughts?
sandbox.cocoondev.org?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Stefano Mazzocchi <st...@apache.org>.
Martin Holz wrote:
> A single cocoon sandbox on sourceforge would soon show the same bloat like cocoon.
I completely share this vision.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 26, 2003 at 03:02:50PM +0100, Martin Holz wrote:
> Jeff Turner <je...@apache.org> writes:
>
> > On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
> > Why? Because then anyone can participate. It tears down any perceived
> > barrier between cocoon-dev and cocoon-users. Best of all, when code
> > eventually is 'promoted', there is a strong possibility of gaining new
> > Cocoon developers. Think of it as housing "alpha committers" as well as
> > "alpha code".
> >
> > The root problem is that Cocoon has more code than code maintainers. The
> > long-term solution is not to juggle the code more effectively, but to
> > gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
> > would be a win in the long run.
>
> There is nothing, that stops you to start a cocoon based project at sourceforge
> right now. But I don't think, there should be no general coocon sandbox at
> sourceforge,because it would favor splitting the community and it would
> blur, which parts of cocoon belong to the cocoon core.
If it comes from Sourceforge, it's obviously not part of the core.
As for community, it depends on if your definition includes users. Mine
does, so I think it would actually help, by providing a common work area
where committers and non-committers can work on things together. A Wiki
for code.
> Sourceforge would be a great place for several specific projects, that
> use cocon,eg. a set of generators,transformers etcto transform Protein
> Data Bank (PDB) files as SVG and Chemical ML, or components to interact
> with SAP.
But in practice, no-one bothers to create new SF project for one or two
files.
> If those components are mature enough and of general interest, they can
> still move under the hood of ASF.
>
> A single cocoon sandbox on sourceforge would soon show the same bloat
> like cocoon.
As with Cocoon, bloat can be managed. In any case, a SF module bloated
with code snippets is better than nothing, which is what we have now.
--Jeff
> Martin
>
>
>
>
Re: Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Martin Holz <ho...@fiz-chemie.de>.
Jeff Turner <je...@apache.org> writes:
> On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
> Why? Because then anyone can participate. It tears down any perceived
> barrier between cocoon-dev and cocoon-users. Best of all, when code
> eventually is 'promoted', there is a strong possibility of gaining new
> Cocoon developers. Think of it as housing "alpha committers" as well as
> "alpha code".
>
> The root problem is that Cocoon has more code than code maintainers. The
> long-term solution is not to juggle the code more effectively, but to
> gain more committers. THAT is why I think a cocoon-contrib @ sourceforge
> would be a win in the long run.
There is nothing, that stops you to start a cocoon based project at sourceforge
right now. But I don't think, there should be no general coocon sandbox at
sourceforge,because it would favor splitting the community and it would
blur, which parts of cocoon belong to the cocoon core.
Sourceforge would be a great place for several specific projects, that use cocon,eg. a set of
generators,transformers etcto transform Protein Data Bank (PDB) files as SVG and Chemical ML,
or components to interact with SAP.
If those components are mature enough and of general interest, they can still move under
the hood of ASF.
A single cocoon sandbox on sourceforge would soon show the same bloat like cocoon.
Martin