Re: development process

[Kieren MacMillan]

Hi again,

> Let's pick one person: Han-Wen.  He's said that he has a few hours
> to spend on LilyPond on Friday afternoon.  Would he prefer to work
> on resolving comments about his latest patch on scheme internals
> (or whatever he's working on) ?  Or would he prefer to spend time
> communicating with his "paired" developer, who's excited about the
> shape of the alto clef and wants to work on that instead?
> 
> I can't answer that question, and neither can you.

I didn’t try to, and don’t want to.

> Han-Wen is the only person who can decide how he'd like to spend his time.

Correct. I’m not suggesting anybody has to do anything they don’t want to do, 
or have any decision made for them.


My syllogism [on this particular focused topic] is simply this:

1. A problem in the past has been patches "dropping off".

2. One of the things that could help (and certainly couldn’t harm) keeping a 
patch moving forward is if every patch were [co-]signed out by a (i.e., at 
least one) developer who is capable of taking that patch to the goal line. 
Conversely, every patch signed out only by one or more developers *incapable* 
of taking it to the goal line is another patch with the distinct possibility of 
taking up (read: wasting) valuable resources (time in review, commenting, etc. 
by higher-level developers) during the process, and ultimately "dropping off".

3. It is worth discussing whether instituting such a system/restriction would 
provide a net benefit to the overall development process and experience.


If one of those premises, or the logical steps/deduction between them, is 
flawed in some way, please let me know. Also, if somewhere in those three steps 
I’ve suggested — explicitly or implicitly — that (e.g.) Han-Wen wouldn’t be 
able to fully make his own decision on how to spend his time, please point that 
out to me.

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Kieren MacMillan]

Hi Graham,

> Thought experiment: suppose that a complete newcomer posts to the
> email list tomorrow, saying that he was interested in working on
>bug #5542 cross-staff slur hides text in eps backend
> (I picked randomly).
> 
> Would anybody jump up and say "great!  Let me help you get
> started.  I'll work on this with you!"?  Or would there be silence
> for a few days?
> 
> If you say "I expect that a developer (but not me) would step
> forward and offer to mentor him"... then you would be expected
> extra volunteer effort from developers.

I wouldn’t (and didn’t) say or expect that at all.

What I *am* saying is this: I’d bet good money that if Joe Newcomer** wasn’t 
allowed to even start work on bug #5542 until Capable Developer stepped forward 
and "co-signed" for the patch — effectively guaranteeing it has at least the 
*technical* possibility of making it to the goal line — there’d be a lot fewer 
newbies frustrated when their patches, which they spent many hours coding, 
"dropped off" during the later stages (review, push, etc.) of the process, 
which is what you explicitly pointed out has been a problem in the past.

Cheers,
Kieren.

** Joe Newcomer was the commissioner of "The Gray Cat & The Flounder", an 
evening-length "theatre of music" piece I wrote in 2015. I hope this post ends 
up in future web searches for Joe.  =)



Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Graham Percival]

On Wed, Feb 05, 2020 at 08:59:33PM -0500, Kieren MacMillan wrote:
> > LilyPond has had a lot of patches get dropped because
> > nobody feels comfortable reviewing / shepherding them.
> 
> Seems to me like one solution to that problem might be a subtle
> variant on extreme programming: All features/fixes must be
> signed out for "patch-ing" by two developers, at least one of
> which has committed to and is capable of being the mentor
> (shepherding/reviewing).

