On 2018-06-01 03:27 +0200, Guillem Jover wrote: > On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote: > >> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote: >> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote: > >> > > Are you reestablishing commit access as it is currently? >> > >> > This is also something I'm not entirely sure about. One problem I've >> > had in the past is when preparing releases, if someone pushes then it >> > invalidates the current release process, which is annoying. Also >> > something I think I agree with the APT team, which they kind of >> > decided as policy recently with the switch to salsa is that if the >> > committers are not following very closely the project (so both mailing >> > lists and IRC), it makes it more difficult to coordinate or be on top >> > of what's going on. >> >> I follow the mailing list. Also I strongly follow your commit policies >> (which might be improved, so please let me know). Sometimes I also >> fix some very minor issue in the documentation (like spelling fixes, I >> think I also unbroke other translations previously).
I also follow the mailing list, but am not on IRC 24/7. But I could show up there and ask before pushing to the repository, if that is desired. > Sure, for major releases those could be announced more promintently on > the list, to prevent those kind of situation, and I should probably do > that again more often as I used to do. The problem has usually come from > hot-fix releases which need to be pushed quickly after an initial major > release. In those cases being on IRC is very handy. OTOH using the sid > branch for those, which I was not entirely sold on, means no conflict > should arise, in theory, but one of the main reasons for that branch > usage was precisely to just avoid those racing pushes. :) > >> > What I've been pondering about is whether switching to a merge-request >> > based workflow for translations, or perhaps even a switch to weblate >> > might work better for everyone? >> >> I'd strongly prefer the current workflow. Having to switch to a >> (partial) web based workflow would make me seriously reconsider my >> involvement. Also I'm not sure everything I've done so far (like >> stated above or fixes for errors in the (old)stable translation) >> would still be possible then. Any web based workflow would be a turn-off for me. > Right, I can understand. Would having your own repo (say on salsa or > elsewhere) where you push to, and which I'd have as one of my remotes > (where I already always fetch from all remotes), be a workable workflow? > I'd either notice and then integrate the changes, or a mail could be > sent, in case I've missed some updates? Manual steps should be avoided as much as possible since they are error-prone and tend to cause additional work. My preference would be to keep the current workflow, but using a second repository would also be fine as long as I don't have to deal with resolving merge conflicts. :-) Cheers, Sven