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

Wed Jan 23 21:26:48 UTC 2019

On Wed, 23 Jan 2019 at 17:21, Erik Faye-Lund
<erik.faye-lund at collabora.com> wrote:
>
> 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?
>
Agreed, vanity is closer to what I was thinking off.

> 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.
>
Fwiw gitlab already groups active and stale branches [1].
If listing all branches in the drop-down at the main page [2] is too
much, gitlab could (patch needed?) reuse the same logic.

> 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.
>
I often git log, although only on the master branch. Thus such change
won't affect me.
Then again, I rarely click on the gitlab branches drop-down list either :-)

Hence I don't see the interest, but if people think it has value - go ahead.

> > 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.
>
Indeed, it was pre-emptive information, since tags was likely to come up.
Especially, since we had reports of "issues" flagged by git fsck [for
some old tags].

In general, I'm neutral on the topic.

HTH
Emil

[1] https://gitlab.freedesktop.org/mesa/mesa/branches
[2] https://gitlab.freedesktop.org/mesa/mesa