incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]
Date Mon, 09 Jan 2017 15:13:11 GMT
On Sun, Jan 8, 2017 at 7:26 PM, John D. Ament <johndament@apache.org> wrote:

> On Sun, Jan 8, 2017 at 6:55 PM Niclas Hedhman <niclas@hedhman.org> wrote:
>
> > Yes, I think we all hear your "frustration" that the process is not as
> > streamlined as it perhaps could, nor that the documentation is as solid
> as
> > one might expect (patches are welcome)
> >
> > The underlying "issue" between the previous "GitHub/Maven releases" and
> > "Apache releases" was discussed at length long time ago. Basically,
> pushing
> > something to Maven Central is not a release. It is a "convenience
> service"
> > by the project, and is not at all required from Apache's point of view.
> > This fact may have some repercussions in how you approach the release.
> >
> > Perhaps it is possible to automate a bunch of this, for future podlings
> to
> > benefit from. And perhaps with help from someone who has experienced this
> > recently and have notes, infra could create a self-service portal for
> > setting it up.
> >
> > In Apache Polygene, we have gotten very far in terms of release
> automation,
> > but the initial steps are of course outside our scope. Probably after our
> > next release, we will publish reusable Gradle components for the Apache
> > release process for other Gradle based projects to benefit from. We'll
> see
> > exactly how we do this.
> >
>
> Agreed with all of the above.  In addition, the ASF parent pom is at
> https://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml which can
> have
> a lot more added to it.
>
> It strikes me though from reading your commentary, a lot of what you ran
> into is specific to how your project is setup.  RAT for instance, I
> wouldn't have ignored headers on README.md (it should have headers).
> Standard eclipse files should probably be excluded by default, since those
> are IDE generated values.  However in your case, if the file is in the
> release it should have a valid header.
>
> Release processes are interesting.  Given a similar set of developers, its
> surprisingly high how frequently release steps will differ between
> projects.  Even when it comes to a build.  Some projects like to have an
> explicit RAT check step, others like it with every build.  Different
> projects have different preferences and I think if we standardize it we'll
> start to stifle creativity.
>
>
>
>
> >
> > Cheers
> > Niclas
> >
> >
> > On Mon, Jan 9, 2017 at 1:12 AM, Edward Capriolo <edlinuxguru@gmail.com>
> > wrote:
> >
> > > On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament <johndament@apache.org>
> > > wrote:
> > >
> > > > On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <niclas@hedhman.org>
> > > wrote:
> > > >
> > > > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <
> johndament@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > > So, instead of tying the "incubating" marker to "incubating",
I
> > > would
> > > > > favor
> > > > > > > a system of marker(s) indicating the code maturity (incl
> legal).
> > > So,
> > > > > for a
> > > > > > > podling release to be 1.2.3 (a la Groovy), the same release
> > > standard
> > > > as
> > > > > > > TLPs are applied, but allow "alpha", "rc" or similar markers
> for
> > > > > podlings
> > > > > > > to "practice" releases. Probably not pushing those to mirrors,
> > but
> > > > > > > otherwise identical in "process" for podling to get their
grips
> > on
> > > > the
> > > > > > > release process.
> > > > > > >
> > > > >
> > > > > > I think this is a fair point, and probably close to what podling
> > > > > > communities do (when its a fairly new codebase).  We often see
> > > releases
> > > > > in
> > > > > > the 0.x line, and in the 1+ lines.  Its up to the podling to
> > > determine
> > > > > how
> > > > > > mature they are from a release numbering standpoint.  I wouldn't
> > want
> > > > the
> > > > > > IPMC to enforce a versioning scheme.
> > > > > > It does however seem like a foundation wide versioning scheme
may
> > > make
> > > > > > sense, or at least references to common references, e.g. semver,
> > may
> > > > make
> > > > > > sense as a recommendation to new podlings.
> > > > >
> > > > > Yeah, this is a tricky question. On one hand I don't like to
> dictate,
> > > but
> > > > > as a user I like to have a unified view of the world. Perhaps one
> or
> > > two
> > > > > DOAP entries would be a good way, and more strongly promote the
> DOAP
> > > and
> > > > > over time our common tooling could provide the unified view. A bit
> of
> > > > "be a
> > > > > good citizen.... for your own sake" attitude.
> > > > >
> > > > >
> > > > I'm not sure what you mean by DOAP entries.  Do you have an example?
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > > >
> > > > > Cheers
> > > > > --
> > > > > Niclas Hedhman, Software Developer
> > > > > http://polygene.apache.org - New Energy for Java
> > > > >
> > > >
> > >
> > > But that pendulum has swung in the opposite direction, and podling
> > releases
> > > are now expected to be at ASF TLP levels.
> > >
> > > I agree with this. I have started the gossip podling. Getting the
> release
> > > out to ASF levels is a bit tricky. Let me explain my situation:
> > >
> > > For projects outside of apache I have my own github and I setup an
> > account
> > > on sonatype. I publish two or three artifacts to maven central and
> have a
> > > good amount of foot traffic for what are niche projects.
> > >
> > > github, sonatype, and travis yaml is a lightning fast setup. Sonatype
> > asks
> > > you to submit a jira one time and after that you can publish unlimited
> > > artifacts in your group to maven central.  After the initial setup a
> > single
> > > pom file is all you need to be publishing to maven central.
> > > mvn release clean; mvn release prepare; mvn release perform
> > > With some plugins you can even automate the closing and releasing the
> > > repository if you wish,I still do that by hand in sonatype UI.
> > >
> > > If you compare this with the apache process there are a lot of
> > disconnected
> > > steps. For example, I took on the role of release engineer. We all live
> > in
> > > the stack overflow generation, this document is really great
> > > https://www.apache.org/dev/release-signing.html in its detail, however
> > it
> > > lacks the "here is the 10 steps you actually need" to cut a release. We
> > > also had to schedule a key signing party for me.
> > >
> > > Also it was very difficult to find the stripped down basic pom file. We
> > > luckily got a contributor that did 90% but as we got closer to the
> > release
> > > I had to figure out how the rat plugin works, how to make it exclude
> > things
> > > etc.
> > >
> > >                         <plugin>
> > >                                 <groupId>org.apache.rat</groupId>
> > >
> >  <artifactId>apache-rat-plugin</artifactId>
> > >                                 <configuration>
> > >                                         <excludes>
> > >
> > > <exclude>README.md</exclude>
> > >
> > > <exclude>eclipse_template.xml</exclude>
> > >                                         </excludes>
> > >                                 </configuration>
> > >                                 <executions>
> > >                                         <execution>
> > >                                                 <phase>verify</phase>
> > >                                                 <goals>
> > >
> >  <goal>check</goal>
> > >                                                 </goals>
> > >                                         </execution>
> > >                                 </executions>
> > >                         </plugin>
> > >
> > > You have to go to a different page for the release module configuration
> > >
> > >
> > > <pushChanges>false</pushChanges>
> > >
> > > <localCheckout>true</localCheckout>
> > >
> > > <autoVersionSubmodules>true</autoVersionSubmodules>
> > >
> > >
> > > Now, I know this is just a process of tracking down some other pom file
> > in
> > > the incubator and taking it apart.
> > >
> > > There were other things too like tickets to infra to give me assess to
> > > things svn, release.apache.org. At one point I was following some old
> > doc
> > > in apache which confused me on which server to put my public_html file.
> > >
> > > Please do not take this to mean I am complaining about the current
> > process
> > > or defending my own ignorance! However, if the process stays as it is.
> I
> > do
> > > think one streamline doc could disconnect all the steps. An example
> would
> > > be like this.
> > >
> > > Checklist:
> > >   Have a signed key with WEB of trust? NO - click here.
> > >   Have svn access to path/to/keys ? Create infra ticket/contact podling
> > >   Create INFRA for project jira
> > >   Create INFRA for https://repository.apache.org/
> > >   Complete pom file with special release and rat baked in
> > >   ...
> > >   put your settings in .m2/settings file
> > >
> > > To wrap it up I do not mind the requirements put it was fairly daunting
> > to
> > > connect u all the things that have to happen to make a release compared
> > to
> > > (sonatype,git,travis) and I found the process tricky to navigate. It
> > sapped
> > > more time than I would have liked and often you end up needing help
> from
> > > infra/ podling crew and people are not always free at the same time.
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org <http://zest.apache.org> - New Energy for
> Java
> >
>

For the rat check. I turned it on every build. The reason I did this is
because the release process will not happen unless the rat check passes.
Another such process is the process that checks the javadoc for errors.

In our case 'we forgot to keep the javadoc up to date as an api changes, we
also missed a header. When I finally ran release:perform the process failed
and I had to hot-fix on the RC branch. I find it better to force the
compliance every build than to find small blockers when attempting to cut a
release. That is only a personal preference.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message