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
