incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier" <grobme...@gmail.com>
Subject Re: [DISCUSS] Incubator exit criteria
Date Tue, 24 Jun 2014 11:02:43 GMT
On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote:

> On Thu, Jun 19, 2014 at 6:22 AM, Christian Grobmeier
> <grobmeier@gmail.com> wrote:
>> I think its not enough to just look at release / committer additions.
>>
>> In the case of Wave, there was a committer addition in the past year. 
>> Still
>> no commits, nor a release. Looking closer you would find that 
>> committer was
>> added because there was some excitement around at that time, with a 
>> lot of
>> plans.
>> But then people were facing simply too much work for a small team, 
>> and
>> the motivation then stopped. A deadline wouldn't not help to get out 
>> a
>> release.
>>
>> That being said, I would like to re-suggest my initial thought with 
>> one
>> modification:
>>
>> - no new committer for a year
>> - AND no release for a year
>> - AND less than 20 emails in a month on dev@
>> - AND less than 10 commits/jira modifications in a month
>> - AND no way to change this in the next three months (in example: 
>> hackathon
>> on horizon)
>
> Here's my personal struggle with two of the items on this list:
> - AND less than 20 emails in a month on dev@
> - AND less than 10 commits/jira modifications in a month
> I can't fathom how a community that is that active can't put
> itself to a task of making a release.

Let's assume the Wave project would have more activity. Maybe lets say
they are operating with around 20 commits a month. It would be still
difficult to release the code base within one year, because its really 
complex and
needs a full refactoring. If we do not weight activity in general in, we 
reduce
the exit criteria to: how fast can you do a release?

And: if you don't manage to make a release in the first year - no matter 
how your
product looks like - you might be thrown out.


> At the ends of the day, the release of an incubating project
> is NOT a glorious exercise in putting the final coat of paint
> on a flawless product. It is rather a very mundane way sharing
> technology with its users community. And after all, growing the
> user community is as important as growing the contributing
> community. It is only fair that IPMC gently reminds PPMC of that.

I agree, but sometimes it's simply not possible to release.
Actually, Wave *could* have released something, but nobody wants
it to look like that.

Let's assume they would release it now, which would be possible in 
theory.
Let's say they would get 3 +1 from the PMC, which will be hard already.
Then you have a released project, but the community is almost inactive.

> Heck, our TLPs practice it (where expectations are arguably
> higher) let alone Incubating projects. Take Hadoop as an
> example -- in order to make Hadoop 2.x successful the
> community decided to put an early alpha releases of
> Hadoop 2.0.x out to share the technology with its users.
> It was exactly the right decisions and ultimately it resulted
> in a much smoother 2.x.y series.

As to my knowledge, some Hadoop-devs get financial support from 
companies.
Projects like Ripple, Wave or Log4cxx do not have that financial 
support.
In most cases, people work on these codebases in their prime time.
For that reason I don't want to compare company-backed projects with
prime-time projects.

> In short -- you don't have to make your releases GA. Alpha
> releases are just fine. Still you have to demonstrate that
> you are capable of sharing your work with the user
> community and doing an alpha/beta/gamma/YNH release
> is the only way to do it.

I know what you mean, but I doubt this alone is a factor we should 
weight for an exit.

People might struggle with a release but be healthy otherwise.
People might get a release done, but have no community otherwise.

That said, reminding people of the "release often and early" thing is 
good to do,
but also have in mind that incubator releases are very difficult to 
make.

Regards,
Christian


>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message