You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Michael Park <mp...@apache.org> on 2016/03/08 05:29:05 UTC
[RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Hi all,
The vote for Mesos 0.27.2 (rc1) has passed with the
following votes.
+1 (Binding)
------------------------------
Kapil Arya
Vinod Kone
Joris Van Remoortere
+1 (Non-binding)
------------------------------
Greg Mann
Michael Browning
There was one -1 non-binding vote from Kevin Klues. I followed up with
Kevin on
the [VOTE] thread, and confirmed that it was ok for us to proceed, since
it's a
flaky test fix that does not affect the resulting binary.
Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/0.27.2
It is recommended to use a mirror to download the release:
http://www.apache.org/dyn/closer.cgi
The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
The mesos-0.27.2.jar has been released to:
https://repository.apache.org
The website (http://mesos.apache.org) will be updated shortly to reflect
this release.
Thanks,
MPark, Joris, Kapil
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Michael Park <mp...@apache.org>.
The Mesosphere deb/rpm packages are available here:
http://open.mesosphere.com/downloads/mesos/
On 7 March 2016 at 23:29, Michael Park <mp...@apache.org> wrote:
> Hi all,
>
> The vote for Mesos 0.27.2 (rc1) has passed with the
> following votes.
>
> +1 (Binding)
> ------------------------------
> Kapil Arya
> Vinod Kone
> Joris Van Remoortere
>
> +1 (Non-binding)
> ------------------------------
> Greg Mann
> Michael Browning
>
> There was one -1 non-binding vote from Kevin Klues. I followed up with
> Kevin on
> the [VOTE] thread, and confirmed that it was ok for us to proceed, since
> it's a
> flaky test fix that does not affect the resulting binary.
>
> Please find the release at:
> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>
> It is recommended to use a mirror to download the release:
> http://www.apache.org/dyn/closer.cgi
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
>
> The mesos-0.27.2.jar has been released to:
> https://repository.apache.org
>
> The website (http://mesos.apache.org) will be updated shortly to reflect
> this release.
>
> Thanks,
>
> MPark, Joris, Kapil
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Cong Wang <cw...@twopensource.com>.
On Tue, Mar 22, 2016 at 5:10 AM, Kevin Klues <kl...@gmail.com> wrote:
> This way it's easy to track the full set of release candidates, as well as
> how they relate to previous release candidates, minor releases, and point
> releases.
There is no essential difference with the current approach which Mesos
uses, logical branches (0.28.1 is a logical branch from 0.28.0 or master
no matter you use tag or branch) are still tagged rather than branched
out.
Branches are just naturally suitable for maintaining logical branches,
they are easier to understand.
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Kevin Klues <kl...@gmail.com>.
The way I've dealt with this on other projects in the past is the following:
1) RC1s for minor releases (e.g., 0.28.0-rc1, 0.29.0-rc1, 0.30-rc1, etc.)
are *always* tagged at some commit on the master branch.
This is only true for actual minor release (i.e. not point releases, e.g.
0.28.1, 0.28.2, etc.)
*0.28.0-rc1* ---> *0.29.0-rc1* ---> *0.30.0-rc1* ---> master
2) RC2s - RNns for minor releases (e.g. 0.28.0-rc2, 0.28.0-rc3
, 0.28.0-rc4
) can either be tagged from the master branch or along a branch originating
from an earlier release candidate.
0.28.0-rc1 --
----
-> master
\ \
\
\--->
*0.28.0-rc4*
\
\---> *0.28.0-rc2*
\
\---> *0.28.0-rc3*
3) Once an RC passes, a tag for the minor release is set as an alias for
the passing RC (.e.g 0.28.0-rc4 -> 0.28.0)
0.28.0-rc1 --
----
-> master
\ \
\
\---> 0.2
8
.0-rc
4 *(0.28.0)*
\
\---> 0.28.0-rc2
\
\---> 0.28.0-rc3
4) Any point releases that need to be made (e.g. 0.28.1, 0.28.2, etc.)
follow the same procedure, except that they don't originate from the master
branch, but rather the tag set for the previous point release.
--
----
-> master
\
\---> 0.2
8
.0-rc
4 (0.28.0)
\
\-----> *0.28.1-rc1*
* \*
* \---> 0.28.1-rc2 (0.28.1)*
* \*
* \---> 0.28.2-rc1 (0.28.2)*
This way it's easy to track the full set of release candidates, as well as
how they relate to previous release candidates, minor releases, and point
releases.
In the past, I've never worried about publishing the branches behind these
tags while building out the RCs, but I see no reason why that should be a
problem. To avoid confusion, we could name them e.g., 0.28.0-rc4-dev and
then grow/shrink them as necessary until we are satisfied with announcing
the RC. At that point, the branch should be dropped and the tag set as e.g.,
0.28.0-rc4.
On Tue, Mar 22, 2016 at 3:40 AM, Joris Van Remoortere <jo...@apache.org>
wrote:
> +1 for branch per RC (if we go with branches). I like your argument against
> re-writing history if we make a mistake.
>
> I think the 2 issues that have come up are:
> 1) visibility into the release process
> 2) pain / lack of context for the release manager of backports to resolve
> merge conflicts for bugs
>
> For 2), Jie's suggestion was that if we had branches set up for future
> backports (even if it were something like 0.24.2-WIP) then committers would
> both:
> a) help amortize the cost of cherry-picking / merge conflicts
> b) have current context about the patch when considering whether it is a
> critical bug fix, as well as backwards compatible
>
> These are likely issues that Vinod will also address in his 1.0 and LTS
> proposals.
>
> On Mon, Mar 21, 2016 at 1:52 PM, Benjamin Mahler <bm...@apache.org>
> wrote:
>
> > A single branch for a release seems brittle because it assumes that RC
> tag
> > N shares the same lineage as RC tag N-1. This is mostly true, but not
> > always. The branching approach that would mirror how I've put together
> > releases would be to have a branch for each RC. The RC N branch is
> usually
> > on top of the RC N-1 branch, but not always.
> >
> > This allows both of the following scenarios:
> >
> > (1)
> > master --------> RC1 ---------> RC2
> >
> > (2)
> > master --------> RC1
> > \--------> RC2
> >
> > Scenario (2) is not possible with a single release branch. The other nice
> > thing about 1 branch per RC is that if we make mistakes, we just create a
> > new branch, rather than re-write history or push out branch removals.
> > Also, we should avoid naming the branch exactly the same as the tag, as
> > that will lead to confusion.
> >
> > But my thought here is that we should take a step back and look at what
> > problems we want to solve with the current tag-only approach. Joris and
> Jie
> > seem to be hinting at there being a lack of visibility into the progress
> of
> > RCs. Is that the issue we're trying to solve? Collaboration on RC's? I
> > haven't done a release in quite some time so it would be great to
> > understand the current pain points.
> >
> > On Mon, Mar 21, 2016 at 1:20 AM, Joris Van Remoortere <jo...@apache.org>
> > wrote:
> >
> > > The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes
> > into
> > > release candidates.
> > >
> > > I'm all for using branches in the repository to put together the
> release
> > > candidates, as well as have committers consider their bug fixes for
> some
> > N
> > > number of backport (future LTS) releases.
> > >
> > > As Kevin and Michael mentioned, tags and branches are different
> concepts.
> > > We can use them together. We still want to create immutable tags to
> point
> > > at releases so that we don't accidentally add new patches to releases
> by
> > > updating a branch.
> > >
> > > I think building up the releases in public branches is a good step
> > towards
> > > improved visibility. I hope this will also increase the accountability
> of
> > > the community to ensure the patches they contribute are committed to
> the
> > > right branches.
> > >
> > > On Fri, Mar 18, 2016 at 8:10 PM, Erik Weathers <
> > > eweathers@groupon.com.invalid> wrote:
> > >
> > > > BTW, if the tag is created against a commit that *doesn't* become
> > > > "unreachable" from HEAD [1], then `git pull` is sufficient to also
> pull
> > > > down the tags.
> > > >
> > > > The only time I've needed to do `git fetch --tags` is when the tagged
> > > > commit SHA gets merged away. So presumably the process being
> followed
> > by
> > > > the core committers / releasers is resulting in these "unreachable"
> > tags.
> > > > Not sure if that is preventable though.
> > > >
> > > > - Erik
> > > >
> > > > [1]
> > > http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
> > > >
> > > > From the git manual (“git help fetch”): [1]
> > > >
> > > > -t, –tags Most of the tags are fetched automatically as branch heads
> > are
> > > > downloaded, but tags that do not point at objects reachable from the
> > > branch
> > > > heads that are being tracked will not be fetched by this mechanism.
> > This
> > > > flag lets all tags and their associated objects be downloaded. The
> > > default
> > > > behavior for a remote may be specified with the remote.<name>.tagopt
> > > > setting. See git-config(1).
> > > >
> > > >
> > > >
> > > > On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <
> > > invitapriore@gmail.com>
> > > > wrote:
> > > >
> > > > > I agree with Kevin -- tags are immutable, so they're naturally
> suited
> > > > > for labeling releases, which ought to be immutable too.
> > > > >
> > > > > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com>
> > > wrote:
> > > > > > I respectfully disagree.
> > > > > >
> > > > > > The whole purpose of tags is to mark permanent things like
> > releases,
> > > > > > whereas branches are designed as temporary lines of development
> > that
> > > > > > come and go (and grow and shrink) dynamically all the time.
> > > > > >
> > > > > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com>
> > wrote:
> > > > > >> I like the idea of using branches to manage releases.
> > > > > >>
> > > > > >> We can use that to manage point releases and backports as well.
> > > > > >>
> > > > > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag
> RCs
> > > in
> > > > > that
> > > > > >> branch. Once the RC is accepted, the head of that branch will
> > become
> > > > the
> > > > > >> release.
> > > > > >>
> > > > > >> Then, we immediate fork that branch and create 0.29.1 branch.
> > > > > >>
> > > > > >> When a new bug fix is committed on the trunk, the committer will
> > > > decide
> > > > > >> whether it'll affect the old releases (a bounded number, we can
> > > decide
> > > > > that
> > > > > >> later). If it does, the committer of that patch should also
> > > > cherry-pick
> > > > > >> that patch to the point releases (e.g., 0.29.1 in this case). We
> > can
> > > > do
> > > > > a
> > > > > >> timely based point releases.
> > > > > >>
> > > > > >> - Jie
> > > > > >>
> > > > > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <
> > cwang@twopensource.com>
> > > > > wrote:
> > > > > >>
> > > > > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <
> > joseph@mesosphere.io>
> > > > > wrote:
> > > > > >>> > Cong Wang,
> > > > > >>> >
> > > > > >>> > The tags are sync'd. See:
> > > > https://github.com/apache/mesos/releases
> > > > > >>> >
> > > > > >>> > You might not have done: git pull --tags
> > > > > >>>
> > > > > >>>
> > > > > >>> Yeah, I figured it out by myself too. This is why I hate tags
> > > > > personally,
> > > > > >>> branches are better since they are fetched without additional
> > > > > parameters.
> > > > > >>>
> > > > > >>> Any reason why Mesos maintainers picked tags over branches to
> > > manage
> > > > > >>> releases? Just curious...
> > > > > >>>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Kevin
> > > > >
> > > >
> > >
> >
>
--
~Kevin
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Joris Van Remoortere <jo...@apache.org>.
+1 for branch per RC (if we go with branches). I like your argument against
re-writing history if we make a mistake.
I think the 2 issues that have come up are:
1) visibility into the release process
2) pain / lack of context for the release manager of backports to resolve
merge conflicts for bugs
For 2), Jie's suggestion was that if we had branches set up for future
backports (even if it were something like 0.24.2-WIP) then committers would
both:
a) help amortize the cost of cherry-picking / merge conflicts
b) have current context about the patch when considering whether it is a
critical bug fix, as well as backwards compatible
These are likely issues that Vinod will also address in his 1.0 and LTS
proposals.
On Mon, Mar 21, 2016 at 1:52 PM, Benjamin Mahler <bm...@apache.org> wrote:
> A single branch for a release seems brittle because it assumes that RC tag
> N shares the same lineage as RC tag N-1. This is mostly true, but not
> always. The branching approach that would mirror how I've put together
> releases would be to have a branch for each RC. The RC N branch is usually
> on top of the RC N-1 branch, but not always.
>
> This allows both of the following scenarios:
>
> (1)
> master --------> RC1 ---------> RC2
>
> (2)
> master --------> RC1
> \--------> RC2
>
> Scenario (2) is not possible with a single release branch. The other nice
> thing about 1 branch per RC is that if we make mistakes, we just create a
> new branch, rather than re-write history or push out branch removals.
> Also, we should avoid naming the branch exactly the same as the tag, as
> that will lead to confusion.
>
> But my thought here is that we should take a step back and look at what
> problems we want to solve with the current tag-only approach. Joris and Jie
> seem to be hinting at there being a lack of visibility into the progress of
> RCs. Is that the issue we're trying to solve? Collaboration on RC's? I
> haven't done a release in quite some time so it would be great to
> understand the current pain points.
>
> On Mon, Mar 21, 2016 at 1:20 AM, Joris Van Remoortere <jo...@apache.org>
> wrote:
>
> > The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes
> into
> > release candidates.
> >
> > I'm all for using branches in the repository to put together the release
> > candidates, as well as have committers consider their bug fixes for some
> N
> > number of backport (future LTS) releases.
> >
> > As Kevin and Michael mentioned, tags and branches are different concepts.
> > We can use them together. We still want to create immutable tags to point
> > at releases so that we don't accidentally add new patches to releases by
> > updating a branch.
> >
> > I think building up the releases in public branches is a good step
> towards
> > improved visibility. I hope this will also increase the accountability of
> > the community to ensure the patches they contribute are committed to the
> > right branches.
> >
> > On Fri, Mar 18, 2016 at 8:10 PM, Erik Weathers <
> > eweathers@groupon.com.invalid> wrote:
> >
> > > BTW, if the tag is created against a commit that *doesn't* become
> > > "unreachable" from HEAD [1], then `git pull` is sufficient to also pull
> > > down the tags.
> > >
> > > The only time I've needed to do `git fetch --tags` is when the tagged
> > > commit SHA gets merged away. So presumably the process being followed
> by
> > > the core committers / releasers is resulting in these "unreachable"
> tags.
> > > Not sure if that is preventable though.
> > >
> > > - Erik
> > >
> > > [1]
> > http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
> > >
> > > From the git manual (“git help fetch”): [1]
> > >
> > > -t, –tags Most of the tags are fetched automatically as branch heads
> are
> > > downloaded, but tags that do not point at objects reachable from the
> > branch
> > > heads that are being tracked will not be fetched by this mechanism.
> This
> > > flag lets all tags and their associated objects be downloaded. The
> > default
> > > behavior for a remote may be specified with the remote.<name>.tagopt
> > > setting. See git-config(1).
> > >
> > >
> > >
> > > On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <
> > invitapriore@gmail.com>
> > > wrote:
> > >
> > > > I agree with Kevin -- tags are immutable, so they're naturally suited
> > > > for labeling releases, which ought to be immutable too.
> > > >
> > > > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com>
> > wrote:
> > > > > I respectfully disagree.
> > > > >
> > > > > The whole purpose of tags is to mark permanent things like
> releases,
> > > > > whereas branches are designed as temporary lines of development
> that
> > > > > come and go (and grow and shrink) dynamically all the time.
> > > > >
> > > > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com>
> wrote:
> > > > >> I like the idea of using branches to manage releases.
> > > > >>
> > > > >> We can use that to manage point releases and backports as well.
> > > > >>
> > > > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs
> > in
> > > > that
> > > > >> branch. Once the RC is accepted, the head of that branch will
> become
> > > the
> > > > >> release.
> > > > >>
> > > > >> Then, we immediate fork that branch and create 0.29.1 branch.
> > > > >>
> > > > >> When a new bug fix is committed on the trunk, the committer will
> > > decide
> > > > >> whether it'll affect the old releases (a bounded number, we can
> > decide
> > > > that
> > > > >> later). If it does, the committer of that patch should also
> > > cherry-pick
> > > > >> that patch to the point releases (e.g., 0.29.1 in this case). We
> can
> > > do
> > > > a
> > > > >> timely based point releases.
> > > > >>
> > > > >> - Jie
> > > > >>
> > > > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <
> cwang@twopensource.com>
> > > > wrote:
> > > > >>
> > > > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <
> joseph@mesosphere.io>
> > > > wrote:
> > > > >>> > Cong Wang,
> > > > >>> >
> > > > >>> > The tags are sync'd. See:
> > > https://github.com/apache/mesos/releases
> > > > >>> >
> > > > >>> > You might not have done: git pull --tags
> > > > >>>
> > > > >>>
> > > > >>> Yeah, I figured it out by myself too. This is why I hate tags
> > > > personally,
> > > > >>> branches are better since they are fetched without additional
> > > > parameters.
> > > > >>>
> > > > >>> Any reason why Mesos maintainers picked tags over branches to
> > manage
> > > > >>> releases? Just curious...
> > > > >>>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~Kevin
> > > >
> > >
> >
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Benjamin Mahler <bm...@apache.org>.
A single branch for a release seems brittle because it assumes that RC tag
N shares the same lineage as RC tag N-1. This is mostly true, but not
always. The branching approach that would mirror how I've put together
releases would be to have a branch for each RC. The RC N branch is usually
on top of the RC N-1 branch, but not always.
This allows both of the following scenarios:
(1)
master --------> RC1 ---------> RC2
(2)
master --------> RC1
\--------> RC2
Scenario (2) is not possible with a single release branch. The other nice
thing about 1 branch per RC is that if we make mistakes, we just create a
new branch, rather than re-write history or push out branch removals.
Also, we should avoid naming the branch exactly the same as the tag, as
that will lead to confusion.
But my thought here is that we should take a step back and look at what
problems we want to solve with the current tag-only approach. Joris and Jie
seem to be hinting at there being a lack of visibility into the progress of
RCs. Is that the issue we're trying to solve? Collaboration on RC's? I
haven't done a release in quite some time so it would be great to
understand the current pain points.
On Mon, Mar 21, 2016 at 1:20 AM, Joris Van Remoortere <jo...@apache.org>
wrote:
> The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes into
> release candidates.
>
> I'm all for using branches in the repository to put together the release
> candidates, as well as have committers consider their bug fixes for some N
> number of backport (future LTS) releases.
>
> As Kevin and Michael mentioned, tags and branches are different concepts.
> We can use them together. We still want to create immutable tags to point
> at releases so that we don't accidentally add new patches to releases by
> updating a branch.
>
> I think building up the releases in public branches is a good step towards
> improved visibility. I hope this will also increase the accountability of
> the community to ensure the patches they contribute are committed to the
> right branches.
>
> On Fri, Mar 18, 2016 at 8:10 PM, Erik Weathers <
> eweathers@groupon.com.invalid> wrote:
>
> > BTW, if the tag is created against a commit that *doesn't* become
> > "unreachable" from HEAD [1], then `git pull` is sufficient to also pull
> > down the tags.
> >
> > The only time I've needed to do `git fetch --tags` is when the tagged
> > commit SHA gets merged away. So presumably the process being followed by
> > the core committers / releasers is resulting in these "unreachable" tags.
> > Not sure if that is preventable though.
> >
> > - Erik
> >
> > [1]
> http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
> >
> > From the git manual (“git help fetch”): [1]
> >
> > -t, –tags Most of the tags are fetched automatically as branch heads are
> > downloaded, but tags that do not point at objects reachable from the
> branch
> > heads that are being tracked will not be fetched by this mechanism. This
> > flag lets all tags and their associated objects be downloaded. The
> default
> > behavior for a remote may be specified with the remote.<name>.tagopt
> > setting. See git-config(1).
> >
> >
> >
> > On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <
> invitapriore@gmail.com>
> > wrote:
> >
> > > I agree with Kevin -- tags are immutable, so they're naturally suited
> > > for labeling releases, which ought to be immutable too.
> > >
> > > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com>
> wrote:
> > > > I respectfully disagree.
> > > >
> > > > The whole purpose of tags is to mark permanent things like releases,
> > > > whereas branches are designed as temporary lines of development that
> > > > come and go (and grow and shrink) dynamically all the time.
> > > >
> > > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
> > > >> I like the idea of using branches to manage releases.
> > > >>
> > > >> We can use that to manage point releases and backports as well.
> > > >>
> > > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs
> in
> > > that
> > > >> branch. Once the RC is accepted, the head of that branch will become
> > the
> > > >> release.
> > > >>
> > > >> Then, we immediate fork that branch and create 0.29.1 branch.
> > > >>
> > > >> When a new bug fix is committed on the trunk, the committer will
> > decide
> > > >> whether it'll affect the old releases (a bounded number, we can
> decide
> > > that
> > > >> later). If it does, the committer of that patch should also
> > cherry-pick
> > > >> that patch to the point releases (e.g., 0.29.1 in this case). We can
> > do
> > > a
> > > >> timely based point releases.
> > > >>
> > > >> - Jie
> > > >>
> > > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com>
> > > wrote:
> > > >>
> > > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io>
> > > wrote:
> > > >>> > Cong Wang,
> > > >>> >
> > > >>> > The tags are sync'd. See:
> > https://github.com/apache/mesos/releases
> > > >>> >
> > > >>> > You might not have done: git pull --tags
> > > >>>
> > > >>>
> > > >>> Yeah, I figured it out by myself too. This is why I hate tags
> > > personally,
> > > >>> branches are better since they are fetched without additional
> > > parameters.
> > > >>>
> > > >>> Any reason why Mesos maintainers picked tags over branches to
> manage
> > > >>> releases? Just curious...
> > > >>>
> > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > >
> >
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Joris Van Remoortere <jo...@apache.org>.
The SHAs rarely exist on HEAD because we tend to cherry-pick bug fixes into
release candidates.
I'm all for using branches in the repository to put together the release
candidates, as well as have committers consider their bug fixes for some N
number of backport (future LTS) releases.
As Kevin and Michael mentioned, tags and branches are different concepts.
We can use them together. We still want to create immutable tags to point
at releases so that we don't accidentally add new patches to releases by
updating a branch.
I think building up the releases in public branches is a good step towards
improved visibility. I hope this will also increase the accountability of
the community to ensure the patches they contribute are committed to the
right branches.
On Fri, Mar 18, 2016 at 8:10 PM, Erik Weathers <
eweathers@groupon.com.invalid> wrote:
> BTW, if the tag is created against a commit that *doesn't* become
> "unreachable" from HEAD [1], then `git pull` is sufficient to also pull
> down the tags.
>
> The only time I've needed to do `git fetch --tags` is when the tagged
> commit SHA gets merged away. So presumably the process being followed by
> the core committers / releasers is resulting in these "unreachable" tags.
> Not sure if that is preventable though.
>
> - Erik
>
> [1] http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
>
> From the git manual (“git help fetch”): [1]
>
> -t, –tags Most of the tags are fetched automatically as branch heads are
> downloaded, but tags that do not point at objects reachable from the branch
> heads that are being tracked will not be fetched by this mechanism. This
> flag lets all tags and their associated objects be downloaded. The default
> behavior for a remote may be specified with the remote.<name>.tagopt
> setting. See git-config(1).
>
>
>
> On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <in...@gmail.com>
> wrote:
>
> > I agree with Kevin -- tags are immutable, so they're naturally suited
> > for labeling releases, which ought to be immutable too.
> >
> > On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com> wrote:
> > > I respectfully disagree.
> > >
> > > The whole purpose of tags is to mark permanent things like releases,
> > > whereas branches are designed as temporary lines of development that
> > > come and go (and grow and shrink) dynamically all the time.
> > >
> > > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
> > >> I like the idea of using branches to manage releases.
> > >>
> > >> We can use that to manage point releases and backports as well.
> > >>
> > >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in
> > that
> > >> branch. Once the RC is accepted, the head of that branch will become
> the
> > >> release.
> > >>
> > >> Then, we immediate fork that branch and create 0.29.1 branch.
> > >>
> > >> When a new bug fix is committed on the trunk, the committer will
> decide
> > >> whether it'll affect the old releases (a bounded number, we can decide
> > that
> > >> later). If it does, the committer of that patch should also
> cherry-pick
> > >> that patch to the point releases (e.g., 0.29.1 in this case). We can
> do
> > a
> > >> timely based point releases.
> > >>
> > >> - Jie
> > >>
> > >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com>
> > wrote:
> > >>
> > >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io>
> > wrote:
> > >>> > Cong Wang,
> > >>> >
> > >>> > The tags are sync'd. See:
> https://github.com/apache/mesos/releases
> > >>> >
> > >>> > You might not have done: git pull --tags
> > >>>
> > >>>
> > >>> Yeah, I figured it out by myself too. This is why I hate tags
> > personally,
> > >>> branches are better since they are fetched without additional
> > parameters.
> > >>>
> > >>> Any reason why Mesos maintainers picked tags over branches to manage
> > >>> releases? Just curious...
> > >>>
> > >
> > >
> > >
> > > --
> > > ~Kevin
> >
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Erik Weathers <ew...@groupon.com.INVALID>.
BTW, if the tag is created against a commit that *doesn't* become
"unreachable" from HEAD [1], then `git pull` is sufficient to also pull
down the tags.
The only time I've needed to do `git fetch --tags` is when the tagged
commit SHA gets merged away. So presumably the process being followed by
the core committers / releasers is resulting in these "unreachable" tags.
Not sure if that is preventable though.
- Erik
[1] http://eddiemoya.com/2013/02/21/better-git-git-fetch-not-getting-tags/
>From the git manual (“git help fetch”): [1]
-t, –tags Most of the tags are fetched automatically as branch heads are
downloaded, but tags that do not point at objects reachable from the branch
heads that are being tracked will not be fetched by this mechanism. This
flag lets all tags and their associated objects be downloaded. The default
behavior for a remote may be specified with the remote.<name>.tagopt
setting. See git-config(1).
On Fri, Mar 18, 2016 at 6:22 PM, Michael Browning <in...@gmail.com>
wrote:
> I agree with Kevin -- tags are immutable, so they're naturally suited
> for labeling releases, which ought to be immutable too.
>
> On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com> wrote:
> > I respectfully disagree.
> >
> > The whole purpose of tags is to mark permanent things like releases,
> > whereas branches are designed as temporary lines of development that
> > come and go (and grow and shrink) dynamically all the time.
> >
> > On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
> >> I like the idea of using branches to manage releases.
> >>
> >> We can use that to manage point releases and backports as well.
> >>
> >> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in
> that
> >> branch. Once the RC is accepted, the head of that branch will become the
> >> release.
> >>
> >> Then, we immediate fork that branch and create 0.29.1 branch.
> >>
> >> When a new bug fix is committed on the trunk, the committer will decide
> >> whether it'll affect the old releases (a bounded number, we can decide
> that
> >> later). If it does, the committer of that patch should also cherry-pick
> >> that patch to the point releases (e.g., 0.29.1 in this case). We can do
> a
> >> timely based point releases.
> >>
> >> - Jie
> >>
> >> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com>
> wrote:
> >>
> >>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io>
> wrote:
> >>> > Cong Wang,
> >>> >
> >>> > The tags are sync'd. See: https://github.com/apache/mesos/releases
> >>> >
> >>> > You might not have done: git pull --tags
> >>>
> >>>
> >>> Yeah, I figured it out by myself too. This is why I hate tags
> personally,
> >>> branches are better since they are fetched without additional
> parameters.
> >>>
> >>> Any reason why Mesos maintainers picked tags over branches to manage
> >>> releases? Just curious...
> >>>
> >
> >
> >
> > --
> > ~Kevin
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Michael Browning <in...@gmail.com>.
I agree with Kevin -- tags are immutable, so they're naturally suited
for labeling releases, which ought to be immutable too.
On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com> wrote:
> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
> whereas branches are designed as temporary lines of development that
> come and go (and grow and shrink) dynamically all the time.
>
> On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
>> I like the idea of using branches to manage releases.
>>
>> We can use that to manage point releases and backports as well.
>>
>> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
>> branch. Once the RC is accepted, the head of that branch will become the
>> release.
>>
>> Then, we immediate fork that branch and create 0.29.1 branch.
>>
>> When a new bug fix is committed on the trunk, the committer will decide
>> whether it'll affect the old releases (a bounded number, we can decide that
>> later). If it does, the committer of that patch should also cherry-pick
>> that patch to the point releases (e.g., 0.29.1 in this case). We can do a
>> timely based point releases.
>>
>> - Jie
>>
>> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com> wrote:
>>
>>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io> wrote:
>>> > Cong Wang,
>>> >
>>> > The tags are sync'd. See: https://github.com/apache/mesos/releases
>>> >
>>> > You might not have done: git pull --tags
>>>
>>>
>>> Yeah, I figured it out by myself too. This is why I hate tags personally,
>>> branches are better since they are fetched without additional parameters.
>>>
>>> Any reason why Mesos maintainers picked tags over branches to manage
>>> releases? Just curious...
>>>
>
>
>
> --
> ~Kevin
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Klaus Ma <kl...@gmail.com>.
@team, are we going to provide LTS version? If so, we definitely need a
branch to back merge issues; if not, we release a new version monthly (??),
we'd suggest user to upgrade to next release.
----
Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
Platform OpenSource Technology, STG, IBM GCG
+86-10-8245 4084 | klaus1982.cn@gmail.com | http://k82.me
On Sat, Mar 19, 2016 at 7:59 AM, Kevin Klues <kl...@gmail.com> wrote:
> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
> whereas branches are designed as temporary lines of development that
> come and go (and grow and shrink) dynamically all the time.
>
> On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
> > I like the idea of using branches to manage releases.
> >
> > We can use that to manage point releases and backports as well.
> >
> > Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in
> that
> > branch. Once the RC is accepted, the head of that branch will become the
> > release.
> >
> > Then, we immediate fork that branch and create 0.29.1 branch.
> >
> > When a new bug fix is committed on the trunk, the committer will decide
> > whether it'll affect the old releases (a bounded number, we can decide
> that
> > later). If it does, the committer of that patch should also cherry-pick
> > that patch to the point releases (e.g., 0.29.1 in this case). We can do a
> > timely based point releases.
> >
> > - Jie
> >
> > On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com>
> wrote:
> >
> >> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io>
> wrote:
> >> > Cong Wang,
> >> >
> >> > The tags are sync'd. See: https://github.com/apache/mesos/releases
> >> >
> >> > You might not have done: git pull --tags
> >>
> >>
> >> Yeah, I figured it out by myself too. This is why I hate tags
> personally,
> >> branches are better since they are fetched without additional
> parameters.
> >>
> >> Any reason why Mesos maintainers picked tags over branches to manage
> >> releases? Just curious...
> >>
>
>
>
> --
> ~Kevin
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Cong Wang <cw...@twopensource.com>.
On Fri, Mar 18, 2016 at 4:59 PM, Kevin Klues <kl...@gmail.com> wrote:
> I respectfully disagree.
>
> The whole purpose of tags is to mark permanent things like releases,
> whereas branches are designed as temporary lines of development that
> come and go (and grow and shrink) dynamically all the time.
Tags are still needed even when you use branches. The base releases
are still need to be tagged obviously. The difference is that the sub-release
tags will not be in master brach any more once we switch to branches,
they will just stay in their own branches.
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Kevin Klues <kl...@gmail.com>.
I respectfully disagree.
The whole purpose of tags is to mark permanent things like releases,
whereas branches are designed as temporary lines of development that
come and go (and grow and shrink) dynamically all the time.
On Fri, Mar 18, 2016 at 4:04 PM, Jie Yu <yu...@gmail.com> wrote:
> I like the idea of using branches to manage releases.
>
> We can use that to manage point releases and backports as well.
>
> Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
> branch. Once the RC is accepted, the head of that branch will become the
> release.
>
> Then, we immediate fork that branch and create 0.29.1 branch.
>
> When a new bug fix is committed on the trunk, the committer will decide
> whether it'll affect the old releases (a bounded number, we can decide that
> later). If it does, the committer of that patch should also cherry-pick
> that patch to the point releases (e.g., 0.29.1 in this case). We can do a
> timely based point releases.
>
> - Jie
>
> On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com> wrote:
>
>> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io> wrote:
>> > Cong Wang,
>> >
>> > The tags are sync'd. See: https://github.com/apache/mesos/releases
>> >
>> > You might not have done: git pull --tags
>>
>>
>> Yeah, I figured it out by myself too. This is why I hate tags personally,
>> branches are better since they are fetched without additional parameters.
>>
>> Any reason why Mesos maintainers picked tags over branches to manage
>> releases? Just curious...
>>
--
~Kevin
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Jie Yu <yu...@gmail.com>.
I like the idea of using branches to manage releases.
We can use that to manage point releases and backports as well.
Say we want to cut 0.29.0 now, we fork a branch 0.29.0 and tag RCs in that
branch. Once the RC is accepted, the head of that branch will become the
release.
Then, we immediate fork that branch and create 0.29.1 branch.
When a new bug fix is committed on the trunk, the committer will decide
whether it'll affect the old releases (a bounded number, we can decide that
later). If it does, the committer of that patch should also cherry-pick
that patch to the point releases (e.g., 0.29.1 in this case). We can do a
timely based point releases.
- Jie
On Fri, Mar 18, 2016 at 1:35 PM, Cong Wang <cw...@twopensource.com> wrote:
> On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io> wrote:
> > Cong Wang,
> >
> > The tags are sync'd. See: https://github.com/apache/mesos/releases
> >
> > You might not have done: git pull --tags
>
>
> Yeah, I figured it out by myself too. This is why I hate tags personally,
> branches are better since they are fetched without additional parameters.
>
> Any reason why Mesos maintainers picked tags over branches to manage
> releases? Just curious...
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 11:56 AM, Joseph Wu <jo...@mesosphere.io> wrote:
> Cong Wang,
>
> The tags are sync'd. See: https://github.com/apache/mesos/releases
>
> You might not have done: git pull --tags
Yeah, I figured it out by myself too. This is why I hate tags personally,
branches are better since they are fetched without additional parameters.
Any reason why Mesos maintainers picked tags over branches to manage
releases? Just curious...
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Joseph Wu <jo...@mesosphere.io>.
Cong Wang,
The tags are sync'd. See: https://github.com/apache/mesos/releases
You might not have done: git pull --tags
On Wed, Mar 16, 2016 at 11:49 AM, Cong Wang <cw...@twopensource.com> wrote:
> On Mon, Mar 7, 2016 at 8:29 PM, Michael Park <mp...@apache.org> wrote:
> > Please find the release at:
> > https://dist.apache.org/repos/dist/release/mesos/0.27.2
> >
> > It is recommended to use a mirror to download the release:
> > http://www.apache.org/dyn/closer.cgi
> >
> > The CHANGELOG for the release is available at:
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
> >
> > The mesos-0.27.2.jar has been released to:
> > https://repository.apache.org
> >
>
> So why the git tags are not synced to github mirror?
>
> $ git tag -l | grep '0\.27\.2'
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Joseph Wu <jo...@mesosphere.io>.
Cong Wang,
The tags are sync'd. See: https://github.com/apache/mesos/releases
You might not have done: git pull --tags
On Wed, Mar 16, 2016 at 11:49 AM, Cong Wang <cw...@twopensource.com> wrote:
> On Mon, Mar 7, 2016 at 8:29 PM, Michael Park <mp...@apache.org> wrote:
> > Please find the release at:
> > https://dist.apache.org/repos/dist/release/mesos/0.27.2
> >
> > It is recommended to use a mirror to download the release:
> > http://www.apache.org/dyn/closer.cgi
> >
> > The CHANGELOG for the release is available at:
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
> >
> > The mesos-0.27.2.jar has been released to:
> > https://repository.apache.org
> >
>
> So why the git tags are not synced to github mirror?
>
> $ git tag -l | grep '0\.27\.2'
>
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 11:49 AM, Cong Wang <cw...@twopensource.com> wrote:
> On Mon, Mar 7, 2016 at 8:29 PM, Michael Park <mp...@apache.org> wrote:
>> Please find the release at:
>> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>>
>> It is recommended to use a mirror to download the release:
>> http://www.apache.org/dyn/closer.cgi
>>
>> The CHANGELOG for the release is available at:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
>>
>> The mesos-0.27.2.jar has been released to:
>> https://repository.apache.org
>>
>
> So why the git tags are not synced to github mirror?
>
> $ git tag -l | grep '0\.27\.2'
Oh, my bad, I keep forgetting to add --tags to git-fetch:
$ git tag -l | grep '0\.27\.2'
0.27.2
0.27.2-rc1
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Cong Wang <cw...@twopensource.com>.
On Mon, Mar 7, 2016 at 8:29 PM, Michael Park <mp...@apache.org> wrote:
> Please find the release at:
> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>
> It is recommended to use a mirror to download the release:
> http://www.apache.org/dyn/closer.cgi
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
>
> The mesos-0.27.2.jar has been released to:
> https://repository.apache.org
>
So why the git tags are not synced to github mirror?
$ git tag -l | grep '0\.27\.2'
Re: [RESULT][VOTE] Release Apache Mesos 0.27.2 (rc1)
Posted by Michael Park <mp...@apache.org>.
The Mesosphere deb/rpm packages are available here:
http://open.mesosphere.com/downloads/mesos/
On 7 March 2016 at 23:29, Michael Park <mp...@apache.org> wrote:
> Hi all,
>
> The vote for Mesos 0.27.2 (rc1) has passed with the
> following votes.
>
> +1 (Binding)
> ------------------------------
> Kapil Arya
> Vinod Kone
> Joris Van Remoortere
>
> +1 (Non-binding)
> ------------------------------
> Greg Mann
> Michael Browning
>
> There was one -1 non-binding vote from Kevin Klues. I followed up with
> Kevin on
> the [VOTE] thread, and confirmed that it was ok for us to proceed, since
> it's a
> flaky test fix that does not affect the resulting binary.
>
> Please find the release at:
> https://dist.apache.org/repos/dist/release/mesos/0.27.2
>
> It is recommended to use a mirror to download the release:
> http://www.apache.org/dyn/closer.cgi
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2
>
> The mesos-0.27.2.jar has been released to:
> https://repository.apache.org
>
> The website (http://mesos.apache.org) will be updated shortly to reflect
> this release.
>
> Thanks,
>
> MPark, Joris, Kapil
>