Dell - Internal Use - Confidential I concur with Adam that we need a list of branches you wish to remove. The hadoop branches 2.3 & 2.4 are relatively new and should not be deleted.
-----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/
