bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH][gnulib] Add the Sframe package


From: Bruno Haible
Subject: Re: [PATCH][gnulib] Add the Sframe package
Date: Sat, 19 Nov 2022 12:48:43 +0100

Weimin Pan wrote:
> But the SFrame package that we'd like to be included in Gnulib
> does not subsume or rely on either libbacktrace or libunwind. Maybe
> I'm missing something here?

That's not the major argument.

Considerations that make Jeffrey and me think that the Sframe code should
better be kept in a git repository separate from Gnulib are:

  * Amount of expected maintenance: In Gnulib, we try to avoid code that
    is CPU/arch specific. We can't avoid it in all cases (e.g. float.in.h,
    asyncsafe-spin.c), but in general we avoid it because there are about
    20 arches to consider, and that makes up for a lot of code and testing.

  * Responsibility for long-term maintenance: Often contributors are no
    longer doing the same kind of development 3 years later, but the code
    needs to be maintained. We would prefer if this code were to be in
    the responsibility of people near to the binutils people, rather than
    us (the Gnulib people).

  * Policy differences: binutils has a bug tracker, whereas Gnulib has a
    mailing list only. Tabs vs. spaces for indentation. Scope of code reviews.
    Maybe more.

  * Practical considerations: The binutils people surely have specialized
    methodology for testing something on 20+ architectures. In Gnulib we
    don't have the same methodology; we just run things under valgrind for
    one platform and generally that's sufficient.

For this reason I proposed a separate git repository, and to access it
through the gnulib-tool option '--local-dir', that is documented in
https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]