Dell - Internal Use - Confidential All, While we're in favor of cleaning this up, there are many folks out of the office who haven't been able to look at which branches we need to preserve. I need to talk with them about the branch history in order to know what we can safely delete. Until this happens, which will most likely be early January, do not delete any branches. Additionally, please indicate here specifically what branches for what repositories you would like to see deleted. I will try my best with to coordinate the discussions and get consensus on this topic. -John
-----Original Message----- From: crowbar-bounces On Behalf Of Sascha Peilicke Sent: Wednesday, December 04, 2013 8:12 AM To: crowbar Subject: Re: [Crowbar] Removing branches fully merged into "master". On Wednesday 04 December 2013 12:32:58 Adam Spiers wrote: > Comments inline ... > > Sascha Peilicke (speili...@suse.com<mailto: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 ;-) -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
