Dell - Internal Use - Confidential What is the purpose of these branch removal? What is the problem they cause and you are trying to fix. And what is the exact list of branches you want to remove. General rule of thumb that all branches correspond to a released version of a product. While it is tagged, branch is still needed in case a bug need to be fixed for a Customer. Thanks, Arkady
-----Original Message----- From: crowbar-bounces On Behalf Of Adam Spiers Sent: Tuesday, March 11, 2014 8:06 AM To: crowbar Subject: Re: [Crowbar] Removing branches fully merged into "master". Please can you post a full list of the branches you intend to delete, to ensure there is no confusion over the expected impact. I think it would also be wise to give everyone in all time zones a minimum of 24 hours to respond before taking action. Thomas Boerger (tboer...@suse.de) wrote: > Hi everybody, > > as nobody else said something i would like to start removing old > branches tomorrow! So it's your last chance to say something if you > would like to get a copy of specific old branches. I will create tags > for all the older release branches except roxy, stoney and hydrogen. > > > Kind regards, > Thomas Boerger > > On Wednesday, December 04, 2013 02:11:50 PM Sascha Peilicke wrote: > > On Wednesday 04 December 2013 12:32:58 Adam Spiers wrote: > > > Comments inline ... > > > > > > Sascha Peilicke (speili...@suse.com) wrote: > > > > Hi there, > > > > > > > > here's a slightly edited per repository list of branches merged > > > > into their master branch. All of those are behind master. In > > > > other words, those are fully merged branches waiting to be > > > > cleaned up. So if nobody objects, I'd like to drop those later > > > > this day. > > > > > > I'm a big fan of cleanup, but I think we should wait another day > > > or two at least, to give our colleagues in the US some time to think it > > > over. > > > > Sure thing. > > > > > > <semi-side-topic> > > > > Playing the same game against release/roxy/master produces > > > > slightly different results. It mainly digs up old release > > > > branches that are only behind (i.e. there was never ever > > > > something committed to them). Let's take swift for example > > > > (already removed the ones that will also appear in the > > > > merged-in-> > > > > > > > > master list further down below): > > > > remotes/crowbar/feature/grizzly/master > > > > remotes/crowbar/release/betty/master > > > > remotes/crowbar/release/fred/master > > > > remotes/crowbar/release/hadoop-2.3/master > > > > remotes/crowbar/release/hadoop-2.4/master > > > > > > > > So the question here is do we want to keep those old / > > > > never-modified release branches or are tags actually more > > > > appropriate? My take is kill whatever we can and add tags > > > > instead. This has the nice side-effect that github auto- > > > > generates releases for each tags (and thus a downloadable source > > > > tarball). This way old releases are more accessible, should > > > > anyone ever wanted to use those. But I may be missing things, so > > > > please speak up which branches really matter. > > > > </semi-side-topic> > > > > > > I think it's a question of support. If we know for sure that > > > *noone* will *ever* need to modify $OLD_RELEASE again or even > > > build an ISO from it, then I think it's OK to convert it from a > > > branch to a tag, with the goal of shrinking the currently long list of > > > branches. > > > However, even needing to still build ISOs from old releases would > > > probably prevent this branch->tag conversion, because ./dev > > > depends on the branches in order to build the ISOs. *Maybe* if > > > the tag had an identical name to the old branch it was replacing, > > > it could still work. But I doubt anyone tested that yet (and > > > Victor might be able to immediately think of reasons why that > > > wouldn't work, e.g. ./dev tool calling "git branch" directly). > > > > Totally forgot about the ./dev tool :-) So let's wait what Victor > > and the others say. > > > > > > Repo: ApacheHadoop > > > > > > > > remotes/crowbar/feature/cb20_devguide/master > > > > > > I think features can and should be removed *iff* they are fully > > > merged in *all* repos. > > > > > > > remotes/crowbar/release/rails3anddb/master > > > > > > I'm not sure why the rails3anddb branches had the "release/" prefix. > > > Pretty sure they can be removed. > > > > > > > remotes/crowbar/andi-node-alloc-change > > > > remotes/crowbar/perf-imp > > > > > > This kind of stuff can almost certainly go iff it's merged. > > > > > > > remotes/crowbar/pull-req/cloudedge/485 > > > > > > AFAIK that shouldn't be there. I'm guessing accidental leakage > > > due to use of ./dev followed by a misguided git push? > > > > > > > remotes/crowbar/vlowther-barclamp-pkg-metadata > > > > remotes/crowbar/vlowther-gemrc-hotfix > > > > > > Obviously stuff with someone's name on shouldn't be deleted until > > > they've approved :-) But in general, best practice is probably to > > > avoid polluting the main repo with personal branches - that stuff > > > should stay in our personal forks. (And as we saw recently, I'm > > > just as guilty of breaking that guideline as anyone else ;-) > > -- > Thomas Boerger <tboer...@suse.de> > Research & Development > > SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany HRB > 16746 (AG Nürnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer > _______________________________________________ > 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/
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
