| RAOF | You know, it's probably time to push intel 2.19. | 06:59 |
|---|---|---|
| mlankhorst | do ittt | 06:59 |
| RAOF | Occasionally losing all text rendering is getting annoying. | 06:59 |
| RAOF | (Which ahs the corollary: don't expect me to reply to anything untill I've rebooted ?) | 07:00 |
| tjaalton | on what hw do you get that? | 07:00 |
| tjaalton | or is in on quantal only? | 07:00 |
| tjaalton | btw, should we try to get mesa 8.0.3 as SRU? | 07:01 |
| tjaalton | i know proposed has one patch backported | 07:01 |
| bryceh | would be nice, although pitti would typically reject it unless each change had an associated ubuntu bug #. But now that RAOF is on SRUs maybe he'll be more allowing? | 07:33 |
| mlankhorst | sure lets sru full synaptics too :D | 07:34 |
| tjaalton | bryceh: there was a session about a more sane sru policy | 07:34 |
| tjaalton | that would allow bugfix releases | 07:35 |
| tjaalton | having a lp# for every change is insane | 07:35 |
| tjaalton | anyway, it should get in quantal first.. | 07:36 |
| tjaalton | Sarvatt: what's the status of mesa 8.0.3? | 07:36 |
| tjaalton | i promised to sponsor it once it's ready | 07:37 |
| tjaalton | anyway, I'll 'test' the sru process with libwacom first :) | 07:45 |
| mlankhorst | bryceh/raof: Should we push synaptics-1.6 branch to quantal? | 07:46 |
| mlankhorst | so we can sru that | 07:46 |
| tjaalton | ask cnd what to do | 07:46 |
| mlankhorst | cnd: ^ | 07:46 |
| tjaalton | there :) | 07:46 |
| mlankhorst | well i believe we should push it to quantal regardless | 07:46 |
| mlankhorst | i don't know if it gets picked up though | 07:47 |
| tjaalton | bryceh: btw, the status page still doesn't show quantal versions | 07:48 |
| bryceh | tjaalton, yes I was at the sane sru policy session; it did not address bugfix releases, that policy is unchanged afaict. | 07:48 |
| tjaalton | we'll see about that | 07:49 |
| tjaalton | :) | 07:49 |
| bryceh | tjaalton, hmm, it should be showing that by now. on my todo list. | 07:49 |
| tjaalton | ok, thanks | 07:52 |
| tjaalton | lunch -> | 07:52 |
| bryceh | mlankhorst, seriously I've never been able to get a point release of any X package through the SRU police in the past, without itemized bug #'s per change. I'm highly skeptical that this has changed, but you're welcome to try. | 07:52 |
| bryceh | (and if it has changed finally, well that's nice, but I'll be quite chagrined) | 07:52 |
| mlankhorst | bryceh: yeah it's just annoying that all the ones in that point release are bugfixes we want | 07:53 |
| mlankhorst | But I don't know if there are even bugs open for some of them, and the corruption one is so annoying that it has to be sru'd as soon as possible, I don't care how. :P | 07:54 |
| bryceh | mlankhorst, if there's any we can reproduce ourselves, those can be done. We'd need to file bug reports ourselves and then "fix" them, and sru that. | 07:55 |
| mlankhorst | bryceh: yeah its annoying people file bugs and don't even bother verifying | 07:56 |
| bryceh | or, if there are upstream bug reports opened which we know should also affect ubuntu, those are sometimes acceptable | 07:56 |
| bryceh | mlankhorst, welcome to ubuntu-x :-) | 07:56 |
| mlankhorst | bryceh: oh and also fun some are not in upstream tracker but in redhat tracker O_O | 07:56 |
| bryceh | if there's changes that are obviously correct by code inspection, *sometimes* those are acceptable, but usually not by themselves; I've had luck sending them in with another fix that is more demonstrable | 07:57 |
| RAOF | We'd *really* like to reduce the number of SRUs that sit in -proposed indefinitely, languishing without testing. | 08:01 |
| mlankhorst | RAOF: Seems I can help airlied with his upstream work in some way after all. Helping him get some hacks removed. :-) | 08:02 |
| RAOF | :) | 08:02 |
| RAOF | One way we're attacking that is that we're enforcing the requirement for a test case; that makes it easier for someone to ensure it's tested. | 08:02 |
| bryceh | RAOF, can you confirm or deny that the SRU team has changed policies regarding bug fix releases (ala allowing mesa 8.0.3 without having bug# breakouts?) | 08:03 |
| mlankhorst | RAOF: I wonder how you want to do that with things like nouveau | 08:03 |
| RAOF | bryceh: There's been no policy change there, but a 8.0.3 SRU *may* be appropriate; GNOME apps get SRUd for their bugfix point releases. | 08:04 |
| RAOF | bryceh: They still need at least one tracking bug, though. | 08:04 |
| RAOF | mlankhorst: Obviously X SRUs have some testing problems - like the kernel, we've got fixes that can only be tested in very specific circumstances. | 08:05 |
| bryceh | RAOF, as I understand it, GNOME has a standing exception with regards to that; do you mean we could get a similar exception for X.org packages? | 08:06 |
| seb128 | bryceh, there is no "wave bug fixes versions in" rules without going through the technical board to get an exception for the said source | 08:06 |
| seb128 | bryceh, no we don't, the exception is for the feature freeze pre release | 08:06 |
| RAOF | bryceh: We could get such a standing exception, yes. | 08:07 |
| seb128 | bryceh, SRUs need to be carefully checked and they are for GNOME, we need the rational, testcase, bugs attached, week in proposed, verification-done for all bugs, etc | 08:07 |
| mlankhorst | seb128: yeah but the problem with synaptics is there are currently a lot of different bugs that are all roughly the same.. | 08:07 |
| mlankhorst | eg weird behavior after suspend fixes | 08:07 |
| mlankhorst | or different thing that can go wrong after disabling and re-enabling | 08:07 |
| seb128 | mlankhorst, SRU team is not that strict, when it's hard to test (i.e random segfaults is a case for GNOME stuff), you write a "run that version for a week and make sure you don't notice a regression" | 08:08 |
| seb128 | mlankhorst, if you get some users doing that and confirming there are no regression they let the SRU in on the basis it might fix the issue or not but in any case it doesn't make things worth | 08:09 |
| seb128 | mlankhorst, we just need to know that people have been running the version and that it's behaving correctly to avoid breakages in -updates | 08:09 |
| RAOF | And if you think it'll fix a bunch of bugs you can upload an SRU with all those bugs in there; as long a reasonable proportion of them are verified fixed we can accept the whole SRU in. | 08:09 |
| mlankhorst | ah k :) | 08:10 |
| RAOF | I think we're also going to be getting some better stats via errors.ubuntu.com for SRUs, which might make things easier to justify. | 08:10 |
| RAOF | At least for crashes. | 08:10 |
| mlankhorst | we should ship 12.10 then, it reports no crashes :-) | 08:11 |
| seb128 | RAOF, they stopped doing the "proportion is verified" it seems | 08:11 |
| seb128 | RAOF, they want all green, where all green might just be the "no visible regression" for the ones that can't be verified | 08:11 |
| RAOF | seb128: I, at least, don't promote to -updates unless there's some verified fixes. | 08:11 |
| seb128 | RAOF, others don't promote unless there is *all* verified fixes (or with a rational of why they are ok even if not verified) | 08:12 |
| bryceh | RAOF, so if we did an upload of a point release which has 20 git changes, and link to 2-3 bugs confirmed as fixed by it, that'd be sufficient? | 08:12 |
| seb128 | bryceh, that's what we basically do for GNOME | 08:13 |
| seb128 | i.e the recent gtk update | 08:13 |
| RAOF | bryceh: As long as the point release changes aren't OMGSCARY, yeah. | 08:13 |
| bryceh | seb128, and you say you don't need any special exception for that? | 08:13 |
| seb128 | bryceh, no | 08:13 |
| bryceh | seb128, no you don't say that, or no you don't need an exception? | 08:13 |
| seb128 | it just needs to be looking with it on a risk,benefit perspective | 08:13 |
| seb128 | bryceh, sorry, we don't need any special exception | 08:14 |
| seb128 | they just review things in the queue and evaluate if it's appropriate for a SRU based on the diff and the rational, regression potential etc | 08:14 |
| bryceh | hmm, interesting. The times I've attempted it I always got push back that each and every change needed a bug # and separate verification | 08:14 |
| seb128 | was that a long ago? | 08:15 |
| bryceh | to the point it was ridiculous to try to get bug fix point releases in | 08:15 |
| seb128 | there was some pendulum swings there from too strict to not enough | 08:15 |
| bryceh | easier to just make a ppa with the new version and point bug reporters there. (thus the x-updates ppa) | 08:16 |
| bryceh | ok, well maybe I experienced it during the too strict phase and gave up at that point | 08:16 |
| seb128 | I think they are reasonable nowadays | 08:16 |
| seb128 | you should try one again and see how it goes | 08:16 |
| mlankhorst | bryceh: oh it's going to be fun to get xrandr in, I think the lib and bin will need to be sru'd if parts of hybrid graphics land this cycle. | 08:17 |
| bryceh | seb128, yeah like I mentioned above, usually pitti was the only one reviewing my sru requests, and he seemed pretty consistently strict about it. But now that others are participating in SRU review, perhaps its more reasonable in cases like these. | 08:18 |
| mlankhorst | but in any case I think synaptics could qualify as being pre-release. :P | 08:22 |
| mlankhorst | bryceh: Can you upload xserver-xorg-input-synaptics to quantal at least? | 08:29 |
| bryceh | mlankhorst, I am able to do that; are the necessary changes staged in git? | 08:37 |
| mlankhorst | Yes :) | 08:38 |
| bryceh | ok great | 08:40 |
| bryceh | mlankhorst, why are patches numbered from 201, rather than from 131? | 08:41 |
| bryceh | oh I see, they're to differentiate patches included in 1.6.2 | 08:41 |
| bryceh | mlankhorst, upload sponsored for quantal. | 08:52 |
| mlankhorst | Thanks! | 08:52 |
| aquarius | bryceh, my bug of xorg snowcrashing (#1003333) seems to have resolved itself, but I don't know *what* resolved it. I don't really want to say "hey, it doesn't happen any more, lucky eh!" and that's it on the bug report, but I don't know what information to provide that would actually be useful to you. | 13:32 |
| tjaalton | heh, there was a post about the new sru process to u-d-a@ earlier today | 15:21 |
| tjaalton | no mention of stable point-releases | 15:28 |
| jussi | hrm, my xorg is eating cpu atm - any ways I could tell why? | 15:39 |
| jussi | (its at about 50-60 %) | 15:39 |
| jussi | guess you are all asleep today. | 16:16 |
| tjaalton | it's some app doing that | 16:17 |
| Sarvatt | best humble bundle ever http://www.humblebundle.com/ | 17:01 |
| Sarvatt | woohoo for linux bastion! | 17:01 |
| Sarvatt | whoa its redeemable in the ubuntu software center | 17:06 |
| bryceh | aquarius, well, as there's not enough info to do diagnostics, if it's no longer reproducible just close the bug out. you can always reopen if it comes back | 17:50 |
| aquarius | bryceh, ok, I shall do. Sorry I can't provide more useful info! | 17:51 |
| jussi | tjaalton: how do I find outh which app? | 18:14 |
| tjaalton | jussi: you could try xrestop | 18:47 |
| jussi | tjaalton: thanks, I found the culprit - a popup flash based advert that I hadnt noticed was open on another desktop... | 18:55 |
| jussi | flasah is evil, no doubt about it | 18:55 |
| jussi | flash even | 18:55 |
| tjaalton | yeah I could've guessed it was the browser.. :) | 19:00 |
| bryceh | tjaalton, package_status is pulling quantal info now | 21:21 |
| tjaalton | bryceh: cool, thanks | 21:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!