Hi Ready to “graduate” / enter incubator, have little to do with releases, it is a lot more about having a community. A single person can make a release, but a single person project will not be able to enter incubator.
However making a release, will hopefully attract users, and hopefully some of them will start to work on the project and thus grow the community. Co-opt with incubator is a good idea, that will ensure that the lab releases according to ASF standards (even though the release should still be marked as “limited”, e.g. due to lack of community). rgds jan I. > On 22 Sep 2017, at 12:28, Danny Angus <danny.an...@gmail.com> wrote: > > Two points here, first is that I intend to explore the ASF github > integration, perhaps as a lab itself, to see how much of that gut hub > lifecycle we can adopt. Collaborate not compete. > > Second point is that I agree that the first release represents a milestone, > and believe that that milestone indicates that a lab is complete, and ready > to graduate. What I meant in respect of incubator was that we could either > co-opt or participate in the incubator solution to this problem, rather > than attempt to solve it again from first principles. > I suspect that after a lab reaches the release stage it is still not > necessarily ready to graduate, but we have no "route to market" stage in > the labs lifecycle, whereas the incubator "podling" probably does cover > this lifecycle stage and if so I'd rather collaborate than compete. > D. > > On 22 Sep 2017 11:19 a.m., "jan iversen" <jancasacon...@gmail.com> wrote: > >> Hi. >> >> “nightly builds” is better than nothing, but that is something a lab can >> do already. >> >> If I were to start a new project as lab (compared to doing it directly in >> GitHub), this would be a severe limitation. >> >> I do agree that official releases should not be allowed, but how about >> calling the kid “labs limited release”, with a severe disclaimer in the >> release notes. >> >> I do not understand your idea of incubator, a lab is not part of incubator >> (with mentors etc), so how should it be able to do a incubator release ? >> If you mean a lab should wait until it has left labs and entered >> incubator, then it is business as we already have it, and in my opinion DOA. >> >> Labs is directly competing with “native” GitHub, where a project can make >> a release when they decide to do it. In order to grow a community, making a >> release is important, >> since it marks a milestone, something a “nightly build” does not. >> >> rgds >> jan i. >> >> >>> On 22 Sep 2017, at 11:48, Danny Angus <da...@apache.org> wrote: >>> >>> One of the biggest sticking points on the use of labs is the limitation >>> imposed by the board on our ability to make "releases". >>> It is my opinion that a compromise is possible, and I would propose that >>> labs be allowed to offer "nightly builds" but that any actual release >>> should be done via the incubator. >>> >>> I would like to canvas other opinions here, and see if we can reach >>> consensus on a more detailed proposal which meets the needs of the labs >> and >>> adequately addressed the concerns of the Board wrt oversight and >> liability. >>> >>> WDYT? >>> >>> Danny >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org >> For additional commands, e-mail: labs-h...@labs.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org For additional commands, e-mail: labs-h...@labs.apache.org
