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 <[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. > >> > >> > >> > > >> > > > >
signature.asc
Description: Digital signature
