On 14 Mar, Jim Lesurf wrote in message
> However I've also now been trying using FireFox (Linux) and that isn't
> much better. I found *one* recent comment from ROOL giving reasons to
> reject JB's changes which it refers to. But I can't find any of the other
> discussions or comments people in this usenet thread seem to be referring
I'm going by the comment made to JB, which references work done with CG to
improve the source tree for merging in 2018, as well as mentioning private
emails between ROOL and CG on the subject which ROOL suggest petered out
when ROOL didn't get answers to their messages.
Even from that one comment, there's clearly far more to this than you've
presented in your initial posts here.
> Tried clicking around various links, and I can find code, but not the
The other discussions look to be private (in emails?), as does a lot of the
older code (or it's well hidden in old branches and merge requests).
That's the main problem that I have with your accusations. If the code is
hidden, that's only because JB and CG have chosen not to put it into a
visible branch on ROOL's GitLab -- and that's their call, not ROOL's.
It might also explain the apparent problems merging. Generally, one branches
the code that one wants to work on through GitLab, works on that branch
locally and keeps it up to date with the changes to the "live" code as one
goes. In that scenario, one just needs to push one's local branch back to
GitLab occasionally for it to be safely backed-up on ROOL's server and
visible to everyone at no extra effort. And when one comes to create that
final merge-request, it's "just" a case of getting the branch fully
up-to-date with where the "live" code is now, and then presenting it to ROOL
If this isn't what has been done, then it could well be an utter nightmare
to merge back in -- which is what ROOL seem to be saying. The comment about
"a misunderstanding of how git can be used" seems to point this way, too.
When projects are moving fast and many people are contributing, it's very
easy to tie oneself up in knots if the source control tools aren't used in
the correct way. I've done this myself with both Subversion and Git, and
know from first-hand experience how painful it can be to sort out. Small,
quick changes can be done in an ad-hoc way without much pain; anything "big"
which affects multiple files or takes weeks or months to complete *must* be
done in a manageable way, with changes in the main source being kept on top
of regularly by merging them in.
If things are so out of kilter in the new USB code that unrelated stuff
removed by other developers in 2018 is reappearing in the 2021 merge
request, then the only people who can fix it are JB and CG. In the worst
case, it even may come down to creating a clean, new branch from HEAD and
transferring their changes across piece by piece (and yes, I've done this
before -- and learned my lesson as to why it's bad to get into this
It might be hard work for the people who wrote the new code -- but it will
be many times more difficult for ROOL, because ROOL aren't familiar with the
changes being applied.
As I've said before, the above is speculative -- based on ROOL's comment to
JB's merge request and my own experiences. I have no insider knowledge of
the situation, which is why I'd hoped that you could back up your own theory
as to what was stopping things.