Thomas Morley <[email protected]> writes: > Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup <[email protected]>: >> >> Han-Wen Nienhuys <[email protected]> writes: >> >> > Rietveld and my local commits are not linked. If I change my commits, I >> > update my commit message. I have to copy those changes out to Rietveld >> > by >> > hand, and it took me quite a while to find the right button (“edit >> > issue”, >> > somewhere in the corner). >> >> Then you have set it up incompletely or use it wrong. > > David, I disagree. As far as I can tell git-cl does not update > commit-_messages_ on Rietveld.
After rereading what Han-Wen wrote more carefully, I have to agree that he was right. I thought this was about followup patches, but indeed the commit message is not changed. > Or I have an incomplete setup myself. No, I was wrong and reading too sloppily. Han-Wen is certainly correct about that point. But then I don't think anyone was really overly defending our current toolset. >> > The whole constellation of tools and processes (bug tracker for managing >> > patch review, patch testing that seems to involve humans, Rietveld for >> > patches, countdown, then push to staging) is odd and different from >> > everything else. For contributing, you need to be very passionate about >> > music typography, because otherwise, you won’t have the energy to >> > invest in >> > how the process works. > > Yes, I took that route, fighting my my way through it. I would think that the highest hurdle for dedicated testers is a working development environment. > Per aspera ad astra... Well, I agree with Han-Wen that lowering the barrier of entrance is a good idea. When I started, VMs were quite unusual. That has changed, so maybe the highest hurdles have shifted a bit. > As already said frequently, our current method is suboptimal. > Afair, it was implemented because of the small amount of developers, > most of them with limited time. > As one example: the countdown-delay gave more of them the chance to > look at proposed patches... > Other problems: sourceforge is not the best as well, git-cl buggy etc > > Han-Wen, I do understand that current setup slows you down and annoys > you and why. It's partly tools, partly workflows. Changing tools will to some degree also necessitate changing workflows; I am not sure how much of the discussion revolves around a desire for a different workflow or different tools. -- David Kastrup
