Re: haskell-debian vs. newest HaXml
Joachim Breitner wrote: > Hi, > > Am Freitag, den 11.09.2009, 15:05 +0100 schrieb Iain Lane: > > So I would recommend that we roll back until the new series is > > declared stable and rdepends start migrating to the new API. I also > > hope that upstream can make this situation more manifest on their > > hackage page - having `cabal install haxml' install an unstable > > version is surely an undesirable situation. > > so would everyone be happy with this solution? Then we can do an > haxml-1.13 upload with bumped epoch and leave it like this for now. I'll do an haxml 1.13 a bumped epoch version over the next couple of days. However, I have no idea how I should handle this in Darcs. The obvious way is just commit 1.13 changes over the top of 1.19 (which is tagged as 1.19) so that when it comes to go back to 1.19 we can just grab the tag and tweak a little. Any other suggestions that may fit this problem better? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: haskell-debian vs. newest HaXml
Hi, On 14 Sep 2009, at 12:11, Erik de Castro Lopo wrote: The obvious way is just commit 1.13 changes over the top of 1.19 (which is tagged as 1.19) so that when it comes to go back to 1.19 we can just grab the tag and tweak a little. This seems fine. It's just a special case of a new upstream release. Regards, Iain This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: haskell-debian vs. newest HaXml
Hi, Am Montag, den 14.09.2009, 21:11 +1000 schrieb Erik de Castro Lopo: > > Am Freitag, den 11.09.2009, 15:05 +0100 schrieb Iain Lane: > > > So I would recommend that we roll back until the new series is > > > declared stable and rdepends start migrating to the new API. I also > > > hope that upstream can make this situation more manifest on their > > > hackage page - having `cabal install haxml' install an unstable > > > version is surely an undesirable situation. > > > > so would everyone be happy with this solution? Then we can do an > > haxml-1.13 upload with bumped epoch and leave it like this for now. > > I'll do an haxml 1.13 a bumped epoch version over the next couple > of days. > > However, I have no idea how I should handle this in Darcs. The obvious > way is just commit 1.13 changes over the top of 1.19 (which is tagged > as 1.19) so that when it comes to go back to 1.19 we can just grab > the tag and tweak a little. > > Any other suggestions that may fit this problem better? Should be fine. I guess most of your modifications in the last upload are independent of the upstream version anyways. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: haskell-debian vs. newest HaXml
Well, I dislike epochs, since we can never get rid of them. It is my feeling that we are going to need to provide both HaXml 1.13 and 1.20 because many library authors won't bother to upgrade something that has been working fine for the last 4 years. Last time I checked, the migration was somewhat involved. The types and constructors have an additional argument, so pretty much every type signature needs to be updated, and other functions need extra arguments. I expect that none, or almost no code will compile as-is with 1.20. If that is true, then I would be happy with leaving the current HaXml upload alone and creating libghc6-haxml13-dev and having packages depend on that if they want the old API. Upsides: - probably have to do it eventually anyway - avoids adding an epoch for the rest of time Downside: - requires significantly more work now. (Though, we make up for it in the long run?) - jeremy On Sep 11, 2009, at 5:15 PM, Joachim Breitner wrote: Hi, Am Freitag, den 11.09.2009, 15:05 +0100 schrieb Iain Lane: So I would recommend that we roll back until the new series is declared stable and rdepends start migrating to the new API. I also hope that upstream can make this situation more manifest on their hackage page - having `cabal install haxml' install an unstable version is surely an undesirable situation. so would everyone be happy with this solution? Then we can do an haxml-1.13 upload with bumped epoch and leave it like this for now. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: haskell-debian vs. newest HaXml
Hi, Am Montag, den 14.09.2009, 14:40 -0500 schrieb Jeremy Shaw: > I dislike epochs, since we can never get rid of them. I do agree here. > Last time I checked, the migration was somewhat involved. The types > and constructors have an additional argument, so pretty much every > type signature needs to be updated, and other functions need extra > arguments. I’m not the most experienced Haskell programmer, but that does not sound too involved to me. It sounds rather like a case of: For each additional argument (type or function), I obviously don’t need it, because my code works, so find out the proper default, add it, and when the code compiles again I’m done. It might be tedious (for all the type sigs), but not involved in the sense that it requires big, non-local code changes. I’d really like to hear from someone who is using HaXml in his code and has done the migration, or at least understood the implications, to tell us how hard it is. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: haskell-debian vs. newest HaXml
On Sep 14, 2009, at 2:47 PM, Joachim Breitner wrote: Hi, I’m not the most experienced Haskell programmer, but that does not sound too involved to me. It sounds rather like a case of: For each additional argument (type or function), I obviously don’t need it, because my code works, so find out the proper default, add it, and when the code compiles again I’m done. It might be tedious (for all the type sigs), but not involved in the sense that it requires big, non-local code changes. Yeah, it's mostly just tedious. There are two approaches Debian can take: 1. provide both APIs and compile each library/app against the API that it requires. Leave the choice of which API to use up to the upstream maintainers. 2. invest the man power to migrate all apps/libraries to the new API and then continue to maintain these modifications until the upstream maintainers decide to migrate as well. Option 2 seems like more work (for Debian) than option 1, and I am not clear what benefits it brings besides having only one version of HaXml in Debian. Additionally, as John Goerzen pointed out, many people use the HaXml package from Debian to build stuff that is not in Debian. As one of those people, I would greatly prefer to be able to apt-get install HaXml 1.13 and 1.20 at the same time so that I can migrate code on my own schedule, or, in some cases, not at all. So option 2 also seems like more work for Debian's users as well. The 1.13.x series is stable, has been for years, and is not likely to require a lot of updates. The primary reason for using the newer versions of HaXml is if you want the new features it offers, not because it is less buggy. It is my belief that once a new stable version of HaXml comes out, people will be slow to migrate. It is very easy in cabal to just depend on < 14, and there is little motivation to upgrade. I think the demand for the newer version of HaXml will come from new apps or libraries that want to use the new features (such as it's SAX style parser). - jeremy -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: haskell-debian vs. newest HaXml
Jeremy Shaw wrote: > If that is true, then I would be happy with leaving the current HaXml > upload alone and creating libghc6-haxml13-dev and having packages > depend on that if they want the old API. I also prefer this option but that would require all apps that currently have Build-Depends on libghc6-haxml-dev to chaneg that to the haxml13 version. > Downside: > - requires significantly more work now. (Though, we make up for it > in the long run?) >From where we are now, adding the epoch vs hasml13 is about the same amount of work. I think the biggest difficulty we're going to have is finding consensus on which fix we choose :-). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-haskell-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