If LilyPond development were a job (which it isn't), and I was the
manager/boss (which I'm not), then I would be totally on board
with ordering experienced developers to spend 20%-30% of their
time mentoring.  This "pair programming" solution is one such
version.

But LilyPond isn't a job.  It's a volunteer effort, and people are
free to donate their time (or not) as they see fit.

Let's pick one person: Han-Wen.  He's said that he has a few hours
to spend on LilyPond on Friday afternoon.  Would he prefer to work
on resolving comments about his latest patch on scheme internals
(or whatever he's working on) ?  Or would he prefer to spend time
communicating with his "paired" developer, who's excited about the
shape of the alto clef and wants to work on that instead?

I can't answer that question, and neither can you.  Han-Wen is the
only person who can decide how he'd like to spend his time.


I would *love* to see more developers collaborating together.  But
if the current landscape is anything like it was from 2000 - 2012,
then I fear that any policy which *required* such collaboration
would likely lead to a collapse of development effort.

My $0.02: developers can already form pairs, or take newcomers
under their wing, or do any number of activities that involve
collaborating off-list.  I tried to set up "programming mentoring"
at least twice, and it always fizzled out.

If there's more developers interested in mentoring, and if they
can get a real community of mentoring going for a few months,
*then* I think it might be worth formalizing such arrangements in
policy.  But unless / until that happens, I would be reluctant to
have a policy that required collaboration which we don't see
happening already.


Thought experiment: suppose that a complete newcomer posts to the
email list tomorrow, saying that he was interested in working on
bug #5542 cross-staff slur hides text in eps backend
(I picked randomly).

Would anybody jump up and say "great!  Let me help you get
started.  I'll work on this with you!"?  Or would there be silence
for a few days?

If you say "I expect that a developer (but not me) would step
forward and offer to mentor him"... then you would be expected
extra volunteer effort from developers.

Cheers,
- Graham

Re: development process

[Kieren MacMillan]

Hi Graham (et al.),

> LilyPond has had a lot of patches get dropped because
> nobody feels comfortable reviewing / shepherding them.

Seems to me like one solution to that problem might be a subtle variant on 
extreme programming: All features/fixes must be signed out for "patch-ing" by 
two developers, at least one of which has committed to and is capable of being 
the mentor (shepherding/reviewing).

The [well-documented] benefits of extreme programming should decrease poor 
design choices out of the gate, reduce the number of errors, make the whole 
process go faster, and guarantee that the "coding team" has the skills and 
commitment to take it to the goal line [assuming the rest of the process is 
relatively smooth and the gatekeepers receptive].

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Graham Percival]

On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote:
> Han-Wen Nienhuys  writes:
> > For context, I have a busy daytime job. I work 80% so I can set aside
> > a couple of hours of concentrated hacking time on Friday.

Yes.  I expect that most people knowledgeable about lilypond code
are in this situation, or have even less time available.  The
whole idea behind the "countdown" system introduced in the early
2010s (which I believe is still in effect) is to make maximum use
out of LilyPond experts who only have a few free hours per week.

Suppose that an expert has 2 hours of time on Friday, and maybe 10
minutes per day to skim emails for the rest of the week.  The idea
is that you can quickly see the patches that are nearing
acceptance, review them, and warn if they make any bad changes.

That's why the "countdown" system has multiple stages -- it was
designed to take at least 72 hours (IIRC) from submission to git
master, precisely to allow infrequent-but-expert developers a
chance to spot mistakes before they got into git.


> >We use “we’ll push if there are no complaints” for contributions. I
> >think this is harmful to contributors, because it doesn’t give 
> > contributors
> >a clear feedback mechanism if they should continue down a path.
> 
> They get feedback when the code is getting reviewed.  If code does not
> get reviewed, having their changes dropped on the floor is not going to
> increase their enthusiasm.

Yes.  And unfortunately, LilyPond has had a lot of patches get
dropped because nobody feels comfortable reviewing / shepherding
them.

That could be avoided if the community demanded that expert
developers spend more time reviewing patches and mentoring
beginners... but that would be horribly insulting to those
developers.  If somebody has volunteered x hundred hours, then
wishes to follow other persuits, the community should thank them
for their effort and wish them well.

> >It is harmful to the project, because we can end up adopting code
> >that we don’t understand.  -

That's true.

It's not an easy place to be in:
- there's not enough experienced developers who want to mentor
  newcomers [1].
- if it's too easy to get code in, stuff will break.
- if it's too hard to get code in, few people will want to
  contribute.

I'm not claiming that the current situation is the ideal balancing
point, but we were aware that it was a compromise solution.

[1] there's good reason for that -- my experience from the grand
documentation project is that approximately 25% of contributors
reached the "break-even" point (compared to me simply writing all
the docs myself) [2].  Based on my investigation into similar
projects (GNOME, google summer of code, etc., around 2012), that
figure is normal.

[2] of course, some of those 25% have gone on to do an incredible
amount of work, so I consider the project to have been a great
success.  Still, I can see how it can be demoralizing for a
developer to put hours into mentoring a newcomer who ends up
contributing only one or two small patches.

> The current scripts were designed to work with Google Code,

Yes.  I wish that github was FSF or GNU approved, or that there
were other tools of the same quality.

Cheers,
- Graham

Re: development process

[Joram Noeck]

Dear developers,

tl;dr:
 * please continue those discussions to a constructive end
 * my experience as a non successful contributor


after more than a year of (relative) abstinence from LilyPond, I enjoy
reading the current drive in both commits and discussions in the
aftermath of the Salzburg conference. (I wished I could have been there.)

I am not a LilyPond developer, so the following is more an outside
perspective. I decided to share it, because "potential new contributors"
are mentioned several times. While sometimes there are no two ways about
it, there is room for improvements and compromise, I guess. Neither the
current dev process and tools are optimal nor is it advisable to change
everything. Because I can feel some tension in the recent discussions,
I’d like to emphasize that the following is to be read in a very
friendly tone.


Experience with trying to contribute


I am working with software development every day. I wanted to contribute
to LilyPond since about 2005. It never happened and there are some reasons:

- Even after reading the CG and getting some helpful answers to
questions, I never understood how the process works.

- tools:
  - I am used to github+travisCI and to Atlassian/Bitbucket/Jira/Jenkins
and I enjoy working with those setups. But I never understood the
LilyPond toolchain and especially the path from a commit/issue to the
final change in a LilyPond version.
  - I don’t understand why
 · there are so many tools involved, lily-git, git-cl and so many
   accounts required
 · it seems so hard to compile LilyPond on an ordinary Linux machine
   i.e. why I need LilyDev
 · dependencies on clang-format or (for a long time) python3 are
   frowned upon while the dependencies on guile and GUB look much
   more complicated to me.
  - I guess (because I haven’t worked my way through the current tools),
several of the already listed tools with better integration of review
and/or issue tracking would be an improvement over the current tools.
  - At some point I needed a Google account which I didn’t want and
could not get without a cell phone.

- I experienced quite some amount of misunderstandings and in a few
cases insinuations which made it very unpleasant to invest the work to
get over the technical hurdles. I felt a bit scared away.

- According to what I read on lilypond-devel, quite frequently
suggestions end up in an undecided state where some are for and some are
against a proposal. But that is probably much less the case for patches.

That’s my very personal experience. I have some minor local patches,
some are made obsolete by recent development. In some months from now, I
might make a new attempt to understand how contributing works.


Braking things down
---

I have the impression that what is currently discussed might be too big
to be decided upon at once. There could be some merit in splitting
things into smaller decisions. I see at least these points:

1. code style conventions
   a) checking tools (astyle, clang-format), for scm or python?
   b) changes only for new code?
   c) and their level of enforcement (hooks, review process, …)
2. tools for git, review, issue tracking, release management
   pros and cons have been mentioned for several options, but even
   if there is nothing new, a systematic assessment could help
3. development process / code of conduct
   a) number of stages from a proposed patch to a final change
   b) decision process and who decides what
   c) formal rules vs. consensus

I am sure I missed some important points here.


Even if it doesn’t matter at all, my personal choices would be:
- tools: github+jenkins, but very open to gitlab and others
 definitely clang-format over astyle (just my experience)
 I moved once from trac to github.
- less manual work in cherry-picking, testing, linking commits to issues
- much more openness towards change
- a clearer description how decisions are made and who decides while
still preferring to keep a community mindset over a strict rule set.

Many thanks to all developers for making LilyPond what it is and I wish
that you can see those discussions as a fruitful way to improve things.
In my opinion it matters for potential new developers.

Cheers,
Joram

Re: development process

[David Kastrup]

"Jürgen Reuter"  writes:

>Hi all,
>
>I fully agree with Han-Wen.  I also could now and then (maybe once a
>week) set aside 2-3 hours work for lily.  But the current development
>process really makes it hard for me to keep up submitting a patch (as
>part of currently 11 commits (mostly small to medium ones), partially
>with dependencies, that have been lying around locally on my machine
>for at least ~3-4 years), as I can't just "git push" my 11 commits
>after these 2-3 hours of work, and then, in my next available slot,
>maybe a week or two weeks later, look at code reviews / comments from
>other people, do a "git fetch" / "git rebase", consider the code
>reviewer's comments, and submit an updated version of the 11 commits.

