Paul, Thanks again. We are all about continuous improvement :)
Lee. On Thu, Jul 25, 2019 at 5:33 PM Paul King <[email protected]> wrote: > [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 > >> > > > >> > > >> > > >
