This is the mail archive of the
mailing list for the GCC project.
+reminder+ Re: Make clear, when contributions will be ignored
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?
On Fri, 2018-12-07 at 10:55 +0000, Дилян Палаузов wrote:
> 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.
> 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.