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
