Hi Antoine, On Tuesday 18 August 2015 11:47:11 Antoine Martin wrote: > I normally keep quiet. But not this time. Enough is enough about > claiming "frequent regressions" from upstream. > I've heard it before, and I have provided statistics on those so called > "frequent regressions" and where they actually come form vs the need to > fix things.
Antoine, it will be hard for me to provide an accurate statistics of all uploads I had to withheld because I've noticed breakage somewhere... It is true that situation improved lately but as you can see it is not perfect yet. You warned me yourself about regression in 0.14.27 and now we have another one in 0.14.28... It is just a few cases but I see no point in digging history for more evidence. We are both have better things to do. :) > So let's get some facts straight. > > First, some context: everyone can take a long hard look at the 0.14.10 > "stable" version found in Debian and decide if "stable" really means > what they think it means: Yes it really means stable. That includes protection from unexpected changes and regressions. 0.14.10 worked very well for me and if I weren't involved to packaging I could have been still using it... Usually we do not upload new releases directly to "stable". For new releases we have backports [1] repository where you can find Xpra/0.14.26. [1]: http://backports.debian.org/ > http://xpra.org/trac/wiki/Packaging This page do not take into account that 0.14.26 is available for "Jessie" through official backports. > There's a large number of serious issues in 0.14.10, people will hit > them despite the fact that those issues are known and have an easy fix > upstream. I could upload isolated fixes for some of those issues but applying cherry- picked fixes takes time that I do not have. Would you be interested to prepare bugfix for stable? Or would you recommend not to include Xpra to stable Debian releases and provide Xpra packages through backports and "testing" only? We do that for some packages that are considered to be unsuitable for release. Patching stable versions is more difficult as uploading new upstream releases is not allowed precisely to avoid regressions like this one. > What percentage will bother filing a Debian ticket for those? Probably > no more than a low single digit (and that's for the very obvious ones, > not the odd crashes), but until they do things don't get fixed at all. This is not true. There are plenty of issues get fixed if they are known to maintainer even if there is no corresponding bug report. However it is true that most bugs get fixed upstream but it is also true that most regression are also introduced upstream. Everyone can report a bug but as you previously argued, there is little sense to report upstream bugs in Debian if they can be reported directly upstream. > This is a fundamentally flawed process and I just don't buy that "this > is the Debian" way. I know for fact packages get fixed, not always just > reactively. I'm not sure what are you trying to say. How would you like this to be organised? Please let us know your ideas of a perfect workflow and maybe we can improve. > Second, this fix has been committed exactly 2 weeks ago, because *we* do > test things and find such issues very quickly: > http://xpra.org/trac/changeset/10214 This bug is fixed only in Debian and in upstream repository. Does anyone still install from source? Anyway this bug is present in the latest release tarball of 0.14 branch. > We even document what goes in each branch, and what will go in and when > where you could have found this fix from day one in this branch's > commit log: > http://xpra.org/trac/wiki/Versions/PendingFixes That's nice but I'm not sure how can I use this information for packaging. > But if you want to make us look bad because you did not test and did not > notice this in *your* package for 2 weeks, fine. At least we're clear on > that. On this instance, with regrets I admit that I did not do enough testing to notice this bug, which is entirely my fault. I let myself to believe that quality of your releases improved. Lesson learned and in the future I'll try to resist wishful thinking to avoid repeating the same mistake. This wouldn't have happen if I were testing 0.14.28 for two weeks. However I've uploaded fix as soon as I've noticed this bug which was less than 48 hours since upload of package with regression. FYI I work on packaging new releases when it fits to my schedule and not the minute when you publish a new release. On this instance I assumed that if release is available for two weeks it may be safer to upload because otherwise corrected 0.14.29 could have been already released (which is still not the case). > Third, AFAIK this bug did not affect anyone using the packages we > provide at xpra.org - only the packages provided by Debian. So you offer binary packages that do not match release tarballs? Do you do your own minor package releases without touching source tarballs? Anyway personally I wouldn't use or recommend using packages from Xpra precisely because I have impression that they got broken more often and remain broken for weeks. I use only official Debian packages. There are always pros and cons. Besides I believe it would be best if Debian packages could be available from Debian only. You could actually help official Debian packaging but you've chosen to support your own repository even though you don't have to... For better or worse Xpra users have a choice where to install from. > Just like very many of the bugs we encounter. You are exaggerating. We do not introduce bugs on purpose. > libav anyone? We have switched to "ffmpeg" if you noticed. I've articulated your concerns regarding "libav" to Debian Multimedia team and now we're using "ffmpeg". > webp versioning? What are you talking about? Are you sure it is our (i.e. Debian) problem and not inactive Webp upstream? > Debian only bugs in sound subsystem? Really? Have you reported them? Or do you count transition bugs like #785859: "xpra: Please update to GStreamer 1.x". > packaging differences? Pull from us. Debian is the authority for Debian packaging. Help us improve. Also I believe it is the best when packaging is done in one place. > shipping an old version? What a crime... :( FYI the only reason why 0.14 is still in "unstable" is because I want it to migrate to "testing" so I could upload it to "jessie-backports". Then I'll replace 0.14.28 in "unstable" with 0.15 (which is still in "experimental"). I'm quite happy with quality of 0.15.4. Thank you for your hard work and commitment. > (see above) questionable patches applied? etc File a bug, will you please? > Although we do end up dealing with those as well, despite the pain. I'd like to think that I was helping with all the countless hours I put to Xpra testing/QA and providing feedback. You do realise you are blaming a fellow contributor, do you? > Lastly, please tell me how to unsubscribe from Debian's bug system for > xpra, as I cannot find any way of doing this myself from here (it says I > am not registered): > https://tracker.debian.org/pkg/xpra I'd much regret to see you go. Please reconsider when you calm down. See https://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system or try form at the lower-left corner of the following page: https://packages.qa.debian.org/x/xpra.html > I no longer wish to read disparaging comments like the one above. I insist that my comment was sincere and accurate. I'm sorry if it hurt your feelings but that's how I see things. It is my perception that I experience regressions in Xpra more often than in some other software. Having said that I respect and much appreciate your work. There is no need to be that sensitive. Bugs happen then they got fixed. Let's move on. > I will no longer try to help support the outdated versions found in Debian. I'm with you, I also want to replace 0.14 with 0.15 ASAP. We are in the middle of massive GCC-5 transition so technically I shouldn’t be uploading just yet. Just like yourself I reckon I'm a bit impatient to switch to 0.15. I hear your concerns, at least those that I understand. -- All the best, Dmitry Smirnov. --- Moral courage is the most valuable and usually the most absent characteristic in men. -- George S. Patton---
signature.asc
Description: This is a digitally signed message part.
