Pierre, Where can I download or "consume" a project community? I would like to have a local copy of it, right here. ;-)
Communities are living things, people, and not an immutable release artifact. Incubation is not a release process, it is effectively an education program for inexperienced people by experienced people, passing the baton of collective knowledge. Sorry, but I simply fail to equate this with the release process of "open source software for the public good", I think the analogy is too thin. Cheers On Sat, Jan 7, 2017 at 4:42 AM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Nicolas, all, > > Despite your believes, you do release communities. Because the community is > the incubating project. Only after the community meets the criteria of > graduation a proposal is submitted, seconded by the IPMC and reviewed by > the board. The community works the code during incubation until it > consistently meets just one (small set) of the graduation criteria > (compliance to ASF rules). But all the other aspects (community size, > diversity and interaction) are far more important for the success, given > the principle Community over Code. > > Otherwise, your suggestion to use the same standards for releasing as tlp > (released communities) and the examples brought forward look very sound and > acceptable. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Fri, Jan 6, 2017 at 1:37 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > > > Coming late to the party... > > > > This has been discussed, and contentious, since "forever". A long time > ago, > > there was a notion that a podling release was not an ASF release (which > was > > the main reason for the "incubating" marker in all release and support > > artifacts. But that pendulum has swung in the opposite direction, and > > podling releases are now expected to be at ASF TLP levels. > > > > Pierre pointed out that "incubating" refers to community and not code, > but > > we don't release a community, we release code. I think this is an > important > > fact. > > > > So, instead of tying the "incubating" marker to "incubating", I would > favor > > a system of marker(s) indicating the code maturity (incl legal). So, for > a > > podling release to be 1.2.3 (a la Groovy), the same release standard as > > TLPs are applied, but allow "alpha", "rc" or similar markers for podlings > > to "practice" releases. Probably not pushing those to mirrors, but > > otherwise identical in "process" for podling to get their grips on the > > release process. > > > > So, I am +1 with John's "something is broken" observation, although I > also > > agree with the many "-1"s that think there is value to the public here. > > > > > > Cheers > > > > On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament <johndam...@apache.org> > > wrote: > > > > > I'll point out that this is a cancel thread..., I'm fine if people want > > to > > > continue chatting in here, but I started a new discussion on > > > https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f > > > d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E > > > > > > I'll try to answer questions I saw pop up > > > > > > Mark Struberg: No, ignoring commons/log4j for a minute, other projects > > > continue to work under legacy maven coordinates. Includes one i > already > > > linked to - groovy, also freemarker, zest/polygene (a project that went > > > straight to TLP). There's neither foundation policy nor legal impact > by > > > using other very similar marks, especially when the project's name > hasn't > > > changed. Publishing under "com.oracle.someProduct" would probably be > bad > > > from a marks standpoint since it shows as property of some other > company, > > > whereas former foundations or completely independent projects. Plus, > the > > > way maven central works you own the entire tld, except for cases where > > its > > > a known third party publisher. For instance, I own (personally) the > > domain > > > name ament.ws and have access to publish under maven coordinates > > > ws.ament.*. Github users have to request io.github.themselves > > manually. I > > > assume that something similar exists between the ASF and Sonatype to > > enable > > > publishing under org.apache, and ensure that no one else can use > > > org.apache. > > > > > > Pierre Smits: This is something I expected to be a hot topic. So while > > > 100% consensus isn't expected, a clear path forward is something to > > expect, > > > even if not everyone is happy about the outcome. FWIW, there seem to > be > > 3 > > > different POVs (that I could identify) on those who were against the > > idea: > > > > > > - Those who thought this was dropping -incubating from the Apache > release > > > archive. > > > - Those who acknowledged that this was maven specific and felt it > should > > > continue as is. > > > - Those who acknowledged that this was currently maven specific and > > should > > > be made broader. > > > > > > John > > > > > > > > > On Wed, Jan 4, 2017 at 4:49 AM Martijn Dashorst < > > > martijn.dasho...@gmail.com> > > > wrote: > > > > > > > Late to the party, but having a long think about this is sometimes > > > > beneficial. > > > > > > > > +1 to drop the -incubator/-incubating version attachment for any > > > > artifacts (not just Maven). > > > > > > > > My reasoning is the following: > > > > > > > > Source code lives longer than any community. Long after a podling has > > > > gone through the incubator, the code remains. The releases remain. > How > > > > a community conducts itself doesn't reflect on the released code. > Code > > > > just exists. > > > > > > > > While it is important for current users coming to a project to know > > > > the status of the community, does it really matter if the code is in > > > > incubation or has graduated? Does that matter in 5 years whether the > > > > code of foo-1.2 was incubating while the community has graduated and > > > > now resides in the attic? > > > > > > > > Releases have a long life. Code has a long life. We shouldn't mix > > > > timely things like project status with long lived things like > > > > releases. Websites are examples of timely, short lived documents and > > > > incubation status is a (relatively) short lived state in the long > > > > lives of projects. We shouldn't burden the long lived artifacts with > > > > the orthogonal status of a project. > > > > > > > > Martijn > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament <johndam...@apache.org > > > > > > wrote: > > > > > All, > > > > > > > > > > I'm calling to vote on a proposed policy change. Current guide at > > [1] > > > > > indicates that maven artifacts should include incubator (or > > incubating) > > > > in > > > > > the version string of maven artifacts. Its labeled as a best > > practice, > > > > not > > > > > a requirement and is not a policy followed on other repository > > > management > > > > > tools (e.g. PyPi). > > > > > > > > > > I therefore push forward that the incubator will cease expecting > > > > java-based > > > > > projects to publish artifacts with "-incubating" in the version > > string, > > > > > with the understanding that: > > > > > > > > > > - Incubating is a term used to refer to a project's stability, not > a > > > > > release's stability. It is generally understood that incubating > > > projects > > > > > are not necessarily immature, but may have a potential of failing > to > > > > become > > > > > a TLP. > > > > > - Podling releases are endorsed, the podling itself is not > endorsed. > > > We > > > > > will not approve releases that are blatantly against ASF policies. > > > > > > > > > > > > > > > [ ] +1 Drop the -incubator/-incubating expectation of maven > projects > > > > > [ ] +/0 > > > > > [ ] -1 Don't drop because.... > > > > > > > > > > > > > > > [1]: > > > > > http://incubator.apache.org/guides/release-java.html#best- > > > practice-maven > > > > > > > > > > > > > > > > -- > > > > Become a Wicket expert, learn from the best: > http://wicketinaction.com > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > > > > -- > > Niclas Hedhman, Software Developer > > http://polygene.apache.org <http://zest.apache.org> - New Energy for > Java > > > -- Niclas Hedhman, Software Developer http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
