[Haskell-cafe] Re: Handling absent maintainers
2010/8/17 Geoffrey Mainland mainl...@eecs.harvard.edu: On 08/17/2010 12:28, Ben Millwood wrote: 2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course. Geoff I imagine maintaining compatibility across template-haskell versions might be tricky. Prior to template-haskell-2.4.0.0, I believe there was no TH support for kinds, and class contexts were simply Types rebranded (not supporting equality constraints). So some not-inconsiderable sections of code would need duplication, or we'd need to deal with CPP which always struck me as a fragile and inelegant solution. Of course, I welcome the patches to prove me wrong :) or well, if you just want to take maintainership yourself, the package is really as much yours as it is mine at this stage. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I can upload a working .4 version of th-lift if needed, but I guess it might be undesirable to depend on it if 0.5 changes the API. I'll have a look at your version and see if I can merge my additions into it. For now, perhaps somebody should re-upload the current version of src-meta with the correct dependencies (TH2.4)? 2010/8/17 Ben Millwood hask...@benmachine.co.uk: 2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
It's a bad call to put any version restriction on the template haskell package in your package description - the cabal solver will still go for the latest version of your package and then try to install the listed version of template haskell from Hackage, which leads to confusing errors. Even if you try to use the version of template haskell to set a flag in your package description, cabal-install will always form an install plan based on the default value of your flag (leaving someone out). Antoine On Aug 18, 2010 3:59 AM, Jonas Almström Duregård jonas.dureg...@gmail.com wrote: I had been in contact with the maintainer of the package who has prepared a version 0.5 and was ... I can upload a working .4 version of th-lift if needed, but I guess it might be undesirable to depend on it if 0.5 changes the API. I'll have a look at your version and see if I can merge my additions into it. For now, perhaps somebody should re-upload the current version of src-meta with the correct dependencies (TH2.4)? 2010/8/17 Ben Millwood hask...@benmachine.co.uk: 2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any prog... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling absent maintainers
On 08/18/2010 02:25, Ben Millwood wrote: 2010/8/17 Geoffrey Mainland mainl...@eecs.harvard.edu: On 08/17/2010 12:28, Ben Millwood wrote: 2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course. Geoff I imagine maintaining compatibility across template-haskell versions might be tricky. Prior to template-haskell-2.4.0.0, I believe there was no TH support for kinds, and class contexts were simply Types rebranded (not supporting equality constraints). So some not-inconsiderable sections of code would need duplication, or we'd need to deal with CPP which always struck me as a fragile and inelegant solution. Of course, I welcome the patches to prove me wrong :) or well, if you just want to take maintainership yourself, the package is really as much yours as it is mine at this stage. Ben I have patches that main compatibility with 6.10, but now that haskell-src-meta depends of th-lift, which requires template-haskell=2.4, I think it's a lost cause. Versioning for template-haskell makes things a real mess now---if I want a package using haskell-src-meta to work on both 6.10 and 6.12, I basically have to test the version of GHC being used and set package dependencies appropriately. Unless someone has a better way? Geoff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas On 5 August 2010 19:38, Ben Millwood hask...@benmachine.co.uk wrote: On Thu, Aug 5, 2010 at 5:07 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust. The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using. Erik It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them, and they can presumably just as easily be revoked. Thanks Mark, I'll request a Hackage account within the next couple of days and then make the upload. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling absent maintainers
On 08/17/2010 12:28, Ben Millwood wrote: 2010/8/17 Jonas Almström Duregård jonas.dureg...@gmail.com: Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course. Geoff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Thu, Aug 5, 2010 at 5:07 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust. The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using. Erik It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them, and they can presumably just as easily be revoked. Thanks Mark, I'll request a Hackage account within the next couple of days and then make the upload. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Thu, Aug 5, 2010 at 6:38 PM, Ben Millwood hask...@benmachine.co.uk wrote: It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them Er, to clarify, I mean signup can't be automated, because account creation is done by a human. Not that hackage charges for accounts or something. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Wed, Aug 4, 2010 at 1:36 AM, Ben Millwood hask...@benmachine.co.uk wrote: On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton mwot...@gmail.com wrote: I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package I'm happy to let you do it, I don't understand much of the actual source. Not sure who's the grand gatekeeper of Hackage, though. Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On 5 August 2010 13:32, Mark Wotton mwot...@gmail.com wrote: On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings. Well, I'd like to see the code required to spontaneously create monkeys at an ethernet port, but from what I've read Hackage has no constraints in place in terms of who uploads what and when. You just can't upload something with a version that's already on Hackage. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
Ivan Lazar Miljenovic wrote: On 5 August 2010 13:32, Mark Wotton mwot...@gmail.com wrote: On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings. Well, I'd like to see the code required to spontaneously create monkeys at an ethernet port, but from what I've read Hackage has no constraints in place in terms of who uploads what and when. You just can't upload something with a version that's already on Hackage. The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust. The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton mwot...@gmail.com wrote: I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling absent maintainers
On Fri, Jul 16, 2010 at 10:54 AM, Mark Wotton mwot...@gmail.com wrote: Hello all, I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our one-world approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it. I can think of a few ways to get around my current problems: 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though. I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
