At all points in time, unless someone screws ups, the following invariant should hold. Most of the workflow follows directly from keeping this in mind.
For a package,
- the version on hackage
- ≥ the version on the tracked Stackage release (if applicable¹)
- = the version in the package plan
- ≥ the version in the VCS (version of the youngest changelog entry)
- ≥ the version of the tag in the VCS
- ≥² the version of the package in the archive
- ¹ occasional we have to diverge from Stackage, but it should be the exception, and will have to be marked explicitly in the package plan.
- ² should be = unless the upload failed, is stuck in NEW, or got rejected.
For all pkg-haskell maintained packages, the Maintainer: field will be set to
Maintainer: Debian Haskell Group <firstname.lastname@example.org>
The Uploaders: field contains those members, who care for this package. This means that when a member wishes to share maintenance responsibility for a package, he puts himself into the Uploaders-field. This does not include sponsors. Members can also remove themselves from the list, but of course they have to wait for the next upload for the change to take effect.
Rationale: There will be situations where team members upload packages but do not wish to undertake any maintenance burden, so they will not put themselves in Uploaders:. Uploads will be considered an NMU, but this is only informational. The benefit of this is that contributors' DDPO pages reflect the packages they care about. Additionally, the Uploaders: field reflects who can be called upon in the event something needs to be done with a package.
All pkg-haskell maintained packages have the Vcs-*-fields set, for example:
Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git Vcs-Browser: https://salsa.debian.org/haskell-team/DHG_packages/tree/master/p/haskell-x11
or, for darcs:
Vcs-Darcs: http://darcs.debian.org/darcs/pkg-haskell/haskell-x11 Vcs-Browser: http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/haskell-x11
Changelog handling and upload management
Here, we follow the procedure as used by the Debian Perl Group:
While working on a package, the distribution field of the changelog is set to UNRELEASED.
When a group member considers the state of the package fit for release, he changes that to unstable and commits it.
- To avoid delays, a non-uploading group member might want to notify the group about this (e.g. on the mailing list or on IRC).
- A Debian Developer then builds the package and uploads it.
- If everything went well, he creates a tag (named after the uploaded version) and pushes it to the repository.
If something is not yet good about the package, the DD will set the distribution back to UNRELEASED and tell the group member, why he did that.
So these three states exist:
Distribution set to UNRELEASED, no tag with the current version: Package is work-in-process, should not be uploaded at this point.
Distribution set to unstable, no tag with the current version: Package is ready to be uploaded.
Distribution set to unstable, a tag with the current version: Package was uploaded, and no changes were done since the upload.
The package entropy tracker follows these semantics and gives a good overview about packages to be uploaded.