It's been stated before but probably not to you in particular: you can
just send in your commits as git-formatted patches to
bug-lilyp...@gnu.org and have them entered as issues.  If there are
objections on the review that do not appear addressed, the patch meister
will stop the patch from progressing to commit state.

Even if not, I think that you have valid Savannah credentials for
pushing yourself, so unless you ask for someone else to push your
patches, you would be free to make the decision to push at your own
leisure (to origin/staging) once they have passed review and progressed
to "push" state.

In short: if you don't want to bother with the messy parts of patch
submission, there is no problem submitting your patches anyway.

All the best

-- 
David Kastrup

Re: development process

[David Kastrup]

Kevin Barry  writes:

> I don't know if lurkers' opinions count, but on the subject of potential
> replacements for Savannah/Sourceforge: I am part of a team that administer
> both Gerrit and Gitlab in-house deployments. If choosing between them I
> would advocate for Gitlab because it includes issue tracking and CI/CD so
> perhaps all work can go through one place and contributors/maintainers
> would not need to have accounts for multiple apps/systems. Gerrit is a good
> code review tool, but for various reasons that may be our own fault, it is
> deeply unpopular where I work.

Ok, that's giving us one point of reference.

> I am sadly not quite up to the task of developing the codebase (maybe one
> day), but I can help with systems/operational things if wanted.

Our last infrastructure move suffered heavily from the people tasked
with it not being acquainted and/or comfortable with the
systems/operational things at hand.

It was sort of a painful lesson, but at the current point of time it
would appear that self-hosting an instance rather than having to rely on
a tentatively "free" offering might be too optimistic for a project of
LilyPond's size compared to the available manpower and knowledge.

And Savannah, the GNU infrastructure, does not really have the sysadmin
power to be part of a helpful solution either, even though we can host
the naked Git repository there (and already do so).

> (I don't have a view on the bigger discussion about process - the
> change most likely to help me to contribute would be mentorship rather
> than any process change).

-- 
David Kastrup

Re: development process

[Kieren MacMillan]

Hi all,

> I don't know if lurkers' opinions count

I hope so, because I’m about to give another one…  ;)

> Gerrit is a good code review tool, but for various reasons
> that may be our own fault, it is deeply unpopular where I work.

I know very few of these tools — my deepest version control experience was with 
CVS, and that was nearly 20 years ago — but seeing these discussions, it seems 
to me very unlikely that a truly democratic process will result in a toolchain 
that everyone likes working with (though I’m hopeful that it can at least 
result in a toolchain that everyone *will* work with).

> (I don't have a view on the bigger discussion about process - the change
> most likely to help me to contribute would be mentorship rather than any
> process change).

+1

I have many projects (hopefully leading to patches!) on the go, ready to bring 
to a mentor once the toolchain and process dust settles.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: development process

[Kevin Barry]

I don't know if lurkers' opinions count, but on the subject of potential
replacements for Savannah/Sourceforge: I am part of a team that administer
both Gerrit and Gitlab in-house deployments. If choosing between them I
would advocate for Gitlab because it includes issue tracking and CI/CD so
perhaps all work can go through one place and contributors/maintainers
would not need to have accounts for multiple apps/systems. Gerrit is a good
code review tool, but for various reasons that may be our own fault, it is
deeply unpopular where I work.

I am sadly not quite up to the task of developing the codebase (maybe one
day), but I can help with systems/operational things if wanted.

(I don't have a view on the bigger discussion about process - the change
most likely to help me to contribute would be mentorship rather than any
process change).

Re: development process

[Dan Eble]

On Feb 5, 2020, at 06:57, David Kastrup  wrote:
> 
> Our current process is awkward technically, not because of the roles its
> human players assume.

+1(000)

For a long time, the LilyPond project has needed these:

  1. more and better automation to reduce the load on the (amazingly
 perseverant) patch tester and lower the bar for others to help
  2. better-integrated bug tracking, code review, and source control
  3. a cross-platform build that is more maintainable, faster, and
 more frequently run

And these are the proposals I've been seeing:

  1. reduced opportunity for review; reduced emphasis on consensus
  2. new roles
  3. a code of conduct
  4. a straw man or two (coming from a lack of familiarity with the
 status quo)
  5. better-integrated bug tracking, code review, and source control

There is some common ground here, but it also comes across in part as trying to 
fix what's not broken.  Perhaps if you would first improve the tools and 
testing, people's confidence in them would grow and they would then be more 
willing to reduce the level of scrutiny on patches.
-- 
Dan

Re: development process

[David Kastrup]

Thomas Morley  writes:

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

Re: development process

[Jürgen Reuter]

   Hi all,

   I fully agree with Han-Wen.  I also could now and then (maybe once a
   week) set aside 2-3 hours work for lily.  But the current development
   process really makes it hard for me to keep up submitting a patch (as
   part of currently 11 commits (mostly small to medium ones), partially
   with dependencies, that have been lying around locally on my machine
   for at least ~3-4 years), as I can't just "git push" my 11 commits
   after these 2-3 hours of work, and then, in my next available slot,
   maybe a week or two weeks later, look at code reviews / comments from
   other people, do a "git fetch" / "git rebase", consider the code
   reviewer's comments, and submit an updated version of the 11 commits.
   With Gerrit / Jenkins (which I use at work, currently version 2.14 with
   old GUI), this is really easy possible (without needing a seperate
   branch for each of the commits, which is hardly possible if there are
   dependencies), and use of Gerrit well established process, such I can
   switch to other tasks and return back to these commits even after a
   week or two, without any hassle.

   With the current setup with Retvield / Subversion Bug Tracking / etc.
   however, I do not see how I can handle this complex process, given a
   maximum of 2-3 hours (if at all) per week, if just the process itself
   for keeping up with the status after a week or two of inactivity
   probably will already consume these 2-3 hours, as I fear.

   So, my vote is +1 for a Gerrit based solution, maybe with Jenkins as
   verification build server.

   Greetings,
   Jürgen


   On Tue, Feb 4, 2020 at 10:57 PM Han-Wen Nienhuys 
   wrote:

 As promised in several code reviews, here my take on the current
 development process. I wrote it as a google doc first, so you can
 also go
 here
 [1]https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJy
 fwT9S-rxGRbYSBTv3PM/edit
 for
 inline comments.
 Context:
