/srv/irclogs.ubuntu.com/2010/12/20/#ubuntu-meeting.txt

=== nixternal_ is now known as nixternal
=== starcraft is now known as starcraftman
=== apachelogger is now known as fdsafdsafdsafdsa
=== fdsafdsafdsafdsa is now known as darthlulu
=== darthlulu is now known as apachelogger
=== fenris is now known as Guest79815
=== Guest79815 is now known as ejat
=== jussi01_ is now known as jussi
=== fenris is now known as Guest75398
cjwatsonoh 'eck, I'm supposed to be the DMB chair this week12:00
cjwatsonbdrung,cody-somerville,persia,geser,soren: roll call12:00
cjwatsonstgraber sent his apologies12:00
cjwatsonpoolie: just rounding folks up12:01
poolieok, thanks12:01
* barry waves12:01
* geser is "half" here (I'm at work)12:02
* cjwatson tries to get the Canonical holiday calendar to load12:02
cjwatsonif we can't manage quorum I'd rather know early so that poolie can go to sleep12:03
pooliethanks :)12:03
cjwatsonoh, soren said he'd be on holiday12:03
cjwatsoncome ON, canonicaladmin12:04
poolieheh :)12:04
barryindeed, it was pretty slow last week12:04
bdrungi am there now12:04
cjwatsonCody can't usually make these times, it's too early in the S12:05
cjwatsonUS12:05
cjwatsonso I think this only works if persia happens to be around12:06
barrycjwatson: 7am's not too early :)12:06
cjwatsonit is for him :)12:06
cjwatson9pm in .jp12:06
bdrung7 am would be way to early for me, too12:06
* barry too w/o a kid to get to school :)12:07
cjwatsonah, and Cody's on holiday today anyway12:07
cjwatsonEmmet's not known to be on holiday, but if he's not around by now, I'm not sure he will be12:07
cjwatsonI'll wait until :10 and then declare this meeting cancelled if we aren't quorate12:07
poolieperhaps, in the event we don't reach quorum, people who are here could give some nonbinding opinions on my applications12:08
poolie*application12:08
poolieor, guidance as to what to do12:08
cjwatsonI already made some comments, and said last time:12:09
cjwatsonhttp://irclogs.ubuntu.com/2010/12/06/%23ubuntu-meeting.txt:[20:38] <cjwatson> I have no complaints or questions but I know some people like to talk to applicants in person12:09
cjwatsonbdrung,geser: would either of you like to comment on any of the applications before us?12:09
cjwatsonthat's https://wiki.ubuntu.com/MartinPool/DeveloperApplication, https://wiki.ubuntu.com/BarryWarsaw/MyApplication, and https://wiki.ubuntu.com/AngelAbad/MOTUApplication12:09
bdrungyes12:10
geserpoolie: do you expect more person to apply for bzr (and related) upload rights? so cjwatson should make a bzr packageset12:11
poolieactually yes, that seems to make sense12:11
pooliethere is a set of bzr and closely-related packages that are likely to be uploaded together12:11
cjwatsonmaxb comes to mind12:12
cjwatsonalso jelmer12:12
poolielifeless12:12
poolieand, perhaps other people in future12:12
* jelmer waves12:12
cjwatsonyes12:12
pooliei guess lifeless and james are(?) already core devs, so this would be redundant12:13
cjwatsonlifeless is already motu but not core-dev12:13
jelmercjwatson: I've actually been meaning to apply for PerPackageUploader-ship but haven't finished my application yet.12:13
cjwatsonjames_w is a core-dev, yes12:13
cjwatsonbut with a reasonably plausible team of four+ that would certainly be worth creating a package set12:13
cjwatsonI think that also perhaps makes poolie's application simpler; he doesn't have upload history on all the packages, but they do form part of a coherent theme12:14
pooliethe main thing i want to do with this is to propose MinorReleaseException candidates for a SRU12:14
geserpoolie: how much involved are you in packaging bzr? I ask because LP shows only one sponsored bzr upload for you and the debian/changelog doesn't mention you12:14
poolieat the moment, we do stable releases that are supposed to be suitable for getting in to Ubuntu updates but they seem to be stalling12:15
pooliegeser: i have done packaging for it into the ppa in the past12:15
pooliemost of the time either maxb or jelmer has uploaded into debian (since they are, iiuc, dd's), and it's flowed from there12:16
geserwould having you PPU upload right change the workflow much (first to Debian and then sync to Ubuntu)?12:17
pooliei think the particular thing it would change is that i could execute step 4 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure12:18
poolieie uploading to -proposed12:18
geserdo the PPA packages differ much from the "official" ones? (I'm trying to judge your packaging skills)12:20
gesercjwatson: would you need to also create bzr package sets for the released Ubuntu versions (if it's possible) to allow poolie to upload to -proposed?12:21
pooliegeser: no, they normally track pretty closely12:22
cjwatsonI think so, and yes it's possible12:22
cjwatsonalbeit unpleasantly manual12:22
poolieas i said on my application, most of what i've contributed to debian and ubuntu has not been packaging-specific work12:22
pooliei don't know if that's just a kind of blindness on my part, or just that i tend to fix bugs that are in the source itself not in packaging-12:23
pooliei'm very happy with getting review/mentorship/whatever and taking things carefully12:23
poolieit just seems to me that doing that within the context of PPU may flow more easily than just asking on the bug12:23
pooliewhich does not seem to be working very well atm12:23
bdrungpoolie: are you member of the Debian Bazaar Maintainers team?12:25
poolieno12:25
pooliei'm not a dd (i'm not sure if that's a necessary condition)12:25
jelmerpoolie: it's not necessary, we'd be happy to have you as a member12:26
poolieah ok12:26
pooliewhat should i do?12:26
=== Ursinha-afk is now known as Ursinha
bdrungpoolie: as member you gain commit access. then you can commit your changes and once a package is ready for upload, you can ask to review and upload12:27
jelmerpoolie: Create an account on Alioth (http://alioth.debian.org/) and request to join the team at https://alioth.debian.org/projects/pkg-bazaar/12:28
poolieok, i'll do that12:29
cjwatsonpoolie: as a general rule what times suit you?  rather than keeping you up again I think we should try to arrange a special meeting12:30
cjwatsongiven the timezone difficulty12:30
pooliei'm normally awake/online-ish from about 0800 to 1900 in utc+1112:32
poolieup until about this time of day is reasonable; after midnight (+30m from now) tends to mess up the next day12:32
cjwatsonso 2100-0800 UTC.  I think we'd want to aim for either end of that for maximum board-member coverage12:33
bdrungcjohnston: 0800 UTC is better than 2100 UTC?12:33
gesertab-fail :)12:34
bdrungdamn, tab completion12:34
poolie0800utc is fine with me12:34
cjwatsonbdrung: possibly, I was just looking up the results from the last time I asked people12:34
barrypoolie: thanks for the endorsement!12:34
poolieyou're welcome12:34
bdrungcjwatson: i prefer 2100 - 2300 UTC12:35
cjwatson0800 would lose cody-somerville and I think stgraber too12:35
cjwatsonI could make it, I imagine everyone else in Europe could, it's probably OK for persia too12:35
cjwatson2100 is presumably good for cody-somerville and stgraber, I can make it at least on some days, bdrung can, not sure about persia as it's 0600 there, soren said he could make that time range before12:36
geser2100 - 2300 UTC suit me much better than 0800 UTC as I'm usually awake till 0000 UTC12:36
cjwatsonso I agree, 2100 UTC seems better on average12:36
pooliethat's even easier for me12:36
cjwatsonpoolie: if you could send a mail to developer-membership-board@ suggesting that time and some days in the new year, then, that would be great12:37
pooliei could do it tomorrow, or the day after, or otherwise the new year12:37
cjwatsonand we can get things sorted out12:37
cjwatsonI suspect holidays will intervene if we try to do it this year, unfortunately12:37
poolieok12:37
gesercjwatson: I guess a "python" package set (for barry) would be a management nightmare, right?12:38
pooliedo the board members who are present feel this is basically on track to be approved?12:38
cjwatsonI suspect so12:38
geserpoolie: I'm not fully decided yet, I'd prefer to see your name mentioned more often in debian/changelog (or sponsored Ubuntu uploads)12:39
barrygeser: i made such a suggestion a month or so ago, but didn't get much response on it, so i gathered it wasn't a popular suggestions ;)12:39
cjwatsonI can't speak for everyone else; constructed as a package set, I think it has a good chance12:39
bdrungpoolie: i have a little concern if you have enough packaging experience.12:39
poolieok, that's useful, i can work towards making sure that does show up more often12:41
bdrungpoolie: your name in debian/changelog and your name as Uploader (for packages maintained in Debian) are a sign for packaging skills12:42
cjwatsonI would say that the bzr packaging is not generally particularly complicated, and I'm more concerned about general level-of-caring / ability to deal with bugs; given that poolie created bzr I'm not sure there's anyone more able to meet those criteria12:42
cjwatsonbut I realise I probably focus less on upload history than other people here12:44
pooliei guess it's not for me in this situation to tell you how to review people12:44
cjwatsondoes anyone have any comments on barry's application?12:44
pooliebut, when i grant access, i tend to go a lot more by "not likely to do anything rash/malicious"12:44
geserbarry: I'm with micahg's comment that 26 uploads (which are mostly python related) are a very few for a "core-dev"12:46
bdrungre barry: i like to see one step before becoming core-dev. a python set would seams to be the right thing for me.12:46
cjwatsongeser: *blink*12:46
cjwatsonbdrung: I'm not prepared to manage a python set12:47
cjwatsonvery many of our present core-devs had fewer than 26 uploads before joining12:47
gesercjwatson: upload history is often a good source for judging packaging skills (getting mention in debian/changelog an other)12:47
cjwatsonbut it's not the only one, and it's not even necessarily the most important one12:47
cjwatsonwe should not laser-focus on it12:48
barryi've had a ton of ppa uploads, though i tend to keep them pruned over time12:48
barryagreed that i've been python focused, but that kind of makes sense given my background and the ongoing py27 transition :)  i do plan on diversifying once that gets more stable12:48
barrygeser: but i get that more, and different, experience can't hurt my application.  thanks12:50
bdrungbarry: re python: i am missing a policy document for what is recommended.12:50
barrybdrung: sorry, i don't understand12:51
bdrungbarry: we want to move to dh_python2 with ubuntu-dev-tools. i was searching for documentation what needs to be put into d/control12:52
barrybdrung: ah. yes, we do need to update the debian python policy for that iirc.  i can work with debian-python to get that in.  there's a number of places that i think need updating to discuss/promote dh_python212:53
bdrungbarry: for example: should we use XS-Python-Version, XB-Python-Version, X-Python-Version? on which package do we have to depend if we want to use dh_python2?12:55
* tumbleweed sticks his nose in12:56
tumbleweedbdrung: we also need some lintian checks for those at some point...12:56
barryx-python-version is recommended, and debhelper (>= 7.0.50~) is i believe the necessary dependency12:56
tumbleweedbdrung: there are also versioned dependancy requirements on python(-all)12:56
tumbleweederr, barry12:56
barryright (i was assuming that, but you know what that say about "assuming" :)12:57
bdrungit would be nice to have that in the python policy12:57
barrybdrung: totally agreed12:57
barry(it's on my todo list now)12:57
gesercjwatson: I try to not focus on upload history alone, but in barry's case the endorsements are also mostly python related (and few, so I don't have much data for judgement)12:59
cjwatsonOK.  I'm going to call it a day here since we can't decide anything anyway, but I encourage people to continue these conversations on other channels12:59
cjwatsongeser: that doesn't bother me for core-dev.  it's broad enough.12:59
bdrungcjwatson: for MOTUs we want to see a full range of activities like sync requests, merges, SRUs, ..., but for core-dev a specific knowledge is enough?13:01
cjwatsonbdrung: it's not that specific13:02
cjwatsonanyway, I give up.  it's obviously the DMB's desire that it be impossible to gain core-dev.13:02
gesercjwatson: before you leave, we should call for new DMB candidates (with christmas and vacations now)13:02
cjwatsonthis is exceptionally frustrating for me.13:02
cjwatsonI don't think I would have bothered applying for core-dev under the current system.13:03
pooliebdrung, geser: may i ask you if, considering barry's application, you think it's very likely that he will make either malicious or careless changes to Ubuntu?13:03
poolie(and if so, what kind of situation you'd fear might happen)13:03
bdrungcjwatson: Things are never as bad as they seem (or as we say in German: Es wird nichts so heiß gegessen, wie es gekocht wird)13:04
cjwatsonbdrung: this has been going on for far too long13:05
cjwatsonit has been frustrating me for a long time13:05
cjwatsonI've seen too many developers wasting time for months on end because our process is just too bureaucratic and scary13:05
cjwatsonso they never bother applying13:05
cjwatsontoo much great talent going to waste13:06
bdrungcjwatson: do we have some guidelines listing the criteria for getting upload rights?13:06
cjwatsonhttps://wiki.ubuntu.com/UbuntuDevelopers is the best we have13:06
tumbleweedpoolie: I've seen barry make one or two common mistakes all (new?) debian/ubuntu developers make (i.e. not closing bugs in changelogs, poor version number choices). Not exactly serious stuff, just things that get less likely with packaging experience. I'm not *worried* about him as a core-dev, though.13:07
poolieso, if he was a core dev, he would probably make some minor or common mistakes13:07
pooliehe would probably do more packaging and thereby accumulate experience faster?13:08
gesercjwatson: do you feel that we require to much "proof" of experience instead of relying more on endorsements?13:08
barrytumbleweed: agreed. one of the things i'm interested in is helping to make our tools better so those kinds of common mistakes don't happen. e.g. the syntax for bug closing is pretty strict, a typo will screw it up13:09
cjwatsonI think we focus on the wrong kinds of experience13:09
tumbleweedpoolie: probably, but having someone review your uploads means you are less likely to get into bad habits13:09
cjwatsonsure, poolie doesn't have many uploads.  but look how much experience he has with bzr, the centre of the proposed package set in question13:09
cjwatsonand for that matter barry's a stalwart of the upstream python community and has been for a long time13:10
gesercjwatson: we should focus more on the communication skills ? (e.g. asking on IRC or mailings lists if one has doubts about a change?)13:10
barryi'm also involved w/dholbach's efforts at a new packaging guide.  our current set of wiki guidelines are fairly disjoint, and oddly too much of the wrong kind of detail13:10
cjwatsonin those cases I think we really just need to make sure they aren't hopelessly confused and aren't likely to screw things up too badly.  the fact that they're experienced developers should count for a lot more.13:10
poolietumbleweed: so the concern behind that is that if someone has core-dev membership or whatever, they will never get reviews, or never seek mentorship?13:10
poolie(that may well be empirically true, for all i know; i'm just trying to make the assumptions explicit)13:11
cjwatsonany experienced upstream developer is going to care about the state of the software and is likely to be mature enough to ask for help if they need t13:11
cjwatson*it13:11
cjwatsonour current practice essentially says "we don't want upstream developers to get involved"13:11
cjwatsonthat may not be the intent but that's the effect13:11
cjwatsonbecause we don't bother crediting that kind of work13:11
pooliegeser: in my experience as a developer, if somebody has a pattern of changing things _without_ communicating or asking13:12
poolieespecially when they should have known to ask13:12
cjwatsonand this depresses me because those are the sorts of people we need more of in the Ubuntu community13:12
geseris packaging really that comparable with upstream development?13:12
tumbleweedpoolie: it is a worry I have when I endorse people who I haven't seen ask for help. But I think enough people follow -changes and will question thigs.13:12
pooliethat's a huge red flag - in fact pretty much the most important one13:12
cjwatsonso we develop a self-congratulating community of people who know how to sync and merge stuff13:12
cjwatsonwhich is all well and good but it's not the centre of everything13:12
cjwatsongeser: yes13:12
cjwatsonit's all code13:12
cjwatsonsure, different tools, different details, it does have to be learned13:12
poolietumbleweed: right, i think reading -changes is very healthy13:13
cjwatsonbut if you look at the packaging diff for your average bzr upload, it's not exactly that hard13:13
cjwatsonif we perpetuate a myth that packaging is hard, people will think it's hard13:13
cjwatsonit's not13:13
poolieright, months go by with nothing more than a version bump13:13
cjwatsonit's no harder than your average upstream build system13:13
barryre: -changes, see my recent suggestion about diffs that i think would actually help upstreams feel more comfortable and participate more13:13
macocjwatson: and to anyone who's looked at autotools stuff, id say easier...13:14
cjwatsonwell, let's not focus on autotools, I find autotools quite natural13:14
geserperhaps I'm too biases with sometimes seeing upstream fighting with packaging in #ubuntu-motu and #ubuntu-packaging (or when occassionally looking at REVU)13:14
cjwatsonbuild systems are very much personal preference13:15
bdrungpackaging is simpler than setting up autotools13:17
barrythe interesting thing is that packaging, specifically d/rules is where the crazy wild west of upstream build systems meets the much more controlled environment of deb/ubu building.  deb/ubu packaging is not hard once you learn the basic guidelines, but d/rules can be quite insane13:17
pooliegeser: i think there probably is some amount of fighting through failing to understand13:18
bdrungbarry: having an upstream source that uses three commands to build and install the package, makes d/rules simple13:18
pooliei've seen some awful packaging into third-party debs or rpms for instance13:18
barrybdrung: very true.  upstreams don't always cooperate though ;)13:18
pooliebut, what are you going to do about it? keeping upstreams out is not a very scalable answer13:18
barryotoh, as simple as 90% of upstream python packages are (or can be), i've seen lots of cruft in the d/u packaging of some python packages.13:19
barryi would *love* to be at a place where 90% of python packages have a 3 line d/rules file, but we're not there yet13:20
bdrungi recommend to simplify d/rules and create patches to achieve the same and send those patches to upstream.13:20
barrybdrung: most likely to debian13:21
cjwatsonthere is a trap here where we fail to distinguish personal packaging preferences from quality requirements13:21
cjwatsonit's still perfectly acceptable for people to use pre-dh debhelper, for instance13:22
tumbleweed(and probably more understandable for less experienced packagers)13:22
cjwatsonif they were doing the whole thing by hand without any helper at all?  these days, that most likely indicates a lack of familiarity with the tools13:22
cjwatsonbut we certainly aren't at the point where we can say that if you aren't using dh rules.tiny or cdbs then you're Doing It Wrong13:23
barryit's definitely true that dh has a lot of "magic", which can be good since folks don't need to worry about a lot of detail, but very bad when they do (because it's very undiscoverable)13:23
cjwatsonanyway, I'm going to take my frustration to mail, I think13:26
pooliei'm going to take mine to bed :)13:26
pooliei hope you will send that mail though13:26
barrythanks for the feedback guys13:27
pooliesame here13:27
=== fenris is now known as Guest44826
gesercjwatson: looks like there is a too big divergence on what to expect from each applicant13:27
=== Guest44826 is now known as ejat
angelabadsorry, but, what about my application?13:32
geserangelabad: we aren't quorate today13:33
angelabadgeser, ok, so I must wait for the next meeting?13:34
bdrungangelabad: yes13:35
angelabadok, no problem.13:35
geserangelabad: don't worry, the other have to wait too (it's only an informal discussion)13:37
angelabadok, thanks13:38
=== Ursinha is now known as Ursinha-lunch
=== JanC_ is now known as JanC
=== Ursinha-lunch is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
mdeslaurhello18:04
keesjdstrand, sbeattie: meetin' time?18:06
mdeslaurhiya kees! :P18:06
* mdeslaur is excited18:06
kees     [0;1;34;94m▌[0m18:06
kees[0;1;34;94m▞▀▖[0m [0;1;34;94m▞[0m18:06
kees[0;34m▌[0m [0;34m▌▞[0m18:06
kees[0;34m▝▀[0m [0;34m▘[0m18:06
jdstrandsure18:06
mdeslaurwth is that18:07
mdeslauransi art?18:07
keesvt100 colors and unicode characters for a 4-line version of   o/18:07
mdeslaurah, well that explains why I can't see it :)18:07
jjohansenhehe, /me neither18:08
keesuhm, okay, starting.18:09
keesso, I've been fighting filesystem corruption on my debmirror. I think I'm hitting bugs in either the kernel's LVM, md, or ext4 or in e2fsprogs.18:10
keesso that's slowing me down.18:10
mdeslaurkees: that narrows it down :)18:10
* jjohansen hides18:10
jdstrandkees: way to narrow it down :P18:10
keesI've still got more auditing work to do.18:10
keesmdeslaur: yeah18:10
jdstrandmdeslaur: haha18:10
mdeslaurhehe18:10
keesI suspect it's the online resizing, actually.18:11
keesanyway, my week is kind of open for pre-year-end interrupts.18:12
keesI'd like to clear the audit queue18:12
keesbut anyway, that's it. mdeslaur is up18:12
mdeslaurso18:13
mdeslaurtoday's my last day before I go on holiday18:13
mdeslaurI'll be officially back on the 3rd18:14
mdeslaurbut since I suck, I'll probably be here anyway18:14
mdeslaurtoday, I did a cve run and will do some triage18:14
mdeslaurthat's it!18:14
mdeslaurjdstrand: your turn18:14
jdstrand\o/18:15
jdstrandso, I start my end of year holiday on thursday, and will be back on the thrid18:15
jdstrandthird18:15
jdstrandI will take over triage and community from mdeslaur tomorrow and wed18:16
keesI can do it thu18:16
jdstrandas for work this week, I am not planning security updates, unless something big comes up18:16
jdstrandI plan to continue on my apparmor documentation tear18:16
keesjdstrand: that's rocking, btw :)18:17
jdstrandand possibly look at the dbus stuff again18:17
jdstrandkees: thanks!18:17
jdstrandthat's it from me18:17
jdstrandjjohansen: are you here this week at all?18:17
jjohansenyeah18:17
jdstrandjjohansen: cool. I'll likely poke you about some doc updates I'm working on today18:18
jjohansensounds good18:18
keesso, for apache mod_apparmor18:22
jdstrandyes?18:22
keesshould we try to write upstream tests, qrt tests, or some combo?18:22
mdeslaurwe had talked about writing qrt tests18:23
jdstrandqrt seems a natural fit since we need apache around to test it18:23
jjohansenkees: both18:23
keesthe apache-server-running infrastructure exists in qrt, so putting it in upstream would be irritating :)18:23
mdeslaurmaybe upstream tests would be more appropriate...but we would need apache18:23
keesjjohansen: okay18:23
jdstrandthough, sbeattie mentioned there is some stuff that could be added upstream as well18:24
jjohansenI think upstream should have some tests but they just don't get launched by default18:24
keesperhaps start with qrt since it's easier to get up and running and work from there?18:24
jjohansenand you need apache setup18:24
jjohansenyes18:24
jdstrandah18:24
jdstrandthat would work with qrt anyway-- we just setup apache and then run the upstream tests18:24
jdstrandkinda like we do for some of the other test suites18:25
jdstrandthat should be added as a WorkItem if it isn't already18:26
jdstrandI'll add it18:26
keesokay, thanks everyone!18:28
jdstrand(added)18:28
mdeslaurthanks!18:28
jdstrandthanks kees!18:28
=== niko is now known as Guest41080
=== nik0 is now known as niko
=== yofel_ is now known as yofel

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