/srv/irclogs.ubuntu.com/2013/04/01/#ubuntu-meeting.txt

=== freeflyi1g is now known as freeflying
=== emma_ is now known as em
=== doko_ is now known as doko
=== lala_ is now known as lalatenduM
=== jcastro_ is now known as jcastro
=== highvolt1ge is now known as highvoltage
=== Ursinha_ is now known as Ursinha
=== Pici is now known as ZarroBoogs
=== huats_ is now known as huats
=== pgraner` is now known as pgraner
=== inetpro_ is now known as inetpro
stgrabersoren: ping20:01
soreno/20:01
soren#startmeeting Technical Board20:01
meetingologyMeeting started Mon Apr  1 20:01:44 2013 UTC.  The chair is soren. Information about MeetBot at http://wiki.ubuntu.com/meetingology.20:01
meetingologyAvailable commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired20:01
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic:
sorenSorry I20:01
stgraberhi soren!20:01
sorenm late. Massive technology fail at my house right now.20:01
sorenOne internet connection, luckily I had backup.20:02
sorenBluetooth keyboard dead.20:02
sorenLuckily, I have a backup.20:02
sorenThere's a pattern there somewhere.20:02
sorenAnyway.20:02
stgraberwell, let's hope it won't get any worse during the meeting then ;)20:02
sorenWelcome.20:02
sorencjwatson, mdz, kees: ?20:02
stgraberlooks like pitti is off IRC today20:03
sorenYeah.20:03
sorenSorry, don't have all my bookmarks on this backup laptop, so digging around a bit.20:03
soren#topic Action review20:04
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Action review
sorenwait for it..20:04
sorenI don't see any action items in the minutes?20:05
sorenMoving on.20:05
soren#topic MRE for Xserver20:05
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: MRE for Xserver
sorenWho's representing?20:06
ScottKsoren: Review of Mark's release reorg proposal didn't get finished last time.20:06
sorenScottK: Alright, let's talk about that next.20:06
sorenJust pinged bryce in #ubuntu-devel.20:07
sorenI guess we can talk about the missing points from Mark's proposal until Bryce turns up.20:07
sorenOh.20:07
sorenbryce: Hi :)20:07
brycewas just wondering about this20:07
brycehi soren20:07
sorenbryce: So we were just starting on this topic now.20:08
mdzsoren, here20:09
sorenhttps://lists.ubuntu.com/archives/technical-board/2013-March/001559.html20:09
soren#link https://lists.ubuntu.com/archives/technical-board/2013-March/001559.html20:09
sorenHas everyone had a chance to read it?20:09
sorenI've read it, but I must say I feel limimited by my ignorance of how all these things fit together.20:10
brycesoren, happy to answer questions20:10
sorenDoes anyone feel sufficiently informed to be able to ask intelligent questions? :)20:10
stgraberI just did and I personally think it's entirely reasonable20:10
stgraberbryce: do I remember correctly that you also run some kind of tests against the cert lab?20:11
brycewe've been doing SRUs of xserver patches for years, and have found the upstream microreleases themselves to be well done now (better than some years ago).  The one reason we hadn't requested MRE in the past was due to lack of test frameworks, but over the last couple years that's been fixed.20:12
brycestgraber, not me personally.  there are tests that could be run, but don't know if the cert lab runs them.20:12
brycestgraber, we do run the tests locally on our own hardware though.20:13
stgraberbryce: ah, that may have been that. I remember that for mesa at least you said you'd pretty good coverage of the various vendors to do hardware testing before actually pushing an SRU20:13
bryceyep20:14
sorenI'm not entirely sure I understand the scope of this request.20:15
bryceand our proposal is to handle the xserver testing the same way as we're doing with mesa, since that process seems to be working out quite well20:15
sorenThe title says "xserver", but is it really all the various xserver-xorg-video-* drivers, too?20:15
stgraberbryce: do you have a list of source packages that'd be covered by that MRE?20:15
brycesoren, no just the xorg-server package20:15
sorenHm. Ok.20:16
brycestgraber, this is only for one source package - 'xorg-server'20:16
stgraberk20:16
sorenI'm a bit puzzled.20:16
brycesince it's just micro releases, those are just bug fixes so never any impacts on any other source packages.20:16
sorenSo these aren't drivers at all.20:16
brycenope, just the server20:16
sorenOk.20:17
sorenWell, in that case: Sure, no problem at all.20:17
brycefrankly the X drivers don't really have much "interesting" code left in them.  We rarely SRU X driver fixes any more.20:17
brycethe "interesting" driver code is now included in the kernel, so those fixes are already taken care of by the normal kernel processes20:18
sorenAre those things mostly in the kernel, then?20:18
sorenOr this "mesa" thing that everyone talks about?20:18
soren:)20:18
bryceah, tldr version is, there's really 3 drivers for graphics - one in the kernel (drm kms), one in mesa (the 3D stuff), and one in X (the 2D 'DRI' drivers)20:19
brycethese days it's the 3D drivers and kernel drivers where all the interesting bugs are.  The 2D X bits tend to be fairly boring and stable.20:19
sorenI see.20:20
sorenCool, thanks for clarifying.20:20
sorenWell, that clears up all my concerns, really.20:20
sorenIf it20:20
soren's just xserver itself, I'm cool with it.20:20
sorenAnyone else?20:20
stgraberI'm perfectly fine with the current proposal20:21
stgrabermdz, cjwatson, kees: ^20:21
mdzsounds more than reasonable20:21
sorenI'll give them a minute to weigh in.20:21
sorenAlright, sold.20:22
sorenDoes anyone want to do the honours of updating the wiki?20:22
sorenOtherwise I'll do it as part of doing the minutes.20:22
sorenbryce: Thanks for your time!20:23
brycesoren, thank you!  :-)20:23
soren#topic PArts of Mark's proposal that were missed in the last meeting20:23
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: PArts of Mark's proposal that were missed in the last meeting
mdzsoren, I'lldo it20:23
sorenScottK: Care to elaborate.20:23
sorenmdz: Thanks very much!20:23
ScottKWe covered support period for regular releases.20:24
ScottKWe covered terminology (regular/LTS)20:24
mdzsoren, oh, hmm, it ought to have a link to the minutes in there, so it's probably better if you do it after you've posted them20:24
sorenmdz: Ah, good point.20:24
sorenmdz: Thanks for trying :)20:24
stgraberScottK: and we covered the "devel" symlink to current dev release too20:25
ScottKYes.20:25
ScottKStill typing.20:25
* stgraber waits20:25
ScottKWe also considered the discussion about kernel updates as ~ what we do now.20:25
ScottKI think there was informal consensus that the rapid moving stuff he refers to should either be done through backports if appropriate ofr PPAs.20:25
ScottKNo new "rules" needed.20:26
ScottKI think the significant point of action that remained was on the point about updates to libraries in an LTS if the API is "stable"20:26
ScottKerr20:26
ScottKrequired upgrades to newer versions of platform components,  ...20:26
ScottKThat's how it starts.20:26
ScottKI think that's the one point remaining that would require a policy change to execute.20:27
sorendo you happen to have a link handy to the entire thing?20:27
ScottKSure20:28
ScottKhttps://lists.ubuntu.com/archives/technical-board/2013-March/001527.html20:28
soren#link https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html20:28
mdzyes, I believe we covered #2 and #3 and did not start on #120:29
mdz(in the previous meeting)20:29
stgraberso on principle I'm not completely opposed to the proposal of updating to newer versions of core components provided they don't change API or the way user interact with those, for example changing a command line tool and causing options to get renammed/removed/changed isn't acceptable to me20:29
sorenScottK: Thanks for the introduction to the topic.20:29
mdzas ScottK says, it seems like the first point under #1 doesn't require a policy change20:30
ScottKWe did discuss this in Kubuntu and came to this position: https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html20:30
stgraberand I personally think that the Unity example in the e-mail is a rather bad one as at least for me Unity isn't associated with stable API and no change visible to the user ;)20:30
mdzstgraber, I agree in principle, though I'd be a bit concerned about the practicality of auditing interfaces20:30
soren#link https://lists.ubuntu.com/archives/technical-board/2013-March/001553.html20:30
ScottKI am particularly concerned about this point since base on our experience with Qt4 in Kubuntu, we are pretty dead certain that post-release updates to Qt (4 or 5) are a REALLY bad idea.20:31
sorenAuditing interfaces as well as defining which interfaces are considered "key".20:31
ScottKIt's not just the interfaces that need to be stable.  It's the behavior behind the interfaces.20:32
mdzthat's part of the interface, as I'm using the term20:32
ScottKUpdating core components seems to me to be approximately the oppposite of what one would want to in an LTS.20:32
ScottKAfter all, people use LTS instead of the regular release because they want stability and consistency.20:32
sorenWell, sort of.20:33
stgraberI also have the feeling that allowing this and having the SRU team do the very close auditing required by such things would in practice be more time consuming than cherry-picking the fixes and getting explicit approval for absolutely required API additions20:33
sorenIt's not uncommon to have LTS users ask for new versions of things. They expect it to t be longlived more than strictly consistent.20:34
sorenWe've traditionally considered this view to be ultimately incoherent.20:34
sorenBut it's certainly not an uncommon view, there is /some/ divergence in what people expect of an LTS.20:35
ScottKsoren: Right.  They often want the thing they want to be new and everything else to be stable.20:35
sorenScottK: Spot on.20:35
stgraberright, wanting LTS and wanting the latest version of the system doesn't quite work ;) leaf packages can be backported and we should try and encourage that. For specific self-contained stacks, PPAs also work rather well, but getting newer versions of core/heavily-shared components is very risky business20:35
sorenIndeed.20:36
sorenI wonder if there would be a useful way to grant an extended MRE for certain things.20:37
sorenLike unity as in Mark's example.20:37
soren"Extended MRE" == and MRE that isn't limited to micro releases.20:37
ScottKIn Kubuntu we generally backport KDE major releases to previous releases in a PPA.  It's quite popular, but it also frequently comes with regressions.20:37
* ScottK would never do it in the Ubuntu archive.20:38
ScottKsoren: Such an exception exists for clamav, so it's been done before.20:38
ScottKThat is a pretty unusual case though.20:38
sorenWhen applying for such an exception, the APIs would need to be specified in the request.20:38
sorenAnd ideally some sort of external API test suite should be provided that would help us verify that the API indeed doesn't change.20:39
ScottKThe clamav one was more about regression testing to validate consistency of behavior.20:39
sorenScottK: clamav was special in many ways. The exception was granted not because of someone's desire for newer, cooler stuff, but simply out of necessity since new databases woudln't work with older clamavs.20:40
ScottKAgreed.20:40
sorenSo while the technicalities might be related, the motivation was entirely different.20:40
ScottKSome exceptions you grant because upstream is sane.  Sometimes it's the opposite.20:41
soren*g*20:41
sorenI feel that this is something that we must consider on a case-by-case basis at the TB level.20:42
sorenPerhaps Unity would be a good guinea pig (if we're willing to entertain the concept at all).20:42
sorenDoes anyone feel qualified and motivated to write up a more specific proposal?20:43
ScottKPersonally, I'm deeply concerned that someone will think this is going to be a wonderful approach for Qt5 in 14.04 and I'm pretty sure it won't.20:43
sorenScottK: I'm confident your opinion on that subject will have an impact on any decision on the subject.20:44
ScottKIf I had a vote, I'd vote for maintaining the current policy - in the Unity case, the safe performance patches have already be backported vai SRU.20:44
ScottKI'd suggest to defer deciding on it until there's an actual case that needs it.20:45
sorenThe proposal as given in Marks e-mail is too vague for us to vote on it.20:45
ScottKThen the TB can evaluate that and see what they think both about it and a more general policy.20:45
sorenI'm cool with that. It seems like we're generally willing to at least consider it, so if anyone wants to pursue it for a particular component, they should be encouraged to propose it.20:46
sorenDoes anyone else have anything to say on this subject?20:47
sorenGuess not.20:48
stgrabernope. I'm always happy to discuss specific exceptions to our policies and I agree that for this, it's probably best to wait until someone actually need it before we go ahead and discuss changing policies.20:48
sorenExcellent.20:49
sorenMoving on.20:49
soren#topic Scan the mailing list archive for anything we missed (standing item)20:49
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Scan the mailing list archive for anything we missed (standing item)
* soren does so20:49
sorenI don't see anything.20:49
soren#topic Check up on community bugs (standing item)20:49
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Check up on community bugs (standing item)
sorenNone.20:49
sorenYay.20:49
soren#topic Select a chair for the next meeting20:50
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Technical Board Meeting | Current topic: Select a chair for the next meeting
sorenI've completely lost track of the order20:50
mdzI believe stgraber is next20:50
stgraberyep20:50
sorenstgraber: You're next according to my alphabet, but you seem to have been chairing a lot recently :)20:50
sorenAlright.20:51
stgrabersoren: I think I only chaired once in January so far, so I don't mind chairing the next one if that gets us back in alphabetical order ;)20:51
sorenCool :)20:51
stgraberand TB meetings are way easier to chair than DMB ;)20:51
sorenErr... What's the meetbot magic to denote decisions?20:52
stgraber#agreed?20:52
sorenYes! That!20:52
soren#agreed stgraber to chair next meeting20:52
sorenstgraber: Thanks :)20:52
sorenAny other business?20:52
sorenAlright, thanks for showing up everyone.20:53
soren#endmeeting20:53
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Apr  1 20:53:09 2013 UTC.20:53
meetingologyMinutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-04-01-20.01.moin.txt20:53
meetingologyMinutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-04-01-20.01.html20:53
stgraberthanks!20:53
=== Ursinha is now known as Ursinha-afk
=== Ursinhal is now known as Ursinha
=== Ursinha-afk is now known as Ursinha

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!