lilypond-devel
[Top][All Lists]
Advanced

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

Re: Cyrillic texinfo support


From: David Kastrup
Subject: Re: Cyrillic texinfo support
Date: Mon, 13 Aug 2012 21:16:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Graham Percival <address@hidden> writes:

> On Mon, Aug 13, 2012 at 08:16:48PM +0200, David Kastrup wrote:
>> Werner LEMBERG <address@hidden> writes:
>> > Hmm, `wild changes' is a mild exaggeration, isn't it?  It makes
>> > 50 Cyrillic characters appear in the PDFs which were simply missing
>> > previously.  It's a one-line change in `macros.itexi'
>> > and a new file.  And of course I've run `make doc' on a freshly cloned
>> > git repository and checked the output whether everything is fine.
> ...
>> And even when the wild code bonanza has started, we will have review
>> processes, and I, like every other developer, have the right to mention
>> my concerns in reviews when changes with large impact are made.
>
> Yes.  Pushing directly to staging is basically a gamble:
> IF YOU WIN: you avoid the delay and hassle of git-cl, reviews, a
> patch countdown, etc.
> IF YOU LOSE: somebody doesn't like something in your patch and is
> annoyed that they didn't have a chance to comment.

I don't see it as a gamble.  Pushing to staging means "I consider this
change to be safe and can't imagine anybody suggesting anything to
change".  Not "I hope nobody will notice", but "I don't expect anybody
to be concerned".

With a _gamble_, you have open expectations.  And if that is the case,
you should use the review process.  Pushing to staging is where you are
_certain_ that no review is called for, needed and wanted.  Typo fixes
where you are reasonably sure of your grammar.  Comment fixes where the
comment does not agree with the code.  Bug fixes that have an obvious
solution.  And so on.

> Honestly, if I were in Werner's position, I probably would have
> done the same.

I wouldn't.  For changes with potentially large impact, I use a review
even when I am of the opinion that I am by far the best-suited
programmer for dealing with a particular problem.

> -- I would have taken the risk that everybody was ok
> with the change, and pushed it directly to staging.  But as soon
> as somebody complained (regardless of who it was, regardless of
> the reason), I would revert the commit, and send the patch for
> review+countdown.

I don't think it makes sense to push every change tentatively to staging
and see whether one can get through with that.

> it's a gamble, and it didn't pay off in this case.

I would prefer it if people don't gamble the development processes.  It
is disrespectful to other developers to consider them irrelevant.  So I
would very much like to see "push to staging" restricted to those cases
where there is a reasonable expectation that everybody would fully agree
with form, content, and intent of a change.

> In the future, we'll all remember that changes to texinfo.tex can be
> problematic, so we'll be slightly less likely to take the gamble with
> that file.

It was not a change to texinfo.tex, but macros.itexi is technically used
even more (if you also count the invocations in non-TeX modes).  And it
is not a fuzzy "can be problematic" here.  It is a change with large
effects which is part of the reason Werner considers it desirable.

-- 
David Kastrup



reply via email to

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