I'll chime in, but on the technical front my experience is rather new in the incubator, i'm still learning.
> Looking at some of the situations we currently have I think we may need > some more general guidance for incubating projects and making releases > after just joining the incubator. By far, the two biggest issues I see are: i) "too many cooks in the kitchen" and IPMC strangers _policing_ the rules on podlings, ii) "There is documentation _all over the place_ and it's not possible to know which of it is outdated and which is still current especially in the face of conflicting information." – Lars Francke. Addressing and improving the rules and process can help. But better documentation, automation of checks, and better communication style and channels, will go a lot further, imho. Another way to think of this is: it is not the podling that failed the release process, but the IPMC that failed the podling. Why were the tooling and documentation not put in place by the IPMC so that it then had to rely upon instead late policing and being the gatekeepers. > In this context “non approved” means > releases or distributions not approved by the PPPM and IPMC (usually by > voting) and available and promoted to the general public. Something that has been brought up is allowing a podling to incrementally improve their releases. What this actually means has not been stated clearly. The different types of resulting podling releases I'm aware of are… a) fully ASF compliant, b) legal but not fully ASF compliant, c) illegally ASF, d) staged/nightly/snapshot, e) external. With these types, my understanding is that a podling needs to demonstrate a number of releases of type (a) before raising its vote for graduation. What's not clear is what releases are (b), and where should (c) releases get hosted? (For example can they simply stay as staged releases.) If the goal is to encourage momentum, and for some podling cultures this means permitting incrementally improving ASF releases, then the more minimal the requirements to (a) are the better, and any shortcomings in releases of type (b) should be listed in a jira ticket rather than as a "-1" vote on the release. So far there's been the effort to minimise the requirements to (a), and this is very appreciated. https://lists.apache.org/thread.html/7690a00c6a8aba9f51a6dfaa9dc9273626715006eab4c43e6893a839@%3Cprivate.incubator.apache.org%3E It's still unclear to me what are all the soft requirements that when violated lead to type (b)? For example this document alludes to the distinction, but not the separation: https://wiki.apache.org/incubator/IncubatorReleaseChecklist Is this documented correctly anywhere? If this was better documented, and violations dealt with as jira tickets, it might well have been enough to have prevented the situation with Zipkin. I'm sure the same is true for the other podlings that have experienced such feedback as abrasive. Another thing is legal violations that lead to (a) but that are not specific to one podling, should not suddenly become a burden on a podling doing its first release. If other releases have the problem, for example it's not been properly identified before, it's brand new or the dust on how to deal with it is still settling, then for the love of god don't decide to pick on it with a podling's *first* release attempt. Get it in order (settled and documented) elsewhere before policing the podling. Taking release violations up with mentors first would also be another way around this problem. I'm also in favour of aiming for deprecating the need for the IPMC votes. With the correct documentation and tooling in place the PPMC vote with 3 mentors approval should be enough to get a release to at least type (b). > This doesn’t > cover snapshots, RCs or nightly which are not advertised to the general > public. Feedback / changes / thoughts from the rest of the IPMC members > welcome. Docker images need to be staged somewhere. Just like the actual convenience binaries need to be signed, checksummed, and tested as-is. So should docker images before they are released to https://hub.docker.com/u/apache Having to build docker images, to verify them as a release candidate, is not cool. Is this something we are to request of Infra? > 2. Can the PPMC make unapproved releases in other places after joining > the incubator? > > No but 3rd parties can and someone from the PPMC can act as a 3rd > party, it must be clear that: > a) These are produced by a 3rd party and not the PPMC and follow > Apache's branding and trademark policy. > b) This is not being used as a mechanism to avoid making Apache > releases. Please make it clear, and do what you can, to support a podling's existing release cadence. The Zipkin community with 15 repositories makes regular (fortnightly) releases. Just because one repository has been migrated to ASF does not mean the other 14 repositories will be (or expect to be) avoiding this release cadence. Neither do they expect trademark/branding issues over the Zipkin name. It is understood that those releases outside of the ASF have to avoid the Apache trademark and anything that implies ASF-endorsed. The distinction between the PPMC and the existing community needs to be written up clearly. As these often will be the same group of people, and people of other cultures/languages may have trouble initially appreciating the important nuance here. > 5. Can the PPMC keep two repos and continue to make releases in the non > Apache one after the code has been moved to the incubator repo? > > No but 3rd parties can. See 2. It’s likely that the old repo name may > need to change to avoid confusion with the Apache project. Please make it clear that during the transition period this applies only to each individual repository, not the original name of the podling. In the situation like Zipkin's, no one is going to be temporarily renaming the 14 external repositories to a different name because only one repository has so far been migrated. regards, Mick --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
