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.189 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=g38a2C9Y8y50XP8iEfigD0Hwq4nhFTlxzGL3CtojnJBdJUaCSsGhOJNIik2shODJD+sU26KpRPp3kqXyZCoDZShs5FhuKq0R/J5btB8VhOerRtrkjGXn+DyH4dW7z3tlWSkZF8bXjtBsSkkarLyqua+IVo+Uo554H1W4aeJUPtg=
Message-ID: <23eb48360608091519u44405112i5f878ab237d1e533@mail.gmail.com>
Date: Wed, 9 Aug 2006 15:19:11 -0700
From: "Igor Vaynberg" <igor.vaynberg@gmail.com>
To: general@incubator.apache.org
Subject: Re: Wicket again (was Re: incubation process for open development
 open source projects)
In-Reply-To: <44DA59D6.2030207@odoko.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_20280_28525745.1155161951134"
References: <f470f68e0608061305s1b35498erb4da65285c7be1a9@mail.gmail.com>
	 <23eb48360608061332m5653f75di52cbe0090c6680db@mail.gmail.com>
	 <44DA59D6.2030207@odoko.co.uk>

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

pardon me for being so ignorant, but all i know of apache is what i read
online and what i have observed from this list.

it seems to me that there are a few recurring concerns about these items,
even in the short period that i have been subscribed.

the incubation, the releases, and the user lists - and the general feeling
toward projects that are in the incubator.

here are a few snippets that cast a lot of doubt on where things actually
stand:

> Jeremy Hughes wrote:
> Then, in its README Axis2 should make very clear which function relies
> on Woden and that this function isn't production ready because it is
> reliant on an incubator podling.

statements like these are always answered by stating that incubation does
not reflect on code quality or whether or not a project is production ready
- but the general negative sentiment is clearly there even if not true in
the eyes of apache folks. and it comes up often.

here is another example.

> Noel J. Bergman
> 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.

where does this leave us?

so i guess what i would like to confirm is the following:

a) we will have a user list in the incubator and our users will not be
discouraged from joining it
b) if we have a final release ready even though we were in the incubator for
a short time ( lets say a month ) it will not be blocked just because of its
timeframe.

thanks,
-Igor


On 8/9/06, Upayavira <uv@odoko.co.uk> wrote:
>
> 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.
>
> Good.
>
> 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
> already).
>
> 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: http://incubator.apache.org/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 <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
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

------=_Part_20280_28525745.1155161951134--