Re: development process

[David Kastrup]

Thomas Morley <address@hidden> writes:

> Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup <address@hidden>:
>>
>> Han-Wen Nienhuys <address@hidden> 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