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.
Chris
Am 05.06.19, 09:50 schrieb "Justin Mclean" <justinmcl...@me.com>:
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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
