myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Sandbox
Date Sun, 15 May 2005 18:46:48 GMT
Hi Martin,

I don't have a problem with the incubator - remember that we came in
quite the same way and I think we did quite well. Additionally, we
might have a smaller community than struts, but I think with respect
to the average Apache project, we do have a fairly large community. I
hope that our community doesn't feel insulted by you calling it small
;)

The only question was if we have many components coming in, and that
might happen quite often JSF being a standardized platform, if we have
to setup an incubator project for that everytime.

I asked at the incubator mailing list if we could have our sandbox in
the incubator, and vote out components as appropriate, and I didn't
even suggest to get around incubator at all or doing things "the easy
way".

But people at incubator where telling me that no, incubator itself was
not necessary everytime for code contributions. If IP is sorted out
and the contribution can be maintained by us (and there is a strong
dedication to that) then we would not have to do that.

I really love the principles of the ASF, and I believe the incubator
has great merits for large codebases donated to the ASF, but incubator
is (albeit maybe small) bureaucratic overhead, and if it is not
necessary according to the principles, it shouldn't be happening,
would be saving work both for us and for the incubator people.

regards,

Martin

On 5/15/05, Martin Cooper <martinc@apache.org> wrote:
> 
> 
> On Sun, 15 May 2005, Martin Marinschek wrote:
> 
> > I am attaching an email trace by Noel and Cliff from a question I
> > asked at the incubator mailing list, which basically said that we
> > don't have to do an incubator subproject for anything which we think
> > we can maintain - so Craig seems to be right in this issue if number
> > of opinions count ;)
> 
> It's not a question of what you *think* you can maintain. If you bring an
> external code base into the ASF repository, you *must be committed* - as a
> community, not one or two individuals - to maintaining it and resolving
> any technical issues, not to mention resolving any legal issues *before*
> it touches the ASF repository. If there is even a hint that this is not
> the case, you should go through the incubator.
> 
> Please don't think of this as "can we avoid doing things the right way and
> just stick it in our repo?". Intended or not, that is how this thread is
> coming across, at least to me. The incubator is there for good reasons,
> and, as Ted has pointed out several times, it need not be a heavyweight
> process. If something is brought into the incubator, and it's in good
> shape with a community forming around it quickly, then there is no reason
> for it to remain there for a protracted period before moving out and
> becoming part of an existing project.
> 
> One other thought I'd like to throw out here: As it is today, the MyFaces
> community is faurly small, and relatively inexperienced in the "ways of
> Apache", albeit with a few mentors keeping tabs on it. Given that, I would
> suggest focussing on what's here now, and grokking the ways of the ASF,
> before rushing into how to accummulate more code from other places.
> 
> --
> Martin Cooper
> 
> 
> > regards,
> >
> > Martin
> >
> >
> > On 5/14/05, Noel J. Bergman <noel@devtech.com> wrote:
> >> Cliff Schmidt wrote:
> >>
> >>> you'd only need an incubator subproject if the code could not be
> >>> supported by the current MyFaces community.  However, if the
> >>> MyFaces PMC feels that the community already exists to maintain
> >>> the new code contribution, then there's no need for an incubator
> >>> subproject.
> >>
> >> But the IP must still be vetted and recorded (q.v.,
> >> https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/projects
> >> /ip-clearance-template.html).
> >>
> >>         --- Noel
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > On 5/15/05, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> >> No there we have Ted and Craig saying something differently - now who
> >> of the two experts is right?
> >>
> >> is it possible to develop something on Sourceforge (by non-commiters)
> >> and have it checked in to the ASF codebase by an ASF committer without
> >> going through the incubator?
> >>
> >> Craig says yes - the committer has to take responsibility for sorting
> >> out the legal issues and everything
> >>
> >> Ted says no - everything has to go through incubator.
> >>
> >> May I suggest that it depends on the size and the clarity of the legal
> >> situation of the contribution with respect to the existing codebase -
> >> one component of one developer who puts the component into public
> >> domain might be okay, several would need to go through incubator?
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 5/15/05, Ted Husted <ted.husted@gmail.com> wrote:
> >>> On 5/11/05, Sean Schofield <sean.schofield@gmail.com> wrote:
> >>>>> Would this satisfy the ASF's requirement for "All New Components
Must Go
> >>>>> Through the Incubator" ? Hopefully...
> >>>>
> >>>> I think Ted's concern regarding this (from the myfaces-pmc thread) is
> >>>> that code that is *already developed* outside of ASF should not go
> >>>> straight into the project.  So for components that grow out of
> >>>> discussions on this board would not apply.  Hopefully that is what he
> >>>> meant anyways.
> >>>
> >>> It's more like all external "codebases" donated to the Foundation
> >>> *must* go through the Incubator.
> >>>
> >>> The two concerns are IP and Community. First, the ASF wants to be
> >>> positive that we do in fact own every line of code in our
> >>> repositories. Of course, under the Apache License, we don't mean "own"
> >>> in the exclusive sense. But "own" in the sense that we can put it
> >>> under the Apache License, and no one else has a legal right to
> >>> complain.
> >>>
> >>> If an external codebase could enter the ASF through any of our dozens
> >>> of projects, it would be too easy for a project to slip and allow in a
> >>> codebase with IP issues. So, when IBM donates Derby, it doesn't go
> >>> straight to db.apache.org, it goes to the Incubator first, where
> >>> another set of eyes can look it over.
> >>>
> >>> Now if the codebase is developed here in our repository, regardless of
> >>> its size, then we own it and we can put it under the Apache License.
> >>> It's only external codebases developed by non-committers that concern
> >>> Incubator.
> >>>
> >>> Of course, the ASF doesn't want code as much as we want community
> >>> (people who create, maintain, and support code). Before any large
> >>> donation is accepted, we need to know that there are *several* members
> >>> of our community who will support the code over the long term.
> >>>
> >>> Essentially, the Incubator is a front controller for new projects and
> >>> external code donations.
> >>>
> >>> A lot of projects maintain sandboxes to ensure that there is a
> >>> community support behind a codebase before making it part of the
> >>> trunk. Once it is part of the trunk, there is an expectation that
> >>> *all* of the committers are ready, willing, and able to support the
> >>> code over the long term.
> >>>
> >>> Another word for sandbox is "whiteboard directory", as mention in the
> >>> Rules for Revolutionaries.
> >>>
> >>> * http://incubator.apache.org/learn/rules-for-revolutionaries.html
> >>>
> >>> If you have a sandbox, or whiteboard, then it should be very, very
> >>> clear to anyone using the component that this code is not part of the
> >>> main distribution, *and* that it subject to change or removal without
> >>> notice. If its too easy to use the sandbox code, then people might not
> >>> realize that it's not part of the standard distribution.
> >>>
> >>> Of course, under SVN, it is quite easy to merge and move components
> >>> later, no matter where you hide them now :)
> >>>
> >>> Often, people will develop novel or "revolutionary" code in the
> >>> sandbox, then propose that it be promoted when the code is ready for
> >>> primetime. (Where primetime means the code is stable and there are
> >>> several people interested in using and supporting the code.)
> >>>
> >>> But, "evolutionary" code can be developed as part of the trunk, if
> >>> everyone agrees its something that needs to be part of the next
> >>> release. Generally, a sandbox is for questionable components that may
> >>> or may not be made part of the standard release.
> >>>
> >>> This is important, because Apache Projects are expected to fully
> >>> support whatever goes into a standard release.  If it goes into the
> >>> standard release, it should be bug-free in every subsequent release,
> >>> and if it we decide to remove it, we should go through a
> >>> deprecate-replace-remove cycle over two or more stable releases.
> >>>
> >>> Putting code in a standard release means we are committed to the code.
> >>>  Putting code in a sandbox is "throwing stuff on the wall and seeing
> >>> if it sticks" :)
> >>>
> >>> Whether a component *needs* to go through a sandbox would depend on
> >>> whether it *needs* to be part of the next standard release. If it's in
> >>> the trunk, and it's not done yet, then it becomes a blocker until it's
> >>> done (or moved out of the trunk).
> >>>
> >>>
> >>> On 5/11/05, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> >>>> What about the sourceforge project that has already been set up?
> >>>
> >>> As mentioned, some people on the Struts team setup a SourceForge site
> >>> to make it easier for non-committers to share code with the Struts
> >>> community. But it is not used as an actual sandbox. (Struts already
> >>> has one of those.) It's just a place where people can share Struts
> >>> extensions and sample applications outside of the standard release.
> >>>
> >>> Of course, if a non-committer wants to develop something and then
> >>> propose it to the Apache Struts Project, a good approach would be to
> >>> develop it on the SourceForge site. But, it would still have to go
> >>> through the incubator and all that.
> >>>
> >>> When a Struts committer want to develop something that might become
> >>> part of the Struts release or a new Struts subproject, we start it in
> >>> the ASF repository, not the SourceForge site.
> >>>
> >>> The cool thing about a sandbox, as used by Struts and Jakarta Commons,
> >>> is that you don't need group approval. You can start it up, and see
> >>> how it goes, without having to convince anyone first. It gives you a
> >>> chance to do the code, and then let the code do the talking.
> >>>
> >>> HTH, Ted.
> >>>
> >>
> >
>

Mime
View raw message