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 05:57:51 UTC
Scratchpad leases (Re: [RT] what cocoon is doing wrong)
On Tue, Feb 25, 2003 at 05:37:07PM -0500, Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
...
> >>I repeat my proposal to kill the scratchpad
> >
> >
> >Hmmm... how could we have done the flow without the scratchpad?
> >Do you really think that Schecoon could have been done in head?
> >
> >Make the scratchpad-blocks dir, and that will automatically solve many
> >of these problems and clear the scratchpad.
> >
> >Let's KISS. Let's start with the obvious. Move the scratchpad into
> >scratchpad-blocks and see what's left. We may be surprised.
+1
...
> What would removal of the Scratchpad force on the community?
>
> * More controlled innovation. Instead of anybody using it as their
> personal playground, it would force the development to be more in
> the face of the community.
Hence schecoon would have been shot down in flames, as people -1'ed it on
the syntax.
> * Better concept of exactly what is in Cocoon. After not being active
> for a while and comming back, I don't even recognize the project.
> How many of the current developers know *all* of what is in the
> CVS archive?
Why would anyone not interested look in the scratchpad?
> * If the community doesn't want to support it, move it someplace else.
> IOW if the community doesn't want some code in the main trunk it is
> for a very good reason. The proposing developer would be encouraged
> to incubate the project elsewhere.
Playgrounds *have* to exist. The question is, do they happen in the
scratchpad or on someone's hard disk. At least in the scratchpad, there
is a chance of half-baked code inspiring others, and forming a nucleus
for further development.
I agree, there is a real problem in that scratchpad code tends to hang
around in limbo forever, never accepted nor rejected.
So how about assigning each scratchpad module a "lease"; being a
predefined period (say 3 months) after which the code's presence in CVS
must be reviewed. When the lease expires, a vote is held, and the code
either becomes official, or is rejected, or has the lease renewed.
For every unit of alpha-quality code (block, scratchpad segment), we
could have a status file (as Tony Collen suggested) indicating things
like:
- code owners (cocoon-dev is not the owner yet)
- description (eg links to mailing list discussions)
- lease expiry
Managed inclusion rather than exclusion.
--Jeff
Re: Scratchpad leases (Re: [RT] what cocoon is doing wrong)
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
>
>>What would removal of the Scratchpad force on the community?
>>
>>* More controlled innovation. Instead of anybody using it as their
>> personal playground, it would force the development to be more in
>> the face of the community.
>
>
> Hence schecoon would have been shot down in flames, as people -1'ed it on
> the syntax.
;P All revolutionary ideas are like that. What would likely have
happened is that the interested parties would have incubated it
elsewhere--perhaps on SourceForge. Knowing the authors' temporament
as they stuck with it, they would have kept in constant contact.
At a later time when everybody "got it", it would most likely have
been incorporated into the main trunk like it is now.
>
>
>>* Better concept of exactly what is in Cocoon. After not being active
>> for a while and comming back, I don't even recognize the project.
>> How many of the current developers know *all* of what is in the
>> CVS archive?
>
>
> Why would anyone not interested look in the scratchpad?
Which is exactly the point.
>
>
>>* If the community doesn't want to support it, move it someplace else.
>> IOW if the community doesn't want some code in the main trunk it is
>> for a very good reason. The proposing developer would be encouraged
>> to incubate the project elsewhere.
>
>
> Playgrounds *have* to exist. The question is, do they happen in the
> scratchpad or on someone's hard disk. At least in the scratchpad, there
> is a chance of half-baked code inspiring others, and forming a nucleus
> for further development.
Or on SourceForge? It would be actually more healthy for this project
if there were a bunch of projects that depended on it and incorporated
themselves into it. Right now we have rampant inbreeding and bloating
of the project.
> I agree, there is a real problem in that scratchpad code tends to hang
> around in limbo forever, never accepted nor rejected.
>
> So how about assigning each scratchpad module a "lease"; being a
> predefined period (say 3 months) after which the code's presence in CVS
> must be reviewed. When the lease expires, a vote is held, and the code
> either becomes official, or is rejected, or has the lease renewed.
>
> For every unit of alpha-quality code (block, scratchpad segment), we
> could have a status file (as Tony Collen suggested) indicating things
> like:
> - code owners (cocoon-dev is not the owner yet)
> - description (eg links to mailing list discussions)
> - lease expiry
>
> Managed inclusion rather than exclusion.
Playgrounds/Scratchpads etc. have a set of challenges surrounding them
that not everyone is aware of. How do you manage CVS access? It may be
that someone has a great idea that needs some incubation, but they have
not proven themselves for Cocoon CVS access rights yet. Do you grant it
to them? What happens when you have people making comments like "my
new module" or "my code does this"? That is a subtle anti-community
sentiment that builds when there is a "scratchpad" section in a greater
CVS archive. These issues need to be dealt with as they are more
damaging than bad code in the CVS.
If anything is in Cocoon's CVS archive it MUST have community ownership,
and community support.
If you want to dedicate another CVS archive or a SourceForge account
to incubating these things, that would be a better ideal IMNSHO.
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
Cocoon sandbox @ Sourceforge? (Re: [Proposal] Cocoon Sandbox)
Posted by Jeff Turner <je...@apache.org>.
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: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 26/02/2003 13.44:
> Jeremy Quinn wrote:
...
>> I personally feel that the 'slash-edit' project in scratchpad is due
>> for removal.
>>
>> It was a nice idea, and a few people did stuff with it, but as an idea
>> for how to build an editor is is (I hope) obsolete.
>>
>> We need to be looking at FlowScript + XForms and FlowScript + Xopus IMHO.
>
> I agree. So go ahead and blast it.
I used it to start the editing stuff in Forrest, and simplified it.
So if anyone is interested we can continue there and add the nice things
you talk about :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, February 26, 2003, at 01:26 PM, Jeremy Quinn wrote:
>
> On Wednesday, February 26, 2003, at 12:44 PM, Stefano Mazzocchi wrote:
>
>> Jeremy Quinn wrote:
>>> On Wednesday, February 26, 2003, at 10:53 AM, Torsten Curdt wrote:
>>>>>>>> Let's KISS. Let's start with the obvious. Move the scratchpad
>>>>>>>> into scratchpad-blocks and see what's left. We may be >>>>>>>> surprised.
>>>>>>
>>>>>> +1
>>>>
>>>>
>>>> The only problem I see is that not everything is "worth" a whole
>>>> block.
>>> I personally feel that the 'slash-edit' project in scratchpad is due
>>> for removal.
>>> It was a nice idea, and a few people did stuff with it, but as an
>>> idea for how to build an editor is is (I hope) obsolete.
>>> We need to be looking at FlowScript + XForms and FlowScript + Xopus
>>> IMHO.
>>
>> I agree. So go ahead and blast it.
>
> I will TRY
Done (I think ....)
regards Jeremy
Re: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, February 26, 2003, at 12:44 PM, Stefano Mazzocchi wrote:
> Jeremy Quinn wrote:
>> On Wednesday, February 26, 2003, at 10:53 AM, Torsten Curdt wrote:
>>>>>>> Let's KISS. Let's start with the obvious. Move the scratchpad
>>>>>>> into scratchpad-blocks and see what's left. We may be surprised.
>>>>>
>>>>> +1
>>>
>>>
>>> The only problem I see is that not everything is "worth" a whole
>>> block.
>> I personally feel that the 'slash-edit' project in scratchpad is due
>> for removal.
>> It was a nice idea, and a few people did stuff with it, but as an
>> idea for how to build an editor is is (I hope) obsolete.
>> We need to be looking at FlowScript + XForms and FlowScript + Xopus
>> IMHO.
>
> I agree. So go ahead and blast it.
I will TRY
regards Jeremy
Re: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> On Wednesday, February 26, 2003, at 10:53 AM, Torsten Curdt wrote:
>
>>>>>> Let's KISS. Let's start with the obvious. Move the scratchpad into
>>>>>> scratchpad-blocks and see what's left. We may be surprised.
>>>>
>>>> +1
>>
>>
>> The only problem I see is that not everything is "worth" a whole block.
>
>
> I personally feel that the 'slash-edit' project in scratchpad is due for
> removal.
>
> It was a nice idea, and a few people did stuff with it, but as an idea
> for how to build an editor is is (I hope) obsolete.
>
> We need to be looking at FlowScript + XForms and FlowScript + Xopus IMHO.
I agree. So go ahead and blast it.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, February 26, 2003, at 10:53 AM, Torsten Curdt wrote:
>>>>> Let's KISS. Let's start with the obvious. Move the scratchpad into
>>>>> scratchpad-blocks and see what's left. We may be surprised.
>>> +1
>
> The only problem I see is that not everything is "worth" a whole block.
I personally feel that the 'slash-edit' project in scratchpad is due
for removal.
It was a nice idea, and a few people did stuff with it, but as an idea
for how to build an editor is is (I hope) obsolete.
We need to be looking at FlowScript + XForms and FlowScript + Xopus
IMHO.
regards Jeremy
Re: [Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Torsten Curdt <tc...@dff.st>.
>>>> Let's KISS. Let's start with the obvious. Move the scratchpad into
>>>> scratchpad-blocks and see what's left. We may be surprised.
>> +1
The only problem I see is that not everything is "worth" a whole block.
>> Why would anyone not interested look in the scratchpad?
Well, I bet everyone is... but as a matter of fact it is hard to keep
track - especially because scratchpad components used to have even less
documentation ;) "how does this thingy work?"
>> Playgrounds *have* to exist. The question is, do they happen in the
>> scratchpad or on someone's hard disk. At least in the scratchpad, there
>> is a chance of half-baked code inspiring others, and forming a nucleus
>> for further development.
>
>
> +q
q? :)
+1
>> I agree, there is a real problem in that scratchpad code tends to hang
>> around in limbo forever, never accepted nor rejected.
>>
>> So how about assigning each scratchpad module a "lease"; being a
>> predefined period (say 3 months) after which the code's presence in CVS
>> must be reviewed. When the lease expires, a vote is held, and the code
>> either becomes official, or is rejected, or has the lease renewed.
>>
>> For every unit of alpha-quality code (block, scratchpad segment), we
>> could have a status file (as Tony Collen suggested) indicating things
>> like:
>> - code owners (cocoon-dev is not the owner yet)
>> - description (eg links to mailing list discussions)
>> - lease expiry
>>
>> Managed inclusion rather than exclusion.
>
> Yes, this sentence is a good explanation :-)
+1 a lease is a good idea!
> I have slept over it, and I start to feel that Stefano implies that all
> that is in xml-cocoon2 is Cocoon... which of course is the most obvious
> thing.
>
> 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
+1 for a sandbox!
> The drawbacks are still present:
>
> - it hides the works a bit more than with scratchpad
> - it does not get tested as with current scratchpad
hm... as long as the build system has a good integration we shouldn't
notice any difference beside having it in a different location.
> So, does this make sense?
totally!
+1 for the sandbox
--
Torsten
[Proposal] Cocoon Sandbox ( Re: Scratchpad leases )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 26/02/2003 5.57:
> On Tue, Feb 25, 2003 at 05:37:07PM -0500, Berin Loritsch wrote:
>
>>Nicola Ken Barozzi wrote:
...
>>>Let's KISS. Let's start with the obvious. Move the scratchpad into
>>>scratchpad-blocks and see what's left. We may be surprised.
>
> +1
>
> ...
>>What would removal of the Scratchpad force on the community?
>>
>>* More controlled innovation. Instead of anybody using it as their
>> personal playground, it would force the development to be more in
>> the face of the community.
>
> Hence schecoon would have been shot down in flames, as people -1'ed it on
> the syntax.
exactly.
>>* Better concept of exactly what is in Cocoon. After not being active
>> for a while and comming back, I don't even recognize the project.
>> How many of the current developers know *all* of what is in the
>> CVS archive?
>
> Why would anyone not interested look in the scratchpad?
And to reply to the first question of this section: what is Cocoon?
Cocoon is in src/blocks and src/java. That is Cocoon. Or at least it
should be... se below.
>>* If the community doesn't want to support it, move it someplace else.
>> IOW if the community doesn't want some code in the main trunk it is
>> for a very good reason. The proposing developer would be encouraged
>> to incubate the project elsewhere.
>
> Playgrounds *have* to exist. The question is, do they happen in the
> scratchpad or on someone's hard disk. At least in the scratchpad, there
> is a chance of half-baked code inspiring others, and forming a nucleus
> for further development.
+q
> I agree, there is a real problem in that scratchpad code tends to hang
> around in limbo forever, never accepted nor rejected.
>
> So how about assigning each scratchpad module a "lease"; being a
> predefined period (say 3 months) after which the code's presence in CVS
> must be reviewed. When the lease expires, a vote is held, and the code
> either becomes official, or is rejected, or has the lease renewed.
>
> For every unit of alpha-quality code (block, scratchpad segment), we
> could have a status file (as Tony Collen suggested) indicating things
> like:
> - code owners (cocoon-dev is not the owner yet)
> - description (eg links to mailing list discussions)
> - lease expiry
>
> Managed inclusion rather than exclusion.
Yes, this sentence is a good explanation :-)
I have slept over it, and I start to feel that Stefano implies that all
that is in xml-cocoon2 is Cocoon... which of course is the most obvious
thing.
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)
So, does this make sense?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Scratchpad leases (Re: [RT] what cocoon is doing wrong)
Posted by Ovidiu Predescu <ov...@apache.org>.
On Tuesday, Feb 25, 2003, at 20:57 US/Pacific, Jeff Turner wrote:
>> What would removal of the Scratchpad force on the community?
>>
>> * More controlled innovation. Instead of anybody using it as their
>> personal playground, it would force the development to be more in
>> the face of the community.
>
> Hence schecoon would have been shot down in flames, as people -1'ed it
> on
> the syntax.
I definitely agree here!
>> * If the community doesn't want to support it, move it someplace else.
>> IOW if the community doesn't want some code in the main trunk it is
>> for a very good reason. The proposing developer would be encouraged
>> to incubate the project elsewhere.
>
> Playgrounds *have* to exist. The question is, do they happen in the
> scratchpad or on someone's hard disk. At least in the scratchpad,
> there
> is a chance of half-baked code inspiring others, and forming a nucleus
> for further development.
>
> I agree, there is a real problem in that scratchpad code tends to hang
> around in limbo forever, never accepted nor rejected.
>
> So how about assigning each scratchpad module a "lease"; being a
> predefined period (say 3 months) after which the code's presence in CVS
> must be reviewed. When the lease expires, a vote is held, and the code
> either becomes official, or is rejected, or has the lease renewed.
>
> For every unit of alpha-quality code (block, scratchpad segment), we
> could have a status file (as Tony Collen suggested) indicating things
> like:
> - code owners (cocoon-dev is not the owner yet)
> - description (eg links to mailing list discussions)
> - lease expiry
>
> Managed inclusion rather than exclusion.
+1
We do need a place for people to experiment with ideas, and the
scratchpad is a good place.
Cheers,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://www.google.com/search?btnI=&q=ovidiu (I'm feeling lucky)