Re: Definite article in synopsis

[Ludovic Courtès]

Hello!

Leo Famulari <address@hidden> skribis:

> On Fri, Sep 23, 2016 at 10:32:56AM +1000, Ben Woodcroft wrote:
>> On 09/23/2016 10:15 AM, Leo Famulari wrote:
>> > On Wed, Sep 21, 2016 at 12:59:51PM +0200, John Darrington wrote:
>> > > I thought we had a policy that the synopsis field must not
>> > > start with an article.
>> > > 
>> > > However running
>> > >  grep 'synopsis  *"The'  *.scm
>> > > 
>> > > shows that we have many instances where this policy is
>> > > not followed.
>> > > 
>> > > Or have I   misunderstood something?
>> > It's a minor issue. I think that making many small changes throughout
>> > the master branch will be too disruptive for what is a relatively minor
>> > style issue.
>> This is true even though changing a description doesn't trigger a rebuild?
>
> I figured that there were hundreds of instances, but checking for "A"
> and "An" (what `guix lint` checks for), it's only 8 packages. So I don't
> think this change will be disruptive.
>
> My comment about the change being "disruptive" was not about rebuilding
> but rather code "churn". And non-functional code churn does seem worth
> the human time required to merge hundreds of conflicts.

I think it’s OK to have occasional “churn” like this, but I agree that
we must make sure to always make such changes on the same branch to
avoid merge conflicts; ‘master’ is OK, both ‘master’ and ‘core-updates’
is not OK.

> Is there a reason to remove "The"? I think it would not always be an
> improvement, for example in a case like this:
>
> (synopsis "The Erlang programming language")

I think the rationale was that it’s often an indication that the
synopsis starts a sentence, but I agree that in some cases this rule
doesn’t work.

>> > If the change is made, I'd prefer it on core-updates. Merging master
>> > into core-updates and vice versa already requires somebody to resolve a
>> > lot of merge conflicts. I'd rather not add to that burden.
>> Do you have any recommendations for changing our practices to ease this
>> issue?
>
> One idea is to do big widespread non-functional changes between
> core-updates branches. That is, immediately after a release is tagged,
> before a new core-updates branch is required.

I would tend to think of ‘master’ as the branch for non-functional
changes like this.  But the key is to make sure such wide changes are
kept in a single branch to avoid merge issues as you wrote.

WDYT?

Thanks,
Ludo’.