incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: late learnings, which could be helpful for all mentors to know
Date Wed, 05 Jun 2019 08:05:37 GMT
How about this as compromise?

If the mentors on the project list have voted +1, then the vote can be continued in parallel?
Shouldn't this help reduce both the time votes take but not waste the limited IPMC bandwidth?

Regarding releasing of all repos ... how about this: 
Instead of having to actually DO releases, at least Release Candidates should be created ...
this would prove the general ability to do a release, but not actually DO it. Of course if
these RCs contain bad things, they should not pass.

Having some automated tooling would have the benefit of finding more than currently and it
would at least help with the projects being able to run those checks themselves and therefore
being able to react first. If a RC fails and things are found by the tooling it's not the
person reporting this who is considered the bad guy cause we could all say: It's the standard
tooling that found this and you could have addressed that yourself before releasing. I know
it doesn't find all issues, but if it finds more than currently, then that's a good thing.
The only danger I see is that we (IPMC) might grow comfortable and simply trust on the tool.


Am 05.06.19, 09:50 schrieb "Justin Mclean" <>:

    Please take this as friendly advice with with a bit of experience and personal opinion
thrown in. (if that intent is not obvious).
    > * "parallel votes" is a technique to reduce the lag between dev@ and
    > general@ by starting the IPMC vote slightly after, but before
    > conclusion of the PPMC one. This may have only been tried once (in
    > Zipkin) and met resistance.
    Please start a new thread where this can be discussed as an option. I think the main issue
will be that it takes up too much of a limited resource (i.e. IPMC volunteer time) and it's
better to have the podling checks first, especially for technical issues. I've seen some releases
go though a dozen release candidates before being put up to the IPMC, I don’t think the
IPMC would like to see those dozen release candidates and to have them withdrawn each time.
I understand that it feels inconvenient to podlings who may be used to making technical releases
without voting on them and not checking for licensing and other issues previously. It could
possibly be an option, if approved by the IPMC, for podlings who have previously made 100%
compliant releases.
    > * "bundled votes" is a technique where multiple repos are sent in a
    > single vote. This is much more efficient for coupled repos than
    > pipelining. OpenWhisk uses this and don't appear to have met
    > resistance.
    That is fine but the IPMC will likely complain if it contains too many release artefacts
or it may not attract enough votes due to time commitment required to review. There's also
a risk that if one artefact is broken you need to make another release candidate of everything,
meaning more work for a podling.
    > * not all repos need to actually release prior to graduation. Both
    > Dubbo and OpenWhisk had unreleased repos when they called for
    > graduation.
    The point here is not that all repos need to have releases or be moved over before graduation
but that the podling needs to show that it can make releases on it own that conform to all
legal, release, distribution and other ASF policies. Actually deeper than just that, that
the PPMC can recognise issues when they occur, and most importantly self-correct on their
own. They need to embody the ASF values (usually referred as the Apache Way) in the way they
act, their structure, how they recognises merit and how they makes decisions. Learning to
making releases is a part of that.
    > * You are allowed to automate release process
    Take care with this, most automation is not going to check or find everything. It not
going to know if some code was copied from somewhere it shouldn’t be or that something is
labeled as license A but actually contains something that is Category X or you don’t have
the rights to distribute that cat photo. It will catch obvious errors and is really good at
that. A PPMC needs to learn why we have these policies and the values under them not just
apply "the rules”, using automation in this way  IMO is a little problematic during incubation
as it can hide what the podling needs to show they understand before graduating. I would guess
1/3 to 1/4 of the serious issues the IPMC catches in releases, wouldn’t be found by automation
or a script.
    > * ASF tools like RAT and the release plugin are barely maintained in
    > comparison with Incubator policy.
    There's nothing in Rat that deals with incubator policy. Incubator policy is that releases
need have a DISCLAIMER, have incubating in their name and be voted on by the IPMC. I think
you mean to say ASF’s release, distribution, branding  or other policies? Rat highlights
possible issues, it reports require interpretation and it requires tuning, but It’s in line
with ASF's release policy as far as I’m aware. It tells you how files are likely to be licensed,
what’s missing a header and what binary files you have. I’m not sure it claims to do more
than that. It doesn’t check the content of LICENSE or NOTICE or many other things that are
mentioned in ASF's policies.
    BTW There's no obligation to use Rat, it just one of a bunch of helpful tools used to
find release issues, a project can choose to look fro them how they want. It’s never going
to find 100% of issues (see above). If you want something better (and more work) then Fossology
(free) or Black Duck (not free) might be an option for your project.
    To unsubscribe, e-mail:
    For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message