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 |
*-----------------------------------------------------*
