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. > <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). > 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 ;-) _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
