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