FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-18-2011, 08:29 AM
Benjamin Drung
 
Default 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
 
Old 02-18-2011, 09:42 AM
 
Default What should we do with iceweasel/xulrunner/libmozjs?

On Feb 18, Mike Hommey <mh@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
 
Old 02-18-2011, 10:36 AM
Mike Hommey
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218113636.GA21269@glandium.org">http://lists.debian.org/20110218113636.GA21269@glandium.org
 
Old 02-18-2011, 10:42 AM
Axel Beckert
 
Default 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 <abe@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218114159.GX12557@sym.noone.org">http://lists.debian.org/20110218114159.GX12557@sym.noone.org
 
Old 02-18-2011, 10:59 AM
Josselin Mouette
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1298030386.18394.65.camel@meh">http://lists.debian.org/1298030386.18394.65.camel@meh
 
Old 02-18-2011, 10:59 AM
Adam Borowski
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218115957.GB16828@angband.pl">http://lists.debian.org/20110218115957.GB16828@angband.pl
 
Old 02-18-2011, 11:34 AM
Mike Hommey
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218123427.GB22394@glandium.org">http://lists.debian.org/20110218123427.GB22394@glandium.org
 

Thread Tools




All times are GMT. The time now is 07:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org