Make claer, when contributions will be ignored

Make claer, when contributions will be ignored

[Дилян Палаузов]

Hello,

on 27th October I sent to gcc-patches a mail with the subject “Don’t
build gdb/readline/libreadline.a, when --with-system-readline is
supplied” and on 14th November I sent a reminder.  I got no answer. 
Before sending the emails I filled a bugzilla ticket.

Can you please make it clear, when contributions will be ignored, or
agree on some procedures, where all contributions are handled in
reasonable time withot reminders, in a way that the processes work
reliably.

If it is unclear, when work made by others will be neglected, and it is
not foreseenable when, then state this clearly this uncertainty.  If
somebody does not feel comfortable with such a statent, then make
something to make the statement superfluous.

Regards
  Дилян

Re: Make claer, when contributions will be ignored

[Segher Boessenkool]

Hi!

On Wed, Dec 05, 2018 at 07:36:09AM +0000, Дилян Палаузов wrote:
> on 27th October I sent to gcc-patches a mail with the subject “Don’t
> build gdb/readline/libreadline.a, when --with-system-readline is
> supplied”

The patch looks fine to me, fwiw.

> and on 14th November I sent a reminder.  I got no answer. 
> Before sending the emails I filled a bugzilla ticket.
> 
> Can you please make it clear, when contributions will be ignored, or
> agree on some procedures, where all contributions are handled in
> reasonable time withot reminders, in a way that the processes work
> reliably.

You can cc: people you think will be able to handle it.  You can ping
your patches regularly (say, every week).

Patches are usually ignored because everyone thinks someone else will
handle it.


Segher

Re: Make claer, when contributions will be ignored

[Maciej W. Rozycki]

On Wed, 5 Dec 2018, Дилян Палаузов wrote:

> Can you please make it clear, when contributions will be ignored, or
> agree on some procedures, where all contributions are handled in
> reasonable time withot reminders, in a way that the processes work
> reliably.

1. You do not have a contract in place that would guarantee you any 
   specific timelines; if you want that, then hire someone to do the
   maintainer's duties for you.

2. Maintainers are volunteers working on the best-effort basis, and
   have other duties.

3. <https://sourceware.org/gdb/wiki/ContributionChecklist#Ping_and_keep_pinging>

4. Wrong mailing list for GDB matters.

 HTH,

  Maciej

Re: Make claer, when contributions will be ignored

[Joseph Myers]

On Wed, 5 Dec 2018, Segher Boessenkool wrote:

> Patches are usually ignored because everyone thinks someone else will
> handle it.

And in this case, it looks like this patch would best be reviewed first in 
the GDB context - then once committed to binutils-gdb, the committer could 
post to gcc-patches (CC:ing build system maintainers) requesting a commit 
to GCC if they don't have write access to GCC themselves.  I consider 
synchronizing changes to such top-level files in either direction to be 
obvious and not to need a separate review.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello,

will it help, if Bugzilla is reprogrammed to send automatically weekly
reminders on all patches, that are not integrated yet?

Will lt help, if I hire myself to integrate the patch, or shall I
rather hire somebody to send reminders?

If something can be done after sending a reminder, then it can be
arranged also without reminders.  In particular, dealing with reminders
is avoidable extra work.

Whether people are paid or not, does not change on the subject very
much.  I have experienced organizations, where people are not paid and
they manage to tackle everything.  I have seen organizations where
people are paid and they do not get the management right.

I am not speaking about having some strict time to get a response, but
rather to ensure an answer in reasonable time.  No answer in reasonable
time is the same as ignorance — the subject of this thread.

The patch I proposed on 27th Oct was first submitted towards GDB and
then I was told to send it to GCC.  Here I was told to sent it to GDB. 
What shall happen to quit the loop?

In any case, if the common aim is to have a system where contributions
do not get lost, then I’m sure the workflows can be adjusted to achieve
this aim.

Regards
  Дилян


On Wed, 2018-12-05 at 17:37 +0000, Joseph Myers wrote:
> On Wed, 5 Dec 2018, Segher Boessenkool wrote:
> 
> > Patches are usually ignored because everyone thinks someone else will
> > handle it.
> 
> And in this case, it looks like this patch would best be reviewed first in 
> the GDB context - then once committed to binutils-gdb, the committer could 
> post to gcc-patches (CC:ing build system maintainers) requesting a commit 
> to GCC if they don't have write access to GCC themselves.  I consider 
> synchronizing changes to such top-level files in either direction to be 
> obvious and not to need a separate review.
> 

+reminder+ Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello,

