On 5/13/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > Again, I am pretty sure that we cannot move components from SF > directly to the sandbox. Code developed outside of the ASF framework > needs to pass through the incubator. My understanding is that this > rule is non-negotiable. >
Non-negotiable for new projects, true ... but that's not necessarily what we are talking about here. It might be worth looking at analogous cases within the ASF already, and see how that works ... two examples I'm familiar with are Jakarta Commons and Struts, but the principles apply more generally. > The sandbox is not a substitute for the incubator. It is for > components that are developed *here* within the myfaces community. > Non-committers will have to submit files, patches to the dev list to > be committed. This is the way its done on jakarta-commons. The > standard for committing something to the sandbox will obviously be > less but the development and development discussions need to take > place in house on the dev list. > Jakarta Commons has a formal "sandbox" area ... but you still must be voted in as an Apache committer (on some project) to take advantage of it. The idea is that some existing committer or group of committers might want to experiment together on a new idea, and see if something comes of it. Some of these fail and wither on the vine, some get promoted. But the key point is that, because it's existing Apache committers, and not a new community, it's not an incubation situation. What happens if some of the people are indeed non-committers at the start? One of the existing committers has to take enough responsibility to post their patches in the short term -- typically, a vote to promote a sandbox project into commons proper will include voting in those individuals as new commons committers -- who, ilke all other commons committers, have technical commit access to *all* of Commons. Therefore, it's a commons-wide vote on both promotion and the new committers. > I would *not* do any serious development in SF and expect that the > components can be part of the sandbox. Please be patient, we will > have the sandbox shortly and IMO there is no need to go the SF route. For Struts, the situation is similar but different. An advantage of being a top level project is that we can establish subprojects -- and we've done so for quite a few things that one or more of the existing Struts committers started working on somewhere, and then brought to the Struts community to propose for general inclusion. The Struts PMC has to accept responsibility for the new subproject's management, but it the work tends to be done by existing committers (already vetted, or they wouldn't have been voted in as committers), and commits *must* be done by existing committers. But the key point is, the new functionality did *not* need to go through the incubator, because that's more about building new communities (which will then turn into separate projects themselves), and teaching the folks in those new communities the Apache culture. Vetting *code* (be it a patch in a Bugzilla report, a new module, a new component, a new sample app, whatever) is the initial responsibility of the committer who applies the changes to the repository, and the formal resposibility to the PMC to ensure that all the code in the repository conforms to the legal requirements of the foundation (proper licenses, etc.). So, how does someone who is interested in participating, but is not currently a committer, demonstrate that they are worthy of committer status? Historically, that gets measured by intelligent contributions on the dev and user mailing lists, attaching proposed patches to bugzilla reports, nagging the existing committers to apply them, and so on. But it can be a little frustrating, because you often depend on an existing committer (who, as we all are, tends to be very busy and spends most of their volunteer time on Struts scratching their *own* itches) -- if I go apply someone's patch, or add a new significant contribution, I'm taking some measure of resonsibility to ensure that I will clean up any messes that *I* made by virtue of doing that commit. So, for Struts at least, a SourceForge project (struts.sf.net) has turned out to be an interesting mechanism for letting ideas germinate, with completely different rules about commit access. And, several of the existing Struts subprojects have come in that way. It's not something that I would suggest the MyFaces community dismiss. But, commit access on an Apache project is serious business. For Struts and Jakarta Commons (and I *strongly* encourage MyFaces to do this too), commit access is across the entire project, not just for someone's one little component, or just to a sandbox area. That means you should be looking for committers that have demonstrated a commitment :-) to the success of the entire project, and are not going to be in "fire and forget" mode (once I get my component in the distribution, I can go away again), or so totally focused on that one component that they don't help with anything else. Having a SF project is one way for potential contributors to prove their worth -- but remember, that's about committers. The code itself can be added to MyFaces by any committer, without going through the Incubator, as long as it is within the area of responsibility stated in the Board resolution that created your top level project -- and, if you did things correctly, that statement will generally be pretty broad, like the Bylaws of some corporations I've seen that basically say "this corporation can do anything that is legal" :-). > > This is my take on the ASF rules. My personal views differ somewhat > from the rules but the rules are there for a reason. I'm sure Ted and > other ASF veterans can clarify. > > sean Craig McClanahan > > > On 5/13/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > > If you want a step before that, the jsf-comp-project on sf.net is > > activated. > > > > There the committer-rights could be given freely to everybody who's > > interested. When a component is ready, it could be promoted to > > the sandbox for refinement, tests and final documentation by an > > approved myfaces-committer. And upon a final vote then promoted > > to the component-toolbox. > > > > just my 2cents > > Alexander > > > > -----Original Message----- > > From: Grant Smith [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, May 11, 2005 8:42 PM > > To: MyFaces Development > > Subject: Sandbox > > > > I'd like to kick off the whole sandbox debate again. Yes, I'm a sucker > > for punishment.. > > > > If I recall correctly, the consensus was to have a "sandbox subproject" > > for new components. I would like to propose a simpler solution: Why not > > have the sandbox as a subdirectory of the existing project. Then we can > > just specify all "s:" components as sandbox components until they are > > completely accepted by the community. At that time they can become "x:" > > components. > > > > Would this satisfy the ASF's requirement for "All New Components Must Go > > Through the Incubator" ? Hopefully... > > > > >
