Make claer, when contributions will be ignored

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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
  Дилян

Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Make claer, when contributions will be ignored

Maciej W. Rozycki
In reply to this post by Дилян Палаузов
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
Reply | Threaded
Open this post in threaded view
|

Re: Make claer, when contributions will be ignored

Joseph Myers
In reply to this post by Segher Boessenkool
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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