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