Re: Project structure

[Jim Marino]

On Mar 21, 2006, at 6:56 AM, rick rineholt wrote:
Maybe there is a middle ground here and all that was
missing was better
communications when contributers plan to add new items
to the main stream build
without the needed overhead of having rigid rules
(sandboxes / separate builds
etc) in place for this?  Adding all of these can in
and of it self make it more
difficult for new commiters to come on board.
I'm not saying there should be separate builds. I just think there  
should be a sandbox where contributions first go. I actually think  
this makes it easier to come on board since standards there are  
laxer, e.g. test coverage, people working on new contributions can  
break things in the sandbox without having to worry about the main  
build, etc. It also help discussion for coming into the main line  
since code can be pointed to. I don't think the rules I mentioned in  
the prior post are onerous.  Let me know if you think they are.

Developers are always free to
place work in a sandbox first if they so chose to do
so.

I'm ok if we don't have everything in the main
developer build if and only if we
have a regular build system that does, so when things
are broken we are aware
and committed to fixing them.

I think this is covered by having the build deal with things in  
contrib, right?

I do second the notion by Sebastien that we should
strive to maintain at the
HEAD of the repository a working version of Tuscany
and it's samples.  IMO, as
painful as it it might be if you plan on work that is
to knowingly break this
for any length of time and you need to check in to
work with others we really
should either create a branch and work on it there or
clearly communicate to the
community the intent to do so and allow some
opportunity to discuss it.

Why not tag a version as stable and tell people to use that one (with  
pointers on how to check it out and build)? I think this would be in  
addition to discussions prior to an intentional break.

I think some of the sample break mess in the past was caused/ 
exacerbated by the following factors:

1. One time we purposely broke the build and discussed it on the list  
prior. In hindsight, I believe this was the correct decision

2. Some other times the build has broken can be traced to poor test  
coverage. I don't think we can have developers start up the samples  
and run them for every check-in, particularly as the number of  
deployment platforms (e.g. Tomcat, Geronimo, OSGi, Celtix, etc.)  
increases. We should have integration tests that are run on the  
developer's box before check-in that cover as much of this as  
possible. Jeremy did a bunch of work for Tomcat in this respect. We  
probably should also consider a continuous build system.  Celtix has  
a interesting system in place so we should have them relate their  
experiences.

3. I believe there we some other times such as the classloader issue  
where the problem was only detectable by running the samples. Perhaps  
tagging certain versions as stable (rather than assuming head is  
always stable) will help with this?

Jim Marino wrote:


On Mar 20, 2006, at 11:45 PM, ant elder wrote:


On 3/21/06, James F Marino <[EMAIL PROTECTED]>

wrote:


<snip/>

3. I would like to see a process where

contributions first go into a



sandbox and are worked on for some time prior to

being put in

extensions. It would be good to have a discussion

(not a vote) before

that move is made ( i.e. to extensions). I think

this is reasonably

"lightweight" and offers a way to get people to

contribute with no bar

(the sandbox).




I'm -1 on this, at least while its so vague.

Exactly how long must

things
be in the sandbox and specifically what must be

achieved before it can be

promoted?



There should not be a precise time limit - these

things should work on a

case-by-case basis. I think there are some common

sense rules that may

be applied like:

1. Does the contribution mesh with the goals set by

the community for

the project? While the goals may change over time, I

think the incubator

proposal is adequate for now in defining them.

2. Does the contribution have support by commiters

to maintain it? I

think this is shown by having things such as

adequate testing and

documentation. One commiter may be enough to

accomplish this.


3. Is the code sufficiently complete to demonstrate

useful functionality?


These rules seem pretty flexible and basic to me.

For example, I would

probably not accept a patch that did not have

adequate test coverage. We

should apply these same standards to ourselves as

commiters. I don't

think we should attempt to define these rules too

rigidly as each

contribution will likely have unique circumstances

and a lot is

subjective. If there are uncertainties, they should

be brought up and

discussed.


I don't think this is workable right now as the

code, APIs and SPIs

are so
volatile, just a few days can be enough for

something that isn't part

of the
build to get broken in several places.

In my last post I was willing to require contrib to

build as long as

there is some process for moving from sandbox to

contrib. So, does this

address your concern?


Synapse had a similar discussion to
this in its early stages and the outcome was for

new contributions to

go in
HEAD, which I think is sensible.


I don't think this solves the problems, it just

moves it. IMO the APIs

need to be stabilized.


If you feel someones contributed something
new and then loses interest and doesn't develop it

and it becomes a

burden
to maintain then you can vote to get the code

removed.




I'd like to understand what your specific objections

are to placing code

first in the sandbox and then through consensus

promoting it to a

contrib area, which would cary the obligation to

build? Could you

enumerate them?

I think this is more workable long-term than having

to go through the

unpleasantness of removing problematic code. It also

would help promote

community ownership of code. Again, I think the

issue is significant

changes such as those that affect the build need to

be discussed first.

This has not been done with several contributions,

hence my concern.



   ...ant







__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com