[Oops, I hit reply not reply-all and missed the list. Here it is again for the list. Also, with pedantic hat on, second stage voting email is [email protected] (not incubator@general).]
It sounds like you have understood. I'll just add some comments. The two stages are mentioned in the incubator cookbook[1], so you can always refer to that. In terms of wording, I wouldn't use "majority or 3". If your PMC ever shrunk down to three in size, a majority would be 2 but you'd need all 3 members to vote +1 to make it official. The official wording[2] is: at least three binding +1 votes and more +1 votes than -1 votes. [P.S. don't ever let your PMC get down to 3 :-)] It is true that all votes have equal weight but you would be wise to listen to your mentors. If you get 4 +1s from non-mentors but a mentor votes -1 and says you have a major problem, the vote has technically passed but you would be unwise to not listen to the feedback. Firstly, it probably won't get past the second round and secondly it is an indication that you haven't as a project grasped the Apache Way of producing high quality artifacts that people can trust and that's probably a red flag as you head towards graduation. In terms of recommended practice, it might also be useful to reference the official release policy. The relevant sections are "summary of release approval process"[3], "what every release must contain"[4] and the "release licensing FAQ"[5]. There is also a useful page on checking hashes and signatures[6]. Cheers, Paul. [1] http://incubator.apache.org/cookbook/#podling_releases [2] http://www.apache.org/foundation/glossary.html#MajorityApproval [3] http://www.apache.org/legal/release-policy.html#release-approval [4] http://www.apache.org/legal/release-policy.html#what-must-every-release-contain [5] http://www.apache.org/legal/release-policy.html#license [6] https://www.apache.org/info/verification.html On Fri, Jul 26, 2019 at 5:25 AM leerho <[email protected]> wrote: > Paul, > Thanks for the clarification. I would like to re-write the steps to make > the process absolutely clear: > > The Voting Process: > > Stage 1: On dev@: > > The VOTE letter is issued and voting stays open for 72+ hours. > > The PPMC members including Mentors vote. All votes have equal weight. > > When a majority or 3 (+1) votes are collected and 72 hours have elapsed, > the process moves to the next stage. > > > Stage 2: On incubator@general > > The VOTE letter is issued and voting stays open for 72+ hours. > When a majority or 3 (+1) *binding* votes (any IPMC members including our > Mentors) are collected and 72 hours have elapsed, > > *then* we can deploy a Release. > > > Recommended Practice for Voters: > > - It is good practice to describe what was checked when voting - then > other voters can exercise some judgement about what extra things they > might > check over and above what might be called the minimal required steps > (e.g. > naming, license, notice files, no binary files normally considered > mandatory - building from source, running test suite, building project > website if applicable might be considered extra steps). > > > > On Wed, Jul 24, 2019 at 7:09 PM Paul King <[email protected]> wrote: > >> On Thu, Jul 25, 2019 at 10:17 AM leerho <[email protected]> wrote: >> >> > Kenn, >> > Thank you for your thoughtful comments! >> > >> > 1. The versioning / branching / tagging / SNAPSHOT / RC / Release >> process. >> > >> > We actually had a long discussion on this and discussed several >> > variations. We were hoping to keep it simple and not have a separate >> > branch for each release, but you bring up a good point about always >> having >> > master with SNAPSHOT, so it can never be accidentally forked and >> confused >> > with a real release. We will move to this for the next go around. >> > >> > 2. Putting Jars in Maven Central prior to the Vote. >> > >> > Since we are talking about RCs, it wasn't clear to me that ASF would >> > approve of a podling putting RCs into staging before the vote. If it is >> > OK, we will definitely do that the next go around. >> > >> >> You would normally publish to a temporary ASF repo during voting, here is >> what Commons CSV used recently: >> >> https://repository.apache.org/content/repositories/orgapachecommons-1440/ >> >> If you go there now you will see it has been deleted once voting >> succeeded. >> They also use Maven, so perhaps looking at their setup/release >> instructions >> might give you pointers. In Apache Groovy we use Gradle and do a similar >> thing but have a slightly different setup to normal. >> >> ## A question for you: Is it possible to deploy RCs (or Releases) >> directly >> >> > to Maven Central using the command line or SVN (or SFTP) ? (i.e., >> without >> > using Maven). >> > >> > 3. Adding slf4j backend. Good suggestion. We will fix that on the >> next >> > go around. >> > >> > 4. Are our Javadocs versioned? Effectively yes (but the user has to do >> a >> > wee bit of work :) ) >> > >> > - From the dist Zip file: after the user unzips the package they can >> > generate their own Javadocs easily. >> > - When we release to Maven Central we deploy a javadoc.jar along with >> > the other release jars. >> > >> > However, so far we have wanted the Javadocs visible from the website >> to >> > be the latest and greatest, thus are snapshots. We could easily change >> > this to showing only the latest release Javadocs, but have not made this >> > explicit decision. >> > >> > 5. The voting rules: >> > >> > You might say only IPMC members' votes are binding. This is true only >> for >> > the vote on general@incubator. For the podling, the PPMC votes should >> be >> > considered binding as to whether or not the artifact should go on to the >> > IPMC vote. >> > >> > >> > "whether or not the artifact should go on to the IPMC vote" is still >> fuzzy >> > because Mentors are IPMC members. >> > >> > Are you saying the following? >> > >> > a) On dev@: >> > >> > The VOTE letter is issued and voting stays open for 72+ hours. >> > >> > The PPMC members (not mentors who are IPMC members) vote. >> > >> > When a majority or 3 (+1) votes are collected the baton is handed to the >> > Mentors to vote. >> > When a majority or 3 (+1) votes are collected from the Mentors the >> baton is >> > handed to incubator@general >> > >> >> It's a two stage process. In the first stage, PPMC members are required to >> vote and you can think of your mentors wearing their PPMC hats in this >> stage when they vote. You need 3 votes from any PPMC members. It's just >> good if some of the votes are from your mentors. >> >> In the second stage, IPMC members vote and your mentors would have their >> IPMC hats on for this bit. If you had three mentor votes in the first >> round >> you can think of them carrying over into the second round - although >> formally they would normally vote again explicitly on the second vote >> email >> to general@incubator. Also, if your mentors have voted in the first >> round, >> you *might* find that other IPMC members feel less need to be as thorough >> when they vote. "Might" because we encourage thorough checks if folks have >> the time! :-) >> >> It's also good practice to describe what was checked when voting - then >> other voters can exercise some judgement about what extra things they >> might >> check over and above what might be called the minimal required steps (e.g. >> naming, license, notice files, no binary files normally considered >> mandatory - building from source, running test suite, building project >> website if applicable might be considered extra steps). >> >> Cheers, Paul. >> >> b) On incubator@general >> > >> > The VOTE letter is issued and voting stays open for 72+ hours. >> > When a majority or 3 (+1) binding votes (other IPMC members) are >> collected, >> > *then* we can deploy a Release. >> > >> > >> > BTW, I have not seen this level of process detail described anywhere. >> I am >> > not objecting, it is just that more clarity would have been helpful :) >> > >> > Lee. >> > >> > On Wed, Jul 24, 2019 at 3:20 PM Kenneth Knowles <[email protected]> >> wrote: >> > >> > > On Tue, Jul 23, 2019 at 3:37 PM leerho <[email protected]> wrote: >> > > >> > > > >> > > > NOTE 2: All of the code has been properly refactored with >> > > > "org.apache.datasketches...". >> > > > All source files have the proper Apache license and have been >> checked >> > > with >> > > > the Maven Rat Plugin. >> > > > The code passes all tests with a coverage of > 98%. >> > > > >> > > >> > > This is really great to have done. Nice! >> > > >> > > >> > > > Git Tag for this release: >> > > > >> > > > >> > > >> > >> https://github.com/apache/incubator-datasketches-memory/tree/1.0.0-incubating-RC2 >> > > > >> > > >> > > I notice that throughout the git history every commit has version >> > > 1.0.0-incubating. You may have considered this already, but maven >> > supports >> > > 1.0.0-incubating-SNAPSHOT which will avoid inappropriate caching. At >> > > publish time it will be replaced with a timestamp, if I recall the >> exact >> > > system. So it often makes sense for every mainline commit on the >> master >> > > branch to have this version in the pom.xml and you just make a single >> > > tagged commit not on master where the version has been changed. >> > > >> > > master --a--b--c--d--e--f-- ... >> > > \ \ >> > > x y >> > > >> > > All of a, b, c, d, e, f can have a SNAPSHOT version while x and y, >> which >> > > exist just to build an RC, can have a non-SNAPSHOT version. >> > > >> > > 5. Repository: Maven Central (repository.apache.org): >> > > > >> > > > Upon acceptance the jar artifacts will be generated from the source >> > > > repository and deployed >> > > > to the Apache Maven Central staging repository: >> > > > >> > > > >> > > > >> > > >> > >> https://repository.apache.org/content/groups/staging/org/apache/datasketches/memory/ >> > > > >> > > >> > > It might be nice to do the staging prior to the vote. Technically they >> > are >> > > "convenience binaries" but it is helpful to test them as well, to >> uncover >> > > any problems before approving the release. Avoids voting +1 on source >> > that >> > > ends up building a bad binary. >> > > >> > > >> > > > $ mvn clean test -P strict >> > > > >> > > > Note also that when running the test suite, you might get the >> following >> > > > message: >> > > > >> > > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". >> > > > SLF4J: Defaulting to no-operation (NOP) logger implementation >> > > > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for >> > > > further details. >> > > > >> > > > This is normal. It just indicates that in your environment, you do >> not >> > > > have a logger in your class-path so the default logger of a no-op is >> > used >> > > > instead. >> > > > >> > > >> > > You should be able to add an slf4j backend to the <scope>test</scope> >> in >> > > your pom.xml so it does not depend on the user/contributor to do so. >> > > >> > > The documentation for the DataSketches Memory component is part of the >> > > > website. >> > > > >> > > > Overview documentation: >> > > > - https://datasketches.github.io/docs/Memory/MemoryPackage.html >> > > > - https://datasketches.github.io/docs/Memory/MemoryPerformance.html >> > > > >> > > > Javadocs: >> > > > >> https://datasketches.github.io/api/memory/snapshot/apidocs/index.html >> > > > >> > > >> > > Is there a versioned revision to the javadocs that could also be >> > previewed >> > > as part of the RC? >> > > >> > > 8. The vote will be performed in two stages: >> > > > - This letter will be published on dev@ open for at least 72 >> hours >> > or >> > > > until necessary number of votes are reached. >> > > > - This letter will be published on incubator@general for at >> least >> > 72 >> > > > hours or until necessary number of votes are reached. >> > > > >> > > >> > > As mentioned on the [VOTE] thread, votes should stay open for 72 >> hours. >> > > >> > > >> > > >> > > > Anybody can vote, but only IPMC member's votes count. >> > > > >> > > >> > > You might say only IPMC members' votes are binding. This is true only >> for >> > > the vote on general@incubator. For the podling, the PPMC votes >> should be >> > > considered binding as to whether or not the artifact should go on to >> the >> > > IPMC vote. >> > > >> > > >> > > > The Apache DataSketches Team >> > > > >> > > >> > > I believe you should sign your emails as yourself. >> > > >> > > Kenn >> > > >> > >> >
