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 >> > >
