emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bastien <bzg@gnu.org>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Dan Drake <dan.drake@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Date: Sat, 01 Feb 2020 14:10:28 +0100	[thread overview]
Message-ID: <87sgjuh2rf.fsf@gnu.org> (raw)
In-Reply-To: <87y2tmd2ug.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Sat, 01 Feb 2020 11:22:15 +0100")

Hi Nicolas,

I think it is worth spending a little time discussing this to ensure
that everyone is aligned on the same understanding, otherwise we may
have to spend more time later, discussing it over and over for other
cases.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> So, I stand on my ground: there is a "non-trivial" part to take into
> consideration when counting locs.

Yes, you are right.

My point is that distinguishing trivial vs. non-trivial parts of a
change may be subject to interpretation.  When in doubt, I recommend
staying on the safe side of not accepting a change that is more than
15 lines of "maybe-significant" changes.

In general, the more FSF-signed contributors there are, the less time
maintainers spend on deciding whether changes are significant or not.

Also, signed contributors are more likely to contribute again, so I
recommend inciting contributors to sign.  I am glad we already have
more than 200 signed contributors, that's a great achievement :)

> I would go even further: when you transform a string regexp into a rx
> regexp, there is no line to count, because there is no new idea to
> copyright in the first place. This is a trivial change.

Yes, in this case there is no new idea, but this is irrelevant to the
discussion, since ideas cannot be copyrighted anyway.

Copyright is about the expression of ideas, and code is also all about
this, hence the difficulty, sometimes, to interpret "significant".

> Anyway, I think arguing here is just wasting our time.

Well, I hope I clarified my point, which is to stay on safe side of
asking contributors to sign the FSF papers when the importance of the
change can be subject to intepretation.

Thanks,

-- 
 Bastien

  reply	other threads:[~2020-02-01 13:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-19 20:13 [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock Dan Drake
2020-01-24 23:30 ` Nicolas Goaziou
2020-01-29  2:11   ` Dan Drake
2020-01-29  9:49     ` Nicolas Goaziou
2020-01-29 12:47   ` Bastien
2020-02-01 10:22     ` Nicolas Goaziou
2020-02-01 13:10       ` Bastien [this message]
2020-02-01 14:15         ` Nicolas Goaziou
2020-02-01 14:34           ` Bastien
2020-02-01 16:48             ` Nicolas Goaziou
2020-02-02 13:41               ` Dan Drake
2020-02-02 13:51                 ` Bastien
2020-02-03 14:41             ` Robert Pluim
2020-02-03 14:53               ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgjuh2rf.fsf@gnu.org \
    --to=bzg@gnu.org \
    --cc=dan.drake@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@nicolasgoaziou.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).