Re: [VOTE] Initial Proposal - Re: Consensus ?

[Peter Donald <do...@apache.org>]

Hi,

Not to be a stick in the mud but ... what this sounds like is Avalon ;) It
is true that most discussion on Avalon is concerned about the
pattern/framework (or more specifically the kernel aspect of the previous).
However what is proposed is still overlapping with Avalon stated purpose
(ie place where server components for Apache are located). Damn I feel like
a broken record here.

Perhaps it is better to analyze the infrastructure rather than the content.
Many seem to want a CJAN distribution system for use both internally and
externally to apache. CJAN would serve as a distribution point for
products. Add a directory on top of CJAN and you have a catalog.
Standardize the layout/structure/testing/gumpiness/whatever of each product
and your a few more steps in the right direction. So I see
Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
discussion.

Another point identified is the need for a scratch pad CVS for giving birth
to new components.

Another point is shared CVS access - lets call this the Commons.

So we have the Scaffold, the ScratchPad and the Commons. All of these are
infrastructure points rather than content. Leaving aside Commons for the
moment, the other two should be integrated into all projects IMHO. Some
projects allow ScratchPad work to occur in main CVS tree, others use
branches, whiteboard directories, proposal directories and contrib
directories. The Scaffold would benefit all jakarta projects.

The Commons is something I would like to see aswell but there does not seem
to be a lot of support for it aside from Sam at the momment ;)

So now onto content. 

Does this project overlap with Avalons stated purpose? Largely it is
identical. Provide a place to share server-side components between Apache
projects. You could complain that Avalon is too integrated or too
frameworky then there is a perfect place to start fixing it ;) My concern
is that with two projects with identical purposes is going to cause a
little confusion. Worse yet I have a feeling that it may be possible that
the same issues/mistakes/problems that occur within Avalon will occur
within this project. I think Sam referred to Avalon as the eternal alpha
project (IIRC it has been around for about 3 years and is only starting to
stabilize recently). 

Speaking for myself (and not for Avalon group) I would love to see a
flattening of CVS access and allow an area to develope and maintain these
different components within Avalon. I don't care about the politics of each
component - as long as they are labeled as STABLE/ALPHA/BETA/whatever and
stick to it. 

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] Initial Proposal - Re: Consensus ?

[Peter Donald <do...@apache.org>]

At 07:08  28/2/01 -0800, David Weinrich wrote:
>> So we have the Scaffold, the ScratchPad and the Commons. All of these are
>> infrastructure points rather than content.
>
>I absolutely agree if you switch /content/products/ and swap some names
>around ;). Essentially the Commons Project is an infrastructure of support
>services for jakarta ( my vision at least... YVMV ). Having it as a
>seperate project helps us develop the methods and processes to do this in
>a way that doesn't intrude upon the internal development of the jakarta
>projects. As the project develops and services mature, projects can start
>using them for what they are without disturbing what exists within that
>project.

+10000 ;)

>> Leaving aside Commons for the
>> moment, the other two should be integrated into all projects IMHO. Some
>> projects allow ScratchPad work to occur in main CVS tree, others use
>> branches, whiteboard directories, proposal directories and contrib
>> directories. The Scaffold would benefit all jakarta projects.
>>
>
>I agree and disagree at the same time. If by integrate you mean 'can be
>used by all projects as they see fit' I agree. If you mean 'will each
>implement in their own way' I disagree. Part of what I think this project
>provides is some of the support services/infrastructure to do these things
>without forcing each project to do them on their own ( reuse on a human
>resources scale if you want to look at it that way). In a way it is a
>place for myself and people who want to contribute *something* but lack
>the expertise to build a framework product to contribute to the jakarta
>project in a way that benefits all of the project. To push the library
>image a bit too far... I don't mind being the person that fills the card
>catalog and puts the books back on the shelves if the project on the
>whole needs that work done and it will free up the people who *don't*
>want to have to do that on but end up doing them anyways out of necessity.

A little bit of push and a little bit of pull would be what I advocate.
Take gump - it is mainly Sams iniative but by sending out mails saying
(your code is broken!!!) it motivates the committers to make changes and
integrate gumps ways into their own ;) Hopefully when Gump includes unit
testing it may be possible to give even more exhaustive feedback to
different groups. In time gump could also notify upstream providers when a
change they make breaks downstream users. it could also integrate things
like statistics and metrics. All of these features are mostly implemented
by Sam but it also should form a feedback loop so that the committers of
each project collaborate more.


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] Initial Proposal - Re: Consensus ?

[Peter Donald <do...@apache.org>]

