On Tue, Apr 28, 2020 at 1:09 PM Adriaan de Groot <gr...@kde.org> wrote: > > One actor is "tooling", as Albert has pointed out. Whatever the resulting > structure is, it needs to be communicated to tool authors on time for tools to > be updated, released, and rolled out for use. Tools mentioned so far: > - kdesrc-build > - i18n / scripty > - release scripts > The tools don't have An Opinion regarding the layout, they just need to be > updated. >
To some extent, yes, but some assumptions are baked in at a quite fundamental level for e.g. kdesrc-build (if I understand the Perl correctly): - Uniqueness of project names. Cannot have two "documentation" projects being advertised through kde-build-metadata - There must be a single shared root prefix for all projects. This prefix may be the empty string, but the point is that repo paths advertised in kde-build-metadata must work from this single root prefix Any solution that wishes to preserve tooling must take these fundamental constraints as given or else risk that you cannot move until the whole world is fixed first. I'm obviously biased as someone who invested some time and effort in kdesrc-build, but the busfactor is a real concern here. E.g.: Michael clearly just hasn't had the time lately to spend on kdesrc-build and I don't think it's such a great idea for me to merge in major changes without him reviewing it first. > > A tool-like actor that I don't think has been mentioned so far is "existing > checkouts". I have a src/kde with all the bits I've looked at "recently". > There may even be some SVN checkouts there -- I'm willing to forget about > those. Surprising and annoying me every time I update those sometime in the > future is not good, but it's only going to annoy me once (per repo, so at most > 143 times for my clones). > I think that this is a bit of a lost cause. I think there's going to be some level of annoyance all around until the pain has finally died away because everybody made the upgrade. We can have a script to help with that but that will inherently assume quite a bit about how you set up your projects manually to begin with and it will still piss off a lot of people because we break their workflow no matter what. The main problem is not technical here, the main problem is that people who use that manual git clone workflow do so because they don't want to use the layers of tooling. So adding layers of tooling to "fix" the manual work flow is defeating the point, and therefore the pain is here to stay I think. At a fundamental the only way to avoid the pain is for the URLs to continue to work somehow, but I gather that is a completely unfeasible solution in terms of not driving sysadmin crazy. A fairly big one is that the fingerprint of the host's SSH key will be different. > > I'd be *vaguely* worried about existing crontabs and automatic jobs that we've > forgotten about, or which others have forgotten about. Those aren't fixable in > the face of any changes to repositories, anyway. > Yep. And I think for the exact same reason why a porting/transitioning script is probably not going help all that much -- too much diff in setup/config/versions/tools on the other end to deal with in a reasonable script. It's the main source of complexity in a tool like kdesrc-build and that has lot's of Perl to hammer systems into submission... :) > > Turning to human actors, who are the more interesting ones, > I think we're in a situation that this migration is going to cause pain for the human element no matter what. I also think that ultimately from a technical pov it mostly doesn't really matter. As someone else already mentioned: the Internet has search engines for that. What exact flavour of labeling/grouping/hierarchy we use, I think it is mostly bikeshedding: I would predict that at first this is going to be annoying for many if not nearly all contributors. After a while we've all made the upgrade (just a matter of tweaking your ~/.gitconfig & git remote set-url per repo) and then it's business as usual. So yes this is about the social aspect. Personally I think the pain is unavoidable for the individual contributor, but what seems to be getting lost in this discussion is that there *is* also an amount of pain that can be avoided. We can avoid pain for the sysadmin team by choosing whatever is easiest to maintain long term here. We can avoid pain for the maintainers of tooling by choosing whatever fits the tooling most easily. In particular we can avoid choosing an option that imposes additional parallel sysadmin work indefinitely, like e.g. dedicated mirror services to redirect stuff. I would like to propose that the sysadmin team pick the layout that is easiest to *implement*, which I suspect is also the most like what we have now, and that we live with that. Unless there is a pressing need, like real hard data that we're losing contributors because they can't find our repos or a sysadmin burden that would be excessively higher than otherwise... let's keep things as simple and straightforward for syadmin and tooling maintainers to implement during the Gitlab migration. Let's worry about the perfect project layout once we've identified the need. That way it's a lot easier to garner consensus for a practical solution that isn't just a wishlist of all the features we would like but which Gitlab may or may not have and which tooling is probably completely unprepared for. By all means disregard this stuff if the pressing need has already been identified and I've either neglected to read e-mails properly or wasn't aware for some other, possibly historical, reason. Regards, - Johan