Wicket again (was Re: incubation process for open development open source projects)

[Upayavira <uv...@odoko.co.uk>]

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 <ro...@gmail.com> wrote:
>>
>> On 8/5/06, Eelco Hillenius <ee...@gmail.com> wrote:
>> > On 8/4/06, William A. Rowe, Jr. <wr...@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

Re: Re: Wicket again (was Re: incubation process for open development open source projects)

[Leo Simons <ma...@leosimons.com>]

On Fri, Aug 11, 2006 at 08:54:09AM +0200, Bertrand Delacretaz wrote:
> On 8/11/06, Leo Simons <ma...@leosimons.com> wrote:
> 
> >...I think recent discussion has shown quite clearly that there is quite a 
> >bit
> >of disagreement on various aspects of incubation relevant to (among 
> >others) the
> >wicket community...
> 
> Just to make sure this is not misinterpreted: I think Leo means
> "relevant to the *case* of the Wicket community".

Erm, yeah, sorry. That one. Its not about wicket, its about the whole
incubation deal in general, and how it applies (or doesn't apply, or
should apply, or whatever) to wicket and others.

LSD

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

Re: Re: Wicket again (was Re: incubation process for open development open source projects)

[Bertrand Delacretaz <bd...@apache.org>]

On 8/11/06, Leo Simons <ma...@leosimons.com> wrote:

> ...I think recent discussion has shown quite clearly that there is quite a bit
> of disagreement on various aspects of incubation relevant to (among others) the
> wicket community...

Just to make sure this is not misinterpreted: I think Leo means
"relevant to the *case* of the Wicket community".

It's not that the Wicket community is unsuitable for incubation, but
their status (a well-established project with a diverse community and
production quality releases) means slightly different needs than what
the incubator is used to. That's my understanding of it.

-Bertrand

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Leo Simons <ma...@leosimons.com>]

On thursday, someone wrote:
<snip type="all context"/>
> this sounds perfect, and is what i pretty much suggested. i was under the
> impression that this is "frowned" upon by the apache folks

I think recent discussion has shown quite clearly that there is quite a bit
of disagreement on various aspects of incubation relevant to (among others) the
wicket community, and I suspect there are quite a few issues without an easily
reachable consensus. In the end, to move forward, what is required is "3 or
more binding +1 votes and more binding +1 votes than binding -1 votes", or
for issues that can be vetoed "3 or more binding +1 votes and no binding -1
votes". And to be clear, in almost all cases here, "binding" votes are votes
by the incubator PMC members.

ciao!

LSD

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Igor Vaynberg <ig...@gmail.com>]

On 8/10/06, robert burrell donkin <ro...@gmail.com> wrote:
snip

bootstrapping a user list is discouraged. any users coming through the
> apache site should be directed to the developer list during the
> transitionary period whilst the incubator project is being
> bootstrapped. (this does take some time.)
>
> if an incubator project votes for a user list, once one is set up of
> course users should be encouraged to join it.


the problem is that our current infrastructure (sf.net) is pretty
unreliable. we have mailing list outages that sometimes last longer then a
week. before we were offered to join apache we were thinking about moving
anyways. so i think in our situation it would be easier to move completely
off asap.

snip

from a pragmatic perspective, if your users really need a regular
> release then IMHO it would be better to issue an offshore wicket
> release in the way you do now and then work on apache incubator
> compliant release based on the same code. (there should be no code
> changes required, just packaging and licensing related ones.) you'd
> need to be careful to remove references to apache from the offshore
> release.


this sounds perfect, and is what i pretty much suggested. i was under the
impression that this is "frowned" upon by the apache folks and might make
the incubation process longer.

-Igor

Re: Wicket again (was Re: incubation process for open development open source projects)

[robert burrell donkin <ro...@gmail.com>]

On 8/9/06, Upayavira <uv...@odoko.co.uk> wrote:
> Igor Vaynberg wrote:

<snip>

> > 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.
>
> My suspicion there is that Noel is being somewhat idealistic in that
> sentiment. Especially given the number of incubating projects that do
> have user lists!

experience has shown that it's better for incubator projects not to
start out with user lists hosted at apache. there is no policy against
incubator project having user lists, it's just that   creating them by
default as part of the proposal has disadvantages  both for new
projects and for those with existing user lists.

