incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Wicket again (was Re: incubation process for open development open source projects)
Date Wed, 09 Aug 2006 21:55:34 GMT
Igor Vaynberg wrote:
> personally i am fine with "incubation takes as long as it takes" statement.
> it is your organization and it is up to you whether or not you want to let
> the project into the incubator and into graduation. i also understand the
> "need to observe open development style on apache ground" argument.


On the subject of 'as long as it takes' - there's nothing to stop us
planning, scheduling and setting up goals - there are a clear list of
criteria we would need to meet and we can 'manage' those. We may well
find that, having covered those criteria, we've done it.

There just remains, and always will remain, the possibility of new
issues arising - ones that haven't yet arisen for other projects and
thus haven't yet made it into the guidelines - but that need to be dealt
with before graduation. I don't forsee any with Wicket, but then, if I
did, I'd be adding them to the guidelines :-)

> what i
> do not understand are a few points regarding incubation of existing
> projects
> with established user bases, such as the release policy and the brand abuse
> concerns which to me seem to go hand in hand. the concern i have with
> bringing wicket over into the incubator is the feeling of the project
> stagnating. we cant do any releases unless they are done through the
> incubator and we cannot release a final release until we graduate. 

I suspect something needs clarifying here (Noel refered to this in an
earlier mail) - you can do releases in the incubator, and you can call
them whatever you like - 2.0alpha, 2.0beta, 2.0final. The only
requirements are (a) that they are labelled 'incubating', and that the
legal requirements for releases are met (which you're probably okay with

So, you certainly can do the releases you plan - they'd just need to be
labelled 'incubating'.

> we are
> only a few months away from releasing versions that our users are waiting
> for so the incubation process, as it stands right now, would seriously hurt
> us. furthermore the general consensus that incubation takes between six
> months to a year also does not work for existing projects who release more
> often then that. you are basically expecting the project to halt until
> graduation. the development might continue but you cannot release any final
> releases which makes users itchy.

Does my above explanation relieve some of these concerns? No-one is
saying you can't release - in fact, releasing code is one way in which
you will demonstrate your appreciation of the way Apache works.

> also releases marked -incubating raise
> concerns and give the impression the code is not production ready, yes we
> know its not true because we are "educated" in the apache jargon - but many
> users are not nor do they have the desire.

I don't think it is quite as straight-forward as that. Some users (those
more committed to Wicket) will listen to what is being said. Some will
worry. Others will love it. Some people's bosses may start considering
Wicket where they wouldn't have done so before.

So, you might find your demographics change a little, but I see no
reason why incubation, in this regard, should harm Wicket.

> so my proposal to improve the incubator situation is to do this:
> let the project into the incubator and let them release at their current
> infrastructure outside of apache. that way the incubation period doesnt
> hurt the project and can take as long as you guys want. the releases will of
> course not contain any apache branding. once the project graduates the
> branding (such as package names) can be applied to the first release
> available through apache itself.

That way you route around the benefit of demonstrating your
understanding of releasing code within Apache, which would slow down
incubation. Hopefully my explanation above alleviates the concerns you
were trying to address here.

> another concern i have is about not letting the user lists onto the
> incubator, this is once again a problem for existing projects, especially
> for frameworks where users are in fact developers themselves. we tweak
> wicket's api a lot based on the users feedback so not having that resource
> available will hurt us. also a lot of issues that start out on the user
> list turn into development issues like bugs, improvements, etc. the user list is
> an invaluable resource for us and probably for other projects as well.

Looking down the list of projects:
most of them seem to have users lists. So bringing the user list along
wouldn't, to my mind, be a problem. The suggestion of leaving the user
list at SF was, to my mind, just one attempt to find an approach for
Wicket - by no means a requirement of the Incubator.

> the incubator process as it stands right now works perfectly well for new
> projects that come to the incubator without a community or code, but it
> just doesnt work for projects that are being "adapted" rather then "incubated"

I think we can find that it does and can work for existing projects -
just perhaps need to clarify exactly how to describe it.

> this is my long winded two cents :)

Hope my explanations above help.

Regards, Upayavira

