Upayavira, I do concede that after watching over Wave here for the last 3 years the project doesn't appear to have progress hugely far in terms of new user-visible functionality, but I don't think that this means the end, as there has been a slow-but-steady set of work on more underlying things - I would argue that 'we' have a tendency to the first 90% of the work, but then stop a bit short far too often.
Yuri and I have put together 9 release candidates for general review under the name 0.4, which have received very varied quantities of responses from the community at large, though all positive - but ultimately all these RCs have had some form of bug we have (previously) considered to be show-stopping, prior to reaching the stage of sending the RC to the IPMC. I would say that this is due in part to the large time scales between (later) attempts, and the patches received in the interim time which caused a breakage, and more generally due to a lack of usage outside of release testing, resulting in these being the first time non-apparent bugs manifest themselves. It would appear that the best way to progress forward from this blocking point, is to simply cut RC10 from (roughly) where we currently stand on master. Say "we know it has bugs, but it sort-of-works if you do X and run only as Y, we will fix everything else in future releases" - which would prevent us getting stuck again at RC stage for anything short of "it doesn't work on any system because the RC is missing the build scripts" - allowing the project to meet the final criteria that has eluded this project for far too long now. Our next board report would be due in January, and assuming we would agree to make our initial release under the limited statement above, I think that making a release by then is perfectly achievable. I would be happy to put together an RC10 tomorrow, as long as there are still people on the Wave list interested in seeing its release? Ali On 7 October 2015 at 22:48, Upayavira <u...@odoko.co.uk> wrote: > That is a reasonable response, Evan. > > So, let's look at what graduation might look like, then we can see about > what goals might be reasonable: > > A podling must have: > 1. proven its ability to produce legally correct releases > 2. demonstrated its ability to vote in new committers and PPMC members > 3. a diverse community > 4. sufficient PPMC members to be able to command 3 or more votes on all > important matters, > notably new committers/PPMC members and on releases. > > So, the ONE thing this podling needs to do before our next board report > is due is make a release. > > This involves these steps: > * prepare a tarball containing the source > * validate that it is (to the best of our knowledge) legally correct > * get at least 3 +1 votes from PPMC members > * submit it to the Incubator PMC for checking > > I personally am hesitant to vote on such things as I have limited > experience of release vetting. My holding back should not be considered > as a negative in any way. > > The PPMC needs to be able to demonstrate its ability to do this in a > self managed way, i.e. without prodding from mentors. > > Note, I don't mention in that list "getting the Incubator PMC to accept > the release". That can sometimes be challenging. But having shown that > this PPMC can (a) produce a release tarball and (b) submit it to the > Incubator PMC having acquired 3 or more +1 votes from PPMC members would > make a big difference in terms of moving us closer to meeting graduation > requirements. > > Reasonable? > > Upayavira > > On Wed, Oct 7, 2015, at 02:01 PM, Evan Hughes wrote: >> maybe instead of deciding the end instead you and Christian set goals >> that >> must be completed by the next checkpoint aka have x amount of submits, >> have >> x more active contributors to help gain momentum. If the tasks are not >> completed sufficiently or dismally fail then sure maybe its for the best. >> >> On 7 October 2015 at 22:44, Evan Hughes <ehu...@gmail.com> wrote: >> >> > Well as the video discussion we had earlier this year, the main problem >> > has been the complexity. We have been taking steps in this direction with; >> > >> > * reducing technical debt (removing updating dependencies), can bee seen >> > from patches last week and there has been work in a gradle or sbt build >> > system which allows people to understand how the project works together. >> > >> > I personally have been looking into giving the website a fresh coat of >> > paint in the past couple of weeks (infrastructures docs on building locally >> > are eh if not on a mac ;) but did get it working). We have also had the >> > addition of the android project for wave. >> > >> > Progress might be slow but progress is still being made. >> > >> > On 7 October 2015 at 20:54, Upayavira <upayav...@odoko.co.uk> wrote: >> > >> >> Dear all, >> >> >> >> I need to sign off the Wave report, but find this difficult. >> >> >> >> The Apache Incubator exists to facilitate projects moving towards being >> >> fully fledged ASF projects. Wave has been >> >> incubating since 2010, and in that time it has not yet been able to >> >> build a community that is likely to sustain itself as an ASF >> >> project. >> >> >> >> It does, therefore, seem to me that it is time for us to retire as a >> >> podling, and allow people here to continue in a location more fitting >> >> with the current level of effort, without the expectation that it needs >> >> to meet some specific set of incubation requirements. >> >> >> >> Note that all of the source code is Apache Licensed, meaning it can be >> >> forked elsewhere - the only discussion required is the name that the >> >> relocated project would take. >> >> >> >> Thoughts? >> >> >> >> Upayavira >> >> >> > >> >
