On Fri, Mar 4, 2016 at 11:27 AM, Misty Stanley-Jones < [email protected]> wrote:
> There is a chicken-and-egg problem here. The solution may be that the only > 'release notes' we have for a patch release like this are links to the JIRA > query and the Github tags which will show the changes. Those two URLs can > be predicted ahead of time and will still work even if we have to go > through multiple RCs. This helps us to stick to not introducing new > features or incompatible changes in patch releases, since we would have no > mechanism to document them. We can also add a Release Notes field to JIRA > so that people can see a draft of the release note for a given issue before > it is even part of a release. > I'm pretty strongly against the only release notes being JIRA links, etc. Most consumers of products (even technical products like Kudu) don't want to parse through technical descriptions. My experience on Hadoop/HDFS is that developers aren't good at deciding when to fill in the 'Release Note' field and even when they do, the automated queries that pull the info end up producing documents with poor organization that aren't very useful to users. I _do_ like the idea of using a 'release notes' field on JIRA or at least a 'Needs release notes' field, so that we can quickly double check when preparing a release that everything that should have been noted was. What's the concern about "predicted ahead of time"? Perhaps we can publish the 'next-version' docs with a header saying "These release notes are work-in-progress for Kudu 0.7.2, which has not yet been released." by means of a special build-time flag? This is what LLVM does, for example: http://llvm.org/docs/ReleaseNotes.html As a consumer of LLVM I appreciate that I can view this page (whose URL never changes) to see what's coming down the pipe. This encourages me to try out release candidates (or even trunk builds) when I see new features or bug fixes that are relevant. -Todd > On Fri, Mar 4, 2016 at 10:33 AM, Jean-Daniel Cryans <[email protected]> > wrote: > > > I talked more to Todd offline, for 0.8.0 we'll try our best to have > release > > notes to be in a releasable format so that it's easy to get them in > before > > cutting an RC. > > > > For 0.7.1 I'm asking for a free pass OR we sink it right away, push the > > release notes ASAP, and roll out a new RC with a 24h voting period. > > > > J-D > > > > On Fri, Mar 4, 2016 at 10:24 AM, Mike Percy <[email protected]> wrote: > > > > > Our release notes come bundled with the source package. In this case > our > > > notes are there in docs/ but it seems strange to only have 0.7.0 > relnotes > > > in a 0.7.1 release tarball. > > > > > > Mike > > > > > > Sent from my iPhone > > > > > > > On Mar 4, 2016, at 6:21 PM, Jean-Daniel Cryans <[email protected]> > > > wrote: > > > > > > > > I feel strongly against having to have the release notes updated on > the > > > > website before being able to roll out an RC. It always takes at least > > one > > > > day to get reviews for that, more on big releases. Then, following > RCs > > > > might also need to have the notes updated, which delays things even > > more. > > > > > > > > If folks care about having some minimal form of release notes, we can > > do > > > > something similar to what HBase does: > > > > https://github.com/apache/hbase/blob/master/CHANGES.txt > > > > > > > > J-D > > > > > > > >> On Fri, Mar 4, 2016 at 8:07 AM, Todd Lipcon <[email protected]> > > wrote: > > > >> > > > >> Perhaps we can keep voting on this release, finish up the release > > notes > > > >> today, and have a quick turnaround on rc2? I imagine if the diff > > between > > > >> the tags is only in the docs/ directory, we can get the voting done > > in a > > > >> couple hours (just verify the sha/signature, no need to rebuild and > > > retest > > > >> if the code is identical) > > > >> > > > >> -Todd > > > >> > > > >> On Fri, Mar 4, 2016 at 6:30 AM, Jean-Daniel Cryans < > > [email protected] > > > > > > > >> wrote: > > > >> > > > >>> Just planning on pushing them to the website when 0.7.1 is > > available.. > > > >>> > > > >>>> On Fri, Mar 4, 2016 at 1:49 AM, Mike Percy <[email protected]> > > wrote: > > > >>>> > > > >>>> Or maybe what you're saying is that you're already planning for an > > > RC2. > > > >>>> > > > >>>>> On Fri, Mar 4, 2016 at 11:47 AM, Mike Percy <[email protected]> > > > wrote: > > > >>>>> > > > >>>>> I'm a little confused about this. So you're saying that we won't > > > >>> include > > > >>>>> release notes in the source artifact for the release? That seems > > > >> pretty > > > >>>>> atypical. > > > >>>>> > > > >>>>> Mike > > > >>>>> > > > >>>>> On Thu, Mar 3, 2016 at 11:34 PM, Jean-Daniel Cryans < > > > >>> [email protected]> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Yeah was planning on casually doing that. My gripe with release > > > >> notes > > > >>> is > > > >>>>>> that they take time to write and review, delaying an RC by days > if > > > >> we > > > >>>> were > > > >>>>>> to wait for them to be written before releasing it. > > > >>>>>> > > > >>>>>> On Thu, Mar 3, 2016 at 1:22 PM, Todd Lipcon <[email protected]> > > > >>> wrote: > > > >>>>>> > > > >>>>>>> Should we edit docs/release_notes.adoc to include release notes > > > >> for > > > >>>>>> 0.7.1 > > > >>>>>>> before releasing? It seems odd that the release wouldn't > mention > > > >> the > > > >>>>>> latest > > > >>>>>>> version in the included release notes. > > > >>>>>>> > > > >>>>>>> -Todd > > > >>>>>>> > > > >>>>>>> On Wed, Mar 2, 2016 at 4:41 PM, Jean-Daniel Cryans < > > > >>>> [email protected] > > > >>>>>>> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Hi, > > > >>>>>>>> > > > >>>>>>>> We're happy to announce the first release candidate for Apache > > > >>> Kudu > > > >>>>>>>> (incubating) 0.7.1. > > > >>>>>>>> > > > >>>>>>>> This release fixes a few important bugs found during the > process > > > >>> of > > > >>>>>>>> releasing 0.7.0 that didn't warrant sinking the vote for. It > > > >> also > > > >>>>>> takes > > > >>>>>>>> care of fixing some licenses. > > > >>>>>>>> > > > >>>>>>>> The is a source-only release. The artifacts were staged here: > > > >> https://dist.apache.org/repos/dist/dev/incubator/kudu/0.7.1-RC1/ > > > >>>>>>>> > > > >>>>>>>> It was built from this tag: > > > >> > > > > > > https://git1-us-west.apache.org/repos/asf?p=incubator-kudu.git;a=commit;h=bd191ec7366e13c3a11c6144f3b5af03d6496b38 > > > >>>>>>>> > > > >>>>>>>> The list of all issues fixed can be found here: > > > >> > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20KUDU%20AND%20fixVersion%20%3D%200.7.1 > > > >>>>>>>> > > > >>>>>>>> KEYS file: > > > >>>>>>>> http://www.apache.org/dist/incubator/kudu/KEYS > > > >>>>>>>> > > > >>>>>>>> I'd suggest going through the README, building Kudu, and > running > > > >>> the > > > >>>>>> unit > > > >>>>>>>> tests. > > > >>>>>>>> > > > >>>>>>>> Please try the release and vote; vote will be open for at > least > > > >> 72 > > > >>>>>> hours. > > > >>>>>>>> > > > >>>>>>>> Thanks, > > > >>>>>>>> > > > >>>>>>>> J-D > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> -- > > > >>>>>>> Todd Lipcon > > > >>>>>>> Software Engineer, Cloudera > > > >> > > > >> > > > >> > > > >> -- > > > >> Todd Lipcon > > > >> Software Engineer, Cloudera > > > >> > > > > > > -- Todd Lipcon Software Engineer, Cloudera
