Re: labels on GitLab

[Jonas Hahnfeld]

Am Dienstag, den 12.05.2020, 17:15 +0200 schrieb Valentin Villenave:
> On 5/12/20, Jonas Hahnfeld <address@hidden> wrote:
> > I'd really hope we can discuss things before changing...
> 
> And *I*’d really hope “discuss things” can amount to more than
> “blindly reverting everything and anything that’s been done by someone
> else”.

I think this statement is exaggerating. I've been working with James to
carry over as much of the process as possible. This includes mechanisms
to automatically add Patch::new to merge requests and a script to get
this into a form that can be used for both the email text and (still
manual) testing.
With SourceForge we used to rely on Phil's page to get a nice list of
where each patch is. During the trial I looked at how to do this in
GitLab and came up with issue priorities. When sorting like this:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
we get a very similar list. I'm not saying this is the only way and
maybe not even the best solution, but it works for the beginning.
The reason I was so quick about "reverting" the additions to
prioritized labels is that we'll (hopefully) see the next countdown
tomorrow. This will be the first using GitLab and merge requests
entirely. Adding even more bumps in there is likely frustrating for
everybody involved.

I fully acknowledge that none of the above is documented. That's
actually yet another reason to be careful when changing project-wide
settings. For what it's worth, I consider this to also apply to myself:
You'll not see me converting the Fixed_x.y.z to milestones without
discussing this first. LilyPond is a large project where most certainly
nobody understands all reasons. This applies to the code, but also to
the infrastructure.

Whew, this took much longer than expected to write calmly. Off to
something else for the rest of the evening.
Jonas

> Look, you’ve obviously spent quite some time setting this up and
> you’re obviously much more familiar with the tools at hand; therefore,
> I’m not gonna bother spending any more time trying to lend a hand
> before *you* update the CG and properly explain what it is you want us
> to do and/or not do, and how you want us to do and/or not do it.
> 
> Cheers,
> -- V.

signature.asc
Description: This is a digitally signed message part