On Sun, May 10, 2020 at 10:51 AM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble: > > On May 9, 2020, at 15:13, David Kastrup <d...@gnu.org> wrote: > > > Carl Sorensen <c_soren...@byu.edu> writes: > > > > ->CS At any rate, I think that we should have appropriate CG > > > > instructions at the time we make the switch. They don't have to be > > > > perfect (the CG has a much lower editing bar than the NR), but they > > > > need to be in place, IMO. > > > > > > It's sort of a hen and egg problem: if we want to have all that before, > > > it increases the workload for those preparing the migration and they > > > have to guess. > > > > > > I totally agree that the CG should reflect the new workflows. But at > > > the time we do the switch, those new workflows are still in flux. > > > > I understand Carl's perspective, but I'm on the side of jumping in. I > > don't expect that we'll be inundated with newbie contributors between now > > and the time we figure out what to put in the CG. > > > > Maybe we could put in a minimal note referring to the project on GitLab and > > explaining that a more thorough CG revision is pending. > > Sure, I can prepare such update. But as written roughly the same time > yesterday, we need to release 2.21.2 in order for that to be uploaded. > > In any case it's not clear to me whether I should prepare for the > migration today or not. This would be less frustrating if other high- > volume developers (including but not limited to David, Han-Wen, Werner) > commented on the plan...
Sorry. I'm fine with the migration going through today. We'll all be confused for a few days, but given that gitlab is more standard infrastructure than what we have, I think we'll figure it out. I suggest: * removing write access to issue tracker from me, so patch upload fails appropriately * stopping the job that mirrors staging => master (I think it runs automatically?) -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
