Thanks for explaining Robert. Makes sense. Eelco
On 8/1/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 8/1/06, Eelco Hillenius <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