At 07:08  28/2/01 -0800, David Weinrich wrote:
>> So we have the Scaffold, the ScratchPad and the Commons. All of these are
>> infrastructure points rather than content.
>
>I absolutely agree if you switch /content/products/ and swap some names
>around ;). Essentially the Commons Project is an infrastructure of support
>services for jakarta ( my vision at least... YVMV ). Having it as a
>seperate project helps us develop the methods and processes to do this in
>a way that doesn't intrude upon the internal development of the jakarta
>projects. As the project develops and services mature, projects can start
>using them for what they are without disturbing what exists within that
>project.

+10000 ;)

>> Leaving aside Commons for the
>> moment, the other two should be integrated into all projects IMHO. Some
>> projects allow ScratchPad work to occur in main CVS tree, others use
>> branches, whiteboard directories, proposal directories and contrib
>> directories. The Scaffold would benefit all jakarta projects.
>>
>
>I agree and disagree at the same time. If by integrate you mean 'can be
>used by all projects as they see fit' I agree. If you mean 'will each
>implement in their own way' I disagree. Part of what I think this project
>provides is some of the support services/infrastructure to do these things
>without forcing each project to do them on their own ( reuse on a human
>resources scale if you want to look at it that way). In a way it is a
>place for myself and people who want to contribute *something* but lack
>the expertise to build a framework product to contribute to the jakarta
>project in a way that benefits all of the project. To push the library
>image a bit too far... I don't mind being the person that fills the card
>catalog and puts the books back on the shelves if the project on the
>whole needs that work done and it will free up the people who *don't*
>want to have to do that on but end up doing them anyways out of necessity.

A little bit of push and a little bit of pull would be what I advocate.
Take gump - it is mainly Sams iniative but by sending out mails saying
(your code is broken!!!) it motivates the committers to make changes and
integrate gumps ways into their own ;) Hopefully when Gump includes unit
testing it may be possible to give even more exhaustive feedback to
different groups. In time gump could also notify upstream providers when a
change they make breaks downstream users. it could also integrate things
like statistics and metrics. All of these features are mostly implemented
by Sam but it also should form a feedback loop so that the committers of
each project collaborate more.


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] Initial Proposal - Re: Consensus ?

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001, Peter Donald wrote:

> Hi,
>
> Not to be a stick in the mud but ...

S'Ok, I'll be a stick in the mud too... :)

> what this sounds like is Avalon ;) It
> is true that most discussion on Avalon is concerned about the
> pattern/framework (or more specifically the kernel aspect of the previous).
> However what is proposed is still overlapping with Avalon stated purpose
> (ie place where server components for Apache are located). Damn I feel like
> a broken record here.
>
> Perhaps it is better to analyze the infrastructure rather than the content.
> Many seem to want a CJAN distribution system for use both internally and
> externally to apache. CJAN would serve as a distribution point for
> products. Add a directory on top of CJAN and you have a catalog.
> Standardize the layout/structure/testing/gumpiness/whatever of each product
> and your a few more steps in the right direction. So I see
> Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
> discussion.

This is what I identified as the Catalog Service/Dewey in a recent email (
just so I can match up the ideas with each of the names we are using )

>
> Another point identified is the need for a scratch pad CVS for giving birth
> to new components.
>
> Another point is shared CVS access - lets call this the Commons.
>

These two are what we have discussed as the Agora Service ( aka sandbox
and whatnot ) and they are pretty much rolled in together. The scratch pad
is facilitated by shared CVS access, and the development of tools is
facilitated by both so...

The 'Commons' is the word I proposed to denote the project as a whole, a
collection of services that facilitate re-use and shared components/code
between projects.

> So we have the Scaffold, the ScratchPad and the Commons. All of these are
> infrastructure points rather than content.

I absolutely agree if you switch /content/products/ and swap some names
around ;). Essentially the Commons Project is an infrastructure of support
services for jakarta ( my vision at least... YVMV ). Having it as a
seperate project helps us develop the methods and processes to do this in
a way that doesn't intrude upon the internal development of the jakarta
projects. As the project develops and services mature, projects can start
using them for what they are without disturbing what exists within that
project.

> Leaving aside Commons for the
> moment, the other two should be integrated into all projects IMHO. Some
> projects allow ScratchPad work to occur in main CVS tree, others use
> branches, whiteboard directories, proposal directories and contrib
> directories. The Scaffold would benefit all jakarta projects.
>

I agree and disagree at the same time. If by integrate you mean 'can be
used by all projects as they see fit' I agree. If you mean 'will each
implement in their own way' I disagree. Part of what I think this project
provides is some of the support services/infrastructure to do these things
without forcing each project to do them on their own ( reuse on a human
resources scale if you want to look at it that way). In a way it is a
place for myself and people who want to contribute *something* but lack
the expertise to build a framework product to contribute to the jakarta
project in a way that benefits all of the project. To push the library
image a bit too far... I don't mind being the person that fills the card
catalog and puts the books back on the shelves if the project on the
whole needs that work done and it will free up the people who *don't*
want to have to do that on but end up doing them anyways out of necessity.


