On 13.05.22 17:55, Joel Sherrill wrote:
On Fri, May 13, 2022 at 10:42 AM Cedric Berger <ced...@precidata.com>
wrote:
On 13.05.22 17:25, Joel Sherrill wrote:
> I think you are missing my point. I'm not opposed to the patches
and
> understand the need.
>
> The RTEMS Project tried putting patches in our git repos when
the RSB
> was new. It did not improve our diligence in getting them
upstream or
> removing them from our git when no longer needed. Putting them in
> tickets at RTEMS.org or upstream improved how diligent we were
about
> at least putting the patch into the right hands.
Ok, I guess understand the need for a ticket on RTEMS.org.
What I'm not sure is what to do upstream: just open a ticket on
mpfr/isl/mpc that says "Please unslack and release a new version
of your
code, it doesn't work on the M1"?
lol. Probably just to politely remind them that their releases need a
poke.
If it's not fixed in their development source, then that's a big reason to
poke and provide the patch.
It's fixed, basically, for all 3 projects, if they would care to
regenerate+release:
https://git.savannah.gnu.org/cgit/config.git/commit/?id=3c20dd431e06337a8b49d8bf791a6a19523a34a4
https://git.savannah.gnu.org/cgit/config.git/commit/?id=2593751ef276497e312d7c4ce7fd049614c7bf80
But the ticket on our side can give a log of the effort to get it
dealt with
upstream.
That makes sense.
This also shows that we need to clean some patches out of the RSB
and RTEMS tools.
Sorry for the lesson in how we have evolved our handling of
patches for upstream projects. It has evolved from back when
the project provided RPMs and they almost never got upstream
to having the RSB and putting them in our repos to now trying to
do the right thing in the beginning and posting them to the project
via their list, a ticket, or via actual merge. If you notice, we have a
pretty tight loop for getting patches into newlib and gcc. binutils
rarely has issues. gdb is slower but we do ok. We've just learned that
if you push on them while working on them, they tend to get merged
so a patch against tool version N is usually obsolete for N+1. The
alternative is updating the patches every release until we do the
right thing.
No probem, I understand and it makes sense to put upstream, but again,
in that particular case, the real problem (autoconf) is already fixed
upstream.
Cedric
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
