[Mesa-dev] [PATCH] docs: add note about sending merge-requests from forks

[Erik Faye-Lund]

On Wed, 2019-01-23 at 10:42 +0000, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> > On Wed, 2019-01-23 at 10:14 +0000, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> > > eric.engestrom at intel.com> wrote:
> > > > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > > > Sending MRs from the main Mesa repository increase clutter in
> > > > > the
> > > > > repository, and decrease visibility of project-wide branches.
> > > > > So
> > > > > it's
> > > > > better if MRs are sent from forks instead.
> > > > > 
> > > > > Let's add a note about this, in case its not obvious to
> > > > > everyone.
> > > > 
> > > > Yes please, we already have way too many dead branches in the
> > > > main
> > > > repo
> > > > without adding that kind of things to it.
> > > > 
> > > > One other thing is that (last time I checked) the scripts
> > > > propagating
> > > > the repo to github et al. don't propagate branch deletions,
> > > > which
> > > > means
> > > > the clutter never gets cleaned there.
> > > 
> > > They're propagated from gitlab.fd.o to git.fd.o, as the hook is
> > > run
> > > within regular post-receive, but you're right that pushing from
> > > git.fd.o to GitHub doesn't notice old branches, as it just pushes
> > > everything present in the git.fd.o repo to GitHub, and doesn't
> > > notice
> > > any branches no longer present.
> > 
> > Yeah, and then add the problem that forking in Github copies *all*
> > branches as well (not just the default branch), means that these
> > branches keeps getting replicated over there. It gets nasty
> > quickly.
> > 
> > Perhaps we should do a manual spring cleaning in the repo soon,
> > moving
> > old, stale branches out to some historical repo and making sure
> > official forks don't have any cruft?
> 
> I looked at that a year or two ago, but I quickly gave up. You're
> welcome
> to give it a go, but be aware that there's a very large number of
> very old
> branches.

Looks quite managable to me. There's really only a few branches that I
think should be kept int he main repo, and I think they can be
enumerated like this:

git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" |
grep -E "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0-
9]+\.[0-9]+$"

Those seems to be *actual* release-branches. There's some other "almost
release-branches", like these:

$ git for-each-ref refs/remotes/origin --format "%(refname:lstrip=3)" |
grep -vE "^[0-9]+\.[0-9]+$|^mesa_[0-9]+_[0-9]+_branch$|^staging/[0-
9]+\.[0-9]+$" | grep -E "^mesa_[0-9]+_branch$|^staging/|^[0-9]+\.[0-
9]+"
18.1-proposed
7.8-gles
mesa_20040127_branch
mesa_20040309_branch
mesa_20050114_branch
staging/18.2-ci

I suppose to be conservative we could include these as well.

But perhaps someone like Emil could chime in here?

Personally, I think we could go as far as removing all "closed" release
branches as well; we can just branch out from the most recent tag if we
need to back-port something in the future.