> On 8/6/06, robert burrell donkin <> wrote:
>> On 8/5/06, Eelco Hillenius <> wrote:
>> > On 8/4/06, William A. Rowe, Jr. <> wrote:
>> > > Eelco Hillenius wrote:
>> > > >> I understand that there are some specific circumstances in this
>> case,
>> > > >> but in general I believe this sort of criteria is why we get
>> > > >> complaints that it's impossible to "innovate" at Apache any
>> more.  We
>> > > >> require all the grunt work of innovation to occur outside of
>> Apache.
>> >
>> > I did not write that actually. I'm sorry I hijacked the VOTE thread.
>> > It's one of the (hopefully) few things to get used to over at Apache,
>> > as at Wicket we aren't that formal about it.
>> it's not a formality here - it's a necessity. the volume of mail is
>> just too great otherwise.
>> > Here is the blurp that attracted my attention, followed by my thoughts:
>> >
>> > > I understand that there are some specific circumstances in this case,
>> > > but in general I believe this sort of criteria is why we get
>> > > complaints that it's impossible to "innovate" at Apache any more.  We
>> > > require all the grunt work of innovation to occur outside of Apache.
>> > >
>> > > The issues of an open specification is one thing.  But aren't "proven
>> > > an actual community" and "work the standard 'apache way'" graduation
>> > > requirements, not entry requirements?  If we expect something coming
>> > > into the incubator to already have a fully functioning, health
>> > > Apache-style community, then the only point of the Incubator is for
>> > > handling licensing issues.
>> >
>> > This is quite interesting...
>> >
>> > Over at Wicket we have been operating 'the Apache way' from a very
>> > early stage in the project (about two years).
>> just FYI the consensus now is that 'open development' is a better term
>> than 'the apache way'
>> > We have mail archives,
>> > commit logs, releases, and history of letting new committers in to
>> > prove all that if people are willing to spend an hour looking for it.
>> > But we feel we have to prove ourselves all over again as the
>> > incubation process expects it's podlings to prove themselves within
>> > the confines of the incubation process.
>> i think that a certain amount of public scrutiny is an inevitable
>> consequence of the democratic nature of the process. i'm hoping that
>> better documentation will help the people who have to go through it
>> feel a little better about it...
>> > The incubation process might benefit from having a categorization of
>> > projects that want to enter. Such categorization basically answers:
>> > * How old are these projects, how many committers, how large is the
>> > community of developers and users?
>> > * Has the project been working apache style for a certain time (the
>> > time being a categorization in itself). If it has, there is no
>> > question about prove - it'll be there as that is one of the key
>> > factors of working the apache way (mailing lists, committers etc.)?
>> AFAICT the proposal was intended to cover this ground
>> i have it in mind to try to add specific sections into the entry guide
>> under development ATM targeted at the different categories of project
>> that might want to entry the incubator.
>> > This categorization would then be the starting point for answering two
>> > things that I think are currently missing in the whole incubation
>> > process (please do tell me if I am wrong/ missed something):
>> > * To what extend can information about the project's readiness be
>> > gathered based on the (outside) history of the project, and how much
>> > information needs to be gathered additionally during incubation? The
>> > availability of such history could get some load of the backs of the
>> > involved parties and might mean a shorter incubation time.
>> this should be covered by the status file. i would hope that mature
>> open development/source open source projects would be able to tick
>> everything but the legal stuff straight away. the legal stuff usually
>> takes a while for open source projects. how long depends on how good
>> the records tracking contributions are.
>> > * What would be the proposed time estimate for the whole incubation?
>> > Factor time currently seems to be non existent in the incubation
>> > process. But 'it takes how long it takes' imo does not cut it.
>> "it takes how long it takes" really is the only good answer whether it
>> cuts it or not
>> the process is democractic - graduation is by election
>> > I believe the incubation process would benefit from formalizing
>> > timelines and milestones so that both parties keep focussed on making
>> > progress. Having a schedule for incubation would also mean that
>> > involved parties could use that schedule for any other plans they
>> > might be making.
>> there's no reason why a project shouldn't set it's own goals. for
>> projects with a strong community and a history of open development, a
>> lot depends on the energy expended towards the goal of graduation.
>> > For example, we (Wicket) would like to have our 2.0
>> > version to be released at Apache, after (if) we're done with
>> > incubation. There is currently no way to even remotely predict when
>> > that might happen. This is inconvenient for our users, but also is a
>> > problem as we are writing a book on that version and our publisher
>> > *does* want to know when that book will be ready for publishing.
>> > Having a code base that is release-ready but that's just waiting for
>> > months for the incubation process to move on for some unknown time is
>> > unacceptable to us.
>> the problem with due diligence is that it's not possible to tell a
>> priori how long it'll take to complete. it does seem to have a habit
>> of dragging on.
>> > The kind of schedule I am thinking of would be
>> > semi-binding. If we meet the requirements for the milestone in time,
>> > we go on to the next stage, unless there is absolute consensus we
>> > shouldn't based on something other that the milestone requirements. If
>> > we don't meet the requirements in time, incubation may be terminated
>> > for that reason alone.
>> requirements are assessed democractically. graduation is proposed when
>> the mentors feel that the project is ready. the incubator PMC votes.
>> this may then be followed by a board vote if the project is heading
>> for top level status.
>> IMHO the incubator should not impose timescales or a schedule on a
>> project but a project may decide to impose a timescale on itself. the
>> project is (of course) equally free to ignore or interpret this
>> schedule as it pleases since it is not binding on apache.
>> - robert
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message