what shall happen, so that no reminders are necessary to move things
forward?  Why does sending a reminder make a difference and are only
penetrant persons blessed?

Regards
  Дилян


On Fri, 2018-12-07 at 10:55 +0000, Дилян Палаузов wrote:
> Hello,
> 
> will it help, if Bugzilla is reprogrammed to send automatically weekly
> reminders on all patches, that are not integrated yet?
> 
> Will lt help, if I hire myself to integrate the patch, or shall I
> rather hire somebody to send reminders?
> 
> If something can be done after sending a reminder, then it can be
> arranged also without reminders.  In particular, dealing with reminders
> is avoidable extra work.
> 
> Whether people are paid or not, does not change on the subject very
> much.  I have experienced organizations, where people are not paid and
> they manage to tackle everything.  I have seen organizations where
> people are paid and they do not get the management right.
> 
> I am not speaking about having some strict time to get a response, but
> rather to ensure an answer in reasonable time.  No answer in reasonable
> time is the same as ignorance — the subject of this thread.
> 
> The patch I proposed on 27th Oct was first submitted towards GDB and
> then I was told to send it to GCC.  Here I was told to sent it to GDB. 
> What shall happen to quit the loop?
> 
> In any case, if the common aim is to have a system where contributions
> do not get lost, then I’m sure the workflows can be adjusted to achieve
> this aim.
> 
> Regards
>   Дилян
> 
> 
> On Wed, 2018-12-05 at 17:37 +0000, Joseph Myers wrote:
> > On Wed, 5 Dec 2018, Segher Boessenkool wrote:
> > 
> > > Patches are usually ignored because everyone thinks someone else will
> > > handle it.
> > 
> > And in this case, it looks like this patch would best be reviewed first in 
> > the GDB context - then once committed to binutils-gdb, the committer could 
> > post to gcc-patches (CC:ing build system maintainers) requesting a commit 
> > to GCC if they don't have write access to GCC themselves.  I consider 
> > synchronizing changes to such top-level files in either direction to be 
> > obvious and not to need a separate review.
> > 

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello,

the current way to come forward is to send biweekly manual reminders.

Will it help, if bugzilla is tweaked to send reminders every two weeks for ready-patches?  This also has the advantage,
that people will not have to once update a patch in BZ and then send it over gcc-patches.

Regards
  Дилян

On Fri, 2018-12-07 at 10:55 +0000, Дилян Палаузов wrote:
> Hello,
> 
> will it help, if Bugzilla is reprogrammed to send automatically weekly
> reminders on all patches, that are not integrated yet?
> 
> Will lt help, if I hire myself to integrate the patch, or shall I
> rather hire somebody to send reminders?
> 
> If something can be done after sending a reminder, then it can be
> arranged also without reminders.  In particular, dealing with reminders
> is avoidable extra work.
> 
> Whether people are paid or not, does not change on the subject very
> much.  I have experienced organizations, where people are not paid and
> they manage to tackle everything.  I have seen organizations where
> people are paid and they do not get the management right.
> 
> I am not speaking about having some strict time to get a response, but
> rather to ensure an answer in reasonable time.  No answer in reasonable
> time is the same as ignorance — the subject of this thread.
> 
> The patch I proposed on 27th Oct was first submitted towards GDB and
> then I was told to send it to GCC.  Here I was told to sent it to GDB. 
> What shall happen to quit the loop?
> 
> In any case, if the common aim is to have a system where contributions
> do not get lost, then I’m sure the workflows can be adjusted to achieve
> this aim.
> 
> Regards
>   Дилян
> 
> 
> On Wed, 2018-12-05 at 17:37 +0000, Joseph Myers wrote:
> > On Wed, 5 Dec 2018, Segher Boessenkool wrote:
> > 
> > > Patches are usually ignored because everyone thinks someone else will
> > > handle it.
> > 
> > And in this case, it looks like this patch would best be reviewed first in 
> > the GDB context - then once committed to binutils-gdb, the committer could 
> > post to gcc-patches (CC:ing build system maintainers) requesting a commit 
> > to GCC if they don't have write access to GCC themselves.  I consider 
> > synchronizing changes to such top-level files in either direction to be 
> > obvious and not to need a separate review.
> > 

Re: Make clear, when contributions will be ignored

[Joseph Myers]

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

On Tue, 5 Feb 2019, Дилян Палаузов wrote:

> Will it help, if bugzilla is tweaked to send reminders every two weeks 
> for ready-patches?  This also has the advantage, that people will not 
> have to once update a patch in BZ and then send it over gcc-patches.

