incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <adrian.f.c...@gmail.com>
Subject late learnings, which could be helpful for all mentors to know
Date Wed, 05 Jun 2019 04:21:58 GMT
Hi, all.

Through Zipkin's incubation, I noticed that knowledge of state of the
art is not equally distributed. Some voting approaches already in use
aren't known. Also what you can use to automate isn't known. As
podlings don't always know the right questions to ask, it might be
beneficial for future podlings if some advice about state of the art
was taught instead. This is especially important as many projects will
likely want to import multiple repos. I will inventory some.

* "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.
* "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.
* not all repos need to actually release prior to graduation. Both
Dubbo and OpenWhisk had unreleased repos when they called for
graduation (OpenWhisk has dozens). It isn't intuitive for projects to
know they don't have to release every repo, so they should be told
this.
* Jenkins is most ASF, but Travis is ok, but CircleCI is not, and
maybe Appveyor is ok.  All we know now, is that CircleCI is not ok,
which is personally fine, but basically people should be able to know
what CI tools are allowed to be used.
* You are allowed to automate release process, even with Travis. It
can be confusing to know what you are allowed to automate, and whether
it must be done with ASF infra etc. The most elaborate example is
https://github.com/apache/incubator-openwhisk-release
* ASF tools like RAT and the release plugin are barely maintained in
comparison with Incubator policy. It is unintuitive that tools
projects use to audit themselves don't evolve lock-step with general
software, policy and discussion. This feels bad whenever told, but
earlier is better.

Anyway, figured I would send off these notes so that folks entering
the incubator don't end up with a lot of unnecessary grief, irritation
due to ignorance about state of the art, or the disparity between
project-specific ASF tools and general ASF tools.

-A

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


Mime
View raw message