A problem with old bugs

A problem with old bugs

[Marcin Borkowski]

Hi there,

I'm sorry to say that I'm a bit sad.  A few months ago (maybe a year)
there was a call to so some work on old, outstanding bugs.
I volunteered for that, and while I did not spend /a lot/ of time on
that, I feel that I did indeed help a bit.  Then, I proceeded to
actually fix a few bugs that were within my reach.  I sent a patch
fixing 21072, then a patch fixing one bug I did not formally submit (but
both the bug and the patch are seemingly quite trivial), and then wanted
to start discussion on 19873.

Unfortunately, I have to say that I got very little feedback.  There was
some discussion (John's on testing, Eli's on my stupid mistakes etc.),
but my patches/emails are mainly left there undecided.

I do understand the main reason (too few developers, the bugs were not
critical), but I have to say that the situation isn't exactly motivating
for me.  I will try to continue work on some bugs for the next week or
two, but I guess I'll stop then, since at this moment it doesn't feel to
have a lot of sense anyway, and I have a lot of ways to spend my time in
a meaningful way...

Is there anything that could be done to avoid turning off people wanting
to help with Emacs development?  Did I choose wrong bugs to work on?  If
so, should I close them as "wontfix", even though (in 2 cases) there are
actual patches that seem to fix them?

Best,

--
Marcin Borkowski

Re: A problem with old bugs

[Thien-Thi Nguyen]

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


() Marcin Borkowski <mbork@mbork.pl>
() Wed, 01 Mar 2017 09:22:55 +0100

   Unfortunately, I have to say that I got very little feedback.
   [...]  I do understand the main reason (too few developers,
   the bugs were not critical), but I have to say that the
   situation isn't exactly motivating for me.

   Is there anything that could be done to avoid turning off
   people wanting to help with Emacs development?  Did I choose
   wrong bugs to work on?  If so, should I close them as
   "wontfix", even though (in 2 cases) there are actual patches
   that seem to fix them?

Do you have write privs to the repo?

If so, perhaps you can find motivation from installing changes
directly and dealing w/ any discussion that ensues, rather than
From positive feedback in discussion pre-commit.  This is the
vaunted "better to ask forgiveness than ask permission" model.
Of course, it's not always so much fun discussing one's mistakes
in public but (take it from someone w/ lots of experience making
mistakes :-D), it does get easier w/ practice.  Sez Perlis:

 Dealing with failure is easy: Work hard to improve.
 Success is also easy to handle: You've solved the wrong
 problem.  Work hard to improve.

I take from this: Satisfaction (and thus motivation to continue)
comes from the hard work applied towards improvement.  What to
improve?  Emacs, yourself, Emacs and yourself, Emacs and others.

If not (no write privs), why not?  What are you waiting for?

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


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

Re: A problem with old bugs

[Marcin Borkowski]

On 2017-03-01, at 11:26, Thien-Thi Nguyen <ttn@gnu.org> wrote:

> () Marcin Borkowski <mbork@mbork.pl>
> () Wed, 01 Mar 2017 09:22:55 +0100
>
>    Unfortunately, I have to say that I got very little feedback.
>    [...]  I do understand the main reason (too few developers,
>    the bugs were not critical), but I have to say that the
>    situation isn't exactly motivating for me.
>
>    Is there anything that could be done to avoid turning off
>    people wanting to help with Emacs development?  Did I choose
>    wrong bugs to work on?  If so, should I close them as
>    "wontfix", even though (in 2 cases) there are actual patches
>    that seem to fix them?
>
> Do you have write privs to the repo?

Nope.  What do I do to get them?

> If so, perhaps you can find motivation from installing changes
> directly and dealing w/ any discussion that ensues, rather than
> From positive feedback in discussion pre-commit.  This is the
> vaunted "better to ask forgiveness than ask permission" model.
> Of course, it's not always so much fun discussing one's mistakes
> in public but (take it from someone w/ lots of experience making
> mistakes :-D), it does get easier w/ practice.  Sez Perlis:
>
>  Dealing with failure is easy: Work hard to improve.
>  Success is also easy to handle: You've solved the wrong
>  problem.  Work hard to improve.

;-)

> I take from this: Satisfaction (and thus motivation to continue)
> comes from the hard work applied towards improvement.  What to
> improve?  Emacs, yourself, Emacs and yourself, Emacs and others.
>
> If not (no write privs), why not?  What are you waiting for?