For any proposed changes to patch submission / review processes to be 
helpful, they need to work with the existing development community, which 
means they need to be designed based on a deep understanding of what works 
for developers and reviewers, and of the issues likely to lead to lack of 
response on a submission (which can be that it doesn't fall clearly into 
any one maintainer's area, but can also be that the submission has 
deficiencies meaning it would take much longer to review than a 
well-formed submission, such as inadequate explanation, lack of testcases, 
lack of documentation, poor or missing comments, failure to follow the GNU 
Coding Standards, lack of ChangeLog entries, etc., and so is likely to be 
dropped unless a reviewer has more time than usual at the time the patch 
is posted).  A discussion at a future GNU Tools Cauldron would be better 
than on the gcc-patches list (which is for concrete discussion of 
individual patches, not meta-discussion of patch review processes).  I 
think an ongoing commitment from someone with sufficient experience with 
the community to maintain and develop any new tool used would also be 
required, as any existing tool in this area is unlikely to do well without 
significant customization.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

On Fri, Dec 07, 2018 at 10:55:11AM +0000, Дилян Палаузов wrote:
> will it help, if Bugzilla is reprogrammed to send automatically weekly
> reminders on all patches, that are not integrated yet?

No, that will not help.

If an interested party sends a friendly ping, that is of course welcome.
But automated pings are spam: unwanted bulk mail.

> The patch I proposed on 27th Oct was first submitted towards GDB and
> then I was told to send it to GCC.  Here I was told to sent it to GDB. 
> What shall happen to quit the loop?

You can cc: both sides of the discussion.  Either also gdb-patches, or also
whoever told you to send it to GCC instead, or both.  And include a link to
the mailing list archive of your thread on gdb-patches in your mail to
gcc-patches, so that all parties can see the relevant context.  Make it
easy for people to help you!


Segher

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello,

thanks to Serger and Joseph for the feedback.

Acting primary upon reminders is a general phenomenon in the society, nothing specific to software teams.  Think on
public administration: it acts sometimes much more collaboratively, if a public/private/famous media reports on the
workflows of the public administration.  Public administration also reacts sometimes only, if reminders are sent.

Not surprizing is, that talking with a public administration, about their policy on acting only after receiving a
reminder, leads to nowhere, as making progress on this discussion with such an administration, needs a lot of reminders.
In summary, such public administrations insist on their right to receive reminders before acting.

Do you share the opinion, that whatever can be done after receiving a reminder, can be arranged also without reminder? 
If yes, how do you propose to proceed, so that a no-reminders-are-necessary-state is reached?

I read in the answer of Segher, that the purpose of reminding is not only to ping, but also to filter the ones who are
pernetrant and sending manually reminders is the means to verify, that the persons really want to make progress.  It was
certainly not intentionally meant this way, but this is a possible reading.

Let me repeat, that the topic is not anyhow GCC specific, nor do I offend the society anyhow.  To make things better,
first the causes for the current state have to be understood.

Raising the topic on GNU Tools Cauldron is a very good idea, but it likely approaches less people than on this mailing
list, I am not that much inside the GCC processes and I do not know, whether I can visit the next meeting.

Regards
  Дилян

On Wed, 2019-02-06 at 06:44 -0600, Segher Boessenkool wrote:
> On Fri, Dec 07, 2018 at 10:55:11AM +0000, Дилян Палаузов wrote:
> > will it help, if Bugzilla is reprogrammed to send automatically weekly
> > reminders on all patches, that are not integrated yet?
> 
> No, that will not help.
> 
> If an interested party sends a friendly ping, that is of course welcome.
> But automated pings are spam: unwanted bulk mail.
> 
> > The patch I proposed on 27th Oct was first submitted towards GDB and
> > then I was told to send it to GCC.  Here I was told to sent it to GDB. 
> > What shall happen to quit the loop?
> 
> You can cc: both sides of the discussion.  Either also gdb-patches, or also
> whoever told you to send it to GCC instead, or both.  And include a link to
> the mailing list archive of your thread on gdb-patches in your mail to
> gcc-patches, so that all parties can see the relevant context.  Make it
> easy for people to help you!
> 
> 
> Segher

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

Hi Dilyan,

On Sun, Feb 10, 2019 at 02:45:02PM +0000, Дилян Палаузов wrote:
> Do you share the opinion, that whatever can be done after receiving a reminder, can be arranged also without reminder? 

Yes.  When people have time for it, they can trivially check what PRs are
still open that they are involved in.

