Scratchpad

[Stefano Mazzocchi <st...@apache.org>]

We still haven't reached consensus on this issue and I think that we 
also mixed concerns in the previous threads. I see several issues on the 
table:

1) how to allow committers to innovate on core
2) how to allow committers to innovate on non-core stuff
3) how to allow non-committers to innovate

Please, let's try to keep them separate.

issue #3
--------

you earn commit access thru the usual apache meritocratic process: you 
show us you are committed to cocoon, you get commit access. This simple 
fact rules out the possibility to have any sandbox open to 
non-committers inside the space handled by the cocoon PMC.

But this does *NOT* rule out the possibility of having a cocoon sandbox 
(wiki-for-code as Jeff brilliantly put it) somewhere else (cocoondev.org 
or sourceforge.net).

anyway, this is something totally orthogonal to our scratchpad concept 
and it's up to the people that want this to happen.

Personally, I don't care enough to help, there is already enough stuff 
to do for core.

issue #1 & #2
-------------

I'm beginning to think that it's pretty accademic to talk about removing 
something without trying to clean it up first.

So, I propose to try to cleanup the scratchpad as much as possible and 
see what's left, as for Nicola suggestion. Of course, help from the code 
authors will be *VERY* appreciated.

At that point, we'll decide whether to keep the scratchpad or not and, 
in case, create some policies about it.

Deal?

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Scratchpad

[Niclas Hedhman <ni...@hedhman.org>]

On Thursday 27 February 2003 01:36, Stefano Mazzocchi wrote:
> We still haven't reached consensus on this issue and I think that we
> also mixed concerns in the previous threads. I see several issues on the
> table:
>
> 1) how to allow committers to innovate on core
> 2) how to allow committers to innovate on non-core stuff

NTIARS, but isn't "core" also a bit wider than necessary, and with a better 
layer system the "core" would be rather tiny, and everything else is 
pluggable, in which case "innovation" can come very naturally.
The "plug-ins" / "add-ons" should perhaps even get their own repositories and 
release cycles (SM: A species concept forming.).

The next issues would then be, "What is standard distro?", "How many Add-Ons 
are directly supported?", "How is this achieved to the convenience of the 
user?"


Niclas

Re: Scratchpad

[Nicola Ken Barozzi <ni...@apache.org>]

Stefano Mazzocchi wrote, On 26/02/2003 18.36:

> Deal?

Definately! :-)

+1

BTW, I have been proactive and deleted the wings scratchpad stuff 
before...  ahhh, how much I like that word, it fills one's mouth... 
proaaaacetive ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Scratchpad

[Berin Loritsch <bl...@apache.org>]

Stefano Mazzocchi wrote:
> We still haven't reached consensus on this issue and I think that we 
> also mixed concerns in the previous threads. I see several issues on the 
> table:
> 
> 1) how to allow committers to innovate on core

Anything in *core* needs community support.  This should not have
a scratchpad IMO.  Why?  The API needs to be clean.  The core is
what you are saying will be supported no matter what.  Therefore
the core needs to reflect what the community is willing to support.

> 2) how to allow committers to innovate on non-core stuff

This is where I think a sandbox/scratchpad would work if the community
wants it.  Blocks are *additions* to cocoon that anyone can use if they
choose to.  By defining how to write blocks and set them up and
incorporate them into your own projects, it makes it easier to maintain
a clean system.

> issue #1 & #2
> -------------
> 
> So, I propose to try to cleanup the scratchpad as much as possible and 
> see what's left, as for Nicola suggestion. Of course, help from the code 
> authors will be *VERY* appreciated.
> 
> At that point, we'll decide whether to keep the scratchpad or not and, 
> in case, create some policies about it.
> 
> Deal?

Sounds good.