On Tue, Jun 24, 2014 at 9:57 AM, Upayavira <u...@odoko.co.uk> wrote: > > > On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote: >> On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote: >> >> > On Thu, Jun 19, 2014 at 6:22 AM, Christian Grobmeier >> > <grobme...@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. > > Unlike Christian (another Wave mentor :-) ), I am generally in support > of this proposal. If a project cannot get a release out, then it > suggests insufficient weight behind it. Releasing software is what the > ASF is about. It is acceptable that a mature ASF project, one that is > code-complete, doesn't release regularly, but an incubator project would > not fall into that camp, therefore being able to say "we can muster the > resources to make a 'legally valid release' within a year seems > eminently reasonable to me. >
I'll offer OpenOffice as an example of how long an initial podling release can take in some cases, due to a number of factors: 1) Getting the code repository migrated from Mercurial to Subversion was time consuming 2) The code that was SGA'ed was for a beta release. It required a lot of bug fixing before it was ready for GA. 3) The SGA'ed code had a good number of copyleft dependencies that had to be replaced, as well as other unique things (at the time) that required review on legal-discuss. 4) Our priority (even over a release) was on migrating community resources like forums, wikis, Bugzilla, extensions repository, etc., since these were being hosted by 3rd parties and we didn't want to remain dependent on their continued (though generous) hosting support. 5) And as we all know, we spent a lot of time spent learning about Apache and how we fit in. A review of our activities be seen in this blog post: https://blogs.apache.org/OOo/entry/an_apache_openoffice_timeline In total, from entering incubation to first release was 11 months and a week. So this confirms that a year, for most projects should be sufficient. But there could be exceptions, due to factors similar to those I listed above. But such exceptions should be rare. Regards, -Rob > Upayavira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
