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

Debian Haskell Policy and group procedures



Hi,

I want to take the creation of the Debian Haskell Group as chance to
bring up the issue of the Debian Haskell Policy. Linked from
http://wiki.debian.org/Haskell and other places is this document:
http://urchin.earth.li/~ian/haskell-policy/haskell-policy.html/index.html
which has not been updated since 2005 and does not current common
practice any more, such as the use of haskell-devscripts, the new
mailing list and probably other stuff that a newcomer should know.

Does anyone volunteer to do the initial overhauling and extending?

Ian, if you are reading this, is it ok for you when the group takes over
the document, and moves it to pkg-haskell.a.d.o? Would you be so kind to
remove it from your place to avoid confusion?


Also, what will our workflow be? One possibility is the following,
starting at the point where the git repository reflects the package in
the archive

 1 Member makes first changes. Runs debchange (with --release-heuristic 
   set to changelog), thus creating a new, UNRELEASED, changelog entry, 
   and commits that.
 2 Step 1 is repeated (including the import of new upstream versions)
 3 Member sees package fit for release, runs "debchange -r unstable", 
   sets NO git tag
 4 If member is not a DD: Sends mail to d-haskell, saying which package
   needs to be sponsored. Sponsor checkouts out the package, builds and
   uploads. The sponsor sets the tag.
 5 Someone (The sponsor? Or the person initiating the upload?) requests 
   binNMUs for all depending packages.

The debatable details are:
 * Who sets the release to unstable, and when? 
 * Who sets the git tag and when?
With the proposed scheme, the release in the changelog indicates the
desired state (package ought to be uploaded), while the tag indicates
the real state (this is the state that has been uploaded).
 * Who works out the binNMU requests?
Until we have a tool that does it for us, we need to do that by hand.
I’d say the member should prepare that, just as he prepares the rest of
the upload. But the request should not be sent to d-release until the
upload is made. I’d say that when a non-DD prepares a package, he
assembles the binNMU commands and includes them in the request for
sponsoring. The sponsor then sends it to d-release when he does the
upload.

What do you think of that?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Reply to: