unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Jambunathan K <kjambunathan@gmail.com>
Cc: dmoncayo@gmail.com, emacs-devel@gnu.org
Subject: RE: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]
Date: Sat, 30 Nov 2013 10:41:30 -0800 (PST)	[thread overview]
Message-ID: <f68d749a-877f-4cd0-84d0-826a2391f8a6@default> (raw)
In-Reply-To: <<83zjom5ls5.fsf@gnu.org>>

> > >> 1. A user that provides feedback/bug reports is valuable, even if he
> > >>    doesn't submit patches.
> > >> 2. A user that also submit patches is even more valuable, even if he
> > >>    doesn't commit them.
> > >> 3. A user that also commit his patches is even (a little) more
> > >>    valuable.
> > >> Currently I'm at level 2.  It's better than nothing, isn't it?
> > >
> > > +1, for drawing attention to the worth of #1 and #2.
> >
> > I am in agreement with what Drew writes.  To add to that...
> > Submit a patch move on.  Adding a note, that someone else commit
> > it is just ....  Surely, no one is under any obligation to commit
> > or accept the patch.
> >
> > Similarly, insisting that people use Bzr or Commit their Patch can
> > be an exhortation, a minor form of persuasion - not quite unlike
> > the "commit my patch".  The other party is under no obligation.
> 
> You are both off-track: this has nothing to do with _contributions_.
> 
> Glenn's frustration (which I share) is that here's an Emacs
> _developer_ who has write access to the repository, and is quite
> capable of doing the 5-sec commit job, but refuses to do so on some
> ^%$#@! principle and lame excuses.

What "^%$#@! principle"?  There is nothing in the thread about a
refusal, and in particular nothing about a refusal based on any ^%$#@!
principle.

What "lame excuses"?  Where in his contract to you does it say that
Dani needs to provide you with a good excuse?  Bravo for that.

He doesn't need to give you, or anyone else, any "excuses".  He has
done nothing wrong, AFAICT.  He has only done something positive:
contribute a patch, which he thinks could improve Emacs.

Whether he is right or wrong about the patch helping is irrelevant.
Whether he commits the patch or not, and whether *anyone* commits the
patch or not, is irrelevant.  He gave Emacs a donation.  You can refuse
it, for whatever reason, including that you think it is more trouble
than it is worth.  He still should be thanked for giving.  (Especially
as it was on Thanksgiving ;-).)

And your pseudo moralistic rant against him for not committing is,
well, off the wall, I'm afraid.  Just because you feel that Dani is
"an Emacs _developer_" (whatever that means), that does not give you
any right to castigate Dani for not committing a patch he contributes.

And yes, it is very much about _contribution_.

> IOW, he is publicly demonstrating his attitude to the project, asking
> others (whose plate is much more full than his, and whose time is more
> sparse than his) to act as his dutiful servants.

Who are you to judge how much someone should contribute?  Dani decides
how Dani contributes.  You are welcome to accept or refuse his
contribution.

Dani's asking someone to commit the patch is normal.  Would you prefer
that he word it like this, for your Highness: "Here is a patch.
Please take a look, and if it please you, please consider committing
it."  (Actually, that's not far from what he actually did say!)

I do *not* see Dani demanding that someone "whose plate is much more
full than his, and whose time is more sparse than his" "act as his
dutiful servant".  That you see it that way is sad, indeed, Eli.

> If this is not unfairness in its extreme, then I don't know what is.
> Dani should do some soul-searching.

You should not be telling Dani what he should be doing.  (Irony
intended.)  And the answer is that you apparently do *not* know what
unfairness in its extreme is.  There is nothing unfair about
submitting a patch without committing it - whether or not you think
of the submitter as "an Emacs _developer_".

What would be unfair would be to expect a particular person whose
plate is full to jump up and commit his patch.  It is not unfair to
ask that *someone* commit the patch.  It is a *request*; nothing
more.  And that is quite clear from what Dani wrote.

What is unfair is to hold Dani to some standard that you feel you
can impose, whereby simply because he has commit access he must
commit a code change.  If he chooses to do that, fine.  You can
certainly request that, just as he can request that someone review
his patch and commit it.

You are not Dani's boss, any more than he is yours.  He is not your
"dutiful servant", just because you have might have knighted him in
your eyes as "an Emacs _developer_".

> That each one of you backed him up is really because you talk
> about Dani, but think about your own, quite different, cases.

Hard to believe that you are now pointing the finger at people who
"backed him up".  Taking names and addresses, are you?  Where will
the Inquisition end?

I'm backing up anyone who contributes and is attacked for not doing
more.  My own case as a contributor is irrelevant.

But yes, I too have commit privileges (or at least I used to;
dunno if I still do).  And I too do not commit code to BZR.  I am
nevertheless reasonably committed to Emacs and its improvement.

