This is the mail archive of the 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: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to test

Manuel Lpez-Ibñez <> writes:
> Another question is how to help existing maintainers such that they
> are more motivated to review patches. Is it a lack of time? lack of
> Interest in the project? do patches simply fall through the cracks? is
> it a dead-lock of people waiting for each other to comment?

In my case, I became a build/libiberty maintainer a long time ago (20
years or so), when DJGPP was a much more active project, and it made
sense for me to be involved in parts of GCC that were sensitve to the
needs of DOS and NTFS filesystems and OSs.  This is not the case any
more, and my justification for maintaining those parts of gcc have
evaporated.  Fortunately, a very minimal effort was involved to
continue.  However, since then, I've not only taken on maintainerships
in other areas (mostly backends, which I need to wean off of eventually)
but I've also switched groups at work, and am no longer focused on gcc
(I'm focused on glibc now).

Also, I've always been opposed to libiberty being a "catch-all" for
cross-useful functionality, so I'm anti-motivated to work on those
portions of libiberty that aren't strictly portability-layer-related
(specifically, the demangler, which I leave to Ian).

So... considering your big-picture-problem, where do I fit in?  How can
I make the big picture better, given what you now know about my
situtation?  What changes do you think would make sense?

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