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. > What exactly is the "several possible ways" you have in mind? Possible ways include taking CELT, removing everything, removing parts, stopping working for and with Debian. > <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? Dear release team, the-me (the maintainer) just uploaded a new version with CELT disabled. Opus support is not yet entered upstream (see https://bts.keep-cool.org/ticket/243 for details). This is NOT because the maintainers think this is right but *ONLY* because we stop caring. Ron Lee is not willing to help, does not follow the standards (like opening tickets early), telling everbody technically wrong things (like the above). The rest of what we hear from him is strong language. We gave up. This is the same for mumble, where the maintainer(s) gave up and handed the maintainership to ron. He broke the package and now it is *completly* *useless* (#675971). In case of RoarAudio it is only completly useless for some of it's users. Whenever there is a problem somebody like him stand up, shout at you and you can be sure one of those words are included: RM, drop or NMU. Most NMUs I saw lately broke the packages in one or another way. The result are developers no longer caring like me. Just a few months ago I hoped to become a DD. Now I think of switching away even as user. Other DDs I know consider the same. Some already done. -- Philipp. (Rah of PH2)
Attachment:
signature.asc
Description: This is a digitally signed message part