-
[2]https://codereview.appspot.com/561390043/#msg32
-
[3]https://docs.google.com/document/d/1zYwygWEKJt21rl-bKL41Ipj
 FmiBjlfob6eS63jd-62I/edit#
 My experiences with the current Lilypond development process.
 For context, I have a busy daytime job. I work 80% so I can set
 aside a
 couple of hours of concentrated hacking time on Friday. When I am in
 my
 element, I can easily churn out a dozen commits in a day. Those
 often touch
 the same files, because a fix often needs a preparatory cleanup
 (“dependent
 changes”).
 My annoyances so far are especially with the review/countdown
 process :
-
Rietveld + git-cl doesn’t support dependent changes. So to make
 do, I
explode my series of changes in individual changes to be reviewed
 (I
currently have 34 branches each with a different commit so git-cl
 can match
up branch names and reviews). For dependent changes, I have to
 shepherd the
base change through review, wait for it to be submitted, and then
 rebase
the next change in the series on origin/master.
-
Because the review happens on the split-out patches, I now switch
 back
and forth between 34 different versions of LilyPond. Every time I
 address a
review comment, I go through a lengthy recompile. The large
 number of
changes clogs up my git branch view.
-
The countdown introduces an extra delay of 2 days in this already
cumbersome process.
-
The review process leaves changes in an unclear state. If Werner
 says
LGTM, but then Dan and David have complaints, do I have to
 address the
comments, or is change already OK to go in?
-
We track the status of each review in a different system (the bug
tracker), but the two aren’t linked in an obvious way: I can’t
 navigate
from the review to the tracker, for example. Some things (eg.
 LGTM) are to
be done in the review tool, but some other things should be in
 the
bugtracker.
-
Using the bug tracker to track reviews is new to me. It is common
 for a
bug to need multiple changes to be fixed. It also adds another
 hurdle to
new developers (setting a sourceforge account and getting that
 added to the
project).
-
I have to keep track of my own dashboard: once changes are
 pushed, I
have to look them up in Rietveld to click the ‘close’ button.
-
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).
 Some of my complaints come fr

Re: development process

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Feb 5, 2020 at 12:11 AM David Kastrup  wrote:
>
>> Where commits do not belong to the same logical issue but are still
>> interdependent, they cannot be logically disentangled even using a
>> Git-specific tool like Gerrit.
>>
>
> Oh, but you can. You can review the change as part of the dependent change,
> but then rebase or cherry-pick them if they can be submitted
> separately.

Then they would not be "interdependent".

>>Because the review happens on the split-out patches, I now switch back
>> >and forth between 34 different versions of LilyPond. Every time I
>> address a
>> >review comment, I go through a lengthy recompile.
>>
>> Recompiles tend to be very fast unless you "make clean" in between or
>> check out, in the same work tree, vastly differing branches, like
>> switching between stable and unstable branches.
>>
>
> Guess what you have to do when working on GUILE 2? You edit central headers
> (recompile everything!) and after it works, compile against GUILE 1.8
> (recompile everything!) to make sure it doesnt break the build.

That would be an obvious choice for keeping two work directories.  Yes,
it requires organising your personal workspace.

>> But that's a side track.  As I already stated: my initial experience
>> with contributing involved patches to LilyPond was that they were
>> ignored because nobody considered themselves able or motivated to
>> review them.  Even simple changes took weeks to get accepted.  For
>> better or worse, there just aren't people responsible for large parts
>> of the code that would be able or willing to judge it on its merits
>> in the context of the LilyPond code base.
>>
>
> The process is not designed to address the lack of people. Rather, the
> idea is that contributing to LilyPond is an experience that is easier
> and more rewarding. From there, we might suck in more people because
> contributing is fun and rewarding.

Uh, I just described that when I started working on LilyPond, in a setup
with maintainers that were merely required to ok a change, contributing
to LilyPond was an experience that was anything other than easy and
rewarding.

> It is possible that we go back to a place where we can't accept
> changes to intricate code (markup macros, music functions?) unless
> they drastically simplify things, because no maintainers want to take
> on responsibility for something that is hard to understand. I think
> that is an acceptable tradeoff if we get more developers for the
> project overall.

I think your idea of the project wastes a humongous potential of
contributors that could benefit the LilyPond universe without even
getting involved with core programming.

Take a look at TeX: the core development is essentially dead.  A number
of offspring engines are done by small teams not numbering more than a
dozen active developers each.  There are likely hundreds of plain TeX
packages available, with plain TeX being a similarly thin layer around
the core engine than what LilyPond has.  And then there is LaTeX,
essentially in a version that stabilised in the 90s.  And ten thousands
of extensions for all purposes, layouts, and functionality built around
that.

You don't get to micromanage that amount of contributors.  The best you
can do is to offer a concentrator of completed ready-made effort like
TeXlive does.

If you choose to close off improving on stuff that depends on the
expertise of single persons investing themselves into a single task,
that has repercussions.

>> That was likely inappropriate by me, sorry for that.  I just pointed
>> out that what you considered detrimental would work in your interest
>> here.
>>
>
> I have said this before, and I'll repeat: I find your assumptions about my
> interests offending.

You already explained that you want your patches in faster.

> Please stop making them. I have dedicated 10 years of my life to
> LilyPond. I wrote most of its code, I spent countless hours as a
> maintainer, community leader, and user support person. What do you
> think my interest is?
>
>>Uncontroversial changes can be submitted immediately after a maintainer
>> >has LGTM’d it,
>>
>> Two problems with that: what is uncontroversial?  And who is a
>> maintainer?  You want less opportunity for people to raise objections,
>> but how can you decide about something being uncontroversial when people
>> don't get to review a patch and consider objections?
>>
>
> Maintainer: see below.
>
> Here is a definition: patches are uncontroversial when a maintainer
> says it's OK.
>
> Here is another definition: a patch is uncontroversial when it
> improves something and doesn't create long-term liability.
>
> Here is a practical example: when you look at, say
> https://codereview.appspot.com/577410045/, there is considerable
> discussion about a detail of using references vs. pointers, but the
> overall cleanup (adding comments, renaming variables) is a pretty
> straightforward improvement.

