Bug#674634: transition: celt
On Sat, May 26, 2012 at 18:38:11 +0930, Ron wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We'd like to remove the celt package from the distro for the Wheezy release. CELT was an experimental codec from Xiph, and that work has now been merged into the Opus codec which is about to be ratified as an IETF standard. The only rdep left in testing at this point is mumble. What's the plan here? Cheers, Julien signature.asc Description: Digital signature
Bug#674634: transition: celt
On Sun, Jul 01, 2012 at 01:16:17AM +0200, Julien Cristau wrote: On Sat, May 26, 2012 at 18:38:11 +0930, Ron wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We'd like to remove the celt package from the distro for the Wheezy release. CELT was an experimental codec from Xiph, and that work has now been merged into the Opus codec which is about to be ratified as an IETF standard. The only rdep left in testing at this point is mumble. What's the plan here? There are too many things that still need fixing with mumble at this stage for me to recommend it as a viable release candidate for wheezy. It currently FTBFS now that boost1.46 was removed, and I don't know yet if that will just need the build-dep adjusted, or actual changes to the source - which is kind of academic while it's also still blocked by the zeroc-ice ABI breakage of #672066 (which at this stage is debian specific, and we have no idea what zeroc-ice upstream is really going to do to make it work with gcc 4.7). So the best plan I have right now would be to remove mumble from testing and worry about fixing its problems in unstable with a free hand (knowing we won't be annoying the release team with large patches to review - which I'm pretty sure it's going to need still before this is all in good shape again). That will let you close this bug - and also give you the option of removing zeroc-ice too if that bug doesn't get a sane fix soon (since mumble is also its only rdep). Shipping that in its current state doesn't really seem like something I'd recommend either, but that one is less of my call to make ... Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674634: transition: celt
reflum, On Mon, 2012-05-28 at 22:37 +0930, Ron wrote: On Mon, May 28, 2012 at 11:54:14AM +0200, Philipp Schafft wrote: On Sat, 2012-05-26 at 18:38 +0930, Ron wrote: Roar, I've been assured by its upstream is likewise easy to just disable support for it - but the-me is giving me some pointless pushback ... I'll NMU that too when the time comes if really needed if this is the final blocker. There shouldn't be any other flow on from this so far as I know. Some of these packages may enable Opus support instead, but doing so is not a prerequisite for us being able to remove celt for Wheezy. Removal of CELT will remove a major feature of src:roaraudio. It will not render the package useless just will make it useless for a group of users. For anyone actually relying on CELT for this (of which I highly suspect there is very near to nobody), the current situation is already worse than useless. The version we have is not bitstream compatible with the version of celt that other distros are shipping, so the result of trying to use it will be something approximating speaker and ear popping noise. This is completly untrue. You yourself told me you taked to other distros to sync this. Also the Protocol requires sending a magic including the bitstream version. If the versions don't match it will fail and tell the user about the problem. Please stop telling everybody's software would be broken. This also would have happened to them if I'd actually uploaded a newer version of CELT as several people had requested ... No. See above. If nobody has reported that to you, then it confirms my suspicion that nobody will actually notice it going away. No. See above. Since you don't even mention celt support in any of your descriptions of roar, either in the package or on your website, this seems more like a minor easter egg than a major feature anyway. Package descriptions are no docs. If I list all features I will have documentation. See your own package descriptions... This is why we like to make this a smooth transition with getting in Opus first, then removing CELT. Also note that this transition needs users using it to change config so it should not be a single upload removing one and adding the other. If you can't sanely handle this in one upload, then your package is broken for your users anyway. There is no arbitrary period of time on the order of 1 month as you claimed earlier in which they will all update to the first version before you upload the second. This has nothing to do with the package but with users. Users are nothing I can update via upload. The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. Let's be very clear on this point. You have been asking me about this for over a year now, and have been fully informed on everything that was planned. So if anyone is a bit late getting their act together, you'll need to discuss that with the man you see in the mirror. Let's make it *very* clear: Last time I asked you you said nothing about this nor pinged the package maintainer via an offical (like BTS) or inoffical (like pinging me on IRC) channel. Yes, this is late in the cycle - but only from the perspective of the release team. Everyone else, including you, has known this was coming, and that things would happen fast after the IETF working group finally concluded, as uncertain as the actual date for that had been. And everyone else, except you, has been extremely cooperative and has got their part of the work done already, efficiently and painlessly. See above. A few days ago, you claimed this would take 4 months. Today you claim a month. Without getting gnuplot out to fit this, on that projection we should be down to my 15 minute estimate, by say, this Wednesday? I'm sorry if this was unclear: I was talking about the technical part here. The diffrence is because there is not only your schedule but also the one of other groups. The RoarAudio project has a defined release cycle to ensure quality. Depending on when you ping us (what you never did) changes take one or two months to go in if they are accepted. You can read about it here: https://bts.keep-cool.org/wiki/ReleaseCycle I already sent you the one line patch that was needed. And I still have the 12 minutes up my sleeve from doing that if you'd like me to upload it. Just say Ok. and it will happen. It doesn't get much easier than that. You send a one line patch to break the package. In the bug you opend (after you gave us 13 minutes to upload or NMU as you said, very nice move btw.) you tell us that it is this easy as it is no transition to opus but a pure removal of celt. Please look at the title of this ticket. Transitions do *NOT* consist of removing something without replaceing it.
Bug#674634: transition: celt
Hey, I will answer as the current/still roaraudio and the previous mumble maintainer, but I do not want to lost too much words anymore about this *** whole situation. As an side note, please CC me, I am not subscribed to this list anymore. Am 07.06.2012 01:23, schrieb Philipp Schafft: Since you don't even mention celt support in any of your descriptions of roar, either in the package or on your website, this seems more like a minor easter egg than a major feature anyway. Package descriptions are no docs. If I list all features I will have documentation. See your own package descriptions... Full ACK with Philipp. This is why we like to make this a smooth transition with getting in Opus first, then removing CELT. Also note that this transition needs users using it to change config so it should not be a single upload removing one and adding the other. If you can't sanely handle this in one upload, then your package is broken for your users anyway. There is no arbitrary period of time on the order of 1 month as you claimed earlier in which they will all update to the first version before you upload the second. This has nothing to do with the package but with users. Users are nothing I can update via upload. I also can not understand why it is a fix to break compatiblity and (main) features by just disabling them blindly.. The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. Let's be very clear on this point. You have been asking me about this for over a year now, and have been fully informed on everything that was planned. So if anyone is a bit late getting their act together, you'll need to discuss that with the man you see in the mirror. Let's make it *very* clear: Last time I asked you you said nothing about this nor pinged the package maintainer via an offical (like BTS) or inoffical (like pinging me on IRC) channel. With my package maintainer hat on I just heard about this removal ~7-10 days ago, and I heard it from one of my upstreams.. Yes, this is late in the cycle - but only from the perspective of the release team. Everyone else, including you, has known this was coming, and that things would happen fast after the IETF working group finally concluded, as uncertain as the actual date for that had been. And everyone else, except you, has been extremely cooperative and has got their part of the work done already, efficiently and painlessly. See above. Everyone else is not ready to replace celt or to support opus, see my messages later.. A few days ago, you claimed this would take 4 months. Today you claim a month. Without getting gnuplot out to fit this, on that projection we should be down to my 15 minute estimate, by say, this Wednesday? I'm sorry if this was unclear: I was talking about the technical part here. The diffrence is because there is not only your schedule but also the one of other groups. The RoarAudio project has a defined release cycle to ensure quality. Depending on when you ping us (what you never did) changes take one or two months to go in if they are accepted. You can read about it here: https://bts.keep-cool.org/wiki/ReleaseCycle I also taked to several people that Philipp said that it *may* be possible to include opus/whatever support withing 1-2 months (I said that around seven days ago), but in the same sentence I said, that it wouldn't be stable, it would be something like a hack to build with the missing celt.. I already sent you the one line patch that was needed. And I still have the 12 minutes up my sleeve from doing that if you'd like me to upload it. Just say Ok. and it will happen. It doesn't get much easier than that. You send a one line patch to break the package. In the bug you opend (after you gave us 13 minutes to upload or NMU as you said, very nice move btw.) you tell us that it is this easy as it is no transition to opus but a pure removal of celt. Please look at the title of this ticket. Transitions do *NOT* consist of removing something without replaceing it. Full ACK with Philipp. hint Embedding celt in roar is not one of them / Oh, that was what you recommended before we told you that this is a very bad idea. Rememer? YOU (ron) said to me, that mumble is such a special case within your great planned and well done celt = opus transition, why it should use it's embedded celt version. I have told you several times that it is a quite bad idea, it would be better to maintain celt as an ato. package about the wheezy lifetime! Using the embedded celt version is a bug per policy and debian-security also will not be happy about this (but I told this too much times..)... Dear release team, the-me (the maintainer) just uploaded a new version with CELT disabled. Opus support is not yet entered upstream (see
Bug#674634: transition: celt
reflum, On Sat, 2012-05-26 at 18:38 +0930, Ron wrote: Roar, I've been assured by its upstream is likewise easy to just disable support for it - but the-me is giving me some pointless pushback ... I'll NMU that too when the time comes if really needed if this is the final blocker. There shouldn't be any other flow on from this so far as I know. Some of these packages may enable Opus support instead, but doing so is not a prerequisite for us being able to remove celt for Wheezy. Removal of CELT will remove a major feature of src:roaraudio. It will not render the package useless just will make it useless for a group of users. This is why we like to make this a smooth transition with getting in Opus first, then removing CELT. Also note that this transition needs users using it to change config so it should not be a single upload removing one and adding the other. The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. I have discusses several possibile ways to get this solved with the-me (the maintainer). In fact both of us would *really* like to get this done. CELT always added some extra work both upstream and in maintaining packages because of the unfrozen bitstream. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Bug#674634: transition: celt
Hello Philipp, Ron, etc. Philipp Schafft l...@lion.leolix.org (28/05/2012): The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. Yes it's late. I have discusses several possibile ways to get this solved with the-me (the maintainer). In fact both of us would *really* like to get this done. CELT always added some extra work both upstream and in maintaining packages because of the unfrozen bitstream. Not speaking for the release team as a whole, but it looks to me that we should be able to consider letting a new roaraudio in (switching from celt to opus) after the freeze. Mraw, KiBi. signature.asc Description: Digital signature
Bug#674634: transition: celt
On Mon, May 28, 2012 at 11:54:14AM +0200, Philipp Schafft wrote: reflum, On Sat, 2012-05-26 at 18:38 +0930, Ron wrote: Roar, I've been assured by its upstream is likewise easy to just disable support for it - but the-me is giving me some pointless pushback ... I'll NMU that too when the time comes if really needed if this is the final blocker. There shouldn't be any other flow on from this so far as I know. Some of these packages may enable Opus support instead, but doing so is not a prerequisite for us being able to remove celt for Wheezy. Removal of CELT will remove a major feature of src:roaraudio. It will not render the package useless just will make it useless for a group of users. For anyone actually relying on CELT for this (of which I highly suspect there is very near to nobody), the current situation is already worse than useless. The version we have is not bitstream compatible with the version of celt that other distros are shipping, so the result of trying to use it will be something approximating speaker and ear popping noise. This also would have happened to them if I'd actually uploaded a newer version of CELT as several people had requested ... If nobody has reported that to you, then it confirms my suspicion that nobody will actually notice it going away. Since you don't even mention celt support in any of your descriptions of roar, either in the package or on your website, this seems more like a minor easter egg than a major feature anyway. This is why we like to make this a smooth transition with getting in Opus first, then removing CELT. Also note that this transition needs users using it to change config so it should not be a single upload removing one and adding the other. If you can't sanely handle this in one upload, then your package is broken for your users anyway. There is no arbitrary period of time on the order of 1 month as you claimed earlier in which they will all update to the first version before you upload the second. The cirtical factor is time here. Ron Lee is a bit late with this transition in the release cycle. Had he given us about a month more we would have done all this already and everybody would be happy. Let's be very clear on this point. You have been asking me about this for over a year now, and have been fully informed on everything that was planned. So if anyone is a bit late getting their act together, you'll need to discuss that with the man you see in the mirror. Yes, this is late in the cycle - but only from the perspective of the release team. Everyone else, including you, has known this was coming, and that things would happen fast after the IETF working group finally concluded, as uncertain as the actual date for that had been. And everyone else, except you, has been extremely cooperative and has got their part of the work done already, efficiently and painlessly. A few days ago, you claimed this would take 4 months. Today you claim a month. Without getting gnuplot out to fit this, on that projection we should be down to my 15 minute estimate, by say, this Wednesday? I already sent you the one line patch that was needed. And I still have the 12 minutes up my sleeve from doing that if you'd like me to upload it. Just say Ok. and it will happen. It doesn't get much easier than that. I have discusses several possibile ways to get this solved with the-me (the maintainer). In fact both of us would *really* like to get this done. CELT always added some extra work both upstream and in maintaining packages because of the unfrozen bitstream. You keep saying that, and then keep denying any action that would actually really do it. The last time I asked you, you even denied being one of the maintainers and having any say in what happens with this at all ... What exactly is the several possible ways you have in mind? hint Embedding celt in roar is not one of them / Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674634: transition: celt
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We'd like to remove the celt package from the distro for the Wheezy release. CELT was an experimental codec from Xiph, and that work has now been merged into the Opus codec which is about to be ratified as an IETF standard. As a result of that, upstream is no longer maintaining celt at all, and being an experimental codec, no two releases of it were ever bitstream compatible with each other (and only one release was ever made that even maintained API compatibility with prior versions). All packages using it at the time knew and accepted that this would be the situation with it while it evolved ... The version that Debian currently is shipping we tried to get consensus on people agreeing to consider it an interoperability snapshot before squeeze, but in the end that never actually happened in practice and other distros shipped other incompatible versions of it anyway. So we (meaning myself, upstream, and anyone else who has discussed this with us in detail) see little value in continuing to ship this, and plenty of opportunity for Harm. Apps using it in Debian will only be interoperable with the Debian releases of themselves, there will be no security support, and it will just further fragment the codec space, at a time when there is a real standard alternative people should be looking at for the future. I'd have moved on this sooner, but it's only been in the last few days that we actually had enough certainty about the IETF process concluding to really know what the foreseeable future of all this was going to be. I've already been actively talking to upstreams of the affected packages to be sure we might actually pull this off in the time we have remaining, and I'm sure enough that this will be possible now to really propose a formal course of action for Wheezy. We've been planning for this in general terms for years now, but nothing could actually move until the IETF did. And now they have. Death, taxes, and bad timing. Anyhow, this actually should be fairly simple, being an experimental codec almost everything already has support for only optionally enabling it. So we just need sourceful uploads of packages to turn it off - then celt can safely be removed. Some of the deps have already been updated to remove it, the remaining ones as of yesterday were: # Broken Depends: gst-plugins-bad0.10: gstreamer0.10-plugins-bad jack-audio-connection-kit: jackd1 jackd2: jackd2 libjack-jackd2-0 mangler: libventrilo3-0 opal: libopal3.10.4 [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc] roaraudio: libroar2 roaraudio Opal I've been told will remove it with its next upload. Mangler appears to be under control, details here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674244 gst, I've spoken to upstream and this is a no-brainer, but I still need to get a ping back from slomo about updating the package. jack should be just disable the option too, but I'm still chasing its Debian maintainer for confirmation of doing it. Worst case I should be able to do a trivial NMU myself. Roar, I've been assured by its upstream is likewise easy to just disable support for it - but the-me is giving me some pointless pushback ... I'll NMU that too when the time comes if really needed if this is the final blocker. There shouldn't be any other flow on from this so far as I know. Some of these packages may enable Opus support instead, but doing so is not a prerequisite for us being able to remove celt for Wheezy. Thanks! Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
