RE: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

RE: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Drew Adams]

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

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Karl Fogel]

The thread has gone on for a long time, I realize, but Dani should be
backed up here.  He did nothing wrong, and shouldn't have been
chastised.  What he did is normal & seen in lots of projects (and we'd
probably see it more often here if Emacs were more amenable to drive-by
contributions in general).

Dani offered a contribution into which he put the amount of effort he
was prepared to put.  If committing it via bzr is too much trouble for
him, then it's too much trouble for him.  Surely Dani is the world's
greatest expert on what's worth his time and what's not.  If someone
here is paying him a salary to contribute to Emacs, please speak up.

Jarek Czekalski wrote "If you, Dani, don't want to learn bzr, others may
not want to waste time on commiting patches that are not useful to
them."  That's perfectly fair -- but Dani never objected to that
reasoning.  He (and others) objected to him being *criticized*.  It's
fine to choose not to commit his patch; it's not fine to flame him for
having different priorities from some other developers.

-K

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Stephen J. Turnbull]

Karl Fogel writes:

Good Lord, Karl, up to now it's been the usual suspects.  But what are
*you* doing joining the pig-pile on these guys?  You know how much
support work they do for this project.  I can only suppose you didn't
notice they in particular have been mentoring the Hon. D. Moncayo.

I've never understood why merely submitting a patch is considered an
*important* contribution.  A contribution, yes, but as often as not
patches from new developers cost a lot more effort from the core
developers than is provided by the contributor himself.  That has been
the case here.

 > What he did is normal & seen in lots of projects

Really?  What he did was to get commit privileges, and then repeatedly
refuse to use them because the VCS *he* chose is too much trouble to
learn how to use.  That's "normal"?

 > He (and others) objected to him being *criticized*.  It's fine to
 > choose not to commit his patch; it's not fine to flame him for
 > having different priorities from some other developers.

The objections are misguided.  His behavior is rude and deserves
criticism.  The circumstances explain, even if they don't justify, the
public flames.

Although the words flamed his priorities, the *reason* he was flamed
is that he is abusing the hospitality of Eli (and Glenn), who spent a
fair amount of effort mentoring him, without which there would be no
committable patch.  He repaid that effort by refusing to take on a
minor chore (committing his own patch), and justified that by
explaining how valuable his time is to him.

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>Really?  What he did was to get commit privileges, and then repeatedly
>refuse to use them because the VCS *he* chose is too much trouble to
>learn how to use.  That's "normal"?

Not saying it's common, but I've seen it before with drive-by
contributions (even from people who technically have commit access).

> > He (and others) objected to him being *criticized*.  It's fine to
> > choose not to commit his patch; it's not fine to flame him for
> > having different priorities from some other developers.
>
>The objections are misguided.  His behavior is rude and deserves
>criticism.  The circumstances explain, even if they don't justify, the
>public flames.
>
>Although the words flamed his priorities, the *reason* he was flamed
>is that he is abusing the hospitality of Eli (and Glenn), who spent a
>fair amount of effort mentoring him, without which there would be no
>committable patch.  He repaid that effort by refusing to take on a
>minor chore (committing his own patch), and justified that by
>explaining how valuable his time is to him.

I didn't know about the mentoring, and agree that in that circumstance
there is often an implicit bargain of "If we help you get up to speed,
you'll take the trouble to repay our efforts by contributing (overcoming
whatever minor technical obstacles that may involve)."  That changes
things.  Based on just the messages I saw, this history wasn't apparent
-- sorry for commenting without knowing the full context.

Best,
-K

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Stefan Monnier]

Could I ask you guys again to move on, please?


        Stefan

Latest changes with lisp/uni-*.el and leim/quail

[Eli Zaretskii]

