Why remove old/unused branches? To keep our garden tidy. They’re distracting at best, confusing at worst. For old release line branches, it’s not clear to a casual committer which branches need to receive a back port. It’s clear if the EOL branches are gone.
On Wed, May 20, 2020 at 18:06 Guanghao Zhang <zghao...@gmail.com> wrote: > +1 for remove feature branches and start a case-by-case discussion for > "others". > > And for branchs of old release line, what's the harm if keep them? I > thought we don't need to remove them. > > Thanks. > > 张铎(Duo Zhang) <palomino...@gmail.com> 于2020年5月21日周四 上午8:14写道： > > > What is the benefit? > > > > Nick Dimiduk <ndimi...@apache.org>于2020年5月21日 周四07:31写道： > > > > > Heya, > > > > > > We have lots of branches hanging around in git. These appear to be > > > 1. branches for old release lines (i.e., 0.90), > > > 2. feature branches (that are potentially stale, i.e., HBASE-11288), > > > 3. "other" (i.e., 0.89-fb, former_0.20, revert-1633-HBASE-24221). > > > > > > Can we decide it's okay to delete some of these? > > > > > > For (1), all of our release tags, going back to 0.1, are preserved. > > There's > > > no benefit to keeping these. > > > > > > For (2), I think there's no discussion required, just someone to go > check > > > each Jira ID, and delete any that are closed, maybe with a comment on > the > > > Jira first. Maybe this could be automated? > > > > > > For (3), I suppose we need a case-by-case discussion? Maybe there are > > > categories of these that can be resolved in blocks. > > > > > > Thanks, > > > Nick > > > > > >