Nobody gave them to me.

What should be the workflow once I have them?  I assume that I branch
off fresh master, push my branch and write here - correct?

Best,

-- 
Marcin Borkowski

Re: A problem with old bugs

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Wed, 01 Mar 2017 09:22:55 +0100
> 
> I'm sorry to say that I'm a bit sad.  A few months ago (maybe a year)
> there was a call to so some work on old, outstanding bugs.
> I volunteered for that, and while I did not spend /a lot/ of time on
> that, I feel that I did indeed help a bit.  Then, I proceeded to
> actually fix a few bugs that were within my reach.  I sent a patch
> fixing 21072, then a patch fixing one bug I did not formally submit (but
> both the bug and the patch are seemingly quite trivial), and then wanted
> to start discussion on 19873.
> 
> Unfortunately, I have to say that I got very little feedback.  There was
> some discussion (John's on testing, Eli's on my stupid mistakes etc.),
> but my patches/emails are mainly left there undecided.

Can you tell which bugs are those?  I'd like to look them up and see
why they stalled.

In general, if there are no unresolved issues raised during the
discussions, you just need to ping the bug address once a week or two,
to make sure the reports don't fall through the cracks.

Thanks.

Re: A problem with old bugs

[Thien-Thi Nguyen]

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


() Marcin Borkowski <mbork@mbork.pl>
() Wed, 01 Mar 2017 14:28:40 +0100

   Nope.  What do I do to get them?

I'm not familiar w/ full details these days, but i think
generally you need to ask the maintainer for them, in the
process making some convincing arguments that you will not
besmirch Emacs and GNU (by introducing or advocating non-Free
software, for example), and that your interaction w/ the project
will be a net positive.  Once swayed, the maintainer starts the
paperwork process (which might involve snail mail), and If All
Goes Well, you will be notified one day.

Another way is to fork Emacs, or find a way to get write privs
on an existing fork.  That resolves the write privs issue, but
raises coordination/synchronization issues.  I was about to say
"not recommended", but on second thought, hey why not?  I can
imagine inter-repo hacking being fruitful and fun, too (YMMV).

   > What are you waiting for?

   Nobody gave them to me.

   What should be the workflow once I have them?  I assume that
   I branch off fresh master, push my branch and write here -
   correct?

