Am Dienstag, den 12.05.2020, 17:15 +0200 schrieb Valentin Villenave: > On 5/12/20, Jonas Hahnfeld <[email protected]> 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
