lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: development process


From: David Kastrup
Subject: Re: development process
Date: Wed, 05 Feb 2020 11:46:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

> 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 can undersign those points.  One of the principal problems I see in
Han-Wen's problem description that he wants to see a hierarchical
solution where we have "trusted maintainers" that make all the
decisions, and when they don't make a decision, a contribution is
automatically considered rejected.

We don't have such a layering now, and we don't have the coverage with
expertise that would be required to make that work successfully.  More
often than not, the person contributing particular code is actually the
best expert of it at the time when the code is involved enough that a
review would make sense.  Reacting to objections and questions also
serves to spread that expertise, sometimes leading to better program
documentation, something leading to people being able to function as a
fallback when maintenance becomes necessary.

> I don't see why we need to have a final list of detailed points that
> we all agree upon before sketching a process.

Well, the current process leaves enough to be desired on the technical
side that making for an actual improvement should not be a high hurdle.
On the "human resources" side, I have the highest respect for the
workable environment and sense of cooperation the current team of
managers, meisters, contributors and coders has been able to provide.

> 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
>

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]