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. But the ticket on our side can give a log of the effort to get it dealt with upstream. 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. --joel > > Cedric > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel