all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Jarek Czekalski <jarekczek@poczta.onet.pl>, emacs-devel@gnu.org
Subject: RE: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]
Date: Sat, 30 Nov 2013 15:05:09 -0800 (PST)	[thread overview]
Message-ID: <466a2599-43b3-4406-8bad-22cfb49c364f@default> (raw)
In-Reply-To: <5299C7FA.2080007@poczta.onet.pl>

> others may not want to waste time on commiting patches that are
> not useful to them.

Nothing wrong with that.  Perfectly understandable.

> If one says "I'm helping, but I'll never learn bzr and you have to
> commit my patches if you want them", they bring a delibarate
> minus to the project, decreasing other developer's time.

Not at all.  *If someone wants the patch* included, then it
eventually needs to be committed.  That's all.  If no one wants it
to be included, it need never be committed.

No patch available to commit = zero.  Patch available to commit = +1,
if it has any interest at all.  Patch never committed is still +1.
If committed, and if the patch does any good and no harm, then +2.

Nothing negative anywhere.  The only negative would be if the patch
got committed and did harm.

No one is required to commit a patch.  No one is required to review
a patch.  No one is required to even acknowledge that a patch has
been provided, or to thank the submitter for it (believe me).

> It's hard to judge for me, a newcomer, whether Dani's pluses
> largely outweight minuses, 

What minuses?  None have been shown.  I'm not sure any have even been
claimed.  In any case, I haven't seen any.  Can you point to any from
this thread, for instance?  Or do you take the position that simply
requesting a commit politely is a minus?  It's not.

> but in general a developer should be able to work on their own.

Should be able to?  Maybe, maybe not.  Should have to?  No.

There is nothing wrong with people working together.  Nothing
wrong with person A signaling a problem, person B proposing a
solution, person C improving on that, and person D committing it.

> Still exceptions may be done for some honorable or valueable
> people.

Who is going to decide who is honorable or valuable?  Emacs
contributions, including some that are worthwhile, come as gifts
from people of all sorts.  Who knows which of those individuals
are honorable or "valuable" people?

It is the gift that should be judged for inclusion, not the giver.

> It would be best if one of the developer's declared: "I'll be
> commiting every patch of Dani. My time is worth less than his, so
> I'll be doing it instead of him".

Why every patch?  Why must one person's time be "worth less" than
another's, in order for the one to commit something contributed by
the other?  That makes no sense at all.

RMS, whose time I think no one would claim is worth less than
anyone else's around here, routinely fixed minor bugs, including
doc bugs.  He spent lots of his time on mundane cleanup and
"unimportant" fixes.  Likewise, Eli, BTW.

> On the other hand, saying: "**someone** should be commiting it,
> because his work is good" is unfair too.

In this thread, NO ONE has said that ANYONE *should* commit Dani's
patch.  (No, I take that back.  Some have insisted that it is only
Dani who should commit Dani's patch.)

Dani *requested* that his patch be committed, IF someone agrees
that it is worthwhile.  To quote Dani's request again:

  "It [the patch] is ok?  If so, please commit it.  TIA."

Translation: Please review it.  If you like it, you are welcome
to it.  Thank you in advance, if you commit it.

Things are being turned around, to make it sound like it is Dani
who is *demanding* that someone commit his patch.  Eli accuses
him of treating others "as his dutiful servants".  Nothing could
be further from the truth, based on what we can see in this
thread, at least.

Can you point to one piece of this thread that shows Dani
arrogantly expecting or demanding that someone commit his patch?
AFAICS, if any arrogance has been shown it has not been from
Dani's corner.

One might wonder why things are being turned around so.  I, for
one, do not know.  Why paint Dani as the bad guy here?  Perhaps
there is a backstory that explains more (dunno), but nothing in
this thread, at least, warranted the aggression dumped on him,
AFAICT.



  reply	other threads:[~2013-11-30 23:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
     [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
2013-12-01  0:05                   ` Karl Fogel
2013-12-01 17:39                     ` Stephen J. Turnbull
2013-12-01 18:33                       ` Karl Fogel
2013-12-01 19:03                       ` 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

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

  git send-email \
    --in-reply-to=466a2599-43b3-4406-8bad-22cfb49c364f@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=jarekczek@poczta.onet.pl \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.