This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]