> The Commons is something I would like to see aswell but there does not seem
> to be a lot of support for it aside from Sam at the momment ;)
>
> So now onto content.
>
> Does this project overlap with Avalons stated purpose? Largely it is
> identical. Provide a place to share server-side components between Apache
> projects. You could complain that Avalon is too integrated or too
> frameworky then there is a perfect place to start fixing it ;) My concern
> is that with two projects with identical purposes is going to cause a
> little confusion. Worse yet I have a feeling that it may be possible that
> the same issues/mistakes/problems that occur within Avalon will occur
> within this project. I think Sam referred to Avalon as the eternal alpha
> project (IIRC it has been around for about 3 years and is only starting to
> stabilize recently).

Here is my take on this: Avalon is a pre-existing project that has
something of a mixed/varying purpose. From the outside the project appears
to be a framework/kernel/system of developing server software in java.

Re: [VOTE] Initial Proposal - Re: Consensus ?

[David Weinrich <dw...@home.com>]

On Thu, 1 Mar 2001, Peter Donald wrote:

> Hi,
>
> Not to be a stick in the mud but ...

S'Ok, I'll be a stick in the mud too... :)

> what this sounds like is Avalon ;) It
> is true that most discussion on Avalon is concerned about the
> pattern/framework (or more specifically the kernel aspect of the previous).
> However what is proposed is still overlapping with Avalon stated purpose
> (ie place where server components for Apache are located). Damn I feel like
> a broken record here.
>
> Perhaps it is better to analyze the infrastructure rather than the content.
> Many seem to want a CJAN distribution system for use both internally and
> externally to apache. CJAN would serve as a distribution point for
> products. Add a directory on top of CJAN and you have a catalog.
> Standardize the layout/structure/testing/gumpiness/whatever of each product
> and your a few more steps in the right direction. So I see
> Catalog/CJAN/Gump as one infrastructure point - lets call this Scaffold for
> discussion.

This is what I identified as the Catalog Service/Dewey in a recent email (
just so I can match up the ideas with each of the names we are using )

>
> Another point identified is the need for a scratch pad CVS for giving birth
> to new components.
>
> Another point is shared CVS access - lets call this the Commons.
>

These two are what we have discussed as the Agora Service ( aka sandbox
and whatnot ) and they are pretty much rolled in together. The scratch pad
is facilitated by shared CVS access, and the development of tools is
facilitated by both so...

The 'Commons' is the word I proposed to denote the project as a whole, a
collection of services that facilitate re-use and shared components/code
between projects.

> So we have the Scaffold, the ScratchPad and the Commons. All of these are
> infrastructure points rather than content.

I absolutely agree if you switch /content/products/ and swap some names
around ;). Essentially the Commons Project is an infrastructure of support
services for jakarta ( my vision at least... YVMV ). Having it as a
seperate project helps us develop the methods and processes to do this in
a way that doesn't intrude upon the internal development of the jakarta
projects. As the project develops and services mature, projects can start
using them for what they are without disturbing what exists within that
project.

> Leaving aside Commons for the
> moment, the other two should be integrated into all projects IMHO. Some
> projects allow ScratchPad work to occur in main CVS tree, others use
> branches, whiteboard directories, proposal directories and contrib
> directories. The Scaffold would benefit all jakarta projects.
>

I agree and disagree at the same time. If by integrate you mean 'can be
used by all projects as they see fit' I agree. If you mean 'will each
implement in their own way' I disagree. Part of what I think this project
provides is some of the support services/infrastructure to do these things
without forcing each project to do them on their own ( reuse on a human
resources scale if you want to look at it that way). In a way it is a
place for myself and people who want to contribute *something* but lack
the expertise to build a framework product to contribute to the jakarta
project in a way that benefits all of the project. To push the library
image a bit too far... I don't mind being the person that fills the card
catalog and puts the books back on the shelves if the project on the
whole needs that work done and it will free up the people who *don't*
want to have to do that on but end up doing them anyways out of necessity.


> The Commons is something I would like to see aswell but there does not seem
> to be a lot of support for it aside from Sam at the momment ;)
>
> So now onto content.
>
> Does this project overlap with Avalons stated purpose? Largely it is
> identical. Provide a place to share server-side components between Apache
> projects. You could complain that Avalon is too integrated or too
> frameworky then there is a perfect place to start fixing it ;) My concern
> is that with two projects with identical purposes is going to cause a
> little confusion. Worse yet I have a feeling that it may be possible that
> the same issues/mistakes/problems that occur within Avalon will occur
> within this project. I think Sam referred to Avalon as the eternal alpha
> project (IIRC it has been around for about 3 years and is only starting to
> stabilize recently).

Here is my take on this: Avalon is a pre-existing project that has
something of a mixed/varying purpose. From the outside the project appears
to be a framework/kernel/system of developing server software in java.