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