to create a user list, a binding vote on the incubator project dev
list is sufficient. no (explicit) incubator pmc involvement is
necessary.

IMHO it would be easier for an existing open source project (with a
user list) moving to apache to bootstrap just a dev list whilst
maintaining their existing user list for a transitionary period. once
the apache infrastructure is up and running ok, then the user list can
be created by vote and the migration managed. i think that this
process is likely to work out more smoothly for existing users.

> > 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
>
> That seems fair enough to me. Hopefully others (particularly Noel) will
> chime in.

here's how i see it (maybe noel will jump in afterwards)

bootstrapping a user list is discouraged. any users coming through the
apache site should be directed to the developer list during the
transitionary period whilst the incubator project is being
bootstrapped. (this does take some time.)

if an incubator project votes for a user list, once one is set up of
course users should be encouraged to join 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.
>
> So long as the other criteria that are required in order to do a release
> are met, I do not see any problem with that.

IMO apache is very unlikely to endorse any full release made from the
incubator.

it's very rare for any incubating project to create compliant releases
the first few times they try. there is more overhead and it may well
be a number of weeks between code cut and having an incubator approved
release. a dedicated and experience open source release manager
willing to research the issues would be able to cut this time
significantly, though.

from a pragmatic perspective, if your users really need a regular
release then IMHO it would be better to issue an offshore wicket
release in the way you do now and then work on apache incubator
compliant release based on the same code. (there should be no code
changes required, just packaging and licensing related ones.) you'd
need to be careful to remove references to apache from the offshore
release.

> In this case, the criteria are objective ones, such as: all contributor
> CLAs have been received by ASF; licenses are correctly placed on all
> source code, license files (NOTICES.txt, LICENSE.txt) are correctly
> placed within the release file, etc, etc. Nothing that should be too
> hard to manage (esp as I'd intend to do most of the CLA gathering before
> actually shifting to Apache - without doing so you'd have committers
> without commit access to your codebase, which really wouldn't work)

typically the part which takes the longest is tracking all the other
small code contributions and ensuring that all contributions are
known, tracked and dealt with appropriately.

- robert

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Upayavira <uv...@odoko.co.uk>]

Igor Vaynberg wrote:
> 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.

That is fair enough - we all start somewhere.

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

This is one fact (the possibility of misinterpretation of the term
'incubating') that Wicket would need to face head on. Make sure it is
clearly documented up front the code maturity level that Wicket has, and
that incubation refers to the process of joining Apache, and is not a
statement about the quality, or otherwise, of the code itself.

Of course, if it makes life easier, you could make me a committer, and
I'm sure I could make sure that your code isn't production ready :-)

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

My suspicion there is that Noel is being somewhat idealistic in that
sentiment. Especially given the number of incubating projects that do
have user lists!

> 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

That seems fair enough to me. Hopefully others (particularly Noel) will
chime in.

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

So long as the other criteria that are required in order to do a release
are met, I do not see any problem with that.

In this case, the criteria are objective ones, such as: all contributor
CLAs have been received by ASF; licenses are correctly placed on all
source code, license files (NOTICES.txt, LICENSE.txt) are correctly
placed within the release file, etc, etc. Nothing that should be too
hard to manage (esp as I'd intend to do most of the CLA gathering before
actually shifting to Apache - without doing so you'd have committers
without commit access to your codebase, which really wouldn't work)

Hopefully that is clearer still?

Regards, Upayavira

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Jeremy Hughes <hu...@apache.org>]

On 8/9/06, Igor Vaynberg <ig...@gmail.com> wrote:
> 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.

I wrote this meaning that Woden isn't production ready but can now see
you could interpret my words as meaning all incubator podlings aren't
production ready - which certainly isn't the case. I hope this isn't
a' Freudian slip' on my part and if it is then is solely because I
have limited exposure to podlings other than Woden. So I apologise.

IMHO, the confusion arises because the podlings aren't *endorsed* as
Apache projects. Making a leap from that to 'is not production ready'
is wrong.

Cheers,
Jeremy

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Igor Vaynberg <ig...@gmail.com>]

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 <ro...@gmail.com> wrote:
> >>
> >> On 8/5/06, Eelco Hillenius <ee...@gmail.com> wrote:
> >> > On 8/4/06, William A. Rowe, Jr. <wr...@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
>
>