Hey Mick, I see some promise in the approach you outline. I'd like to explain the advantages my project drew from the current system, so that we don't lose anything important in the process of change. Then I would like to suggest a refinement of your approach. I'm top posting here, because I'm organizing my thoughts a little differently than yours and Justin's
The problem I believe you are expressing ------------------------------------------------------------- Correct me if I've got it wrong. The release process is working as a barrier rather than a path through the incubator. This is especially problematic if a business involved in the project has a commercial requirement for continuous releases. The problem is bigger still if code import is unexpectedly slowed down by any sort of legal or technical issues. This issue could prevent otherwise promising projects from coming to Apache. What I value in the current system ------------------------------------------------------------- When my project (Fineract for the record) moved to the incubator, I read the release voting mails for my own and other's projects. This helped me develop an understanding of what was expected of an Apache release. Justin's emails were by far the most informative. Whether he gave a +1 or a -1, he evaluated the release as far as was possible. For all issues he identified, Justin explained how they contributed to his vote, what would need to change, and whether it blocked a release or blocked graduation. I learned both from the votes on Fineract releases *and* the votes on the other projects in the incubator. Documentation is good, but seeing a process lived is so much more helpful. I say this both as a former podling member and as a mentor who is still learning. And I've heard similar sentiments from many others, including ASF board members. Also, our mentors were not always the most active, so it would have been impossible for us to get a release out at all if we had depended on only them to vote on our releases. We have a shortage of mentors in the incubator. If projects are not willing to accept fly-by help, there may actually not be enough help at all in certain areas. The incubator could be forced to accept less projects. Weex (the podling I'm currently mentoring) currently only has two mentors. If Justin were to stop voting on their releases, they wouldn't be able to make official Apache releases anymore. When Fineract releases were voted on we took the feedback and captured it in Jira tickets. Because our users do not always communicate with us in Jira tickets, we were accustomed to capturing our work items ourselves. We do use Jira, but not all Apache projects do. Weex uses github issues. Expecting someone who is helping many projects to find your issue tracker also seems unreasonable to me. I'd rather have the input in the form of an e-mail than no input at all. When it came time to for Fineract to graduate, no one had to figure out what our last x releases were and check if they conformed. If we had made a release it was at least pretty good, and the evidence of how good was right there on the list. Not only that, but others could observe how we respond to feedback. They had a sense of how we might respond if the board asked us for some change. It was also always clear what Fineract releases the Apache legal shield applied to: all of them. How I'd compose the current suggestions ------------------------------------------------------------- I think Mick's approach of sorting releases into types is promising, and potentially helpful, and I do think that moving away from a binary vote for all releases (+1/-1) can create a path for podlings where what we have now feels like a wall that needs to be jumped over. I'd suggest we stick with emails. If the expectation is that voting produces tickets, the podling is perfectly capable of capturing them. And there are other ways to make a release evaluation less binary. Currently Justin (and many who have started following his example including me), gives a vote, lists what he checked and what he found. It would be possible to list what was checked and what was found without the vote. Instead of a vote, each problem found could be put in the categories you've identified: (not fully ASF compliant, illegal). Informally we already do this. I agree with you, Mick, that we should allow releases outside of the ASF. I think we're all in agreement that that must be resolved before graduation. This means that the ASF legal shield won't apply to these releases. But many projects were already making releases before they started incubating. Removing that legal shield may not be fair to any new committers you gain during incubation. They may believe they are protected when they are not. This is a drawback that we may simply have to accept here. I also believe projects should be able to make nightlies/snapshots/QA builds available for testing without voting both before and after graduation. As a mentor, I _shudder_ at the thought of being asked to vote on a new release every day. Removing the possibility for QA builds only forces project activity behind corporate firewalls. It doesn't enable transparency or community. As to the documentation ------------------------------------------------------------- This is both a typical software project problem and a typical volunteer organization problem: "'somebody' should fix this mess". Whoever takes it on certainly will not be paid for it, and is very likely to get yelled at for it. Given those two conditions, it's actually surprising that it's as good as it is. And that's not even considering the ways in which incubator information is duplicated in other places in the foundation, or contradicted, or linked. Best Regards, Myrle On Mon, Feb 25, 2019 at 10:05 AM Mick Semb Wever <m...@apache.org> wrote: > > 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 > >
