On Fri, Feb 18, 2011 at 01:34:27PM +0100, Mike Hommey wrote: > 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?
Three months later, I see no significant change in the reverse dependencies status. At the moment, we're stuck with 3.5 in testing and unstable, and 4.0 in experimental. This deeply sucks. However, by the time wheezy is released, Firefox will have had several new releases. And the current embedding API (gtkembedmoz) has already been removed from Firefox 5.0, coming in a few weeks. We're obviously not going to maintain xulrunner 1.9.1 or 1.9.2 forever, so at some point, things relying on gtkembedmoz will have to either contribute to mozilla to get a new embedding API that works better for them (it would be about time), or die. Waiting for that to happen, the only solution forward is IMHO to remove packages using gtkembedmoz. Packages relying on xulrunner-dev to build plugins should still be fine, though. As for libmozjs, the API is a fast moving target, and AFAIK, only a few packages such as gjs are following the trend. Others should probably die too. The Debian Mozilla team just doesn't have the resources to handle the situation entirely. We (sic) can't fix all rdeps that can be fixed (here I'm thinking things that can switch to something else than xulrunner, like kazehakase, but I think that one was RMed), and sort out the other rdeps status on our own. Past and present experience suggests that nothing is ever going to happen in experimental, so I guess the only way to get things moving is a painful massive breakage in unstable. What's the release team take? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110513071942.ga7...@glandium.org