> If yes, how do you propose to proceed, so that a no-reminders-are-necessary-state is reached?

Keep things as is?  Reminders already are not necessary.

If you want more attention given to the bugs you are involved in, you can
hire people to do that, or file reports for more interesting bugs, or make
your bug reports easier to work with.

Since GCC has one major release every year, handling less urgent bugs can
take up to a year as well.

> I read in the answer of Segher, that the purpose of reminding is not only to ping, but also to filter the ones who are
> pernetrant and sending manually reminders is the means to verify, that the persons really want to make progress.  It was
> certainly not intentionally meant this way, but this is a possible reading.

The point is that automated reminders for PRs *are spam*.


Segher

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello Segher,

the current procdure is:

-- write at https://gcc.gnu.org/bugzilla/
-- read an answer, that the update shall be posted to gcc-patches
-- subscribe to gcc-patches, post the change and wait for an answer.

This waiting is not for free.  There are a lot of emails, for the person might not be interested, but only waits for a
reply on the own email.  So after some time, I made filters sorting the emails from the mailing list, in order to make
the waiting cheaper.

-- at https://www.gnu.org/software/gcc/contribute.html is written “If you do not receive a response to a patch that you
have submitted within two weeks or so, it may be a good idea to chase it by sending a follow-up email to the same
list(s).”

Because it is written that reminders are..., I have sent a reminder.


> > If yes, how do you propose to proceed, so that a no-reminders-are-necessary-state is reached?
> 
> Keep things as is?  Reminders already are not necessary.
> 

This statement does not align with the aforementioned webpage.

The optimal way will be, if a bug/patch is filled in bugzilla and nothing more is necessary from the reporter.  Postgres
sends bugs collected over website over a mailing list.

Regards
  Дилян

On Sun, 2019-02-10 at 14:56 -0600, Segher Boessenkool wrote:
> Hi Dilyan,
> 
> On Sun, Feb 10, 2019 at 02:45:02PM +0000, Дилян Палаузов wrote:
> > Do you share the opinion, that whatever can be done after receiving a reminder, can be arranged also without reminder? 
> 
> Yes.  When people have time for it, they can trivially check what PRs are
> still open that they are involved in.
> 
> > If yes, how do you propose to proceed, so that a no-reminders-are-necessary-state is reached?
> 
> Keep things as is?  Reminders already are not necessary.
> 
> If you want more attention given to the bugs you are involved in, you can
> hire people to do that, or file reports for more interesting bugs, or make
> your bug reports easier to work with.
> 
> Since GCC has one major release every year, handling less urgent bugs can
> take up to a year as well.
> 
> > I read in the answer of Segher, that the purpose of reminding is not only to ping, but also to filter the ones who are
> > pernetrant and sending manually reminders is the means to verify, that the persons really want to make progress.  It was
> > certainly not intentionally meant this way, but this is a possible reading.
> 
> The point is that automated reminders for PRs *are spam*.
> 
> 
> Segher

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

On Mon, Feb 11, 2019 at 12:44:31PM +0000, Дилян Палаузов wrote:
> -- at https://www.gnu.org/software/gcc/contribute.html is written “If you do not receive a response to a patch that you
> have submitted within two weeks or so, it may be a good idea to chase it by sending a follow-up email to the same
> list(s).”

That is about patches.  Not about bugzilla.  Sending reminders for bugzilla
reports is useless and annoying.  Sending reminders for patches however is
necessary, the way our development works currently.  It isn't clear any
change to procedures would help at all, since the fundamental problems need
to be attacked to make any progress.  Maintainers do not have infinite time,
and there is no incentive to deal with high-cost low-profit patches.


Segher

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello Segher,

my question was how do you propose to proceed, so that a no-reminders-for-patches-are-necessary-state is reached.

There is no relation with having infinite time or dealing with high-cost low-profit patches.

Previously I raised the quesion, whether automating the process for sending reminders, is a good idea.  This saves time
of people to write reminders.

Greetings
  Дилян

On Mon, 2019-02-11 at 07:57 -0600, Segher Boessenkool wrote:
> On Mon, Feb 11, 2019 at 12:44:31PM +0000, Дилян Палаузов wrote:
> > -- at https://www.gnu.org/software/gcc/contribute.html is written “If you do not receive a response to a patch that you
> > have submitted within two weeks or so, it may be a good idea to chase it by sending a follow-up email to the same
> > list(s).”
> 
> That is about patches.  Not about bugzilla.  Sending reminders for bugzilla
> reports is useless and annoying.  Sending reminders for patches however is
> necessary, the way our development works currently.  It isn't clear any
> change to procedures would help at all, since the fundamental problems need
> to be attacked to make any progress.  Maintainers do not have infinite time,
> and there is no incentive to deal with high-cost low-profit patches.
> 
> 
> Segher

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

