遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/6011)
<a href="https://www.bestpractices.dev/projects/6011"><img src="https://www.bestpractices.dev/projects/6011/badge"></a>
GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system.
https://gitlab.gnome.org/GNOME/glib/-/blob/main/CONTRIBUTING.md
https://gitlab.gnome.org/GNOME/glib/-/blob/main/CODE_OF_CONDUCT.md?ref_type=heads
GLib, and all of its supporting infrastructure (such as the documentation website, tarball hosting, git hosting, etc.) is hosted by the GNOME Project on https://gitlab.gnome.org. This hosting is supported by the GNOME Foundation’s sysadmin team, which has a handover and restore procedure for if someone disappears. In the worst case, if the entire busload of GLib maintainers were to disappear, the sysadmin team would be able to hand the keys over to some other suitably trusted member of the GNOME community.
The project currently (as of April 2024) has 19 people with maintainer access (see the <maintainer> elements in https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib.doap?ref_type=heads). Some of them are more active than others, but they are all trusted to do maintainer tasks.
<maintainer>
Upcoming releases are planned as GitLab milestones (https://gitlab.gnome.org/GNOME/glib/-/milestones). These list issues/tasks which are definitely planned to go into an upcoming release. Typically this planning is done on a 6-monthly timescale rather than a 12-monthly timescale.
While GLib is a utility library, and therefore more of a collection of APIs than something with a high-level design, it does have detailed documentation of those APIs: https://docs.gtk.org/glib/
GLib is a utility library, not a user application. There is no one single thing which most users will want to start with when they first link GLib into their code.
The documentation is built from comments in the source code (https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/reference/glib/meson.build?ref_type=heads). These comments are next to each function definition, so it’s easy to keep them up to date as functions change or as bugs are fixed.
Best Practices badge shown at the top of https://gitlab.gnome.org/GNOME/glib
GLib is a system library, and does not have a user interface (graphical or otherwise).
All user-visible strings produced by GLib are translatable, and translations exist for tens of languages. The translations are in https://gitlab.gnome.org/GNOME/glib/-/tree/main/po?ref_type=heads, and the current translation statistics are at https://l10n.gnome.org/module/glib/.
GLib is hosted on GitLab (https://gitlab.gnome.org/GNOME/glib/) and GitLab meets this requirement.
https://gitlab.gnome.org/GNOME/glib/-/issues
The names of reporters are logged in GitLab alongside the vulnerability report, which is always labelled with label ‘1. Security’. So the names can be found by searching the issue list: https://gitlab.gnome.org/GNOME/glib/-/issues/?sort=created_date&state=closed&label_name%5B%5D=1.%20Security&first_page_size=20
https://gitlab.gnome.org/GNOME/glib/-/blob/main/SECURITY.md?ref_type=heads#user-content-reporting-a-vulnerability
In as much as clang-format can support the coding style in GLib (which is not perfectly), it is checked for every merge request using a CI job which is allowed to fail: https://gitlab.gnome.org/GNOME/glib/-/blob/main/.gitlab-ci/run-style-check-diff.sh?ref_type=heads
GLib uses Meson, and Meson honours these flags (https://mesonbuild.com/Reference-tables.html#compiler-and-linker-flag-environment-variables).
GLib uses Meson, and Meson does this.
Glib uses Meson, and Meson handles dependency trees correctly. Builds all start from the top level, and cannot be done on individual subdirectories.
GLib is regularly tested by the reproducible-builds project and has consistently reproducible builds: https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/glib2.0.html
GLib uses Meson. Meson allows installation using meson install (https://mesonbuild.com/Installing.html) and uninstallation using meson uninstall.
meson install
meson uninstall
GLib uses Meson, and Meson supports DESTDIR (https://mesonbuild.com/Installing.html#destdir-support).
DESTDIR
All dependencies are declared using the dependency() function in Meson. For example: https://gitlab.gnome.org/GNOME/glib/-/blob/5c8fbc3cdafabea3e2e188bd5a23c7028b1acc8d/meson.build#L2184
dependency()
https://gitlab.gnome.org/GNOME/glib/-/blob/main/CONTRIBUTING.md#user-content-features-and-enhancements
warning_level=3 is Meson’s highest level of warnings: https://gitlab.gnome.org/GNOME/glib/-/blob/1dfea6bc9312a5367f603d4cf3c68e0c54084d41/meson.build#L7
warning_level=3
I think Coverity does?
oss-fuzz is run on GLib: https://gitlab.gnome.org/GNOME/glib/-/blob/main/fuzzing/README.md valgrind’s memcheck tool is run on the unit tests in GLib weekly: https://gitlab.gnome.org/GNOME/glib/-/blob/main/.gitlab-ci.yml#L222
后退