As is Dani.  As are many others who contribute less than you do.
Are you going to get on their cases too, going on about how full
your plate is relative to theirs?

Back off, please.  We do not need a holier-than-thou Grand
Inquisitor.

If a consistent contributor has to ask: "It's better than nothing,
isn't it?", and explains "I just asked someone to commit my patch.
(I don't think I'm asking too much)" - then we have lost our way.

And that, in response to an aggressive "Look, you've got commit
rights, you've chosen to use git...".  Look, yourself, tough guy.

And that aggression was a response to this polite request from Dani:

  "Anyway, the below patch works for me.  It is ok?  If so, please
   commit it.  TIA."

(Please, do consult the (short) thread and make up your own mind:
http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg01084.html)

Yes, Dani, your contribution is much, much better than nothing.

And if someone bitches about being overworked by comparison to you,
just ignore them - that they feel a need for such comparison is not
your fault or your problem.



       reply	other threads:[~2013-11-30 18:41 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<83txew8m9v.fsf@gnu.org>
     [not found] ` <<CAH8Pv0hxmFCoEgd6Wag93LAuNy0JPPJ6UNjt3xcWjNdKAB=K5A@mail.gmail.com>
     [not found]   ` <<837gbr8uxa.fsf@gnu.org>
     [not found]     ` <<CAH8Pv0g0P7x=_KOmV2737AJpHgDEJu6_ecdmBseU6rVDuTzKQw@mail.gmail.com>
     [not found]       ` <<lubo13dl4n.fsf@fencepost.gnu.org>
     [not found]         ` <<CAH8Pv0h-7J-N-Drhc4vNw=26LtK4YShep0cuDXQeoPjLgqfvoQ@mail.gmail.com>
     [not found]           ` <<f527b11d-f842-4426-8e41-4991f9abe40c@default>
     [not found]             ` <<87wqjqts1b.fsf@gmail.com>
     [not found]               ` <<83zjom5ls5.fsf@gnu.org>
2013-11-30 18:41                 ` Drew Adams [this message]
2013-12-01  0:05                   ` participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail] Karl Fogel
2013-12-01 17:39                     ` Stephen J. Turnbull
2013-12-01 18:33                       ` Karl Fogel
2013-12-01 19:03                       ` Stefan Monnier
2013-11-28 17:32 Latest changes with lisp/uni-*.el and leim/quail Eli Zaretskii
2013-11-28 20:36 ` Glenn Morris
2013-11-29  8:42   ` Eli Zaretskii
2013-11-29 13:46     ` Stefan Monnier
2013-11-29 14:25       ` Eli Zaretskii
2013-11-29 16:43         ` Stefan Monnier
2013-11-29  7:46 ` Dani Moncayo
2013-11-29  8:38   ` Eli Zaretskii
2013-11-29  9:03     ` Dani Moncayo
2013-11-29 20:10       ` Glenn Morris
2013-11-29 21:40         ` Dani Moncayo
2013-11-30  0:37           ` participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail] Drew Adams
2013-11-30  4:47             ` Jambunathan K
2013-11-30  8:36               ` Eli Zaretskii
2013-11-30  8:43                 ` Dani Moncayo
2013-11-30 11:04                   ` Eli Zaretskii
2013-11-30 11:11                   ` Jarek Czekalski
2013-11-30 23:05                     ` Drew Adams
2013-12-01  7:26                       ` Thien-Thi Nguyen
2013-12-01  7:27                         ` Jambunathan K
2013-12-02 13:29                         ` Rüdiger Sonderfeld
2013-12-02 13:37                           ` Jarek Czekalski
2013-12-03 10:51                           ` Thien-Thi Nguyen
2013-12-03 20:03                             ` Wolfgang Jenkner
2013-12-03 20:33                               ` Andreas Schwab
2013-12-03 20:55                                 ` Wolfgang Jenkner
2013-12-03 21:18                                   ` Andreas Schwab
2013-12-04  8:50                             ` Thien-Thi Nguyen
2013-12-04 10:05                               ` Andreas Schwab
2013-12-04 13:52                                 ` Stefan Monnier
2013-12-04 13:57                                   ` Andreas Schwab
2013-12-08 11:01                                 ` adventures w/ git-bzr Thien-Thi Nguyen
2013-12-01  7:50                       ` participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail] Thien-Thi Nguyen
2013-12-01  8:09                         ` Jambunathan K
2013-11-30  8:47                 ` Jambunathan K
2013-11-30 13:50                 ` Stefan Monnier

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=f68d749a-877f-4cd0-84d0-826a2391f8a6@default \
    --to=drew.adams@oracle.com \
    --cc=dmoncayo@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kjambunathan@gmail.com \
    /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.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).