Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of igor.vaynberg@gmail.com
 designates 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Sr+A12+JC2FM75taqA8M1/tF6ck+tsxnY6ShqT0JQlf7k5m7iIkMItb+pzLA3o8lJQHMciJ6XAaJrsdIcqgb2AAbRwnAp2Nvr/v7OBNVN+je7bCUBIxVJqviOfwp7xqq1CjqVypG2kM+ndBCnSflaN/AOnRXZg8NS5zTfe4XM08=
Message-ID: <23eb48360608061332m5653f75di52cbe0090c6680db@mail.gmail.com>
Date: Sun, 6 Aug 2006 13:32:08 -0700
From: "Igor Vaynberg" <igor.vaynberg@gmail.com>
To: general@incubator.apache.org
Subject: Re: incubation process for open development open source projects [WAS
 Re: Glasgow - community? specs? other issues?]
In-Reply-To: <f470f68e0608061305s1b35498erb4da65285c7be1a9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24206_5281417.1154896328361"
References: <f470f68e0608061305s1b35498erb4da65285c7be1a9@mail.gmail.com>

------=_Part_24206_5281417.1154896328361
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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. 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. 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. 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.

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.

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.

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"

this is my long winded two cents :)

-Igor


On 8/6/06, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
>
> On 8/5/06, Eelco Hillenius <eelco.hillenius@gmail.com> wrote:
> > On 8/4/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

------=_Part_24206_5281417.1154896328361--