On Fri, Mar 4, 2016 at 8:33 PM, Jean-Daniel Cryans <[email protected]>
wrote:

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

I'd be +0 on skipping for this release. However it probably means we need a
"docs release" tag so we know where to build the docs from for pushing them
to the site. I'm also +1 for a quick 24h vote on RC2, especially if all we
put in it are docs changes relative to RC1.

Personally I don't think relnotes for a patch release need to be at the
standard of a major release. Just a list of the most important changes is
probably sufficient.

Something else we could do is simply "git rm" the release notes from the
master branch docs and make it a web site-only thing. That fully decouples
it from voting, and maybe it makes life easier for the RM.

Mike


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

Reply via email to