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

[Emil Velikov]

Hi all,

In case the patch is still outstanding, feel free to add
Reviewed-by: Emil Velikov <emil.velikov at collabora.com>

On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
<erik.faye-lund at collabora.com> wrote:
>
> 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.
>
Before we start removing things I think we should consider:
 - what extra size savings are we talking about
If it's something like, say 10MiB personally I would not bother.

 - but most importantly, what the goal is - a) remove merged work, b)
reduce size c) list only active branches, d) other
Personally a) and b) sound perfectly reasonable, while c) seems like
bike shedding.

If people want to go with c) the first regular expression from Erik,
that lists all the release branches, feels list the best solution.
Considering memory serves me right, for [very] old release branches
the history/tags is non-linear and some tags are detached. Hence
dropping them sounds like a bad idea.

HTH
Emil