What should we do with iceweasel/xulrunner/libmozjs?
Hi, Now that squeeze is released, it's time to start pushing new things to unstable. I've been asked several times already how things would be evolving in the near future, to which I answered it would quite stay the way it is now until upstream releases 4.0, at which point I'd upload 4.0 to unstable. But that might change. And I'm hereby requesting feedback on what fellow developers (especially maintainers of the various reverse dependencies) think about them. Here are some of the available options: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Pros: More exposure for the 3.6 and 4.0 packages. Cons: More work for reverse dependencies, which would be made to build and work with 3.6 and then again with 4.0 in a few weeks. Last time I checked (which was 3 months ago), 4.0 doesn't work on s390, sparc and ia64, which would make problems. - Keep things the way they are (3.5 in unstable, 3.6 in experimental, 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's released. Pros: we don't need to make sure everything in unstable builds and works properly with 3.6 before doing the work again with 4.0 in a month or so. Cons: Broken architectures with 4.0. - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. Pros: We don't break anything in testing/unstable, and we don't have to deal immediately with the broken architectures. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. - Keep everything in place, prepare rdeps to build and work with 4.0, and push 4.0 to unstable when everything is ready. Pros: We don't break anything in testing/unstable, and when 4.0 lands on unstable, nothing breaks either. Cons: Past experience shows that it takes a lot of time to fix rdeps. My gut feeling is that breaking things in unstable would create an incentive to fix, which doesn't exist when the package is in experimental or worse, outside the archive. - Suggest your own if you have better ideas (really, I mean it). As I mentioned above, my initial idea was to go with the second option, breaking most rdeps in the process, but then I remembered that 4.0 doesn't work on all our architectures, and I'm hesitating, now. So, fellow developers, what do you think? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218091242.ga4...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
Am Freitag, den 18.02.2011, 10:12 +0100 schrieb Mike Hommey: Hi, Now that squeeze is released, it's time to start pushing new things to unstable. I've been asked several times already how things would be evolving in the near future, to which I answered it would quite stay the way it is now until upstream releases 4.0, at which point I'd upload 4.0 to unstable. But that might change. And I'm hereby requesting feedback on what fellow developers (especially maintainers of the various reverse dependencies) think about them. Here are some of the available options: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Pros: More exposure for the 3.6 and 4.0 packages. Cons: More work for reverse dependencies, which would be made to build and work with 3.6 and then again with 4.0 in a few weeks. Last time I checked (which was 3 months ago), 4.0 doesn't work on s390, sparc and ia64, which would make problems. - Keep things the way they are (3.5 in unstable, 3.6 in experimental, 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's released. Pros: we don't need to make sure everything in unstable builds and works properly with 3.6 before doing the work again with 4.0 in a month or so. Cons: Broken architectures with 4.0. - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. Pros: We don't break anything in testing/unstable, and we don't have to deal immediately with the broken architectures. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. - Keep everything in place, prepare rdeps to build and work with 4.0, and push 4.0 to unstable when everything is ready. Pros: We don't break anything in testing/unstable, and when 4.0 lands on unstable, nothing breaks either. Cons: Past experience shows that it takes a lot of time to fix rdeps. My gut feeling is that breaking things in unstable would create an incentive to fix, which doesn't exist when the package is in experimental or worse, outside the archive. - Suggest your own if you have better ideas (really, I mean it). As I mentioned above, my initial idea was to go with the second option, breaking most rdeps in the process, but then I remembered that 4.0 doesn't work on all our architectures, and I'm hesitating, now. So, fellow developers, what do you think? I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Feb 18, Mike Hommey m...@glandium.org wrote: - Suggest your own if you have better ideas (really, I mean it). I support option #2: I have been using it since you started packaging it and it works great: better than 3.6 and hugely better than 3.5. s390, sparc and ia64 are not exactly popular architectures, and more so on desktops, so I believe that encouraging their porters would be helpful. -- ciao, Marco signature.asc Description: Digital signature
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 10:12:42AM +0100, Mike Hommey wrote: snip As I mentioned above, my initial idea was to go with the second option, breaking most rdeps in the process, but then I remembered that 4.0 doesn't work on all our architectures, and I'm hesitating, now. So, fellow developers, what do you think? To add some more insight, here is a list of the reverse build dependencies in main for xulrunner-dev: chmsee eclipse firegpg galeon gecko-mediaplayer gjs gluezilla gnome-chemistry-utils gnome-python-extras google-gadgets gtk-vnc instantbird kazehakase libgtk2-mozembed-perl libjdic-java libreoffice mongodb moon mozvoikko mozzemberek openjdk-6 openvrml packagekit parole pcmanx-gtk2 pyxpcom rhythmbox ruby-gnome2 sugar-hulahop swt-gtk totem virt-viewer vlc weave xiphos and for libmozjs-dev: couchdb edbrowse elinks freej gjs gxine libjavascript-perl libproxy mediatomb openvrml All these packages most probably need changes to at least build against 3.6 or 4.0. (though I wouldn't mind if someone would actually try ;) ) Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218113636.ga21...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
Hi, Mike Hommey wrote: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. That would be my favourite. I use Conkeror (which is a XULRunner application and hence depends on xulrunner) with 3.6 since it is in experimental and it works without problems since a year or so. Ubuntu has the Debian package with just slight modification of some defaults together with xulrunner-1.9.2 in Lucid 10.04 LTS. They just had to backport a few upstream fixes. OTOH since my upstream announced 4.0 compatibility a lot has changed in 4.0 (sic!) and the last time I tried it, it seemed to make quite some problems. Will check again the current state of the packages in the mozilla.d.n repo (and later experimental). Cons: More work for reverse dependencies, which would be made to build and work with 3.6 and then again with 4.0 in a few weeks. No problem for me. In the contrary, I'd be glad if 4.0 doesn't hit unstable immediately. - Keep things the way they are (3.5 in unstable, 3.6 in experimental, 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's released. [...] - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. I think 3.6 should go to unstable and replace 3.5 as soon as poosible, so these options look like heading backwards. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. Right. That's why I want to see 3.6 in unstable as soon as possible independently of the state of 4.0. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218114159.gx12...@sym.noone.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit : I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. I’d favor that one too. The sooner we can adapt reverse dependencies to 4.0 in experimental, the better. And no need to do the work twice. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298030386.18394.65.camel@meh
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 10:12:42AM +0100, Mike Hommey wrote: [iceweasel] - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Extra effort for you. - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. Well, but is there any point in sinking work into it? It's not like it's going last more than a couple of months. Any work you put into 3.6 reduces the polish on 4.0 by that much. Porting rdeps to 3.6 then to 4.0 would put additional strain on their respective maintainers, too. 4.0-experimental now and -unstable when it's released would minimize the amount of unnecessary work, while giving 4.0 more exposure. It is stable enough for daily use, too. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218115957.gb16...@angband.pl
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote: Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit : I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. I’d favor that one too. The sooner we can adapt reverse dependencies to 4.0 in experimental, the better. And no need to do the work twice. There have been almost a year to adapt reverse dependencies to 3.6 in experimental. And I don't think most rdeps are ready for 3.6. Do you expect things to be significantly different? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218123427.gb22...@glandium.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
Le vendredi 18 février 2011 à 13:34 +0100, Mike Hommey a écrit : On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote: I’d favor that one too. The sooner we can adapt reverse dependencies to 4.0 in experimental, the better. And no need to do the work twice. There have been almost a year to adapt reverse dependencies to 3.6 in experimental. And I don't think most rdeps are ready for 3.6. Do you expect things to be significantly different? Yes. We’re no longer in a freeze but at the beginning of a development cycle. Note that we’re mostly doing the same for GNOME; skipping most of 2.32 in unstable, to work on 2.91 in experimental. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298034464.18394.72.camel@meh
Re: What should we do with iceweasel/xulrunner/libmozjs?
On 02/18/2011 05:42 AM, Axel Beckert wrote: Hi, Mike Hommey wrote: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. That would be my favourite. I use Conkeror (which is a XULRunner application and hence depends on xulrunner) with 3.6 since it is in experimental and it works without problems since a year or so. Ubuntu has the Debian package with just slight modification of some defaults together with xulrunner-1.9.2 in Lucid 10.04 LTS. They just had to backport a few upstream fixes. [snip] Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. Right. That's why I want to see 3.6 in unstable as soon as possible independently of the state of 4.0. I concur with Axel. Been using iceweasel 3.6 since soon after it hit experimental, and stuff like vlc/unstable work like a champ. -- The normal condition of mankind is tyranny and misery. Milton Friedman -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d5ec1e9.2040...@cox.net
