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

[Erik Faye-Lund]

On Wed, 2019-01-23 at 17:03 +0000, Emil Velikov wrote:
> Hi all,
> 
> In case the patch is still outstanding, feel free to add
> Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
> 

Thanks, pushed.

> 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.

I'm not sure that's the correct use of the term "bike shedding". You
might think that it's vanity?

Anyway, the goal isn't really either of those, but it's more closely
related to c) than any of the other points.

The goal is really to make it easier to browse the repository. Having
everyone's pet branch around in the main repo doesn't really make sense
now that forking is literally a press of a button. And it clutters up
the repository, making browsing the branches harder.

So yes, arguably it *is* very much a vanity thing, but I don't think it
is in a bad way; we're not losing any data, but we *are* moving some
historical data. I doubt anyone will care apart from it being easier to
find what you're looking for.

> If people want to go with c) the first regular expression from Erik,
> that lists all the release branches, feels list the best solution.

OK, thanks for clarification. If we end up doing this, it'll always be
an option to move branches incorrectly moved back again anyway, so I'm
not too worried.

> 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.

Hmm, interesting. Anyway, I wasn't suggesting removing any tags, I've
never had an issue with them.