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 > > >
