On Wed, Aug 6, 2014 at 7:14 PM, Scott Kitterman <ubu...@kitterman.com> wrote: > On Wednesday, August 06, 2014 18:05:20 Harald Sitter wrote: >> On Wed, Aug 6, 2014 at 3:24 PM, Scott Kitterman <ubu...@kitterman.com> > wrote: >> > On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: >> >> On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman <ubu...@kitterman.com> >> > >> > wrote: >> >> > On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: >> >> >> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman <ubu...@kitterman.com> >> >> > >> >> > wrote: >> >> >> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: >> >> >> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman >> >> >> >> <ubu...@kitterman.com> >> >> >> > >> >> >> > wrote: >> >> >> >> > I, for one, >> >> >> >> > think the notion that we won't apply known fixes because upstream >> >> >> >> > is >> >> >> >> > non- >> >> >> >> > responsive is silly. I don't intend to be bound by it. >> >> >> >> >> >> >> >> Where does the fix come from then? >> >> >> > >> >> >> > Could be defective Python code I figured out by myself (for >> >> >> > reference, >> >> >> > this >> >> >> > exact scenario is why we had an even sort of working displayconfig >> >> >> > in >> >> >> > hardy - if this policy had been in effect, it would have had to be >> >> >> > removed and not replaced since there was no replacement available). >> >> >> >> >> >> so why did you not pick up maintainership? >> >> > >> >> > Because it would have needed a full rewrite to work with the then brand >> >> > new X stack reliably. We were going to have a new tool for Intrepid >> >> > anyway, so beating it into sort of working was enough for Kubuntu and >> >> > I'm >> >> > certainly not qualified to take on upstream development for all of KDE. >> >> >> >> Why would you not be qualified? You created a Kubuntu specific fork of >> >> the software, so since you were fit to maintain that one I am sure the >> >> same would have worked upstream. Seeing as you were able to beat it >> >> into working state for Kubuntu it would appear to me that there is >> >> nothing that would have prevented you from doing the change upstream >> >> and releasing a new tarball. At worse you had to roll a tarball >> >> instead of dumping a patch into debian/ (which would then have had >> >> up-to-date translations thus possibly not being all that much of a >> >> waste of time to begin with), at best 3 other distributions had picked >> >> it up and thanks to that ended up with a working display config in >> >> their LTS release. >> > >> > Perhaps. That would have required some commitment on my part to do work >> > to >> > support other distros that I wasn't willing to take on. Since the X stuff >> > does vary from distro to distro, I had (and still have) no idea what of >> > what I was doing was Ubuntu specific and what might be generally >> > applicable. >> >> I hear kwin does fine without distribution specific solutions. At any >> rate, if a distro had not been able to use it because of compatibility >> issues and you were not willing or capable or whatever to resolve it, >> that would have been where they needed to make their own decisions on >> whether to patch it into working state and hopefully upstream that >> patch or not ship it at all or ship the old version or whatever. By >> not going out and saying "this here software is unmaintained, I made >> it so it works with kubuntu and relased version x.y which is less >> shitty than the previous release" you pretty much excluded others from >> an option to possibly use it as we cannot expect others to track what >> we patch or don't patch (just like we don't track every other distros >> patch work). So had another distro needed it worst case they'd have >> duplicated the work on their own or be lucky enough to find our patch >> through a web search. >> >> >> The reasons why we don't want to condone dead upstream pseudo >> >> maintenance patchy nonesense is multifaceted. The fact that distro >> >> patchy is selfish towards everyone else is one part of it. Another one >> >> is that the patch policy needs a responsible person up the stream to >> >> review and approve and possibly merge a patch, with out one the patch >> >> policy doesn't allow certain patches at all. >> >> Another important side of the argument is that of reliable and >> >> balanced quality. No one takes on responsibility for the quality, so >> >> we must assume it has excessively shitty quality or is of no use >> >> because otherwise someone were to feel the need to stand up and take >> >> on maintenance or at the very least care enough to fix startup >> >> crashes, data loss, bug triage etc.etc.. And ultimately that leads to >> >> the question of whether we should have a piece of software of >> >> obviously shitty quality under our wings to begin with considering no >> >> one else wants to care about it either. >> > >> > I generally agree with that, but there are cases where all the >> > alternatives >> > were worse. Shipping without any tool at all to configure a monitor was a >> > non- starter. >> >> There pretty much always is an almost equally suitable alternative >> (case in point: displayconfig-gtk). >> >> But yeah, let's assume there really is no replacement software >> available, and no one is willing to actually do an upstream commit >> (which is really a social problem as I am absolutely willing to go on >> record that there is next to no overhead when doing things upstream >> with no maintainer being there to stand in your way). We have then >> failed have we not? Software doesn't go unmaintained and breaks over >> night, the new x was expected for at least half a year, displayconfig >> was pretty unmaintained for about a year. Somewhere along the line >> someone could have gone 'I think we have a problem', and poked >> upstream KDE (as indicated in the poking KDE bit of dead upstreams) to >> get advise on what to do or maybe even a fix. So, had we been forced >> to ship without a display configuration tool it would have been a >> defeat no doubt about that, at the same time it would have been a very >> honest taking of responsibility for our failure in realizing that >> there is a problem coming our way. > > Sure. Could have. Didn't. Mistakes happen. Pretty much my entire point is > that these policies are all very nice, but sometimes stuff happens and it's > just not the way to go.
There are no penalties for policy violation described in the policies. Never have been. If someone violates policy and shit blows up they will get shamed for it. If it is really bad or it happens too often perhaps people might not trust the person anymore, perhaps they will file a complicate with one of the 300 councils we have to have his rights removed or something. What I am saying is as with the debian policy it is something to hold on to. Making a judgement call and going the other way won't get the person a free trip to hell in the afterlife, but they better be sure of their decision because if things go sideways. Equally if someone then comes along and does it the 'right' way, it's all the better and that someone surely would deserve all the more credit for it. As far as mistakes go the policy is the thing to hold on to. If one does it the policy way one should not be at liberty to make the mistake of thinking that a 30k line patch one wrote or found on the internet should be added to the packaging simply because there is no upstream to say that it is a truly terrible idea. >> Sweeping things under the rug doesn't do anything but (possibly) make >> ourselves feel good about "having made it". It doesn't help motivate >> someone to write a replacement software. It doesn't communicate to the >> user that any and all bug reports they file against this beast will >> not be answered (unless maybe if it sounds very bad and was mentioned >> numerous times on IRC). It doesn't help any of the other distributions >> that might face pretty much the same problem maybe now or maybe in 3 >> months. There is quite simply no benefit to be had from distro >> patching severe bitrot bugs in software where you can't even upstream >> the fixbecause there is no one there to upstream to. >> >> >> All that being said, perhaps the policy ought to be amended to say >> >> that instead of having the package removed from the archive it must >> >> not be on our ISOs and Kubuntu should not be the maintainer. At the >> >> end of the day what someone does because they want to is their own >> >> business. So, if someone feels like foobar should be in the archive >> >> and that they feel up to the task of keeping it not broken that's >> >> their choice to make and execute. Even if it then reflects badly on >> >> Kubuntu and Ubuntu at large if a user installs that software and finds >> >> it to be unusable for whatever reason. There is not much one can do >> >> about that, and this is a global problem to some extent anyway. >> > >> > That's true. It's definitely beyond the scope of what Kubuntu policy >> > could >> > mandate to insist on packages being removed from the archive if someone >> > did >> > not want them removed. That said, we still have the situation where the >> > unmaintained crap we have is better than the alternatives available. >> >> Truth be told the reason it says 'remove' is primarily focused on >> software we introduced and only we used, as to prevent low quality >> nonesense no one wants anymore from lingering around (as has been the >> case in the past, although I fail to remember a precise example, we >> are usually good at getting undesired things nuked within a cycle). So >> perhaps the amendment should be: >> >> remove package >> if it is entirely broken as per general viabilithy assesment >> OR deemed a suitable resolution by the developer noticing it has a >> dead upstream >> AND no one objects on mailing list to removal <<< additional >> requirement to removal by choice >> >> AND if only we use <<< additional requirement to removal in general >> >> (otherwise retain; close bugs; create this-thing-be-unmaintained bug) >> >> >> But, we as creators of Kubuntu however should not support selfish >> >> life-support patching for the software we use to build our product on. >> >> It does not benefit anyone to drag along broken unreliable software. >> >> Giving it the boot on the other hand does not only free up resources >> >> better spent elsewhere, it also makes people moan and whine about this >> >> super important application that is now gone and this makes it all the >> >> more likely that someone steps up and does what needs to be done to >> >> make it a super awesome piece of software again. >> > >> > If someone had told me when I started fixing displayconfig that I could >> > only do it as upstream and I couldn't upload changes to Ubuntu, then I >> > wouldn't have bothered. While I think what you are suggesting is >> > generally correct, there are specific cases where it doesn't apply. As >> > written, it's too hard line. >> v >> >> >> The present policy is already given a lot of leeway to make sure the >> >> user doesn't need to suffer unless there really is no other way. But >> >> the must-not-be-patched thing is really not something that can be >> >> changed or removed IMO. If patching maintained software is >> >> semi-forking then patching unmaintained software that is entirely >> >> broken as per the presented check list is a definite fork because the >> >> patched version is then the only working version and thus the defacto >> >> source to be used. >> > >> > OK. I don't see the leeway. Must be removed is pretty clearly one thing. >> >> ^ hard line and leeway. The original draft actually suggested to not >> ship or retain unmaintained software at all, which is the logical >> result of saying that unmaintained software must not be introduced as >> a completely new package. If you cannot introduce new software that is >> known to be unmaintained, it'd be a double standard to say that >> unmaintained software can be knowingly kept around until it falls prey >> to bitrot. So as writer of the original draft I can honestly say that >> the presented version is really very liberal ;) >> >> I do realize that it is a really drastic policy still. And it is >> intentionally that way, just like the patch policy. Offering software >> we cannot ensure isn't crap isn't exactly something that reflects good >> on us, the product, the ubuntu community or kde. >> >> >> So, your concern is that this sort of short term workaround isn't >> >> possible with the presented policy, but really it is. Instead of >> >> making a distro patch you would commit your bandaid solution upstream, >> >> release a new tarball. By doing that you are making your work easily >> >> available to others and improve the quality of the upstream product. >> >> You'd then be a maintainer (of sorts). Other distros as well as our >> >> guys might have additional tweaks so they run it by you (for example >> >> as per our patch policy) and maybe after 3 months you roll a new >> >> tarball and official declare displayconfig is now to be considered >> >> rubbishware and one should use xyreplacement going forward. >> >> Instead of making other distros run circles around kubuntu packaging >> >> to find the relevant patch and then somehow try to keep an eye on it >> >> in case some other kubuntu dev improves on it, the very same thing has >> >> been published upstream and everyone knows how and has tech to watch >> >> upstream for cahnges and how to deal with upstream and even how to >> >> roll a simple tarball from upstream including translations and whatnot >> >> (e.g. the releaseme framework). >> > >> > Commit upstream is great for people with upstream commit rights. For >> > distro packagers like me, it's a whole mess of bureaucracy that's a lot >> > of work. Slightly similarly, I noticed an obvious error in the last >> > kapidox release. I fixed it (patch) and pinged the maintainer on IRC. I >> > think that's enough. >> Getting upstream commit rights requires: someone to confirm that you >> won't break everything. The bureaucracy involved is filing a request >> with the sysadmins who will ask the person to confirm your >> not-screwuppery. All of this is usually done in <24hrs. >> >> Getting a patch proxy-committed: at best it's ask a person; at worst >> it's filing a review and defending the code in review. >> >> For someone used to our level of bureacracy all of this ^ is like >> #lawelessland. >> >> There does not appear to be anything wrong with sharing one's >> >> accomplishments. >> > >> > There's nothing wrong with it. It may be more trouble than it's worth in >> > some cases. >> >> I am sure the potential 30 other packagers who might need the patch as >> well would disagree. >> >> >> On a related note I actually traveled back in time and looked at >> displayconfig. Last actual upstream release was early 07-2007, since then >> JR did >> upstream bugfixes and pulled svn snapshots (which is a problem to be >> dealt with another time ;)). So it actually wouldn't be considered a >> dead upstream as per the poke upstream exception for kde projects >> (collective ownership -> collective responsibility -> chances are >> someone will find it in their heart to unbreak a broken and >> unmaintained piece of KDE software). >> >> I will also say that since it was kde3 software it is a really bad >> example to begin with because it came out of the dark ages when we >> used to patch everything and the kitchen sink. What was it? Some 100 >> or 150 patches in kdebase alone? ;) > > In this case, as I recall it, I was basically bug fixing it back into > existence. I'd find a crash, figure a reasonable way around it, update, and > see > what the next one was. The added complexity and latency of trips upstream > would have resulted in an worse end result. You'd have done it the very same way, except instead of dumping the patch into debian/patches you had dumped it into svn. > Is this ideal, not, but it wasn't an ideal situation. > > I'm curious how this notion of upstream review and dead upstreams works with > upstreams that don't care about anything but the most recent release. doesn't apply: # Characteristics - There is no upstream bug tracker, or bugs are not being triaged in the upstream bug tracker. - There is no VCS, or the VCS has not seen any feature or bug fix commits in >= 6 months. - No new release has been published in >= 6 months. - Upstream developers cannot be contacted or are not responding. > Taking your PyQt5 on Trusty issue (usb-creator), I'm pretty sure upstream's > answer for anything other than a very specific reproducer that he can easily > find a specific commit to address will be "update to 5.3.1", which we can't > do. > > Support from upstreams like that isn't much different than dead ones in many > cases. It is in that we know there will be a next version and the next version will likely be better than the current version (unless of course upstream likes bad press, then it would be worse, but that's a different story entirely). If I wrote a patch for it I could run it by upstream and upstream would tell me whether it is obviously going to break everything. If I asked nicely or threw some monies at upstream they'd probably even give me a fix. With a dead upstream there is no next version so by laws of nature the code will rot and start to stink and all the patches I'd land probably would turn the thing into a zombie that eats your CPU. If upstream reads mails but simply refuses to respond I'd still get a fix for monies though. HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
