Re: development process

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 09:50 +0100 schrieb Han-Wen Nienhuys:
> 
> >> We don't need to rehash that the current system sucks.
> >
> > This would also be my comment on the initial message: It's again saying
> > how bad the current process is. It would be far more constructive to
> > make a concrete proposal about how to do it instead.
> 
> I want us to come to consensus what the problems are and before we try to fix 
> them. If we have no consensus about where we're trying to go, then a concrete 
> proposal will also generate controversy.
> 
> 
> It is useful to observe how the current system sucks: if we agree on what the 
> problems are, we can have a shot at spelling out our requirements. If there 
> is consensus of what we want from a process (the requirements), we can 
> evaluate options (eg. github, gitlab, gerrit etc.) against our requirements, 
> and select tradeoffs that suit ourselves best. 
> 
> 
> There is a list at the bottom of properties of what I think a better process 
> looks like.
> 
> I am sufficiently versed with github and gerrit to be able to build something 
> that could work, but doing so is a lot more work than discussing things, so I 
> like to be sure I am building something that solves the problem.
> 
> I get the feeling you don't like where this is going, but maybe you could 
> tell us what you think are problems, and what you would like to see in a 
> different process.

That's not really my point, I agree that we should improve the process.
I think everybody has a list of wishes such as yours, the major points
from mine would be:
 * have less tools to work with (currently SF, Rietveld, Savannah)
 * use tools that agree on a particular SCM (git-cl's history of SVN
and the custom code to open issues on SF)
 * use tools that are open and / or have an active future (experience
with Google Code, context of SF, requirements of GNU).

I don't see why we need to have a final list of detailed points that we
all agree upon before sketching a process. Note that "proposal" in my
view doesn't mean there needs to be a working prototype. I would be
happy to merely have a (subjective) list of points to address followed
by how concrete tools would solve them and why others don't.
Would it help you if I posted something like this?

> if you can only work with concrete proposals, I guess you'll have to wait 
> until the rest of us come to that point.

Okay.

Jonas

signature.asc
Description: This is a digitally signed message part