Submission Policies
The
cppget.org repository accepts open
source and source-available
build2
packages. Its submission
policies try to achieve a balance between the quality of packages and ease
of submission (if you are familiar with the Debian package repository, you
will notice many similarities). It is recommended (but not required) that
newly-created packages (as opposed to packages of existing/third-party
projects) follow the
Canonical
Project Structure.
Each submitted package is first added to queue.cppget.org where it is automatically tested in a number of build configurations.
Provided the package successfully builds on at least one
platform/compiler combination, it is moved to the
testing
section of the
cppget.org repository where
it can be further tested by interested users as well as reviewed. After some
time, it is moved to the
stable
section provided the following
conditions are met:
- The package has at least one positive review that was performed by an
experienced
build2
user. - There are no serious issues reported with the package based on further testing.
See Package Review for details.
Once in
stable
, the package will be continuously built and
tested in an evolving set of build configurations. If a package in the
stable
section no longer builds on at least one
platform/compiler combination (for example, because it is no longer
maintained), then it is moved to the
legacy
section where it is
no longer tested.
Other key points to keep in mind when submitting a package to cppget.org:
-
Packages are in the source code form.
Packages can use any free/open source or source-available license. The only requirement is that they are built from source.
-
Package names are on a first come first serve basis.
Name squatting, however, is prohibited. If you submit a package without any useful functionality in order to reserve a name, it will be removed and you will be banned.
-
Package submissions are public and permanent.
Specifically, packages in the
stable
andlegacy
sections cannot be removed under any circumstances.Note also that package submissions include your name and email address which will become a part of the public submission record that cannot be altered.
The recommended way to submit a package is with the
bdep-publish(1)
command. See the
Toolchain
Introduction for how it fits into the overall development workflow.
Specifically, it is a good idea to make use of the
CI Service before submitting.
The changes to the
queue.cppget.org and
cppget.org archive repositories are tracked in
the corresponding
git
repositories:
git.cppget.org/queue (mirror:
github.com/cppget/queue) and
git.cppget.org/public
(mirror:
github.com/cppget/public). For
the submission service protocol description see
Package
Submission.