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 <[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: PGP signature
