incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eelco Hillenius" <eelco.hillen...@gmail.com>
Subject Re: Maven 2 repo for incubating project releases?
Date Tue, 01 Aug 2006 21:46:41 GMT
Thanks for explaining Robert. Makes sense.

Eelco


On 8/1/06, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> On 8/1/06, Eelco Hillenius <eelco.hillenius@gmail.com> wrote:
> > > Most users should not be using Incubator code.  Only those who are committed
> > > and willing to trust that the project will do well here and eventually
> > > become an ASF project.
> > >
> > > Remember that most people don't believe that Incubator projects should even
> > > have a user@ list, only a dev@ list.
> >
> > I'm new to Apache incubation (and part of project Wicket which just
> > put up a proposal for incubation). What is very different from what I
> > expected it to be, is that it seems that the whole process 'feels'
> > like it is geared towards new projects. Which is surprising given the
> > number of mature/ proven projects that regularly enter incubation.
>
> effort is usually applied where concerns are greatest - and ATM that's
> helping closed projects to open up. there's less concern about mature
> projects using open development so less energy has been devoted there.
>
> (so, it's important that people keep jumping in if the process isn't
> working as well as it might.)
>
> > Saying that most users should not be using incubator code makes sense
> > for projects that are in some alpha stage of development. But for more
> > mature projects (such as Wicket, active for 2.5 years, 6,000 - 12,000
> > downloads monthly and a couple of thousand more via maven, 17,000+
> > messages on the user lists alone), doing that would either effectively
> > shut the project down for more than half a year (and probably loose a
> > huge customer base) or force developers to branch and maintain a
> > production release somewhere else. This way of looking at incubation
> > strikes me being quite inflexible.
>
> here's another way of looking at this: an established open source
> project with a philosophy sympathetic to apache should be able to pass
> through incubation relatively quickly. the only issue should be
> (legal) compliance.  once such a project has demonstrated that all
> their code base is covered by the appropriate legal documents,
> complies with the licensing policy and that they understand how to
> create complient releases then they should tidy up the paperwork and
> think about applying for graduation.
>
> apache is trusted by a lot of downstream organisations to create
> releases which are legally sound. we spend a lot of energy trying to
> ensure that our official releases are squeaky clean.
>
> releases from the incubator are painful for various reasons. it's
> probable that existing release processes will need changes before they
> are ok at apache. things may well go more smoothly if production
> releases are cut offshore at first.
>
> > Forgive me if I misinterpreted what incubation is all about, but I
> > expected incubation to be a period where the project being incubated
> > and Apache see whether they are a good fit to each other. Surely, such
> > projects should communicate that incubation does not guarantee that
> > the project will actually be accepted to be an Apache project, or that
> > the project decides to go on with Apache, but it should communicate a
> > strong intention from both sides. Otherwise what is the point of even
> > having a formalized process and involving users in it?
>
> apache is democractic and so some minimal formal process is needed :-)
>
> apache means open development. we want to encourage maximum
> participation. we'd like everyone (including users) to be involved.
>
> but i think i agree with the sentiments expressed above (at least for
> mature open source projects moving to apache)
>
> the incubator is still very much under development. we still have a
> lot to learn.
>
> > Furthermore,
> > the process of incubation and saying something about the usability of
> > projects' releases should imho be two different, disconnected aspects.
>
> we trying pretty hard not to say anything about the usability of releases
>
> the risk with incubator releases is not code quality - it's legal.
> there is higher legal risk using incubator releases then official
> apache releases. (this probably needs to be said better in the
> documentation - patches gratefully received.)
>
> there would also some concerns about branding if full releases were
> allowed but IMHO this is more of an issue for projects that begin as
> closed source. (we want them to demonstrate that they understand how
> to open up the development before we allow full releases associated
> with the apache brand.)
>
> we could add some formal process for podlings with a good track record
> to cut full releases but i think it would be better if they invested
> more energy into pushing towards graduation than another formality.
>
>  - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message