On Mon, Feb 11, 2019 at 02:16:27PM +0000, Дилян Палаузов wrote:
> Hello Segher,
> 
> my question was how do you propose to proceed, so that a no-reminders-for-patches-are-necessary-state is reached.
> 
> There is no relation with having infinite time or dealing with high-cost low-profit patches.
> 
> Previously I raised the quesion, whether automating the process for sending reminders, is a good idea.  This saves time
> of people to write reminders.

But that would be "optimising" exactly the wrong thing!  The choke point is
patch review.  So you should make it easier to review a patch, instead of
making it easier to send in more patches.  Your complaint is that many
patches are sent in but then not reviewed, or not reviewed for a long while,
after all.

Easy to review patches are of course first and foremost patches that do the
correct thing.  But also they need to clearly say what they fix (and how),
how the patch was tested, and they should often contain testcases for the
testsuite.  Easy to review patches usually use the same style and
presentation as all other easy to review patches.


Segher

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello Segher,

your prompt answer is appreciated.

As a matter of fact patches are not reviewed for whatever reason in reasonable time.

My point is to reorgnize the approach in such a way, that sending reminders gets irrelevant (has no impact) and
therefore not necessary.

Currently priority is given to submitters who send reminders, irrespective of the properties a patch has.

Regards
  Дилян

On Mon, 2019-02-11 at 10:22 -0600, Segher Boessenkool wrote:
> On Mon, Feb 11, 2019 at 02:16:27PM +0000, Дилян Палаузов wrote:
> > Hello Segher,
> > 
> > my question was how do you propose to proceed, so that a no-reminders-for-patches-are-necessary-state is reached.
> > 
> > There is no relation with having infinite time or dealing with high-cost low-profit patches.
> > 
> > Previously I raised the quesion, whether automating the process for sending reminders, is a good idea.  This saves time
> > of people to write reminders.
> 
> But that would be "optimising" exactly the wrong thing!  The choke point is
> patch review.  So you should make it easier to review a patch, instead of
> making it easier to send in more patches.  Your complaint is that many
> patches are sent in but then not reviewed, or not reviewed for a long while,
> after all.
> 
> Easy to review patches are of course first and foremost patches that do the
> correct thing.  But also they need to clearly say what they fix (and how),
> how the patch was tested, and they should often contain testcases for the
> testsuite.  Easy to review patches usually use the same style and
> presentation as all other easy to review patches.
> 
> 
> Segher

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

On Sun, Feb 17, 2019 at 04:59:40PM +0000, Дилян Палаузов wrote:
> As a matter of fact patches are not reviewed for whatever reason in reasonable time.

Yes.  This is an age-old problem.

> My point is to reorgnize the approach in such a way, that sending reminders gets irrelevant (has no impact) and
> therefore not necessary.
> 
> Currently priority is given to submitters who send reminders, irrespective of the properties a patch has.

No, that is not true for many reviewers.  It is however true that patches
that are *not* pinged (say, once a week) often are forgotten, or the
maintainer assumes the patch is not wanted anymore, etc.


Segher

Re: Make clear, when contributions will be ignored

[Дилян Палаузов]

Hello Segher,

On Sun, 2019-02-17 at 13:09 -0600, Segher Boessenkool wrote:
> On Sun, Feb 17, 2019 at 04:59:40PM +0000, Дилян Палаузов wrote:
> > My point is to reorgnize the approach in such a way, that sending reminders gets irrelevant (has no impact) and
> > therefore not necessary.
> > 
> > Currently priority is given to submitters who send reminders, irrespective of the properties a patch has.
> 
> No, that is not true for many reviewers.  It is however true that patches
> that are *not* pinged (say, once a week) often are forgotten, or the
> maintainer assumes the patch is not wanted anymore, etc.

The assumption that an unpinged patch is not wanted any more is obviously wrong.  The assumption shall be, that people
who do not send reminders have not read, that they are supposed to send reminers, as these people assume that sending
reminders makes no difference.

If this is not true for many reviewers, why does sending reminder then make a difference and the webpage advices to send
reminders?  

To sum up, sending a reminder on a subject and the subject (patch being good/bad/excellent/inappropriate/messy) are two
different things.  I am talking here about the necessity for sending reminders, irrespective of the subject/properties a
patch has.

Regards
  Дилян