incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <justinmcl...@me.com>
Subject Re: late learnings, which could be helpful for all mentors to know
Date Wed, 05 Jun 2019 07:50:04 GMT
Hi,

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.

Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message