See file CONTRIBUTE.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (query)
   (pcase (context query)
     (`(technical ,ml) (correctp ml))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


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

Re: A problem with old bugs

[Noam Postavsky]

On Thu, Mar 2, 2017 at 2:38 AM, Thien-Thi Nguyen <ttn@gnu.org> wrote:
>
> I'm not familiar w/ full details these days, but i think
> generally you need to ask the maintainer for them, in the
> process making some convincing arguments that you will not
> besmirch Emacs and GNU (by introducing or advocating non-Free
> software, for example), and that your interaction w/ the project
> will be a net positive.  Once swayed, the maintainer starts the
> paperwork process (which might involve snail mail), and If All
> Goes Well, you will be notified one day.

Paper is only needed for copyright assignment, to get write access you
just make a request here: https://savannah.nongnu.org/my/groups.php

Re: A problem with old bugs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We no longer need copyright assignments to be done on paper,
in many cases.  When the contributor talks with assign@gnu.org,
the response should explain whether it needs to be on paper or not.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: A problem with old bugs

[Phillip Lord]

Marcin Borkowski <mbork@mbork.pl> writes:
>> If not (no write privs), why not?  What are you waiting for?
>
> Nobody gave them to me.
>
> What should be the workflow once I have them?  I assume that I branch
> off fresh master, push my branch and write here - correct?


Emacs doesn't have a well developed branch merge workflow. In general,
people push things straight onto master. If you are unsure whether your
patch is good, then asking on emacs-devel, then no one complaining for a
while is probably a good sign.

At the end of the day, try and get it right, but breaking Emacs is going
to happen and it's not a disaster. I've done it lots recently!

Phil

Re: A problem with old bugs

[Marcin Borkowski]

On 2017-03-01, at 17:16, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Wed, 01 Mar 2017 09:22:55 +0100
>> 
>> I'm sorry to say that I'm a bit sad.  A few months ago (maybe a year)
>> there was a call to so some work on old, outstanding bugs.
>> I volunteered for that, and while I did not spend /a lot/ of time on
>> that, I feel that I did indeed help a bit.  Then, I proceeded to
>> actually fix a few bugs that were within my reach.  I sent a patch
>> fixing 21072, then a patch fixing one bug I did not formally submit (but
>> both the bug and the patch are seemingly quite trivial), and then wanted
>> to start discussion on 19873.
>> 
>> Unfortunately, I have to say that I got very little feedback.  There was
>> some discussion (John's on testing, Eli's on my stupid mistakes etc.),
>> but my patches/emails are mainly left there undecided.
>
> Can you tell which bugs are those?  I'd like to look them up and see
> why they stalled.

As I said above, 21072, 19873 and one patch submitted here:
https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00707.html

>
> In general, if there are no unresolved issues raised during the
> discussions, you just need to ping the bug address once a week or two,
> to make sure the reports don't fall through the cracks.

OK, I'll do that.

> Thanks.

Best,

-- 
Marcin Borkowski

Re: A problem with old bugs

[Marcin Borkowski]

On 2017-03-06, at 14:19, Phillip Lord <phillip.lord@russet.org.uk> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>>> If not (no write privs), why not?  What are you waiting for?
>>
>> Nobody gave them to me.
>>
>> What should be the workflow once I have them?  I assume that I branch
>> off fresh master, push my branch and write here - correct?
>
>
> Emacs doesn't have a well developed branch merge workflow. In general,
> people push things straight onto master. If you are unsure whether your
> patch is good, then asking on emacs-devel, then no one complaining for a
> while is probably a good sign.

That's interesting.  I'd be a bit afraid of pushing to master, if only
because I have a habit of compiling Emacs from master from time to
time...

> At the end of the day, try and get it right, but breaking Emacs is going
> to happen and it's not a disaster. I've done it lots recently!

;-)

> Phil

Thanks,

--
Marcin Borkowski

Re: A problem with old bugs

[Marcin Borkowski]

On 2017-03-02, at 13:33, Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Thu, Mar 2, 2017 at 2:38 AM, Thien-Thi Nguyen <ttn@gnu.org> wrote:
>>
>> I'm not familiar w/ full details these days, but i think
>> generally you need to ask the maintainer for them, in the
>> process making some convincing arguments that you will not
>> besmirch Emacs and GNU (by introducing or advocating non-Free
>> software, for example), and that your interaction w/ the project
>> will be a net positive.  Once swayed, the maintainer starts the
>> paperwork process (which might involve snail mail), and If All
>> Goes Well, you will be notified one day.
>
> Paper is only needed for copyright assignment, to get write access you
> just make a request here: https://savannah.nongnu.org/my/groups.php

I have had my papers signed for some time now, this is not a problem.

Best,

-- 
Marcin Borkowski

Re: A problem with old bugs

[Phillip Lord]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2017-03-06, at 14:19, Phillip Lord <phillip.lord@russet.org.uk> wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> writes:
>>>> If not (no write privs), why not?  What are you waiting for?
>>>
>>> Nobody gave them to me.
>>>
>>> What should be the workflow once I have them?  I assume that I branch
>>> off fresh master, push my branch and write here - correct?
>>
>>
>> Emacs doesn't have a well developed branch merge workflow. In general,
>> people push things straight onto master. If you are unsure whether your
>> patch is good, then asking on emacs-devel, then no one complaining for a
>> while is probably a good sign.
>
> That's interesting.  I'd be a bit afraid of pushing to master, if only
> because I have a habit of compiling Emacs from master from time to
> time...

In practice, master is the only way to get people to test things for
you.

You can always push to a branch and ask for feedback. It's less usual,
but you'll often get something.

Phil

Re: A problem with old bugs

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: emacs-devel@gnu.org
> Date: Tue, 07 Mar 2017 07:15:09 +0100
> 
> >> Unfortunately, I have to say that I got very little feedback.  There was
> >> some discussion (John's on testing, Eli's on my stupid mistakes etc.),
> >> but my patches/emails are mainly left there undecided.
> >
> > Can you tell which bugs are those?  I'd like to look them up and see
> > why they stalled.
> 
> As I said above, 21072, 19873 and one patch submitted here:
> https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00707.html

I replied to the 2 bug reports, let's hope we will get the ball
rolling again on them.

As for the patch posted here, I think it makes sense to make such
changes only if they are done in all modes.  Doing that only in one
major mode will only confuse people.  So if you'd like to pursue this
change (and I do think it would be a good change), please make the
change in a way that will produce similar behavior in all the other
modes with define their beginning-of-defun functionality.

Thanks, and sorry about your reports falling through the cracks.

Re: A problem with old bugs

[Marcin Borkowski]

On 2017-03-07, at 17:51, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 07 Mar 2017 07:15:09 +0100
>> 
>> >> Unfortunately, I have to say that I got very little feedback.  There was
>> >> some discussion (John's on testing, Eli's on my stupid mistakes etc.),
>> >> but my patches/emails are mainly left there undecided.
>> >
>> > Can you tell which bugs are those?  I'd like to look them up and see
>> > why they stalled.
>> 
>> As I said above, 21072, 19873 and one patch submitted here:
>> https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00707.html
>
> I replied to the 2 bug reports, let's hope we will get the ball
> rolling again on them.

OK, I'll try to make a few final modifications and push them.

> As for the patch posted here, I think it makes sense to make such
> changes only if they are done in all modes.  Doing that only in one
> major mode will only confuse people.  So if you'd like to pursue this
> change (and I do think it would be a good change), please make the
> change in a way that will produce similar behavior in all the other
> modes with define their beginning-of-defun functionality.

I am not sure whether I understand.  The problem was specifically with
lisp version of `beginning-of-defun'.  With other modes, there is a bit of
a mess: some modes set `beginning-of-defun-function' (e.g. js-mode and
js2-mode), some rebind C-M-a to their beginning-of-defun (e.g. c-mode).
Now, other modes (again, I used c-mode and js2-mode for reference) do
various things when arg=0 for beginning-of-defun - e.g. c-mode claims to
go back to the current defun's header, js2-mode just pretends that arg
is 1 etc.

Unifying that (1) might not be the best idea and (2) would require quite
a lot of work for all Emacs built-in modes.

I could try to do that, but this would take a bit.  Also, I do not know
many of the languages involved, and I'd prefer not to touch their
modes.

> Thanks, and sorry about your reports falling through the cracks.

No problem,

-- 
Marcin Borkowski

Re: A problem with old bugs

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Mar 2017 08:01:45 +0100
> 
> 
> > I replied to the 2 bug reports, let's hope we will get the ball
> > rolling again on them.
> 
> OK, I'll try to make a few final modifications and push them.

Thanks.

> > As for the patch posted here, I think it makes sense to make such
> > changes only if they are done in all modes.  Doing that only in one
> > major mode will only confuse people.  So if you'd like to pursue this
> > change (and I do think it would be a good change), please make the
> > change in a way that will produce similar behavior in all the other
> > modes with define their beginning-of-defun functionality.
> 
> I am not sure whether I understand.  The problem was specifically with
> lisp version of `beginning-of-defun'.  With other modes, there is a bit of
> a mess: some modes set `beginning-of-defun-function' (e.g. js-mode and
> js2-mode), some rebind C-M-a to their beginning-of-defun (e.g. c-mode).
> Now, other modes (again, I used c-mode and js2-mode for reference) do
> various things when arg=0 for beginning-of-defun - e.g. c-mode claims to
> go back to the current defun's header, js2-mode just pretends that arg
> is 1 etc.

I tried in Lisp and in C, and they both go up one line.

> Unifying that (1) might not be the best idea and (2) would require quite
> a lot of work for all Emacs built-in modes.

But if we do that only in Lisp, we just increase the mess, don't we?
I might be okay with fixing only a few popular modes, because that
will make the mess smaller, so it will be a step in the right
direction, even if we don't go all the way.

> I could try to do that, but this would take a bit.  Also, I do not know
> many of the languages involved, and I'd prefer not to touch their
> modes.

I don't expect you to need to know these languages, as
beginning-of-defun should already be well defined for them.

Re: A problem with old bugs

[John Wiegley]

>>>>> "MB" == Marcin Borkowski <mbork@mbork.pl> writes:

MB> I do understand the main reason (too few developers, the bugs were not
MB> critical), but I have to say that the situation isn't exactly motivating
MB> for me. I will try to continue work on some bugs for the next week or two,
MB> but I guess I'll stop then, since at this moment it doesn't feel to have a
MB> lot of sense anyway, and I have a lot of ways to spend my time in a
MB> meaningful way...

I'm sorry this was a discouraging experience for you, Marcin. Have things
moved forward yet?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2