[Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> All,
> 
> The mesa project has now hit 100 merge requests (36 are still open). 
> I (and I'm sure others) would be curious to hear people's initial
> thoughts on the process.  What's working well?  What's not working? 
> Is it total fail and should we go back to mailing lists?
> 

So, overall I think it works pretty well. I have some things I think
maybe we could do better, some of which has already been pointed out:

1. New MRs should probably get their cover-letter automatically sent to
the mailing list for incrased visibility.

2. Perhaps we should ban sending MRs from the main mesa repo? With
gitlab, it's trivial to make your own fork, and you can delegate
permissions to other users for collaborators. I don't think there's any
reason to clutter up the main mesa repo with all kinds of branches. But
it seems some people send their MRs from the main-repo anyway. Perhaps
we should document that this isn't how to send MRs?

3. There's some browsing-pain with the commit list. For instance, I
always second-guess if the latest commit is at the top or bottom. Some
times this is not a problem due to timestamps, but sometimes this isn't
clear from that either. I also tend to get a bit lost in context. Some
of this is probably habit, though.

I don't think any of these issues are show-stoppers from moving
entirely to MRs, though. Perhaps issue #1 here should be fixed first,
dunno...

Issue #1 is of course "just" a matter of writing some script that gets
triggered by a hook. It's just work that needs to be done; any of us
that complain about it could take up the work, I suppose.

The only question is where to host such a service... perhaps it's just
a gitlab CI step? That way we'd get some "automatic" cloud computing
power to do the work, but it doesn't really seem like a perfect fit;
we'd need to be able to distinguis between CI steps that are triggered
due to new 

Related to issue #2 here, think there's a lot of "historical" branches
that we can move from the repo, into some sort of "historical-branches" 
fork or something... Would that be worthwile?

It seems easier for end-users if they only find "official" branches
(release-branches, really) in the repo.

Similarly, I also think release-branches can be deleted at some point
after they are EOL, which makes it a bit easier to see what's going on.
At this point they should be pointing to the same commit as the most
recent tag of that minor-version series anyway, so nothing would be
lost...