The 

Re: development process

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Feb 5, 2020 at 10:23 AM Jonas Hahnfeld  wrote:
>
>> I don't see why we need to have a final list of detailed points that we
>> all agree upon before sketching a process.
>
>
> I think it's a more systematic way of approaching the problem. The reason
> I'm doing it this way, is because I have a vested interest. My daytime job
> is managing the  Gerrit codereview team at Google, so I am more intimately
> familiar with Gerrit, have slight preference for its review experience, and
> a vested interest in seeing it in broader use.

Let me just use this to point out that our current environment has been
the result of getting stuck in the lurch when Google decided to
discontinue providing Google Code.  So going from that experience, it
would make sense to favor tools where we have useful contingency plans
for falling out of support.

-- 
David Kastrup

Re: development process

[Thomas Morley]

Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup :
>
> Han-Wen Nienhuys  writes:

> >The review process leaves changes in an unclear state. If Werner says
> >LGTM, but then Dan and David have complaints, do I have to address the
> >comments, or is change already OK to go in?

It's not a rare case, that someone gives a LGTM, overlooking serious weaknesses.
While someone else catches them.
Thus I think _all_ complaints should be addressed before pushing.

> The change is ok to go in when it has been approved for pushing.  I find
> the idea of ignoring instead of addressing complaints weird.

In general (without quoting other parts of previous mails) we should
decide: when is a patch mature for push?
(1) Currently a patch _without_ review-comments will end up in master
after the review-circle is finished.
This has the advantage that proposed code does not get lost.
Thus I like to keep it, although it comes with the risk that bugs are
introduced unnoticed.
As an example see:
buggy:
https://codereview.appspot.com/346030043/
fixed:
https://codereview.appspot.com/567060043

(2) As already said, if comments are present, all should be adressed.
Or a separate issue should be created. As an example:
- patch for new-feature xy is pushed
- documentation for it is delayed in issue 

>
> >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.
Or I have an incomplete setup myself.

> >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.
Per aspera ad astra...

> >The review tool supports painless reverts. When it is easy to fix up
> >mistakes, contributors will feel less afraid to make changes.

Currently I can't imagine how this should work.

P.e. I once pushed a patch with a serious problem (not caught at review).
A  translator relied on it.
A fix for the initial problem and the translation-push resulted in
broken staging.