I don't know if it's on purpose, nor whether it matters, but the
latest changes in these two directories have the following effects:

 . loaddefs.el does not mention the uni-*.el files after a bootstrap,
   but if you go onto lisp and "make autoloads", they are added

 . leim/quail/*.el files _are_ mentioned in loaddefs.el

 . Every time you say "make", it wants to compile leim-list.el (which
   has no-byte-compile flag)

Re: Latest changes with lisp/uni-*.el and leim/quail

[Glenn Morris]

Eli Zaretskii wrote:

>  . loaddefs.el does not mention the uni-*.el files after a bootstrap,
>    but if you go onto lisp and "make autoloads", they are added

I added no-update-autoloads to those files.
(Not sure if this causes them to be left out from loaddefs.el or not,
but if not, it's a general issue.)

>  . leim/quail/*.el files _are_ mentioned in loaddefs.el

Intended.

>  . Every time you say "make", it wants to compile leim-list.el (which
>    has no-byte-compile flag)

Fixed.

Re: Latest changes with lisp/uni-*.el and leim/quail

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 28 Nov 2013 15:36:07 -0500
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> >  . loaddefs.el does not mention the uni-*.el files after a bootstrap,
> >    but if you go onto lisp and "make autoloads", they are added
> 
> I added no-update-autoloads to those files.

It doesn't seem to be working.  Try removing loaddefs.el, then say
"make autoloads" in the lisp directory, and grep the result -- you
will still see their names.

Re: Latest changes with lisp/uni-*.el and leim/quail

[Stefan Monnier]

> It doesn't seem to be working.  Try removing loaddefs.el, then say
> "make autoloads" in the lisp directory, and grep the result -- you
> will still see their names.

Seeing their names in there is not a problem, AFAIK.


        Stefan

Re: Latest changes with lisp/uni-*.el and leim/quail

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 29 Nov 2013 08:46:19 -0500
> 
> > It doesn't seem to be working.  Try removing loaddefs.el, then say
> > "make autoloads" in the lisp directory, and grep the result -- you
> > will still see their names.
> 
> Seeing their names in there is not a problem, AFAIK.

What is that section for, anyway?

Re: Latest changes with lisp/uni-*.el and leim/quail

[Stefan Monnier]

>> Seeing their names in there is not a problem, AFAIK.
> What is that section for, anyway?

It's there to record the last time these files were "looked at".
So as to avoid looking at them again if they haven't changed in the
mean time.


        Stefan

Re: Latest changes with lisp/uni-*.el and leim/quail

[Dani Moncayo]

On Thu, Nov 28, 2013 at 6:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> I don't know if it's on purpose, nor whether it matters, but the
> latest changes in these two directories have the following effects:

Another (adverse) effect that I see is that now "git status" from my
git repo reports a series of untracked files:

#       lisp/international/charprop.el
#       lisp/international/uni-bidi.el
#       lisp/international/uni-category.el
#       lisp/international/uni-combining.el
#       lisp/international/uni-comment.el
#       lisp/international/uni-decimal.el
#       lisp/international/uni-decomposition.el
#       lisp/international/uni-digit.el
#       lisp/international/uni-lowercase.el
#       lisp/international/uni-mirrored.el
#       lisp/international/uni-name.el
#       lisp/international/uni-numeric.el
#       lisp/international/uni-old-name.el
#       lisp/international/uni-titlecase.el
#       lisp/international/uni-uppercase.el
#       lisp/leim/ja-dic/
#       lisp/leim/leim-list.el


Doesn't something similar happen in bzr?
Shouldn't you tweak '.bzrignore' and '.gitignore' to consider the above files?

-- 
Dani Moncayo

Re: Latest changes with lisp/uni-*.el and leim/quail

[Eli Zaretskii]

> Date: Fri, 29 Nov 2013 08:46:57 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> Another (adverse) effect that I see is that now "git status" from my
> git repo reports a series of untracked files:
> 
> #       lisp/international/charprop.el
> #       lisp/international/uni-bidi.el
> #       lisp/international/uni-category.el
> #       lisp/international/uni-combining.el
> #       lisp/international/uni-comment.el
> #       lisp/international/uni-decimal.el
> #       lisp/international/uni-decomposition.el
> #       lisp/international/uni-digit.el
> #       lisp/international/uni-lowercase.el
> #       lisp/international/uni-mirrored.el
> #       lisp/international/uni-name.el
> #       lisp/international/uni-numeric.el
> #       lisp/international/uni-old-name.el
> #       lisp/international/uni-titlecase.el
> #       lisp/international/uni-uppercase.el
> #       lisp/leim/ja-dic/
> #       lisp/leim/leim-list.el
> 
> 
> Doesn't something similar happen in bzr?
> Shouldn't you tweak '.bzrignore' and '.gitignore' to consider the above files?

.bzrignore already does.

Re: Latest changes with lisp/uni-*.el and leim/quail

[Dani Moncayo]

>> Another (adverse) effect that I see is that now "git status" from my
>> git repo reports a series of untracked files:
>>
>> #       lisp/international/charprop.el
>> #       lisp/international/uni-bidi.el
>> #       lisp/international/uni-category.el
>> #       lisp/international/uni-combining.el
>> #       lisp/international/uni-comment.el
>> #       lisp/international/uni-decimal.el
>> #       lisp/international/uni-decomposition.el
>> #       lisp/international/uni-digit.el
>> #       lisp/international/uni-lowercase.el
>> #       lisp/international/uni-mirrored.el
>> #       lisp/international/uni-name.el
>> #       lisp/international/uni-numeric.el
>> #       lisp/international/uni-old-name.el
>> #       lisp/international/uni-titlecase.el
>> #       lisp/international/uni-uppercase.el
>> #       lisp/leim/ja-dic/
>> #       lisp/leim/leim-list.el
>>
>>
>> Doesn't something similar happen in bzr?
>> Shouldn't you tweak '.bzrignore' and '.gitignore' to consider the above files?
>
> .bzrignore already does.

Thanks.

I've just realized that .gitignore and .bzrignore are very different.
I don't understand why.  Shouldn't they be pretty similar?

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


diff --git a/.gitignore b/.gitignore
index 1ee08d8..a5bca1f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,4 +16,7 @@ TAGS

 /bin/
 /site-lisp/
-/leim/ja-dic/
+/lisp/leim/ja-dic/
+/lisp/leim/leim-list.el
+/lisp/international/charprop.el
+/lisp/international/uni-*

-- 
Dani Moncayo

Re: Latest changes with lisp/uni-*.el and leim/quail

[Glenn Morris]

Look, you've got commit rights, you've chosen to use git, why don't you
fix these things if they bother you, rather than asking someone else to
do so? Oh, because you won't take 30mins to learn how to use bzr (or
git-bzr, or whatever). If 200 people each spend 10 seconds reading one
of your "please commit this for me" messages, that's more than 30mins
wasted.

(Anyway, someone else already fixed it.)

Re: Latest changes with lisp/uni-*.el and leim/quail

[Dani Moncayo]

> Look, you've got commit rights, you've chosen to use git, why don't you
> fix these things if they bother you, rather than asking someone else to
> do so?

When I know how to fix something (like in this case), I fix it.  And
that is what I've done.  I just asked someone to commit my patch.  (I
don't think I'm asking too much).

> Oh, because you won't take 30mins to learn how to use bzr (or
> git-bzr, or whatever).

No, the question is not that simple.  The spare time I can afford to
devote to my "programming hobbies" is very scarce.  In that little
time, I try to contribute to and learn a bit of Emacs, while at the
same time get a bit of experience with git (in which I have interest
too).  Currently I don't have time for more.

IOW, currently Emacs is the only project in which I use git, so, if I
used bzr instead (in which I have no interest), I would not have the
opportunity to get experienced with git, and that, IMO, would be
definitely too bad.

> If 200 people each spend 10 seconds reading one
> of your "please commit this for me" messages, that's more than 30mins
> wasted.

That is one point of view, but another one is this:
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?

-- 
Dani Moncayo

participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Drew Adams]

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

But these are not *levels*.  And the "more" and "even (a little) more"
are inappropriate here.  All sincere effort can be helpful.

It makes no sense to quantify either the effort spent or the resulting
improvement, especially based only on the type of activity.

Spending 1/2 hour providing feedback + 1/2 hour committing code is
not necessarily more helpful than spending 1 hour providing feedback
(or 1 hour committing code).  All time spent is welcome.

And the result of the time spent, however long, likewise does not fit
into any useful value hierarchy.

Sometimes just posing a question can be worth an awful lot.  And good
feedback can sometimes prevent a lot of needless coding or committing.  Likewise, providing Emacs development snapshots that people can test
with - that's a great benefit that you provide, IMO.

You have N hours to spend.  You choose how to spend that time.  No
one should be trying to tell you how to spend your time, or thinking
that what they do with their time is more important than what you
choose to do with yours.

There are thousands of bugs reported, many (most) with good, careful
reports that lie dormant and die neglected.  Some people spend lots
of their volunteer time fixing Emacs bugs.  Others prefer to develop
new features and not fix bugs.  So what?  That's life.  It is not
constructive to berate volunteers for not doing this or that.

Don't let such bullying get you down, Dani.  I, for one, am very
appreciative of what you do.

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

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

Once you realize that you are working (together?) with "No Obligation",
"No Incentives" or "No Punishments" scenario, the activity itself can
take on more meaning and focus can shift to just the activity (whatever
that may be)

----------------------------------------------------------------

There are two autonomous entities dancing together.  Dancing - the
footwork - is difficult.  Loosely-coupled bodies trying to create a
graceful movement.  The perils of a wrong move - The twisted ligaments
and an occasional cramp - These are all painful, instructive or atleast
entertainment-worthy.

Just laugh, shrug or curse.  Pick separate ways or walk together.

----------------------------------------------------------------

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Sat, 30 Nov 2013 10:17:12 +0530
> Cc: Emacs development discussions <emacs-devel@gnu.org>,
> 	Dani Moncayo <dmoncayo@gmail.com>
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> >> 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.

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.

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

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

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Dani Moncayo]

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

With all due respect, Eli.  I'm sorry that you think so.

I want to contribute to Emacs, while at the same time using the VCS I
like.  Just that.  The only drawback of that approach is that every
now and then some other developer would have to commit some patch of
mine.  I think it is a reasonable tradeoff.


-- 
Dani Moncayo

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Eli Zaretskii]

> Date: Sat, 30 Nov 2013 09:43:54 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> I want to contribute to Emacs, while at the same time using the VCS I
> like.

git-bzr makes this possible.

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jarek Czekalski]

W dniu 11/30/2013 09:43 AM, Dani Moncayo pisze:
>> 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.
>>
>> 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.
> With all due respect, Eli.  I'm sorry that you think so.
>
> I want to contribute to Emacs, while at the same time using the VCS I
> like.  Just that.  The only drawback of that approach is that every
> now and then some other developer would have to commit some patch of
> mine.  I think it is a reasonable tradeoff.
>
>

I have also another idea of fair approach. If you, Dani, don't want to 
learn bzr, others may not want to waste time on commiting patches that 
are not useful to them. At this moment these are the patches regarding 
git things.

The best user is such that brings only pluses to the project, without 
intended minuses. 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. Eli supported.

It's hard to judge for me, a newcomer, whether Dani's pluses largely 
outweight minuses, but in general a developer should be able to work on 
their own. Still exceptions may be done for some honorable or valueable 
people. 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". On the other hand, saying: "**someone** 
should be commiting it, because his work is good" is unfair too.

Jarek

RE: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Drew Adams]

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

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

() Drew Adams <drew.adams@oracle.com>
() Sat, 30 Nov 2013 15:05:09 -0800 (PST)

   What minuses?  None have been shown.

I think there is opportunity cost for whoever does the commit.
If that person is not the original programmer, the cost must be
shared.  It's natural for people to balk at sharing costs.

For some situations (e.g., paying for a group lunch) there is
more or less a social protocol for settling the matter.  Here,
there is no such protocol, except for thread-around-the-moon
arguing.

Personally, i just recently learned about "git-bzr" and, being
in the same boat as OP, am resolved to try it out RSN.  Maybe
OP can do likewise, and we can coalesce our experiences into a
suitable blurb under admin/notes/, to ease things for others.
Surely that is better than continuing this thread.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jambunathan K]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> Personally, i just recently learned about "git-bzr" and, being in the
> same boat as OP, am resolved to try it out RSN.

+1

1. How we colloborate can be negotiated, it is personal and situational.
2. That colloboration or co-operation is essential is beyond any doubt.

(2) should feed (1).

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Rüdiger Sonderfeld]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

On Sunday 01 December 2013 08:26:53 Thien-Thi Nguyen wrote:
> Personally, i just recently learned about "git-bzr" and, being
> in the same boat as OP, am resolved to try it out RSN.  Maybe
> OP can do likewise, and we can coalesce our experiences into a
> suitable blurb under admin/notes/, to ease things for others.
> Surely that is better than continuing this thread.

I'm in a similar situation.  I recently got commit rights and would like to 
continue using git.  It's simply the system I know and fits in my workflow 
(thanks magit).  Without commit rights it was easy because I could simply use 
git to format the patches and send them to bugs/devel.

I have already imported trunk through git-bzr.  Is anybody here using git-bzr 
to push to the Emacs master?  How well does this work?

Regards,
Rüdiger

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jarek Czekalski]

W dniu 2013-12-02 14:29, Rüdiger Sonderfeld pisze:
> I have already imported trunk through git-bzr.  Is anybody here using git-bzr
> to push to the Emacs master?  How well does this work?
>
> Regards,
> Rüdiger

Seems like this may start a valuable discussion, but it will be lost if 
it remains under this long and misleading subject. Please post such 
questions as a new thread. Preferrably as a brand new subject, not 
started with "reply to". Still it may be fixed if an answer is created 
in this way.

Jarek

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

() Rüdiger Sonderfeld <ruediger@c-plusplus.de>
() Mon, 02 Dec 2013 14:29:53 +0100

   I have already imported trunk through git-bzr.

In in the process of doing so (i believe) as i type this...
For the record, here is what i had to do (Debian "wheezy" system):
- # aptitude purge git
- Add "deb URL wheezy-backports ..." to /etc/apt/sources.list.
- # aptitude install -R git/wheezy-backports
- # aptitude install -R git-bzr/wheezy-backports
- $ cd ~/build/GNU
- $ git clone bzr::bzr+ssh://ttn@bzr.savannah.gnu.org/emacs/trunk e
  (I chose destination dir "e" to avoid conflict w/ the default "emacs",
   the current Git repo and build tree for this very Emacs, here...)

Now i see e/.git/bzr/.bzr/repository/upload/ w/ a slowly-growing .pack
file (294MB at the moment).  I suppose this is a temporary work area for
git-remote-bzr and the working tree e/ will be populated once download
is complete.

So far, so good.  (Now watch the gods strike me and my old computer
down -- Murphy's Law...)

   Is anybody here using git-bzr to push to the Emacs master?

Soon that would be me (and you, right?), and hopefully OP...

   How well does this work?

Why don't you try it and post your observations?  That's what i will do.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Wolfgang Jenkner]

On Tue, Dec 03 2013, Thien-Thi Nguyen wrote:

> () Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> () Mon, 02 Dec 2013 14:29:53 +0100
>    Is anybody here using git-bzr to push to the Emacs master?
>
> Soon that would be me (and you, right?), and hopefully OP...
>
>    How well does this work?
>
> Why don't you try it and post your observations?  That's what i will do.

Like other people I have done some experiments with local repositories
and there is a thing that bothers me: While, by default, `git push' to
some other git repo succeeds only if this would not change the history
of what is already in that repo, there is apparently no such safeguard
against rewriting history in an upstream bzr repo (and pushing to
a bound branch instead does not quite work).

The stuff below corresponds to "NOTE ABOUT FAST-FORWARDS" in
git-push(1).

[1 /tmp]$ bzr init trunk
Created a standalone tree (format: 2a)
[2 /tmp]$ (cd trunk && touch foo && bzr add $_ && bzr commit -m X && bzr log --line)
adding foo
Committing to: /tmp/trunk/
added foo
Committed revision 1.
1: Wolfgang Jenkner 2013-12-02 X
[3 /tmp]$ git clone bzr::trunk local
Cloning into 'local'...
Checking connectivity... done
[4 /tmp]$ (cd trunk && echo "trunk change" >foo && bzr commit -m A && bzr log --line) 
Committing to: /tmp/trunk/
modified foo
Committed revision 2.
2: Wolfgang Jenkner 2013-12-02 A
1: Wolfgang Jenkner 2013-12-02 X
[5 /tmp]$ (cd local && echo "local change" >foo && git commit -a -m B && git log --oneline && git push) 
[master 8b5e5ad] B
 1 file changed, 1 insertion(+)
8b5e5ad B
ad0e090 X
Text conflict in foo
1 conflicts encountered.
To bzr::/tmp/trunk
   ad0e090..8b5e5ad  master -> master
[6 /tmp]$ (cd trunk && bzr log --line)
2: Wolfgang Jenkner 2013-12-02 B
1: Wolfgang Jenkner 2013-12-02 X
[7 /tmp]$ ls -l trunk
total 12
-rw-r--r--  1 wolfgang  wheel  68 Dec  2 16:52 foo
-rw-r--r--  1 wolfgang  wheel   0 Dec  2 16:52 foo.BASE
-rw-r--r--  1 wolfgang  wheel  13 Dec  2 16:52 foo.OTHER
-rw-r--r--  1 wolfgang  wheel  13 Dec  2 16:52 foo.THIS
[8 /tmp]$ cat trunk/foo
<<<<<<< TREE
trunk change
=======
local change
>>>>>>> MERGE-SOURCE
[9 /tmp]$ cat local/foo
local change
[10 /tmp]$ (cd local && git pull)
Already up-to-date.
[11 /tmp]$ git clone bzr::trunk new-local
Cloning into 'new-local'...
Checking connectivity... done
[12 /tmp]$ cat new-local/foo
local change
[13 /tmp]$ (cd trunk && bzr status)
modified:
  foo
unknown:
  foo.BASE
  foo.OTHER
  foo.THIS
conflicts:
  Text conflict in foo
[14 /tmp]$ 

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Andreas Schwab]

Wolfgang Jenkner <wjenkner@inode.at> writes:

> Like other people I have done some experiments with local repositories
> and there is a thing that bothers me: While, by default, `git push' to
> some other git repo succeeds only if this would not change the history
> of what is already in that repo, there is apparently no such safeguard
> against rewriting history in an upstream bzr repo (and pushing to
> a bound branch instead does not quite work).

This should work properly with git-remote-bzr.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Wolfgang Jenkner]

On Tue, Dec 03 2013, Andreas Schwab wrote:

> Wolfgang Jenkner <wjenkner@inode.at> writes:
>
>> Like other people I have done some experiments with local repositories
>> and there is a thing that bothers me: While, by default, `git push' to
>> some other git repo succeeds only if this would not change the history
>> of what is already in that repo, there is apparently no such safeguard
>> against rewriting history in an upstream bzr repo (and pushing to
>> a bound branch instead does not quite work).
>
> This should work properly with git-remote-bzr.

The example I gave used this remote helper (included with git 1.8.4.3).

Or did you mean my parenthetical remark?

Wolfgang

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Andreas Schwab]

Wolfgang Jenkner <wjenkner@inode.at> writes:

> On Tue, Dec 03 2013, Andreas Schwab wrote:
>
>> Wolfgang Jenkner <wjenkner@inode.at> writes:
>>
>>> Like other people I have done some experiments with local repositories
>>> and there is a thing that bothers me: While, by default, `git push' to
>>> some other git repo succeeds only if this would not change the history
>>> of what is already in that repo, there is apparently no such safeguard
>>> against rewriting history in an upstream bzr repo (and pushing to
>>> a bound branch instead does not quite work).
>>
>> This should work properly with git-remote-bzr.
>
> The example I gave used this remote helper (included with git 1.8.4.3).

Then this part doesn't work:

                try:
                    peer.bzrdir.push_branch(branch, revision_id=revid)
                except bzrlib.errors.DivergedBranches:
                    print "error %s non-fast forward" % ref
                    continue

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

() Thien-Thi Nguyen <ttn@gnu.org>
() Tue, 03 Dec 2013 11:51:58 +0100

   Now i see e/.git/bzr/.bzr/repository/upload/ w/ a slowly-growing
   .pack file (294MB at the moment).  I suppose this is a temporary work
   area for git-remote-bzr and the working tree e/ will be populated
   once download is complete.

   So far, so good.  (Now watch the gods strike me and my old computer
   down -- Murphy's Law...)

Ah yes, Mr. Murphy.  After four hours, the hard disk filled up (5.8 G is
apparently not enough) and the process exited failurefully.  The good
(?) news is that the death was clean, and apart from a huge increase in
entropy, there remains no sign of activity whatsoever.  I and my old
computer thank you for dropping by.  :-/

I'm curious: What is the maximum transient disk footprint people see for
"git clone bzr::..." and for a "pure bzr" (no git-bzr) checkout?  Is
there a huge difference?  How about footprint after successful checkout?

[If anyone wants to donate me a new(er) computer for Emacs (and other
 Free Software) hacking, please contact me off-list.]

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Andreas Schwab]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> I'm curious: What is the maximum transient disk footprint people see for
> "git clone bzr::..." and for a "pure bzr" (no git-bzr) checkout?

After git clone bzr:: the size of the pack file will be about 12G (no
delta compression), after git gc --aggressive it shrinks to 193K.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Stefan Monnier]

> delta compression), after git gc --aggressive it shrinks to 193K.

Now, *that* is what I call aggressive!


        Stefan

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> delta compression), after git gc --aggressive it shrinks to 193K.
>
> Now, *that* is what I call aggressive!

193M, of course. :-)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

adventures w/ git-bzr

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

() Andreas Schwab <schwab@linux-m68k.org>
() Wed, 04 Dec 2013 11:05:55 +0100

   After git clone bzr:: the size of the pack file will be about 12G (no
   delta compression), after git gc --aggressive it shrinks to 193K.

OK, i scrounged up a 15GB USB (1.0?!) external drive and was able to do
the "git clone bzr::" in 7.5 hours -- woo hoo!  It's somewhat tight now:

 $ LANG=C df -h .
 Filesystem      Size  Used Avail Use% Mounted on
 /dev/sdb1        14G   13G  794M  95% /mnt/mulo

This was after two failing attempts, both ending with an error message:

 bzrlib.errors.GhostRevisionsHaveNoRevno: Could not determine revno for
   {ID-1} because its ancestry shows a ghost at {ID-2}
 Write failed: Broken pipe

In both attempts, ID-1 was:

 kenner@gnu.org-19980613195110-2j7ddnyudwfyfytc

ID-2 for the attempts were (respectively):

 dmoncayo@gmail.com-20131207130209-d61sb5r2xuww52j0
 jan.h.d@swipnet.se-20131207142629-caazt8axffdl8p2o

On the third (successful) attempt, the only strange output was
(excerpt):

 progress revision 60600 'master' (60600/115406)
 progress revision 60700 'master' (60700/115406)
 Write failed: Broken pipe
 progress revision 60800 'master' (60800/115406)
 progress revision 60900 'master' (60900/115406)

I hope these errors are not an indication of tampering or corruption.
Next step is to snapshot this tree (somehow) and then do some local
munging experiments, perhaps starting w/ "git gc --aggressive".

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

() Drew Adams <drew.adams@oracle.com>
() Sat, 30 Nov 2013 15:05:09 -0800 (PST)

   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.

Probably the interpretation is a function of what kind of English one
is used to, mostly.  To me, the construction "Please ACT." has command
overtones, whereas the construction "Could you please ACT?" i would
take unambiguously as a request.  Not only does the latter end w/ a
(re)quest(ion) mark, it makes use of the "conditional mood":

 http://en.wikipedia.org/wiki/Conditional_mood

English (like Emacs) weirds its users -- oh well, life goes on...  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jambunathan K]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> To me, the construction "Please ACT." has command overtones, whereas
> the construction "Could you please ACT?" i would take unambiguously as
> a request.

Since we are going Meta...

It is not only felicity with the language alone but also the cultural
and historical baggage.  (I believe this thread is a result of latter
type.)

To me - the baser me - an Occidental "Please and Thanks" is VERY
DIFFERENT from Oriental "Please and Thanks".  So...

Will, the twain meet?

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:


> frustration (which I share)

Tell once.

Refuse co-operation or don't oblige, if repeated.

Don't commit the patch.  By committing the patch, a perceived errant
behaviour is encouraged.

> That each one of you backed him up

I brought attention to the reality - of "loose coupling" and "no
obligation".

I am a bzr user, so ...

Re: participation & contribution [was: Latest changes with lisp/uni-*.el and leim/quail]

[Stefan Monnier]

Please people, can we tone it down, and move on to actual development?
Thank you,


        Stefan