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 <[email protected]>: > 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 <[email protected]>: > >> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]>: >> > > >> > >> 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. >> > >> >> > >> > >