What would your suggestion to avoid such situations?



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.
Some other complaints you wrote could be summarized as not being
familar with those tools (e.g. Rietveld's edit).
I made similar expierences with GitHub, though:
I took me hours to figure out how to use oll-repo, it's all explained
in the wiki. I didn't find that wiki for a long time... g
Or how to switch on GitHub between "unified diff" and "side-by-side
diff with in-line comments", took me felt ages ... grrr
To summarize: I'm really not familar with GitHub :)

Not being familar with a certain tool will vanish after some time ofcourse.
I still object to switch to GitHub, as said in Salzburg: GitHub is
nowadays owned by Microsoft.
But I would be open for other tools, if others agree (I can't comment
on GitLab or Gerrit, though, I simply have no experience with them).


My 2 cents,
  Harm

Re: development process

[David Kastrup]

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

Re: development process

[Han-Wen Nienhuys]

On Wed, Feb 5, 2020 at 10:23 AM Jonas Hahnfeld  wrote:

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


I think it's a more systematic way of approaching the problem. The reason
I'm doing it this way, is because I have a vested interest. My daytime job
is managing the  Gerrit codereview team at Google, so I am more intimately
familiar with Gerrit, have slight preference for its review experience, and
a vested interest in seeing it in broader use.

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

Yes, definitely!

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


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: development process

[Han-Wen Nienhuys]

On Wed, Feb 5, 2020 at 12:11 AM David Kastrup  wrote:

> Where commits do not belong to the same logical issue but are still
> interdependent, they cannot be logically disentangled even using a
> Git-specific tool like Gerrit.
>

Oh, but you can. You can review the change as part of the dependent change,
but then rebase or cherry-pick them if they can be submitted separately.

>Because the review happens on the split-out patches, I now switch back
> >and forth between 34 different versions of LilyPond. Every time I
> address a
> >review comment, I go through a lengthy recompile.
>
> Recompiles tend to be very fast unless you "make clean" in between or
> check out, in the same work tree, vastly differing branches, like
> switching between stable and unstable branches.
>

Guess what you have to do when working on GUILE 2? You edit central headers
(recompile everything!) and after it works, compile against GUILE 1.8
(recompile everything!) to make sure it doesnt break the build.

>The large number of changes clogs up my git branch view.  -
> >
> >The countdown introduces an extra delay of 2 days in this already
> >cumbersome process.
> >-
> >
> >The review process leaves changes in an unclear state. If Werner says
> >LGTM, but then Dan and David have complaints, do I have to address the
> >comments, or is change already OK to go in?
>
> The change is ok to go in when it has been approved for pushing.  I find
> the idea of ignoring instead of addressing complaints weird.
>



>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.
>
> git cl upload
>
> will copy the current change set to Rietveld.  I am impressed at the
> rate of change you manage to churn out without relying on the commands
> we use for that purpose, but this certainly can be done less painfully.
>
>
> > Some of my complaints come from having to manage a plethora of changes,
> but
> > I suspect the process will trip new contributors up too, to note:
> >
> >
> >-
> >
> >Seeing your code submitted to a project is what makes coders tick. It
> is
> >the Dopamine hit Facebook exploits so well, and so should we. The key
> to
> >exploiting it is instant gratification, so we should get rid of
> artificial
> >delays
> >-
> >
> >We use “we’ll push if there are no complaints” for contributions. I
> >think this is harmful to contributors, because it doesn’t give
> contributors
> >a clear feedback mechanism if they should continue down a path.
>
> They get feedback when the code is getting reviewed.  If code does not
> get reviewed, having their changes dropped on the floor is not going to
> increase their enthusiasm.
>
> And just above you wanted to know when you are free to ignore feedback.
>


>
> > David uses a patch
> >  he made to GUILE
> > as an example that code can be stuck in a limbo. I disagree with this
> > assessment. To me it shows the GUILE community considering and then
> > rejecting a patch (comment #26 and #40).
>
> Nope.  It is an Andy-only domain, and Andy does not respond.  That's all
> there is to it.  You don't see any "wontfix" tag or other form of
> rejection.  The issue remains open.
>
> > I imagine that David was not happy about this particular decision, but
> > I see a process working as expected.
>
> There was no decision.  There were some comments which I addressed and
> put into context.
>

To me, a phrase like "I don't have time now to continue arguing with you
about this issue. Sorry." means "No"


> > If anything, it took too long and was not explicit enough in rejecting
> > the patch. Also, in cases like these, one would normally build
> > consensus about the plan before going off and writing a patch.
>
> Uh, I am banished from the Guile developer list.  There is no way to
> build consensus.  And I was merely implementing what Andy Wingo stated
> in a comment should be implemented, in the manner he stated it should be
> done.
>
> But that's a side track.  As I already stated: my initial experience
> with contributing involved patches to LilyPond was that they were
> ignored because nobody considered themselves able or motivated to review
> them.  Even simple changes took weeks to get accepted.  For better or
> worse, there just aren't people responsible for large parts of the code
> that would be able or willing to judge it on its merits in the context
> of the LilyPond code base.
>

The process is not designed to address the lack of people. Rather, the idea
is that contributing to LilyPond is an experience that is easier and more
rewarding. From there, we might suck in more people because contributing is
fun and 

Re: development process

[Jonas Hahnfeld via Discussions on LilyPond development]

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

Re: development process

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

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

On Wed, Feb 5, 2020 at 9:31 AM Jonas Hahnfeld  wrote:

> Am Mittwoch, den 05.02.2020, 00:11 +0100 schrieb David Kastrup:
> > Han-Wen Nienhuys <
> > hanw...@gmail.com
> > > writes:
> >
> > > My experiences with the current Lilypond development process.
> > >
> > > For context, I have a busy daytime job. I work 80% so I can set aside
> > > a couple of hours of concentrated hacking time on Friday. When I am in
> > > my element, I can easily churn out a dozen commits in a day. Those
> > > often touch the same files, because a fix often needs a preparatory
> > > cleanup (“dependent changes”).
> > >
> > > My annoyances so far are especially with the review/countdown process :
> > >
> > >
> > >-
> > >
> > >Rietveld + git-cl doesn’t support dependent changes. So to make do,
> I
> > >explode my series of changes in individual changes to be reviewed (I
> > >currently have 34 branches each with a different commit so git-cl
> can match
> > >up branch names and reviews). For dependent changes, I have to
> shepherd the
> > >base change through review, wait for it to be submitted, and then
> rebase
> > >the next change in the series on origin/master.
> >
> > Changes belonging to the same topic should be committed to the same
> > Rietveld review and Sourceforge issue.  One can commit them in sequence
> > to Rietveld when it is desirable to view them independently.  This does
> > not allow to view fixes resulting from discussion in the context of the
> > ultimately resulting commit chain (which will usually be fixed
> > per-commit with git rebase -i).
> >
> > For a sequence of commits belonging to one logical change, this is the
> > somewhat defective way of doing stuff.  It's not as bad as you happened
> > to use it, but it definitely is a tool that grew on Subversion and added
> > Git as an afterthought.
> >
> > Where commits do not belong to the same logical issue but are still
> > interdependent, they cannot be logically disentangled even using a
> > Git-specific tool like Gerrit.
> >
> > >Because the review happens on the split-out patches, I now switch
> back
> > >and forth between 34 different versions of LilyPond. Every time I
> address a
> > >review comment, I go through a lengthy recompile.
> >
> > Recompiles tend to be very fast unless you "make clean" in between or
> > check out, in the same work tree, vastly differing branches, like
> > switching between stable and unstable branches.
> >
> > Or bisecting across a version change.  It's annoying how much just
> > depends on the VERSION file, but not actually something that the review
> > tool will help with.
> >
> > >The large number of changes clogs up my git branch view.  -
> > >
> > >The countdown introduces an extra delay of 2 days in this already
> > >cumbersome process.
> > >-
> > >
> > >The review process leaves changes in an unclear state. If Werner
> says
> > >LGTM, but then Dan and David have complaints, do I have to address
> the
> > >comments, or is change already OK to go in?
> >
> >

Re: development process

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 05.02.2020, 00:11 +0100 schrieb David Kastrup:
> Han-Wen Nienhuys <
> hanw...@gmail.com
> > writes:
> 
> > My experiences with the current Lilypond development process.
> > 
> > For context, I have a busy daytime job. I work 80% so I can set aside
> > a couple of hours of concentrated hacking time on Friday. When I am in
> > my element, I can easily churn out a dozen commits in a day. Those
> > often touch the same files, because a fix often needs a preparatory
> > cleanup (“dependent changes”).
> > 
> > My annoyances so far are especially with the review/countdown process :
> > 
> > 
> >-
> > 
> >Rietveld + git-cl doesn’t support dependent changes. So to make do, I
> >explode my series of changes in individual changes to be reviewed (I
> >currently have 34 branches each with a different commit so git-cl can 
> > match
> >up branch names and reviews). For dependent changes, I have to shepherd 
> > the
> >base change through review, wait for it to be submitted, and then rebase
> >the next change in the series on origin/master.
> 
> Changes belonging to the same topic should be committed to the same
> Rietveld review and Sourceforge issue.  One can commit them in sequence
> to Rietveld when it is desirable to view them independently.  This does
> not allow to view fixes resulting from discussion in the context of the
> ultimately resulting commit chain (which will usually be fixed
> per-commit with git rebase -i).
> 
> For a sequence of commits belonging to one logical change, this is the
> somewhat defective way of doing stuff.  It's not as bad as you happened
> to use it, but it definitely is a tool that grew on Subversion and added
> Git as an afterthought.
> 
> Where commits do not belong to the same logical issue but are still
> interdependent, they cannot be logically disentangled even using a
> Git-specific tool like Gerrit.
> 
> >Because the review happens on the split-out patches, I now switch back
> >and forth between 34 different versions of LilyPond. Every time I 
> > address a
> >review comment, I go through a lengthy recompile.
> 
> Recompiles tend to be very fast unless you "make clean" in between or
> check out, in the same work tree, vastly differing branches, like
> switching between stable and unstable branches.
> 
> Or bisecting across a version change.  It's annoying how much just
> depends on the VERSION file, but not actually something that the review
> tool will help with.
> 
> >The large number of changes clogs up my git branch view.  -
> > 
> >The countdown introduces an extra delay of 2 days in this already
> >cumbersome process.
> >-
> > 
> >The review process leaves changes in an unclear state. If Werner says
> >LGTM, but then Dan and David have complaints, do I have to address the
> >comments, or is change already OK to go in?
> 
> The change is ok to go in when it has been approved for pushing.  I find
> the idea of ignoring instead of addressing complaints weird.
> 
> >We track the status of each review in a different system (the bug
> >tracker), but the two aren’t linked in an obvious way: I can’t navigate
> >from the review to the tracker, for example. Some things (eg. LGTM) are 
> > to
> >be done in the review tool, but some other things should be in the
> >bugtracker.
> 
> We don't need to rehash that the current system sucks.  We had to amend
> our process after relying on a proprietary tool, namely Google Code,
> ended up hanging us out to dry and we had to replace the parts removed.
> Our available knowledge and volunteer power ended up with the current
> setup which was not intended as a keeper.  It kept the project working,
> but I doubt many people will be sad to see it replaced.
> 
> >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.
> 
> git cl upload
> 
> will copy the current change set to Rietveld.  I am impressed at the
> rate of change you manage to churn out without relying on the commands
> we use for that purpose, but this certainly can be done less painfully.
> 
> 
> > Some of my complaints come from having to manage a plethora of changes, but
> > I suspect the process will trip new contributors up too, to note:
> &g

Re: development process

[David Kastrup]

Han-Wen Nienhuys  writes:

> My experiences with the current Lilypond development process.
>
> For context, I have a busy daytime job. I work 80% so I can set aside
> a couple of hours of concentrated hacking time on Friday. When I am in
> my element, I can easily churn out a dozen commits in a day. Those
> often touch the same files, because a fix often needs a preparatory
> cleanup (“dependent changes”).
>
> My annoyances so far are especially with the review/countdown process :
>
>
>-
>
>Rietveld + git-cl doesn’t support dependent changes. So to make do, I
>explode my series of changes in individual changes to be reviewed (I
>currently have 34 branches each with a different commit so git-cl can match
>up branch names and reviews). For dependent changes, I have to shepherd the
>base change through review, wait for it to be submitted, and then rebase
>the next change in the series on origin/master.

Changes belonging to the same topic should be committed to the same
Rietveld review and Sourceforge issue.  One can commit them in sequence
to Rietveld when it is desirable to view them independently.  This does
not allow to view fixes resulting from discussion in the context of the
ultimately resulting commit chain (which will usually be fixed
per-commit with git rebase -i).

For a sequence of commits belonging to one logical change, this is the
somewhat defective way of doing stuff.  It's not as bad as you happened
to use it, but it definitely is a tool that grew on Subversion and added
Git as an afterthought.

Where commits do not belong to the same logical issue but are still
interdependent, they cannot be logically disentangled even using a
Git-specific tool like Gerrit.

>Because the review happens on the split-out patches, I now switch back
>and forth between 34 different versions of LilyPond. Every time I address a
>review comment, I go through a lengthy recompile.

Recompiles tend to be very fast unless you "make clean" in between or
check out, in the same work tree, vastly differing branches, like
switching between stable and unstable branches.

Or bisecting across a version change.  It's annoying how much just
depends on the VERSION file, but not actually something that the review
tool will help with.

>The large number of changes clogs up my git branch view.  -
>
>The countdown introduces an extra delay of 2 days in this already
>cumbersome process.
>-
>
>The review process leaves changes in an unclear state. If Werner says
>LGTM, but then Dan and David have complaints, do I have to address the
>comments, or is change already OK to go in?

The change is ok to go in when it has been approved for pushing.  I find
the idea of ignoring instead of addressing complaints weird.

>We track the status of each review in a different system (the bug
>tracker), but the two aren’t linked in an obvious way: I can’t navigate
>from the review to the tracker, for example. Some things (eg. LGTM) are to
>be done in the review tool, but some other things should be in the
>bugtracker.

We don't need to rehash that the current system sucks.  We had to amend
our process after relying on a proprietary tool, namely Google Code,
ended up hanging us out to dry and we had to replace the parts removed.
Our available knowledge and volunteer power ended up with the current
setup which was not intended as a keeper.  It kept the project working,
but I doubt many people will be sad to see it replaced.

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

git cl upload

will copy the current change set to Rietveld.  I am impressed at the
rate of change you manage to churn out without relying on the commands
we use for that purpose, but this certainly can be done less painfully.


> Some of my complaints come from having to manage a plethora of changes, but
> I suspect the process will trip new contributors up too, to note:
>
>
>-
>
>Seeing your code submitted to a project is what makes coders tick. It is
>the Dopamine hit Facebook exploits so well, and so should we. The key to
>exploiting it is instant gratification, so we should get rid of artificial
>delays
>-
>
>We use “we’ll push if there are no complaints” for contributions. I
>think this is harmful to contributors, because it doesn’t give contributors
>a clear feedback mechanism if they should continue down a path.

They get feedback when the code is getting reviewed.  If code does not
get reviewed, having their chan

Re: development process

[Janek Warchoł]

I've just went through the patch upload process (for proposed Code of
Conduct https://codereview.appspot.com/575620043/) and I agree that it
should be changed. It was obscure and confusing even for me.

cheers,
Janek

wt., 4 lut 2020 o 22:57 Han-Wen Nienhuys  napisał(a):

> As promised in several code reviews, here my take on the current
> development process. I wrote it as a google doc first, so you can also go
> here
>
> https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJyfwT9S-rxGRbYSBTv3PM/edit
> for
> inline comments.
>
>
> Context:
>
>-
>
>https://codereview.appspot.com/561390043/#msg32
>-
>
>
>
> https://docs.google.com/document/d/1zYwygWEKJt21rl-bKL41IpjFmiBjlfob6eS63jd-62I/edit#
>
>
> My experiences with the current Lilypond development process.
>
> For context, I have a busy daytime job. I work 80% so I can set aside a
> couple of hours of concentrated hacking time on Friday. When I am in my
> element, I can easily churn out a dozen commits in a day. Those often touch
> the same files, because a fix often needs a preparatory cleanup (“dependent
> changes”).
>
> My annoyances so far are especially with the review/countdown process :
>
>
>-
>
>Rietveld + git-cl doesn’t support dependent changes. So to make do, I
>explode my series of changes in individual changes to be reviewed (I
>currently have 34 branches each with a different commit so git-cl can
> match
>up branch names and reviews). For dependent changes, I have to shepherd
> the
>base change through review, wait for it to be submitted, and then rebase
>the next change in the series on origin/master.
>-
>
>Because the review happens on the split-out patches, I now switch back
>and forth between 34 different versions of LilyPond. Every time I
> address a
>review comment, I go through a lengthy recompile. The large number of
>changes clogs up my git branch view.
>-
>
>The countdown introduces an extra delay of 2 days in this already
>cumbersome process.
>-
>
>The review process leaves changes in an unclear state. If Werner says
>LGTM, but then Dan and David have complaints, do I have to address the
>comments, or is change already OK to go in?
>-
>
>We track the status of each review in a different system (the bug
>tracker), but the two aren’t linked in an obvious way: I can’t navigate
>from the review to the tracker, for example. Some things (eg. LGTM) are
> to
>be done in the review tool, but some other things should be in the
>bugtracker.
>-
>
>Using the bug tracker to track reviews is new to me. It is common for a
>bug to need multiple changes to be fixed. It also adds another hurdle to
>new developers (setting a sourceforge account and getting that added to
> the
>project).
>-
>
>I have to keep track of my own dashboard: once changes are pushed, I
>have to look them up in Rietveld to click the ‘close’ button.
>-
>
>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).
>
>
> Some of my complaints come from having to manage a plethora of changes, but
> I suspect the process will trip new contributors up too, to note:
>
>
>-
>
>Seeing your code submitted to a project is what makes coders tick. It is
>the Dopamine hit Facebook exploits so well, and so should we. The key to
>exploiting it is instant gratification, so we should get rid of
> artificial
>delays
>-
>
>We use “we’ll push if there are no complaints” for contributions. I
>think this is harmful to contributors, because it doesn’t give
> contributors
>a clear feedback mechanism if they should continue down a path. It is
>harmful to the project, because we can end up adopting code that we
> don’t
>understand.
>-
>
>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.
>
>
> David uses a patch <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474>
> he
> made to GUILE as an example that code can be stuck in a limbo. I disagree
> with this assessment. To me it

development process

[Han-Wen Nienhuys]

As promised in several code reviews, here my take on the current
development process. I wrote it as a google doc first, so you can also go
here
https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJyfwT9S-rxGRbYSBTv3PM/edit
for
inline comments.


Context:

   -

   https://codereview.appspot.com/561390043/#msg32
   -


   
https://docs.google.com/document/d/1zYwygWEKJt21rl-bKL41IpjFmiBjlfob6eS63jd-62I/edit#


My experiences with the current Lilypond development process.

For context, I have a busy daytime job. I work 80% so I can set aside a
couple of hours of concentrated hacking time on Friday. When I am in my
element, I can easily churn out a dozen commits in a day. Those often touch
the same files, because a fix often needs a preparatory cleanup (“dependent
changes”).

My annoyances so far are especially with the review/countdown process :


   -

   Rietveld + git-cl doesn’t support dependent changes. So to make do, I
   explode my series of changes in individual changes to be reviewed (I
   currently have 34 branches each with a different commit so git-cl can match
   up branch names and reviews). For dependent changes, I have to shepherd the
   base change through review, wait for it to be submitted, and then rebase
   the next change in the series on origin/master.
   -

   Because the review happens on the split-out patches, I now switch back
   and forth between 34 different versions of LilyPond. Every time I address a
   review comment, I go through a lengthy recompile. The large number of
   changes clogs up my git branch view.
   -

   The countdown introduces an extra delay of 2 days in this already
   cumbersome process.
   -

   The review process leaves changes in an unclear state. If Werner says
   LGTM, but then Dan and David have complaints, do I have to address the
   comments, or is change already OK to go in?
   -

   We track the status of each review in a different system (the bug
   tracker), but the two aren’t linked in an obvious way: I can’t navigate
   from the review to the tracker, for example. Some things (eg. LGTM) are to
   be done in the review tool, but some other things should be in the
   bugtracker.
   -

   Using the bug tracker to track reviews is new to me. It is common for a
   bug to need multiple changes to be fixed. It also adds another hurdle to
   new developers (setting a sourceforge account and getting that added to the
   project).
   -

   I have to keep track of my own dashboard: once changes are pushed, I
   have to look them up in Rietveld to click the ‘close’ button.
   -

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


Some of my complaints come from having to manage a plethora of changes, but
I suspect the process will trip new contributors up too, to note:


   -

   Seeing your code submitted to a project is what makes coders tick. It is
   the Dopamine hit Facebook exploits so well, and so should we. The key to
   exploiting it is instant gratification, so we should get rid of artificial
   delays
   -

   We use “we’ll push if there are no complaints” for contributions. I
   think this is harmful to contributors, because it doesn’t give contributors
   a clear feedback mechanism if they should continue down a path. It is
   harmful to the project, because we can end up adopting code that we don’t
   understand.
   -

   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.


David uses a patch <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17474> he
made to GUILE as an example that code can be stuck in a limbo. I disagree
with this assessment. To me it shows the GUILE community considering and
then rejecting a patch (comment #26 and #40). I imagine that David was not
happy about this particular decision, but I see a process working as
expected. If anything, it took too long and was not explicit enough in
rejecting the patch. Also, in cases like these, one would normally build
consensus about the plan before going off and writing a patch.

David suggests that I like getting patches in by fiat/countdown, but I
disagree. If you look at the past 2 weeks, you can see that I have actually
tried to address all code review comments so far, and again, it is more
important for the project to have explicit consensus than that individual
contributors that go off in possibly conflicting directions.

Here is what a development process should look to me


   -

   Uncontroversial changes can be sub