Re: [RFC] switch to GitLab / gitlab.com

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 21:02 +0000 schrieb address@hidden:
> On 05/02/2020 16:13, Dan Eble wrote:
> > On Feb 5, 2020, at 10:09, Jonas Hahnfeld <
> > address@hidden
> > > wrote:
> > > required to synchronize the review and the associated issue. I propose
> > > to start using GitLab hosted on gitlab.com [4] for all of this:
> > > Repository, Issues, and Merge Requests (MR) for reviews. It was
> > > evaluated 'C' in 2015 [5] and should be an 'acceptable hosting for a
> > > GNU package' [6].
> > 
> > Fine with me.  I don't expect to donate my time to make _any_ move happen, 
> > but I'd accept working with these tools to get my patches into LilyPond.  
> > It could hardly be worse than the current combination.
> > —
> > Dan
> > 
> > 
> 
> Let's assume this all 'comes to pass' what is, or how will, the 
> transition of what I do now be expected to happen?
> 
> How much (if anything) will I still need or be expected to do?

As explained in my original message, I'm not proposing changes to the
process. So for you as the Patch meister I would be "business as
usual", just with a different tool.

> These are rhetorical for now but will need consideration.
> 
> You will need suppose a testing phase and then a cut-off point from the 
> current patch review process.

I don't have a plan for this yet, this is merely a proposal to break
out from the cycle of complaining and instead discuss changes step by
step. But if we decide to pursue this direction, ultimately I guess
you're right, some cut-off needs to happen...

> (N.B. I really don't mind if the answer is that I'll be required no more 
> and I am out of a 'job' so to speak, I am not looking for empathy, all 
> that I am concerned with is that we don't end up with different 
> developers/patches working in two systems in parallel (if you see what I 
> mean), and that at the end of it all we still have the ability for 
> 'drive-by-patches' from developers or contributors whom today, just like 
> to send in git-formatted patches).

No, my hope is that you would be willing to continue your 'job',
basically implementing the process on top of the new tool. It will
certainly require some changes in the details (like using labels), but
from a high level it's hopefully the same.
In the future, we might (re-)introduce some automation to test changes
automatically. This would still leave checking the regtests and the
countdown cycle for a human, unless we also change that. But that's out
of scope, at least for me, right now.

Does this answer your questions?
Jonas

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