+1 for whatever option means master is the latest stable version (i.e., production-ready).
On Tue, Oct 7, 2014 at 6:27 AM, William Slacum <wilhelm.von.cl...@accumulo.net> wrote: > Slight correction: "N patches" should be "N branches". > > On Tue, Oct 7, 2014 at 6:24 AM, William Slacum < > wilhelm.von.cl...@accumulo.net> wrote: > >> #1 would be nice. I would discourage the cherry-pick-back-from-master >> model because it completely disregards git's history model and makes >> auditing changes nearly impossible because for N patches, the same change >> exists N times under different IDs. If we wanted that, we'd be back to >> subversion without mergeinfo. >> >> #2 and #3 is possible now with our branching strategy. Is there some >> deficiency you notice with it? >> >> While we're a big project, I think we might be able to benefit from a >> review-then-commit process. It could allow us to review any patch to >> master, and if we determine it is relevant in historical branches, we >> commit it to the historical branch and then merge forward before publishing >> to our public history. >> >> >> >> On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bus...@cloudera.com> wrote: >> >>> What if we start with what we want and work from there, instead of >>> starting >>> from our current model. >>> >>> I would really like: >>> >>> 1) A *single* place where new contributors can base patches >>> >>> 2) Stable planned release lines where a release manager can determine what >>> does or does not get included >>> >>> 3) a git history that makes it easy for me to tell what jiras impact a >>> given release tag >>> >>> One way to achieve these goals is to adopt a commit-to-master and >>> cherry-pick approach. >>> >>> * Master would be the default landing zone for new commits (unless they >>> only apply to an older branch). >>> * Master would have a version that represents unstable "future work" (so >>> right now presumably 3.0 if Christopher wants to start solidifying 2.0) >>> * We'd have a branch for each current dev branches >>> * When a fix applies to an older branch a committer (and usually not a >>> contributor) would cherry pick it from master >>> * When the release manager for a new version was ready to start >>> stabilizing >>> things they'd make a new branch >>> * Said release manager would determine what feature changes in master get >>> pulled back to the new major release >>> >>> The big disadvantage with this approach is that in the event that there is >>> a bad commit `git bisect` will only find it on a single development >>> branch. >>> On the plus side, the lack of merge commits means that it's easier to >>> revert. >>> >>> On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ctubb...@apache.org> wrote: >>> >>> > True. Everything I'm thinking of would work with no master, but that >>> might >>> > be confusing, and might break some tooling without extra effort (which >>> > branch is default when cloning?). We also kind of assume that the master >>> > branch is forward-moving only, but other branches are disposable and >>> can be >>> > rebase'd, deleted, re-created, etc. >>> > >>> > Alternatively, if people understood that a "2.0" branch is a "future" >>> > branch when 1.7 (master) is the "current", that'd work, too... I just >>> worry >>> > that people will merge it poorly. >>> > >>> > I suppose the best option, then, is probably to keep the status quo, and >>> > use a branch name like "ACCUMULO-####" which represents the overall work >>> > for a particular future release plan, instead of a name which looks >>> like a >>> > maintenance branch. >>> > >>> > >>> > -- >>> > Christopher L Tubbs II >>> > http://gravatar.com/ctubbsii >>> > >>> > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum < >>> > wilhelm.von.cl...@accumulo.net> wrote: >>> > >>> > > It seems to me you can get everything you want by merely getting rid >>> of >>> > > master or making master just be the 1.7 branch. I'm not really >>> concerned >>> > > about the name, because it's easy enough to figure out. Master >>> > duplicating >>> > > a tag doesn't really seem useful to me, save for "here's the highest >>> > > version we have released", which is of limited utility when a user can >>> > just >>> > > check the tags. I don't see the point in having master be something >>> for >>> > the >>> > > sake of having master. >>> > > >>> > > >>> > > >>> > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <josh.el...@gmail.com> >>> wrote: >>> > > >>> > > > Christopher wrote: >>> > > > >>> > > >> What purpose does the master branch serve if it's just the same as >>> the >>> > > >>> last >>> > > >>> > major release tag? >>> > > >>> > >>> > > >>> > >>> > > >>> >>> > > >> I think Josh had some specific opinions on this, but the general >>> idea >>> > > from >>> > > >> what I understood was that master is supposed to be stable... >>> > > >> representative of the latest, most modern release, because it's >>> what a >>> > > new >>> > > >> contributor would expect to fork to create a patch. That's hard to >>> do >>> > if >>> > > >> the goalpost is moving a lot, and it makes feature merges more >>> > > >> complicated, >>> > > >> since contributors have to rebase or merge themselves in order to >>> > > create a >>> > > >> patch that merges cleanly. Having a stable master makes it very >>> easy >>> > to >>> > > >> contribute to the most recent release. >>> > > >> >>> > > > >>> > > > No, I don't really care for a stable-only master (I think I diverge >>> > from >>> > > > the git-flow model in that regard). I like master to just be a >>> > > > "commits-go-here" area more than anything. >>> > > > >>> > > >>> > >>> >>> >>> >>> -- >>> Sean >>> >> >>
