You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Evans Ye <ev...@apache.org> on 2017/06/25 17:54:29 UTC
Re: [DISCUSS] Bigtop 1.2.1 release
Hi all,
Olaf asked on slack that how do we do 1.2.1 release when there's no patch
goes in 1.2-branch and most on the patches for 1.2.1 are on master.
My thinking is directly release 1.2.1 version from master, with following
reasons:
1. We did not bump master to 1.3.0-SNAPSHOT
2. With small number of components upgraded we can say it's a minor version
release for bigtop. We've discussed this to meet the goal of release
earlier, release often.
3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1 except
Debian-9 support, which may or may not be excluded because it's quite
independent.
4. We don't have too much resource to maintain two release lines. We shall
better keep it simple as long as it's still a reasonable way.
We're close to the end of June so I'll start to prepare the release. For
those doc related JIRAs, I'll try to get them polished before the release.
Please help me to get the others fixed if you've some free cycles :)
[1]. https://s.apache.org/byeu
2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> > you have time to get it to the finish line recently?
>
> Unfortunately, I don't have enough knowledge about it to really
> understand what's needed and what's not, the install.sh I have
> edited so far is mostly "err, this file doesn't exist anymore,
> let's comment the line to let the compilation continue".
>
> So I do have a compiling solr 6, but I'm fairly certain the
> generated packages are incomplete :/
>
> Arnaud.
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Evans Ye <ev...@apache.org>.
Thanks for picking that up.
Once we all agreed the approach to release 1.2.1 directly from master. I'll
retag those JIRAs to be fixed in 1.2.1.
2017-06-26 2:12 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> Hi Evans,
>
> Sorry for that: The important patch BIGTOP-2754
> <https://issues.apache.org/jira/browse/BIGTOP-2754> has not proper
> versioning string in JIRA and it is not included in the list you provided.
>
> The Zookeeper Update to 3.4.10 has been reverted, since it broke too much.
>
> Olaf
>
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Evans,
Sorry for that: The important patch BIGTOP-2754 <https://issues.apache.org/jira/browse/BIGTOP-2754> has not proper versioning string in JIRA and it is not included in the list you provided.
The Zookeeper Update to 3.4.10 has been reverted, since it broke too much.
Olaf
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Evans Ye <ev...@apache.org>.
Cos,
Well there's no problem for following the original solution we have. Just
let me try whether conflict is resolveable. I'll do release from 1.2-branch
if its applicatable.
All,
I'll start to push back those jiras against 1.2.1 to 1.3 if no comment made
tomorrow. Please raise your hand if you think that really need to be fixed.
Konstantin Boudnik <co...@apache.org>於 2017年6月29日 週四，上午4:41寫道：
> On Wed, Jun 28, 2017 at 10:21PM, Evans Ye wrote:
> > Cos,
> >
> > Good point that release from master need a frozen time.
> > What do you suggest, specifically? Merging master into 1.2-branch and
> > manually do rebase -i to remove those 1.3 patches? That seems doable
> since
> > we have been guarded by one JIRA one patch policy.
>
> From the previous conversation I understood there's not many of the 1.3
> specific patches right? So, the merge into 1.2 branch should be pretty
> straight-forward in this case. I quickly tried to do it and looks like
> most of
> the conflicts are in the pom file (version strings supposedly).
>
> Cos
>
> > 2017-06-28 22:17 GMT+08:00 Evans Ye <ev...@apache.org>:
> >
> > > Kevin,
> > >
> > > Thanks for sharing your thoughts.
> > > I know that's the most solid way to do releases. But I've some concern
> > > about it. Not on the technical side, but from the community
> perspective.
> > >
> > > These are things we need to do if we go for your solution:
> > >
> > > - features that break backwards compat go on 'master' (when they're
> ready,
> > > of course); bug fixes should make their way to 'stable' as appropriate.
> > > - educate committers to be sure of the branch they're committing
> > >
> > > New feature goes to the master is pretty OK, but when it comes to bug
> > > fixes, the things become complicated. Let me name some of the
> scenarios:
> > >
> > > a). Bug only in 1.2.x
> > > b). Bug only in master
> > > c). Bug that exists in both branches
> > > d). Bug that exists in both branches, but the patch does not apply to
> > > both...
> > > e). I don't know which option above applies to my case
> > >
> > > Additionally, how do one judge it's a new feature or bug? Or it's
> > > something else?
> > >
> > > I'm actually fine either way. My concern is just about the resource. If
> > > the community want to go for a solid release process. I'd be happy to
> adopt
> > > in 1.2.1.
> > >
> > >
> > >
> > >
> > > 2017-06-28 8:11 GMT+08:00 Kevin Monroe <ke...@canonical.com>:
> > >
> > >> I'm gonna jump in with my $0.02 and say that releasing from 'master'
> is
> > >> never a good idea. It just so happens to work out for us now, but I'm
> > >> pretty sure c0sin is a masochist and we should be wary of anything he
> > >> suggests. (heart you c0s!)
> > >>
> > >> I, for one, have lofty goals of puppet-4 enablement, but that's
> clearly a
> > >> feature that doesn't belong on the 1.2.x train. Freezing 'master'
> for a
> > >> 1.2.x point release just makes my feature branch more-and-more
> outdated
> > >> during the freeze, so let's not do that. And let's not worry about
> which
> > >> jiras belong on which branch at potential release time -- it's too
> error
> > >> prone. Let's instead come up with a release process that works for
> us.
> > >>
> > >> Full disclosure in case you didn't recognize my email domain -- I
> work at
> > >> Canonical, and the steady Ubuntu release cadence (April / October) has
> > >> worked very well for us. I'm not suggesting we align Bigtop with
> those
> > >> dates, but I *am* suggesting we come up with a regular release cycle
> that
> > >> works for us.
> > >>
> > >> Here's what I have in mind:
> > >> - clone 'master' to 'stable' right now; this is the branch from which
> all
> > >> 1.2.x releases will be born until 1.3.
> > >> - features that break backwards compat go on 'master' (when they're
> ready,
> > >> of course); bug fixes should make their way to 'stable' as
> appropriate.
> > >> - educate committers to be sure of the branch they're committing (i'm
> > >> guilty of this, as i do not pay much attention to the destination of
> > >> things
> > >> i commit -- if the patch applies, it gets pushed to master!). aside:
> half
> > >> of us use patches attached to JIRAa; the other (better) half use
> github
> > >> PRs. let's pick one way and do that!
> > >> - define a release cadence: quarterly, biannually, annually, whatever
> > >> makes sense. personally, i like quarterly. newbies to our project
> get a
> > >> stable release that's at-worst 3 months old. this of course brings
> the
> > >> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
> > >> - integration test strategy. i know juju can test stacks; i'm sure
> itest
> > >> or some k8s / container strategy can be used as well. let's build on
> > >> Evans' matrix [1] to gate releases. this needs to be cross-OS and
> > >> cross-$arch, as I believe this to be one of the major advantages of
> Bigtop
> > >> -- it just works no matter the underlying infra.
> > >>
> > >> I know this stuff is like software engineering 101, but I think it's
> > >> important to keep our band-of-crazies on the same page. If for no
> other
> > >> reason, let's just agree on something for my sake. Thoughts?
> > >>
> > >> [1]
> > >> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-tru
> > >> nk-deployments/
> > >>
> > >> Thanks!
> > >> -Kevin
> > >>
> > >> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org>
> > >> wrote:
> > >>
> > >> > Releasing from master is ok but would actually create more work than
> > >> > it seems. Basically, we'd need to freeze the master through the
> whole
> > >> > release process, etc. With all 1.2.1 patches on master we can just
> > >> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
> > >> > blocking anything.
> > >> >
> > >> > It doesn't mean we have to support 1.2.* unless we want to and have
> > >> > resources, but just from the pure technical standpoint it seems
> > >> > easier. But I am ok either way.
> > >> >
> > >> > Cos
> > >> >
> > >> > --
> > >> > Take care,
> > >> > Konstantin (Cos) Boudnik
> > >> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> > >> >
> > >> > Disclaimer: Opinions expressed in this email are those of the
> author,
> > >> > and do not necessarily represent the views of any company the author
> > >> > might be affiliated with at the moment of writing.
> > >> >
> > >> >
> > >> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org>
> wrote:
> > >> > > Hi all,
> > >> > >
> > >> > > Olaf asked on slack that how do we do 1.2.1 release when there's
> no
> > >> patch
> > >> > > goes in 1.2-branch and most on the patches for 1.2.1 are on
> master.
> > >> > >
> > >> > > My thinking is directly release 1.2.1 version from master, with
> > >> following
> > >> > > reasons:
> > >> > >
> > >> > > 1. We did not bump master to 1.3.0-SNAPSHOT
> > >> > > 2. With small number of components upgraded we can say it's a
> minor
> > >> > version
> > >> > > release for bigtop. We've discussed this to meet the goal of
> release
> > >> > > earlier, release often.
> > >> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in
> 1.2.1
> > >> > except
> > >> > > Debian-9 support, which may or may not be excluded because it's
> quite
> > >> > > independent.
> > >> > > 4. We don't have too much resource to maintain two release lines.
> We
> > >> > shall
> > >> > > better keep it simple as long as it's still a reasonable way.
> > >> > >
> > >> > > We're close to the end of June so I'll start to prepare the
> release.
> > >> For
> > >> > > those doc related JIRAs, I'll try to get them polished before the
> > >> > release.
> > >> > > Please help me to get the others fixed if you've some free cycles
> :)
> > >> > >
> > >> > > [1]. https://s.apache.org/byeu
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> > >> > >
> > >> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> > >> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> > >> > >> > you have time to get it to the finish line recently?
> > >> > >>
> > >> > >> Unfortunately, I don't have enough knowledge about it to really
> > >> > >> understand what's needed and what's not, the install.sh I have
> > >> > >> edited so far is mostly "err, this file doesn't exist anymore,
> > >> > >> let's comment the line to let the compilation continue".
> > >> > >>
> > >> > >> So I do have a compiling solr 6, but I'm fairly certain the
> > >> > >> generated packages are incomplete :/
> > >> > >>
> > >> > >> Arnaud.
> > >> > >>
> > >> >
> > >>
> > >
> > >
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Jun 28, 2017 at 10:21PM, Evans Ye wrote:
> Cos,
>
> Good point that release from master need a frozen time.
> What do you suggest, specifically? Merging master into 1.2-branch and
> manually do rebase -i to remove those 1.3 patches? That seems doable since
> we have been guarded by one JIRA one patch policy.
From the previous conversation I understood there's not many of the 1.3
specific patches right? So, the merge into 1.2 branch should be pretty
straight-forward in this case. I quickly tried to do it and looks like most of
the conflicts are in the pom file (version strings supposedly).
Cos
> 2017-06-28 22:17 GMT+08:00 Evans Ye <ev...@apache.org>:
>
> > Kevin,
> >
> > Thanks for sharing your thoughts.
> > I know that's the most solid way to do releases. But I've some concern
> > about it. Not on the technical side, but from the community perspective.
> >
> > These are things we need to do if we go for your solution:
> >
> > - features that break backwards compat go on 'master' (when they're ready,
> > of course); bug fixes should make their way to 'stable' as appropriate.
> > - educate committers to be sure of the branch they're committing
> >
> > New feature goes to the master is pretty OK, but when it comes to bug
> > fixes, the things become complicated. Let me name some of the scenarios:
> >
> > a). Bug only in 1.2.x
> > b). Bug only in master
> > c). Bug that exists in both branches
> > d). Bug that exists in both branches, but the patch does not apply to
> > both...
> > e). I don't know which option above applies to my case
> >
> > Additionally, how do one judge it's a new feature or bug? Or it's
> > something else?
> >
> > I'm actually fine either way. My concern is just about the resource. If
> > the community want to go for a solid release process. I'd be happy to adopt
> > in 1.2.1.
> >
> >
> >
> >
> > 2017-06-28 8:11 GMT+08:00 Kevin Monroe <ke...@canonical.com>:
> >
> >> I'm gonna jump in with my $0.02 and say that releasing from 'master' is
> >> never a good idea. It just so happens to work out for us now, but I'm
> >> pretty sure c0sin is a masochist and we should be wary of anything he
> >> suggests. (heart you c0s!)
> >>
> >> I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
> >> feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
> >> 1.2.x point release just makes my feature branch more-and-more outdated
> >> during the freeze, so let's not do that. And let's not worry about which
> >> jiras belong on which branch at potential release time -- it's too error
> >> prone. Let's instead come up with a release process that works for us.
> >>
> >> Full disclosure in case you didn't recognize my email domain -- I work at
> >> Canonical, and the steady Ubuntu release cadence (April / October) has
> >> worked very well for us. I'm not suggesting we align Bigtop with those
> >> dates, but I *am* suggesting we come up with a regular release cycle that
> >> works for us.
> >>
> >> Here's what I have in mind:
> >> - clone 'master' to 'stable' right now; this is the branch from which all
> >> 1.2.x releases will be born until 1.3.
> >> - features that break backwards compat go on 'master' (when they're ready,
> >> of course); bug fixes should make their way to 'stable' as appropriate.
> >> - educate committers to be sure of the branch they're committing (i'm
> >> guilty of this, as i do not pay much attention to the destination of
> >> things
> >> i commit -- if the patch applies, it gets pushed to master!). aside: half
> >> of us use patches attached to JIRAa; the other (better) half use github
> >> PRs. let's pick one way and do that!
> >> - define a release cadence: quarterly, biannually, annually, whatever
> >> makes sense. personally, i like quarterly. newbies to our project get a
> >> stable release that's at-worst 3 months old. this of course brings the
> >> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
> >> - integration test strategy. i know juju can test stacks; i'm sure itest
> >> or some k8s / container strategy can be used as well. let's build on
> >> Evans' matrix [1] to gate releases. this needs to be cross-OS and
> >> cross-$arch, as I believe this to be one of the major advantages of Bigtop
> >> -- it just works no matter the underlying infra.
> >>
> >> I know this stuff is like software engineering 101, but I think it's
> >> important to keep our band-of-crazies on the same page. If for no other
> >> reason, let's just agree on something for my sake. Thoughts?
> >>
> >> [1]
> >> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-tru
> >> nk-deployments/
> >>
> >> Thanks!
> >> -Kevin
> >>
> >> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>
> >> > Releasing from master is ok but would actually create more work than
> >> > it seems. Basically, we'd need to freeze the master through the whole
> >> > release process, etc. With all 1.2.1 patches on master we can just
> >> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
> >> > blocking anything.
> >> >
> >> > It doesn't mean we have to support 1.2.* unless we want to and have
> >> > resources, but just from the pure technical standpoint it seems
> >> > easier. But I am ok either way.
> >> >
> >> > Cos
> >> >
> >> > --
> >> > Take care,
> >> > Konstantin (Cos) Boudnik
> >> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >> >
> >> > Disclaimer: Opinions expressed in this email are those of the author,
> >> > and do not necessarily represent the views of any company the author
> >> > might be affiliated with at the moment of writing.
> >> >
> >> >
> >> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
> >> > > Hi all,
> >> > >
> >> > > Olaf asked on slack that how do we do 1.2.1 release when there's no
> >> patch
> >> > > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
> >> > >
> >> > > My thinking is directly release 1.2.1 version from master, with
> >> following
> >> > > reasons:
> >> > >
> >> > > 1. We did not bump master to 1.3.0-SNAPSHOT
> >> > > 2. With small number of components upgraded we can say it's a minor
> >> > version
> >> > > release for bigtop. We've discussed this to meet the goal of release
> >> > > earlier, release often.
> >> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
> >> > except
> >> > > Debian-9 support, which may or may not be excluded because it's quite
> >> > > independent.
> >> > > 4. We don't have too much resource to maintain two release lines. We
> >> > shall
> >> > > better keep it simple as long as it's still a reasonable way.
> >> > >
> >> > > We're close to the end of June so I'll start to prepare the release.
> >> For
> >> > > those doc related JIRAs, I'll try to get them polished before the
> >> > release.
> >> > > Please help me to get the others fixed if you've some free cycles :)
> >> > >
> >> > > [1]. https://s.apache.org/byeu
> >> > >
> >> > >
> >> > >
> >> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> >> > >
> >> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> >> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> >> > >> > you have time to get it to the finish line recently?
> >> > >>
> >> > >> Unfortunately, I don't have enough knowledge about it to really
> >> > >> understand what's needed and what's not, the install.sh I have
> >> > >> edited so far is mostly "err, this file doesn't exist anymore,
> >> > >> let's comment the line to let the compilation continue".
> >> > >>
> >> > >> So I do have a compiling solr 6, but I'm fairly certain the
> >> > >> generated packages are incomplete :/
> >> > >>
> >> > >> Arnaud.
> >> > >>
> >> >
> >>
> >
> >
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Konstantin Boudnik <co...@apache.org>.
Indeed Kev, and that's in fact why I am still spending my time here in the
Bigtop - out of the pure masochism! Longing for an occasional insult from my
buds ;) After all, who doesn't love an occasional friendly punch like that?
You're bringing up obvious yet good points and as you can read in our Wiki,
that's pretty much the process we were following for a while now. And indeed
it works, except we still are trying to make our release schedule to be more
regular. Perhaps one of the major issues with having predictable and stable
releases, is the absence of a decent integration testing. As you can see, the
community has made a decent push with auto-deployment and more. But we still
aren't where we need to be, in my opinion.
I like all the discussions about using swarm or k8s or whatever, but besides
of 1) the work that needs to be done we are 2) short of the compute resources.
While I am sure with Juju it would be easier to cover more of 1) ground, the
2) still needs to be addressed. Perhaps not in the next 3 days, but still...
As for the immediate need - I will harp on what I just said: I do think we can
release from the master, but I still want to understand what problem that will
help to solve? Why don't we stick with the model that we already have in place
and that has been working so far? I guess this one goes to Evans (sorry pal if
I missed the answer in the thread elsewhere).
Thanks,
Cos
On Tue, Jun 27, 2017 at 07:11PM, Kevin Monroe wrote:
> I'm gonna jump in with my $0.02 and say that releasing from 'master' is
> never a good idea. It just so happens to work out for us now, but I'm
> pretty sure c0sin is a masochist and we should be wary of anything he
> suggests. (heart you c0s!)
>
> I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
> feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
> 1.2.x point release just makes my feature branch more-and-more outdated
> during the freeze, so let's not do that. And let's not worry about which
> jiras belong on which branch at potential release time -- it's too error
> prone. Let's instead come up with a release process that works for us.
>
> Full disclosure in case you didn't recognize my email domain -- I work at
> Canonical, and the steady Ubuntu release cadence (April / October) has
> worked very well for us. I'm not suggesting we align Bigtop with those
> dates, but I *am* suggesting we come up with a regular release cycle that
> works for us.
>
> Here's what I have in mind:
> - clone 'master' to 'stable' right now; this is the branch from which all
> 1.2.x releases will be born until 1.3.
> - features that break backwards compat go on 'master' (when they're ready,
> of course); bug fixes should make their way to 'stable' as appropriate.
> - educate committers to be sure of the branch they're committing (i'm
> guilty of this, as i do not pay much attention to the destination of things
> i commit -- if the patch applies, it gets pushed to master!). aside: half
> of us use patches attached to JIRAa; the other (better) half use github
> PRs. let's pick one way and do that!
> - define a release cadence: quarterly, biannually, annually, whatever
> makes sense. personally, i like quarterly. newbies to our project get a
> stable release that's at-worst 3 months old. this of course brings the
> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
> - integration test strategy. i know juju can test stacks; i'm sure itest
> or some k8s / container strategy can be used as well. let's build on
> Evans' matrix [1] to gate releases. this needs to be cross-OS and
> cross-$arch, as I believe this to be one of the major advantages of Bigtop
> -- it just works no matter the underlying infra.
>
> I know this stuff is like software engineering 101, but I think it's
> important to keep our band-of-crazies on the same page. If for no other
> reason, let's just agree on something for my sake. Thoughts?
>
> [1]
> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-trunk-deployments/
>
> Thanks!
> -Kevin
>
> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > Releasing from master is ok but would actually create more work than
> > it seems. Basically, we'd need to freeze the master through the whole
> > release process, etc. With all 1.2.1 patches on master we can just
> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
> > blocking anything.
> >
> > It doesn't mean we have to support 1.2.* unless we want to and have
> > resources, but just from the pure technical standpoint it seems
> > easier. But I am ok either way.
> >
> > Cos
> >
> > --
> > Take care,
> > Konstantin (Cos) Boudnik
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >
> > Disclaimer: Opinions expressed in this email are those of the author,
> > and do not necessarily represent the views of any company the author
> > might be affiliated with at the moment of writing.
> >
> >
> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
> > > Hi all,
> > >
> > > Olaf asked on slack that how do we do 1.2.1 release when there's no patch
> > > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
> > >
> > > My thinking is directly release 1.2.1 version from master, with following
> > > reasons:
> > >
> > > 1. We did not bump master to 1.3.0-SNAPSHOT
> > > 2. With small number of components upgraded we can say it's a minor
> > version
> > > release for bigtop. We've discussed this to meet the goal of release
> > > earlier, release often.
> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
> > except
> > > Debian-9 support, which may or may not be excluded because it's quite
> > > independent.
> > > 4. We don't have too much resource to maintain two release lines. We
> > shall
> > > better keep it simple as long as it's still a reasonable way.
> > >
> > > We're close to the end of June so I'll start to prepare the release. For
> > > those doc related JIRAs, I'll try to get them polished before the
> > release.
> > > Please help me to get the others fixed if you've some free cycles :)
> > >
> > > [1]. https://s.apache.org/byeu
> > >
> > >
> > >
> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> > >
> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> > >> > you have time to get it to the finish line recently?
> > >>
> > >> Unfortunately, I don't have enough knowledge about it to really
> > >> understand what's needed and what's not, the install.sh I have
> > >> edited so far is mostly "err, this file doesn't exist anymore,
> > >> let's comment the line to let the compilation continue".
> > >>
> > >> So I do have a compiling solr 6, but I'm fairly certain the
> > >> generated packages are incomplete :/
> > >>
> > >> Arnaud.
> > >>
> >
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Evans Ye <ev...@apache.org>.
In fact, I've discovered a doc on our wiki. I can recall that we have been
through the discussion before.
https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute#HowtoContribute-ForCommitters:howtocommitapatchinbothmasterandreleasebranch
However, we do not follow the doc in practice.
In scrum we can probably say that the solution does not work as we
expected, shall we change it during retrospective?
2017-06-28 22:21 GMT+08:00 Evans Ye <ev...@apache.org>:
> Cos,
>
> Good point that release from master need a frozen time.
> What do you suggest, specifically? Merging master into 1.2-branch and
> manually do rebase -i to remove those 1.3 patches? That seems doable since
> we have been guarded by one JIRA one patch policy.
>
> Evans
>
> 2017-06-28 22:17 GMT+08:00 Evans Ye <ev...@apache.org>:
>
>> Kevin,
>>
>> Thanks for sharing your thoughts.
>> I know that's the most solid way to do releases. But I've some concern
>> about it. Not on the technical side, but from the community perspective.
>>
>> These are things we need to do if we go for your solution:
>>
>> - features that break backwards compat go on 'master' (when they're ready,
>> of course); bug fixes should make their way to 'stable' as appropriate.
>> - educate committers to be sure of the branch they're committing
>>
>> New feature goes to the master is pretty OK, but when it comes to bug
>> fixes, the things become complicated. Let me name some of the scenarios:
>>
>> a). Bug only in 1.2.x
>> b). Bug only in master
>> c). Bug that exists in both branches
>> d). Bug that exists in both branches, but the patch does not apply to
>> both...
>> e). I don't know which option above applies to my case
>>
>> Additionally, how do one judge it's a new feature or bug? Or it's
>> something else?
>>
>> I'm actually fine either way. My concern is just about the resource. If
>> the community want to go for a solid release process. I'd be happy to adopt
>> in 1.2.1.
>>
>>
>>
>>
>> 2017-06-28 8:11 GMT+08:00 Kevin Monroe <ke...@canonical.com>:
>>
>>> I'm gonna jump in with my $0.02 and say that releasing from 'master' is
>>> never a good idea. It just so happens to work out for us now, but I'm
>>> pretty sure c0sin is a masochist and we should be wary of anything he
>>> suggests. (heart you c0s!)
>>>
>>> I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
>>> feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
>>> 1.2.x point release just makes my feature branch more-and-more outdated
>>> during the freeze, so let's not do that. And let's not worry about which
>>> jiras belong on which branch at potential release time -- it's too error
>>> prone. Let's instead come up with a release process that works for us.
>>>
>>> Full disclosure in case you didn't recognize my email domain -- I work at
>>> Canonical, and the steady Ubuntu release cadence (April / October) has
>>> worked very well for us. I'm not suggesting we align Bigtop with those
>>> dates, but I *am* suggesting we come up with a regular release cycle that
>>> works for us.
>>>
>>> Here's what I have in mind:
>>> - clone 'master' to 'stable' right now; this is the branch from which all
>>> 1.2.x releases will be born until 1.3.
>>> - features that break backwards compat go on 'master' (when they're
>>> ready,
>>> of course); bug fixes should make their way to 'stable' as appropriate.
>>> - educate committers to be sure of the branch they're committing (i'm
>>> guilty of this, as i do not pay much attention to the destination of
>>> things
>>> i commit -- if the patch applies, it gets pushed to master!). aside:
>>> half
>>> of us use patches attached to JIRAa; the other (better) half use github
>>> PRs. let's pick one way and do that!
>>> - define a release cadence: quarterly, biannually, annually, whatever
>>> makes sense. personally, i like quarterly. newbies to our project get a
>>> stable release that's at-worst 3 months old. this of course brings the
>>> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
>>> - integration test strategy. i know juju can test stacks; i'm sure itest
>>> or some k8s / container strategy can be used as well. let's build on
>>> Evans' matrix [1] to gate releases. this needs to be cross-OS and
>>> cross-$arch, as I believe this to be one of the major advantages of
>>> Bigtop
>>> -- it just works no matter the underlying infra.
>>>
>>> I know this stuff is like software engineering 101, but I think it's
>>> important to keep our band-of-crazies on the same page. If for no other
>>> reason, let's just agree on something for my sake. Thoughts?
>>>
>>> [1]
>>> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-tru
>>> nk-deployments/
>>>
>>> Thanks!
>>> -Kevin
>>>
>>> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>
>>> > Releasing from master is ok but would actually create more work than
>>> > it seems. Basically, we'd need to freeze the master through the whole
>>> > release process, etc. With all 1.2.1 patches on master we can just
>>> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
>>> > blocking anything.
>>> >
>>> > It doesn't mean we have to support 1.2.* unless we want to and have
>>> > resources, but just from the pure technical standpoint it seems
>>> > easier. But I am ok either way.
>>> >
>>> > Cos
>>> >
>>> > --
>>> > Take care,
>>> > Konstantin (Cos) Boudnik
>>> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>> >
>>> > Disclaimer: Opinions expressed in this email are those of the author,
>>> > and do not necessarily represent the views of any company the author
>>> > might be affiliated with at the moment of writing.
>>> >
>>> >
>>> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
>>> > > Hi all,
>>> > >
>>> > > Olaf asked on slack that how do we do 1.2.1 release when there's no
>>> patch
>>> > > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
>>> > >
>>> > > My thinking is directly release 1.2.1 version from master, with
>>> following
>>> > > reasons:
>>> > >
>>> > > 1. We did not bump master to 1.3.0-SNAPSHOT
>>> > > 2. With small number of components upgraded we can say it's a minor
>>> > version
>>> > > release for bigtop. We've discussed this to meet the goal of release
>>> > > earlier, release often.
>>> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
>>> > except
>>> > > Debian-9 support, which may or may not be excluded because it's quite
>>> > > independent.
>>> > > 4. We don't have too much resource to maintain two release lines. We
>>> > shall
>>> > > better keep it simple as long as it's still a reasonable way.
>>> > >
>>> > > We're close to the end of June so I'll start to prepare the release.
>>> For
>>> > > those doc related JIRAs, I'll try to get them polished before the
>>> > release.
>>> > > Please help me to get the others fixed if you've some free cycles :)
>>> > >
>>> > > [1]. https://s.apache.org/byeu
>>> > >
>>> > >
>>> > >
>>> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
>>> > >
>>> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
>>> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
>>> > >> > you have time to get it to the finish line recently?
>>> > >>
>>> > >> Unfortunately, I don't have enough knowledge about it to really
>>> > >> understand what's needed and what's not, the install.sh I have
>>> > >> edited so far is mostly "err, this file doesn't exist anymore,
>>> > >> let's comment the line to let the compilation continue".
>>> > >>
>>> > >> So I do have a compiling solr 6, but I'm fairly certain the
>>> > >> generated packages are incomplete :/
>>> > >>
>>> > >> Arnaud.
>>> > >>
>>> >
>>>
>>
>>
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Evans Ye <ev...@apache.org>.
Cos,
Good point that release from master need a frozen time.
What do you suggest, specifically? Merging master into 1.2-branch and
manually do rebase -i to remove those 1.3 patches? That seems doable since
we have been guarded by one JIRA one patch policy.
Evans
2017-06-28 22:17 GMT+08:00 Evans Ye <ev...@apache.org>:
> Kevin,
>
> Thanks for sharing your thoughts.
> I know that's the most solid way to do releases. But I've some concern
> about it. Not on the technical side, but from the community perspective.
>
> These are things we need to do if we go for your solution:
>
> - features that break backwards compat go on 'master' (when they're ready,
> of course); bug fixes should make their way to 'stable' as appropriate.
> - educate committers to be sure of the branch they're committing
>
> New feature goes to the master is pretty OK, but when it comes to bug
> fixes, the things become complicated. Let me name some of the scenarios:
>
> a). Bug only in 1.2.x
> b). Bug only in master
> c). Bug that exists in both branches
> d). Bug that exists in both branches, but the patch does not apply to
> both...
> e). I don't know which option above applies to my case
>
> Additionally, how do one judge it's a new feature or bug? Or it's
> something else?
>
> I'm actually fine either way. My concern is just about the resource. If
> the community want to go for a solid release process. I'd be happy to adopt
> in 1.2.1.
>
>
>
>
> 2017-06-28 8:11 GMT+08:00 Kevin Monroe <ke...@canonical.com>:
>
>> I'm gonna jump in with my $0.02 and say that releasing from 'master' is
>> never a good idea. It just so happens to work out for us now, but I'm
>> pretty sure c0sin is a masochist and we should be wary of anything he
>> suggests. (heart you c0s!)
>>
>> I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
>> feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
>> 1.2.x point release just makes my feature branch more-and-more outdated
>> during the freeze, so let's not do that. And let's not worry about which
>> jiras belong on which branch at potential release time -- it's too error
>> prone. Let's instead come up with a release process that works for us.
>>
>> Full disclosure in case you didn't recognize my email domain -- I work at
>> Canonical, and the steady Ubuntu release cadence (April / October) has
>> worked very well for us. I'm not suggesting we align Bigtop with those
>> dates, but I *am* suggesting we come up with a regular release cycle that
>> works for us.
>>
>> Here's what I have in mind:
>> - clone 'master' to 'stable' right now; this is the branch from which all
>> 1.2.x releases will be born until 1.3.
>> - features that break backwards compat go on 'master' (when they're ready,
>> of course); bug fixes should make their way to 'stable' as appropriate.
>> - educate committers to be sure of the branch they're committing (i'm
>> guilty of this, as i do not pay much attention to the destination of
>> things
>> i commit -- if the patch applies, it gets pushed to master!). aside: half
>> of us use patches attached to JIRAa; the other (better) half use github
>> PRs. let's pick one way and do that!
>> - define a release cadence: quarterly, biannually, annually, whatever
>> makes sense. personally, i like quarterly. newbies to our project get a
>> stable release that's at-worst 3 months old. this of course brings the
>> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
>> - integration test strategy. i know juju can test stacks; i'm sure itest
>> or some k8s / container strategy can be used as well. let's build on
>> Evans' matrix [1] to gate releases. this needs to be cross-OS and
>> cross-$arch, as I believe this to be one of the major advantages of Bigtop
>> -- it just works no matter the underlying infra.
>>
>> I know this stuff is like software engineering 101, but I think it's
>> important to keep our band-of-crazies on the same page. If for no other
>> reason, let's just agree on something for my sake. Thoughts?
>>
>> [1]
>> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-tru
>> nk-deployments/
>>
>> Thanks!
>> -Kevin
>>
>> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>
>> > Releasing from master is ok but would actually create more work than
>> > it seems. Basically, we'd need to freeze the master through the whole
>> > release process, etc. With all 1.2.1 patches on master we can just
>> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
>> > blocking anything.
>> >
>> > It doesn't mean we have to support 1.2.* unless we want to and have
>> > resources, but just from the pure technical standpoint it seems
>> > easier. But I am ok either way.
>> >
>> > Cos
>> >
>> > --
>> > Take care,
>> > Konstantin (Cos) Boudnik
>> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>> >
>> > Disclaimer: Opinions expressed in this email are those of the author,
>> > and do not necessarily represent the views of any company the author
>> > might be affiliated with at the moment of writing.
>> >
>> >
>> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
>> > > Hi all,
>> > >
>> > > Olaf asked on slack that how do we do 1.2.1 release when there's no
>> patch
>> > > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
>> > >
>> > > My thinking is directly release 1.2.1 version from master, with
>> following
>> > > reasons:
>> > >
>> > > 1. We did not bump master to 1.3.0-SNAPSHOT
>> > > 2. With small number of components upgraded we can say it's a minor
>> > version
>> > > release for bigtop. We've discussed this to meet the goal of release
>> > > earlier, release often.
>> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
>> > except
>> > > Debian-9 support, which may or may not be excluded because it's quite
>> > > independent.
>> > > 4. We don't have too much resource to maintain two release lines. We
>> > shall
>> > > better keep it simple as long as it's still a reasonable way.
>> > >
>> > > We're close to the end of June so I'll start to prepare the release.
>> For
>> > > those doc related JIRAs, I'll try to get them polished before the
>> > release.
>> > > Please help me to get the others fixed if you've some free cycles :)
>> > >
>> > > [1]. https://s.apache.org/byeu
>> > >
>> > >
>> > >
>> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
>> > >
>> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
>> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
>> > >> > you have time to get it to the finish line recently?
>> > >>
>> > >> Unfortunately, I don't have enough knowledge about it to really
>> > >> understand what's needed and what's not, the install.sh I have
>> > >> edited so far is mostly "err, this file doesn't exist anymore,
>> > >> let's comment the line to let the compilation continue".
>> > >>
>> > >> So I do have a compiling solr 6, but I'm fairly certain the
>> > >> generated packages are incomplete :/
>> > >>
>> > >> Arnaud.
>> > >>
>> >
>>
>
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Evans Ye <ev...@apache.org>.
Kevin,
Thanks for sharing your thoughts.
I know that's the most solid way to do releases. But I've some concern
about it. Not on the technical side, but from the community perspective.
These are things we need to do if we go for your solution:
- features that break backwards compat go on 'master' (when they're ready,
of course); bug fixes should make their way to 'stable' as appropriate.
- educate committers to be sure of the branch they're committing
New feature goes to the master is pretty OK, but when it comes to bug
fixes, the things become complicated. Let me name some of the scenarios:
a). Bug only in 1.2.x
b). Bug only in master
c). Bug that exists in both branches
d). Bug that exists in both branches, but the patch does not apply to
both...
e). I don't know which option above applies to my case
Additionally, how do one judge it's a new feature or bug? Or it's something
else?
I'm actually fine either way. My concern is just about the resource. If the
community want to go for a solid release process. I'd be happy to adopt in
1.2.1.
2017-06-28 8:11 GMT+08:00 Kevin Monroe <ke...@canonical.com>:
> I'm gonna jump in with my $0.02 and say that releasing from 'master' is
> never a good idea. It just so happens to work out for us now, but I'm
> pretty sure c0sin is a masochist and we should be wary of anything he
> suggests. (heart you c0s!)
>
> I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
> feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
> 1.2.x point release just makes my feature branch more-and-more outdated
> during the freeze, so let's not do that. And let's not worry about which
> jiras belong on which branch at potential release time -- it's too error
> prone. Let's instead come up with a release process that works for us.
>
> Full disclosure in case you didn't recognize my email domain -- I work at
> Canonical, and the steady Ubuntu release cadence (April / October) has
> worked very well for us. I'm not suggesting we align Bigtop with those
> dates, but I *am* suggesting we come up with a regular release cycle that
> works for us.
>
> Here's what I have in mind:
> - clone 'master' to 'stable' right now; this is the branch from which all
> 1.2.x releases will be born until 1.3.
> - features that break backwards compat go on 'master' (when they're ready,
> of course); bug fixes should make their way to 'stable' as appropriate.
> - educate committers to be sure of the branch they're committing (i'm
> guilty of this, as i do not pay much attention to the destination of things
> i commit -- if the patch applies, it gets pushed to master!). aside: half
> of us use patches attached to JIRAa; the other (better) half use github
> PRs. let's pick one way and do that!
> - define a release cadence: quarterly, biannually, annually, whatever
> makes sense. personally, i like quarterly. newbies to our project get a
> stable release that's at-worst 3 months old. this of course brings the
> burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
> - integration test strategy. i know juju can test stacks; i'm sure itest
> or some k8s / container strategy can be used as well. let's build on
> Evans' matrix [1] to gate releases. this needs to be cross-OS and
> cross-$arch, as I believe this to be one of the major advantages of Bigtop
> -- it just works no matter the underlying infra.
>
> I know this stuff is like software engineering 101, but I think it's
> important to keep our band-of-crazies on the same page. If for no other
> reason, let's just agree on something for my sake. Thoughts?
>
> [1]
> https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-
> trunk-deployments/
>
> Thanks!
> -Kevin
>
> On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > Releasing from master is ok but would actually create more work than
> > it seems. Basically, we'd need to freeze the master through the whole
> > release process, etc. With all 1.2.1 patches on master we can just
> > merge them into 1.2 and have the sweet time releasing 1.2.1 without
> > blocking anything.
> >
> > It doesn't mean we have to support 1.2.* unless we want to and have
> > resources, but just from the pure technical standpoint it seems
> > easier. But I am ok either way.
> >
> > Cos
> >
> > --
> > Take care,
> > Konstantin (Cos) Boudnik
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >
> > Disclaimer: Opinions expressed in this email are those of the author,
> > and do not necessarily represent the views of any company the author
> > might be affiliated with at the moment of writing.
> >
> >
> > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
> > > Hi all,
> > >
> > > Olaf asked on slack that how do we do 1.2.1 release when there's no
> patch
> > > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
> > >
> > > My thinking is directly release 1.2.1 version from master, with
> following
> > > reasons:
> > >
> > > 1. We did not bump master to 1.3.0-SNAPSHOT
> > > 2. With small number of components upgraded we can say it's a minor
> > version
> > > release for bigtop. We've discussed this to meet the goal of release
> > > earlier, release often.
> > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
> > except
> > > Debian-9 support, which may or may not be excluded because it's quite
> > > independent.
> > > 4. We don't have too much resource to maintain two release lines. We
> > shall
> > > better keep it simple as long as it's still a reasonable way.
> > >
> > > We're close to the end of June so I'll start to prepare the release.
> For
> > > those doc related JIRAs, I'll try to get them polished before the
> > release.
> > > Please help me to get the others fixed if you've some free cycles :)
> > >
> > > [1]. https://s.apache.org/byeu
> > >
> > >
> > >
> > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> > >
> > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> > >> > you have time to get it to the finish line recently?
> > >>
> > >> Unfortunately, I don't have enough knowledge about it to really
> > >> understand what's needed and what's not, the install.sh I have
> > >> edited so far is mostly "err, this file doesn't exist anymore,
> > >> let's comment the line to let the compilation continue".
> > >>
> > >> So I do have a compiling solr 6, but I'm fairly certain the
> > >> generated packages are incomplete :/
> > >>
> > >> Arnaud.
> > >>
> >
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Kevin Monroe <ke...@canonical.com>.
I'm gonna jump in with my $0.02 and say that releasing from 'master' is
never a good idea. It just so happens to work out for us now, but I'm
pretty sure c0sin is a masochist and we should be wary of anything he
suggests. (heart you c0s!)
I, for one, have lofty goals of puppet-4 enablement, but that's clearly a
feature that doesn't belong on the 1.2.x train. Freezing 'master' for a
1.2.x point release just makes my feature branch more-and-more outdated
during the freeze, so let's not do that. And let's not worry about which
jiras belong on which branch at potential release time -- it's too error
prone. Let's instead come up with a release process that works for us.
Full disclosure in case you didn't recognize my email domain -- I work at
Canonical, and the steady Ubuntu release cadence (April / October) has
worked very well for us. I'm not suggesting we align Bigtop with those
dates, but I *am* suggesting we come up with a regular release cycle that
works for us.
Here's what I have in mind:
- clone 'master' to 'stable' right now; this is the branch from which all
1.2.x releases will be born until 1.3.
- features that break backwards compat go on 'master' (when they're ready,
of course); bug fixes should make their way to 'stable' as appropriate.
- educate committers to be sure of the branch they're committing (i'm
guilty of this, as i do not pay much attention to the destination of things
i commit -- if the patch applies, it gets pushed to master!). aside: half
of us use patches attached to JIRAa; the other (better) half use github
PRs. let's pick one way and do that!
- define a release cadence: quarterly, biannually, annually, whatever
makes sense. personally, i like quarterly. newbies to our project get a
stable release that's at-worst 3 months old. this of course brings the
burden of a release manager; i'm happy to sign up as the 1.2.2 RM.
- integration test strategy. i know juju can test stacks; i'm sure itest
or some k8s / container strategy can be used as well. let's build on
Evans' matrix [1] to gate releases. this needs to be cross-OS and
cross-$arch, as I believe this to be one of the major advantages of Bigtop
-- it just works no matter the underlying infra.
I know this stuff is like software engineering 101, but I think it's
important to keep our band-of-crazies on the same page. If for no other
reason, let's just agree on something for my sake. Thoughts?
[1]
https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-trunk-deployments/
Thanks!
-Kevin
On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Releasing from master is ok but would actually create more work than
> it seems. Basically, we'd need to freeze the master through the whole
> release process, etc. With all 1.2.1 patches on master we can just
> merge them into 1.2 and have the sweet time releasing 1.2.1 without
> blocking anything.
>
> It doesn't mean we have to support 1.2.* unless we want to and have
> resources, but just from the pure technical standpoint it seems
> easier. But I am ok either way.
>
> Cos
>
> --
> Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
> > Hi all,
> >
> > Olaf asked on slack that how do we do 1.2.1 release when there's no patch
> > goes in 1.2-branch and most on the patches for 1.2.1 are on master.
> >
> > My thinking is directly release 1.2.1 version from master, with following
> > reasons:
> >
> > 1. We did not bump master to 1.3.0-SNAPSHOT
> > 2. With small number of components upgraded we can say it's a minor
> version
> > release for bigtop. We've discussed this to meet the goal of release
> > earlier, release often.
> > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1
> except
> > Debian-9 support, which may or may not be excluded because it's quite
> > independent.
> > 4. We don't have too much resource to maintain two release lines. We
> shall
> > better keep it simple as long as it's still a reasonable way.
> >
> > We're close to the end of June so I'll start to prepare the release. For
> > those doc related JIRAs, I'll try to get them polished before the
> release.
> > Please help me to get the others fixed if you've some free cycles :)
> >
> > [1]. https://s.apache.org/byeu
> >
> >
> >
> > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
> >
> >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
> >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
> >> > you have time to get it to the finish line recently?
> >>
> >> Unfortunately, I don't have enough knowledge about it to really
> >> understand what's needed and what's not, the install.sh I have
> >> edited so far is mostly "err, this file doesn't exist anymore,
> >> let's comment the line to let the compilation continue".
> >>
> >> So I do have a compiling solr 6, but I'm fairly certain the
> >> generated packages are incomplete :/
> >>
> >> Arnaud.
> >>
>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Konstantin Boudnik <co...@apache.org>.
Releasing from master is ok but would actually create more work than
it seems. Basically, we'd need to freeze the master through the whole
release process, etc. With all 1.2.1 patches on master we can just
merge them into 1.2 and have the sweet time releasing 1.2.1 without
blocking anything.
It doesn't mean we have to support 1.2.* unless we want to and have
resources, but just from the pure technical standpoint it seems
easier. But I am ok either way.
Cos
--
Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.
On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <ev...@apache.org> wrote:
> Hi all,
>
> Olaf asked on slack that how do we do 1.2.1 release when there's no patch
> goes in 1.2-branch and most on the patches for 1.2.1 are on master.
>
> My thinking is directly release 1.2.1 version from master, with following
> reasons:
>
> 1. We did not bump master to 1.3.0-SNAPSHOT
> 2. With small number of components upgraded we can say it's a minor version
> release for bigtop. We've discussed this to meet the goal of release
> earlier, release often.
> 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1 except
> Debian-9 support, which may or may not be excluded because it's quite
> independent.
> 4. We don't have too much resource to maintain two release lines. We shall
> better keep it simple as long as it's still a reasonable way.
>
> We're close to the end of June so I'll start to prepare the release. For
> those doc related JIRAs, I'll try to get them polished before the release.
> Please help me to get the others fixed if you've some free cycles :)
>
> [1]. https://s.apache.org/byeu
>
>
>
> 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
>
>> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
>> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
>> > you have time to get it to the finish line recently?
>>
>> Unfortunately, I don't have enough knowledge about it to really
>> understand what's needed and what's not, the install.sh I have
>> edited so far is mostly "err, this file doesn't exist anymore,
>> let's comment the line to let the compilation continue".
>>
>> So I do have a compiling solr 6, but I'm fairly certain the
>> generated packages are incomplete :/
>>
>> Arnaud.
>>
Re: [DISCUSS] Bigtop 1.2.1 release
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
The Debian-9 is indeed a feature patch, which can be omitted from 1.2.1 .
BIGTOP-2808 is rather risky to include, but is needed to fix a deployment issue. This has to be tested by other devs as well.
Olaf
> Am 25.06.2017 um 19:54 schrieb Evans Ye <ev...@apache.org>:
>
> Hi all,
>
> Olaf asked on slack that how do we do 1.2.1 release when there's no patch
> goes in 1.2-branch and most on the patches for 1.2.1 are on master.
>
> My thinking is directly release 1.2.1 version from master, with following
> reasons:
>
> 1. We did not bump master to 1.3.0-SNAPSHOT
> 2. With small number of components upgraded we can say it's a minor version
> release for bigtop. We've discussed this to meet the goal of release
> earlier, release often.
> 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1 except
> Debian-9 support, which may or may not be excluded because it's quite
> independent.
> 4. We don't have too much resource to maintain two release lines. We shall
> better keep it simple as long as it's still a reasonable way.
>
> We're close to the end of June so I'll start to prepare the release. For
> those doc related JIRAs, I'll try to get them polished before the release.
> Please help me to get the others fixed if you've some free cycles :)
>
> [1]. https://s.apache.org/byeu
>
>
>
> 2017-05-29 21:05 GMT+08:00 Arnaud Launay <as...@launay.org>:
>
>> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit:
>>> Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do
>>> you have time to get it to the finish line recently?
>>
>> Unfortunately, I don't have enough knowledge about it to really
>> understand what's needed and what's not, the install.sh I have
>> edited so far is mostly "err, this file doesn't exist anymore,
>> let's comment the line to let the compilation continue".
>>
>> So I do have a compiling solr 6, but I'm fairly certain the
>> generated packages are incomplete :/
>>
>> Arnaud.
>>