On 2016-05-23 10:05:21, Joachim Breitner wrote: > Hi, > > this blog post is relevant for us: > https://unknownparallel.wordpress.com/2016/05/22/stackage-lts-and-ghc-8 > -0/ > > This suits us quite well. Here is what I propose: > > * We busily update packages to Stackage nightly, and upload to > unstable. > * When LTS 6 is released, we upgrade packages to that, and then freeze > Haskell, so that is stabilizes and migrates to testing. > * Mumble mumble (see below) > * When LTS 7 is released, we upload GHC 8 to unstable, upgrade > packages to LTS 7, and work hard to get it into testing before > the Debian freeze. This part of the plan sounds good… :) > The mumble mumble phase allows for two options (we don’t have to decide > on that until then): > > A: We track Stackge Nightly and GHC-8 only in our git repository, Not even in experimental? I fear this is a too conservative plan, hiding problems for a longer time (as you say below). > using "dht make-all" etc. to figure out what is amiss. We > do not upload to unstable until LTS 7 is released and > everything works when we build it; then we upload everything > in one go. This minimizes breakage in unstable, and in the mean- > time we can still fix issues in testing via uploads to unstable > > B: We track Stackage Nightly and GHC-8 in unstable. This way, we know > about arch-specific problems earlier, but unstable is broken (for a > long time, I fear) and we cannot upload fixes meant for testing. What kind of fixes-for-testing are you thinking about? And what kind of "unstable-is-broken" breakage are you expecting? > Question: How close are we to getting the current set of packages into > testing? Should we wait for that (possibly staging the next set of > uploads in our git repository?) +1. > PS: PPAs would help... And +1 :) iustin
Attachment:
signature.asc
Description: PGP signature