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/
