Disclaimer: I am not a github expert. Regarding branch lifecycle:
1. Work on the release being actively developed continues in a branch 2. When that release is shipped, another branch is made so that active development on the next release can continue in one branch, and critical fixes can be made in the shipped branch only if needed It sounds like the recommendation for best practice is to convert the shipped branch to a tag once that branch is no longer supported? Is there a safe way to do this without risking losing the branch? If a branch has 1 change in it that is not included in any other branch, then it can't be converted to a tag can it? Thanks, Chris Dell -----Original Message----- From: crowbar-bounces On Behalf Of Sascha Peilicke Sent: Wednesday, March 12, 2014 10:07 AM To: crowbar Subject: Re: [Crowbar] Removing branches fully merged into "master". On Wednesday 12 March 2014 13:59:57 Adam Spiers wrote: > [BTW no need to send to both crowbar@dell.com and > crow...@lists.us.dell.com] Sascha Peilicke (sasc...@mailbox.org) wrote: > > On the other hand, seasoned developers with an eye for beauty are > > consistently annoyed by the continued over-use of Github. > > I'd call it abuse or misuse of git rather than over-use of github, but > essentially I agree. > > > People use the "crowbar" Github > > organization for their private feature-fiddling while they should do > > that in their own fork. Whether to keep stable-release branches or > > use tags instead is a matter of taste, I believe. > > Not quite, IMHO - unmaintained stable releases should be tagged, and > maintained stable releases should be branched. At risk of stating the > obvious, this is because git tags are intended for stationary > snapshots, whereas branches are intended for tracking moving targets. Very well written and I agree. It all depends how "moving target" is defined. So far I don't think we properly phase out "old branches". People just stop to push code there at some point. In other words, we should think about a proper release life-cycle. Dunno what that means for Dell's pile of branches, but the SUSE guys more or less informally fix at most 3 branches. That is the current dev branch (stoney) and the two releases in maintenance (pebbles aka SUSE Cloud 2.0 and roxy for SUSE Cloud 3). > > But the following examples are really a miss-use: > > remotes/crowbar/release/hadoop-2.1/master > > remotes/crowbar/release/hadoop-2.2/master > > remotes/crowbar/release/hadoop-2.3/master > > remotes/crowbar/release/hadoop-2.4/master > > > > It should be one "hadoop" branches with tags 2.1, 2.2, 2.3 and 2.4. > > That depends on whether there is an intention to maintain 2.1 > independently of 2.2 etc. Yes, closely related to the life-cycle discussion above. > > remotes/crowbar/release/mesa-1.6.1/master > > remotes/crowbar/release/mesa-1.6/master > > remotes/crowbar/release/mesa-1.7/master > > > > Same here. > > I'm not so sure - IIRC at least two of these are considered > independent releases. Ok, in that case I don't know enough about Dell guy's commitment to the mesa branches. > > remotes/crowbar/release/mesa-1.6.1/openstack-build/master > > > > WTF? Away with thee! > > Yeah there is a big WTF factor with that. It stems from the abuse of > git branches to track not only releases but also products, or builds, > or something else depending on your preferred terminology. > > > I guess that's where the most cleanup potential lies. > > I'd say removing ancient feature / topic branches is the lowest > hanging fruit. And the least controversial. -- Viele Grüße, Sascha Peilicke _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
