09:00 \sh         it's 20:00 UTC...welcome ladies and gentlemen
 === zul [] has
 joined #ubuntu-meeting
 09:00 zul         heylo
 09:00 ogra_ibook  :)
 09:00 sistpoty    hey ogra_ibook
 09:01 raphink     hi ogra_ibook
 09:01 raphink     hi zul
 09:01 sistpoty    ok, anyone volunteering to do the minutes?
 09:01 lucas       * silence *
 09:02 raphink     * more silence *
 09:02 Riddell     like a Quaker meeting this
 09:02 raphink     hi Riddell
 09:02 \sh         sistpoty: i'll do it when it's ok if I send later this week
 09:02 sistpoty    cool, thx \sh
                   let's start with discussion... who made the first point
 09:03 sistpoty    /usr/share/common-licenses/GPL vs
 09:03 siretart    hu folks
 09:03 sistpoty    hi siretart
 === janimo [] has joined #ubuntu-meeting
 09:03 raphink     I did sistpoty
 09:03 Riddell     start with names no?
 09:03 sistpoty    then go ahead, raphink ;)
 09:03 \sh         yes
 09:03 \sh         please state your names
 === sistpoty is StefanPotyra
 === dholbach is Daniel Holbach
 === \sh is Stephan Hermann
 === crimsun is Daniel Chen
 === chninkel is Yann Rouillard
 === raphink is Raphael Pinson
 === LaserJock is Jordan Mantha
 === janimo is Jani Monoses
 === lucasd is Lucas Duailibe
 === Riddell is Jonathan Riddell
 === lucas is Lucas Nussbaum (LP: nussbaum)
 === zul is Charles Short
 === ogra_ibook is ogra on th eibook :)
 09:04 dholbach    wow, full house
 09:04 sistpoty    :)
 === siretart is Reinhard Tartler
 === Mithrandir is Tollef Fog Heen, but not really present
 09:04 lucas       lrwxrwxrwx 1 root root     5 2005-10-02 23:23 GPL -> GPL-2
 09:04 lucas       -rw-r--r-- 1 root root 17989 2005-06-16 16:32 GPL-2
 09:05 lucas       what do you suggest, raphink ?
                   the first poing comes from some talks on #ubuntu-motu about
                   the license link in debian/copyright. This seems like a small
 09:05 raphink     issue but not everbody seem to have tyhe same opinion of it.
                   I looked in Policy for this and found only notices about the
                   GPL file, not GPL-2
 09:05 raphink     so it seems like GPL is a link to the latest version of GPL,
                   currently GPL-2
                   I wanted to point that out since many seem to belive that
 09:05 raphink     packages licensed under "GPL v2 or later" should point to
 09:05 raphink     this doesn't matter so much now
 09:06 raphink     but GPL-3 is to be out in a matter of months, if not weeks
 === lucas thinks we should leave Debian decide about this, since changing this
 requires changing a lot of packages
 09:06 raphink     so we'd better have clear policy on this link in copyright
 09:06 lucas       GPL v3 won't be released before a year or so
 09:06 lucas       it's only the reviewing process that starts next monday
 09:06 raphink     lucas : my point was mainly about REVU so far since we also
                   release new packages ;)
 === siretart also agrees with lucas that this discussion should be rather rised
 on debian-devel
 09:07 raphink     ok
 09:07 raphink     :)
 09:07 ogra_ibook  i think it should be rised at the TB
 09:07 sistpoty    ogra_ibook++
 09:07 raphink     ok
 09:07 raphink     next week then ;)
 09:07 dholbach    yeah, i agree with ogra
 09:07 ogra_ibook  put it on the agenda there :)
 09:08 siretart    even better :)
 09:08 Riddell     are we under disagreement?
 09:08 \sh         well...
                   if in doubt we should be consulting
 09:08 crimsun     /usr/share/doc/$foo/copyright anyhow, but yes, the issue's
                   one for the TB (though we should try and minimize deviation
                   from Debian)
 09:08 \sh         I'm not convinced about this paragraph:
 09:08 \sh         Each version of the License is given a distinguishing version
 09:08 \sh         number. If the Document specifies that a particular numbered
 09:08 \sh         of this License "or any later version" applies to it, you
                   have the
 09:08 \sh         option of following the terms and conditions either of that
 09:08 \sh         version or of any later version that has been published (not
                   as a
 09:08 \sh         draft) by the Free Software Foundation.
 === claud1 [] has joined #ubuntu-meeting
 09:08 crimsun     err, not /usr/share/doc/$foo/copyright but COPYING in the
 09:08 raphink     hmm
 09:09 lucas       \sh: what do you mean by "not convinced" ?
 09:09 raphink     do I had it to the TB agenda ?
 09:09 raphink     s/had/add/
 09:09 \sh         lucas: it gives upstream a choice
 09:09 lucas       basically, a package stating GPLv2 or later should point to
                   GPL, while a package stating GPLv2 should point to GPL-2
 09:10 ogra_ibook  raphink, thats the way to get it to the TB
 09:10 sistpoty    \sh: imo it also gives distributors a choice, but IANAL
 09:10 lucas       \sh: it gives the user or the distributor a choice
 09:10 \sh         lucas: to say: only GPLv2 or "later == GPLv3"
                   does anyone disagree with use GPL-2 for programs that are
 09:10 Riddell     strictly GPL 2 and use GPL symlink for programs that are GPL
                   2 or later?
 09:10 ogra_ibook  raphink, i dont think its a MOTU specific issue ...
 09:10 \sh         sistpoty: well...the debian/dir is licensed by the maintainer
                   in my POV
 09:10 raphink     indeed ogra_ibook
 09:10 sistpoty    good point \sh
 09:10 sistpoty    but let's defer that to TB and move on... agreed?
 09:10 crimsun     Riddell: I don't disagree, but it's a matter for the TB
 09:10 \sh         so we have to deal with two license issues here
 09:11 siretart    next!
 09:11 \sh         sistpoty: agreed :)
 09:11 ogra_ibook  \sh, nope, we dont
 09:11 sistpoty    ok, next point are the todo's doko_ has for us...
 09:11 \sh         ogra_ibook: to go on :()
 09:11 ogra_ibook  \sh, the whole distro has ;)
 09:11 sistpoty    hehe
 09:12 raphink     huhu
 09:12 sistpoty    they are basically 1) packages still depending on libstdc++5
 09:12 sistpoty    which ftbfs
 09:12 sistpoty    I once started a wiki page MOTUStdc++-transition...
 09:12 dholbach    how is the status there? how much is left?
 09:12 sistpoty    but I don't know about the current state of these
 09:13 \sh         sistpoty: vn4 / im-sdk are not gcc4 compatible somehow
 09:13 sistpoty    \sh: we need at least g++-3.4
 09:13 siretart    sistpoty: please allow me a foolish question: why do packages
                   build depending on gcc-3.3 ftbfs?
 09:13 siretart    I mean why still have gcc-3.3 around!
                   sistpoty: i think the page is broken..when I looked only 1 or
 09:13 \sh         2 packages were left...and then we recevied again a mail from
          I have a look
 09:13 sistpoty    siretart: obviously they don't b-d on gcc-3.3, but didn't get
                   ever rebult
 09:14 siretart    ah. I see
 09:14 sistpoty    doko_: reading this?
 09:14 \sh         siretart: because it was the time in breezy, when not all
                   packages were tested to be build with gcc-3.4/4.0
 09:14 raphink     sistpoty: so then? how is it a work for MOTU to rebuild them
 09:14 lucas       so it's just about uploading a -1build1 version so they gets
                   rebuilt ?
 09:14 siretart    sistpoty: so can we assume that all those FTBFS do also apply
                   in debian?
 09:14 sistpoty    \sh: I'm not quite clear (in his mail, doko_ wrote, that the
                   lists are rebuilt daily, but I don't think they are)
 09:15 sistpoty    lucas: no
 09:15 raphink     what has to be done with these packages then?
 09:15 sistpoty    raphink, lucas: they ftbfs... we need to make them build
 09:15 siretart    lucas: they most probably where tried to be rebuild but
 09:15 lucas       ok
 09:15 \sh         lucas: definetly not :)
 09:15 raphink     k
 09:15 sistpoty    iirc they where all uloaded with -nbuildx
 09:15 \sh         and one of the biggest problem with this is, some packages
                   are not well maintained anymore
 09:15 lucas       so this item can be merged with the FTBFS check later ;)
 09:16 sistpoty    lucas: it could, but should at least get some attention now
 09:16 sistpoty    I tried some packages, but they are horribly broken, so we
                   might want to check for a new upstream version
 09:16 dholbach    yeah, upstream versions asap :)
 09:16 raphink     ok
 09:17 raphink     for each of them?
 09:17 dholbach    only if it helps and it is feasible
 09:17 raphink     ok
 09:17 sistpoty    raphink: if it makes them compile ;)
 09:17 dholbach    some upstreams have stopped working too, i fear
                   raphink: try to build them first with actuall toolchain, if
 09:17 \sh         this is not working out, try gcc-3.4 and if this is not
                   working new upstream check and try to build it :)
 09:17 dholbach    uvf is in one week
 09:17 \sh         s/actuall/actual/
 09:18 dholbach    we will have exceptions, but not too many
 09:18 raphink     yep \sh understood :)
 09:18 sistpoty    how do we want to handle these packages? try again with the
 09:18 crimsun     if you come across mythtv, discard it. I'm pulling from
                   -fixes svn branch to make it build with g++-4.0.
 09:18 sistpoty    s/handle/organize handlinge/
                   sistpoty: they aren't that many, I think a wiki page might be
 09:18 siretart    feasible in this case (and you know how much I hate wikis for
 09:18 sistpoty    crimsun: bah... I'm just about to fix mythplugins...
 09:18 \sh         well, I can take the new allocator transition list
 09:19 sistpoty    \sh: they seem to be ftbfs-candidates as well
 09:19 siretart    sistpoty: and mythtv needs a lot of love, it is currently
                   orphaned :(
 09:19 \sh         sistpoty: doesn't matter...but most of hte packages don't
                   need a rename because they're apps :)
 09:19 dholbach    i think for the following week we should concentrate on
                   updating/merging where we need it - what do you guys think?
 09:20 sistpoty    dholbach++
 09:20 raphink     +1 dholbach
 09:20 raphink     some guys will shout on REVU that their packages are not
                   being reviewed ;)
 09:20 dholbach    if there are fixes we can get from cvs, we should get them in
 09:20 \sh         well..merging/updating/new apps are prio 1 i think until the
 09:20 dholbach    raphink: NEW packages have time until feature freeze (= Feb
 09:21 raphink     dholbach: what exactly is frozen on 19th then?
 09:21 lucas       can't we postpone UVF for universe ?
 09:21 dholbach    new upstream versions
 09:21 \sh         lucas: no
 09:21 dholbach    the spec explicitly say no
 09:21 crimsun     lucas: no, that was a huge issue last release
 09:21 siretart    lucas: we have UVF for a reason
 09:21 sistpoty    ok, seems like we are already moving to the next point on the
                   agenda... uvf for universe
 09:21 \sh         lucas: we decided at ubz to go with the release schedule this
                   time more strictly
 09:22 lucas       raphink: MoM stops working, so new packages in Debian don't
                   get imported into Ubuntu
 09:22 sistpoty    dholbach: do you know if mom will be running until the last
                   day of UVF?
 09:22 dholbach    sistpoty: we should Keybuk about that
 09:22 dholbach    i think it'll have to be fixed for Malone
 09:22 dholbach    although... that doesn't matter for universe
 09:22 dholbach    forget what i said
 09:22 \sh         dholbach: well...for universe it never filed any bugs in
                   bugzilla :) so we don't need a fix :) right now
 09:22 dholbach    we should kindly ask him
 09:23 sistpoty    dholbach: if it *is* running till the last day, we definitely
                   won't be able to "hand"-merge last runs packages
 09:23 dholbach    we can just talk to him
 09:23 \sh         actually for the remaining merges we have time to the 2nd of
 09:23 \sh
 09:23 raphink     so on the 19th automatic merges stop
 09:24 raphink     but we keep merging manually till the 2nd of feb ?
 09:24 \sh         raphink: there are no automatic merges :)
 09:24 raphink     right?
                   and hey, UVF is not the end of the world. if you can show
 09:24 siretart    that a new version from debian fixes some important problem,
                   we can still sync it
 09:24 sistpoty    ah, good to know \sh
 09:24 \sh         raphink: only mom stops...and we have to stop on the 2nd
 09:24 raphink     \sh: I mean syncs
 09:24 lucas       raphink: right
 09:24 siretart    but we won't focus on merging anymore. we focus on bugfixing.
                   of a bug can be fixed by a sync, even better!
 09:24 \sh         raphink: the auto sync robot is stopping, MoM is not running
 09:25 sistpoty    ok, how will we handle uvf-exceptions?
 09:25 raphink     yep got that :)
 09:25 sistpoty    same as last year: get dholbach's or ogra_ibook's ok?
 09:25 raphink     and we only sync as manual requests if syncs fix bugs
 09:25 \sh         sistpoty: I think the same way as we handle it in main..ask
                   mdz or kamion
 09:25 siretart    sistpoty: I propose the same procedure as with breezy
 09:25 sistpoty    s/last year/breezy/
 09:25 sistpoty    siretart++
 === dsas [] has joined
 09:25 siretart    sistpoty: ogra appointed 2 or 3 delegates who
                   proxied/approved sync requests
 09:25 dholbach    i think they will have better things to do
 09:26 dholbach    we should raise the topic in the TB meeting
 09:26 siretart    yes
 09:26 ogra_ibook  sistpoty, there was a documment anywhere on the wiki from the
                   UBZ BOF where its outlined
 09:26 \sh         dholbach: we should :)
 09:26 dholbach    since this was not explicitly mentioned in the spec
 09:26 ogra_ibook  dholbach, it was mentioned
 09:26 ogra_ibook  Kamion showed me the part
 09:26 dholbach    ogra_ibook: who approves exceptions?
 09:27 ogra_ibook  as it sounded there should be no exceptions ...
 09:27 \sh         ogra_ibook:
                   We have found in the past that newer universe packages tend
                   to demand newer dependencies in main. Accordingly, universe
                   will enter UpstreamVersionFreeze at the same time as main, in
 09:27 \sh         order to reduce dependency tension between newer versions of
                   packages in main and universe. The exact details of sync and
                   merge schedules will be the decision of the MOTU team. As in
                   main, syncs and merges to universe after UVF must be verified
                   to build and in
 09:27 \sh         anted for new or updated dependencies).
 09:27 ogra_ibook  apart from that it will be as in all releases before, Kamion
                   and mdz i think
 09:27 dholbach    ogra_ibook: you're wrong
 09:27 \sh
 09:27 dholbach    "no exceptions" is wrong.
 09:27 siretart    ogra_ibook: come on, we will need exceptions, if we don't
                   want to diverge totally!
 09:27 ogra_ibook  siretart, sure
                   Jan 06 13:50:53 Kamion        dholbach:
 09:28 dholbach explicitly
                   contradicts that, but we'll be flexible with exceptions for
 09:28 ogra_ibook  siretart, but at a very minimal base as i understand the
                   above \sh just pasted
 09:28 dholbach    there you go
                   well, since we need a decision, how do dholbach and \sh feel
 09:28 crimsun     about being the proxies? (Don't mean to exclude ogra, but I
                   presume he'll be busy with Edubuntu)
 09:28 dholbach    crimsun: let's raise the topic at the TB
                   the biggest problem is "new dependencies in main for universe
 09:28 \sh         packages" this we should avoid...for universe itself, we can
                   get it straight, and we can discuss it with mdz/kamion
 09:28 dholbach    and sort out the process explicitly
 === siretart would volunteer again for proxying
 09:28 lucas       what do we do regarding REVU ?
 09:29 ogra_ibook  you can abuse me after feature freeze again ... i'll have
                   more time then :)
 09:29 lucas       we just stop uploading packages on the 19th ?
 === \sh is not volunteering because I don't know if i'm still there then :)
 (means online)
 09:29 ogra_ibook  lucas, new versions, yes
 09:29 ogra_ibook  lucas, exceptions need approval and extra review
 09:29 lucas       (this would lower the pressure on the MOTUs and let them
                   concentrate on bugfixing)
 09:29 crimsun     dholbach: certainly; it would be nice to say "here are our
                   proxies" when approved
 09:30 lucas       ogra_ibook: totally new packages are no longer accepted ?
 09:30 siretart    I'd really require a malone bugnr for each exception this
 09:30 raphink     ogra_ibook: I understnad new packages are not considered new
                   versions ?
 09:30 dholbach    lucas:
 09:30 dholbach    Feature Freeze is the date
 09:31 sistpoty    do we have an agreement for exceptions already?
 09:31 crimsun     raphink: right, 1.2.3-(X+1) is fine, but 1.2.(Y+1)-X is not
 09:31 ogra_ibook  sistpoty, TB
 09:31 sistpoty    ok
                   between UVF and FF, we keep getting new packages in, but not
 09:31 raphink     getting new versions of existing packages from Debian,
 09:31 siretart    from DapperReleaseProcess: The exact details of sync and
                   merge schedules will be the decision of the MOTU team.
 09:31 \sh         regarding new packages: this paragraph is important
                   Since entirely new packages in universe are relatively safe
 09:31 \sh         and attract a number of new developers, they will be
                   liberally admitted until FeatureFreeze if they do not require
                   additional or newer dependencies.
 09:31 raphink     crimsun: I guess unless Y=-1
 09:32 raphink     ok
 09:32 raphink     :)
 09:32 raphink     so REVU is still up till FF
 09:32 dholbach    "new versions" are cumbersome
 09:32 siretart    yes
 09:32 sistpoty    \sh: ok, then we can defer the point "packages on revu" (I
                   have already some thoughts about it, but let's defer this)
 09:32 dholbach    you can always pack a 3MB patch in debian/patches
 09:32 \sh         dholbach: go away :)
 09:33 raphink     lol
 09:33 ogra_ibook  dholbach, i was told that nobody will approve that anymore in
                   breezy :)
 09:33 dholbach    so try to have this in mind, we really want minimal changes
 09:33 crimsun     that way madness lies (cf. vlc)
 09:33 LaserJock   next item?
 09:33 dholbach    yeah :)
 09:33 sistpoty    LaserJock++
 09:33 lucas       ok, I think the topic was covered. Shall we move on to FTBFS
                   packages ?
 09:33 siretart    so, did we agree on the proxies yet?
 09:33 raphink     yep
 09:34 siretart    please repeat them
 === freemanen [] has joined
 09:34 sistpoty    siretart: deferred to TB, as I understood it
 09:34 \sh         siretart: TB ... and remove me from the list :)
 09:34 siretart    sorry, please not the TB
 09:34 ogra_ibook  sistpoty, the called proxies were \sh and dholbach
 09:34 siretart    we should at least make proposals for the TB
 09:34 lucas       who is in charge of forwarding items to the TB ?
 09:34 \sh         ogra_ibook: the called proxies were siretart and dholbach
 09:34 ogra_ibook  but to get the right conact people we said TB
 09:34 ogra_ibook  \sh, and you :)
 09:35 raphink     TB is on 17th right?
 09:35 \sh         ogra_ibook: no...because of the private matters
 09:35 lucas       15th I think
 09:35 lucas       but not sure
 === raphink checks
 09:35 siretart    ogra_ibook: \sh doesn volunteer, and me alone is crazy
 09:35 siretart    ogra_ibook: I'd propose sistpoty as proxy
 09:35 lucas       ah no 17
 09:35 dholbach    i trust enough in siretart, sistpoty and slomo_ to have them
                   decide too
 09:35 \sh         ogra_ibook: right now, I'm more a SPoF
 09:35 siretart    and slomo, right
 09:35 raphink     ;)
 09:35 ogra_ibook  dholbach++
 09:35 raphink     lucas: better for you to know and not miss it ;)
 09:36 lucas       :)
 09:36 dholbach    crimsun too
 09:36 raphink     ;)
 09:36 ogra_ibook  dholbach++
 09:36 dholbach    but we should decide on the number of people proxying in the
                   TB meeting
 09:36 ogra_ibook  :)
 09:36 siretart    yay for crimsun! :)
 09:36 dholbach    and see how well we do
 === dholbach hugs crimsun
 09:36 sistpoty    yay for crimsun from /me as well
 09:36 sistpoty    probably ajmitch for nightly changes?
 === \sh can play the replacement proxy when there is a chance
 09:37 lucas       yeah, I was about to say that TZ problems should be
 09:37 \sh         but I wouldn't count on that
 09:37 ogra_ibook  how many did we have in breezy ? 3 ? 5 ?
 09:37 siretart    ogra_ibook: too few
 09:37 \sh         ogra_ibook: 4 or 5 ... you dholbach siretart I and ?
 09:37 ogra_ibook  lucas, you can cover TZ shifts on the ML :)
 09:38 ogra_ibook  i think ajmitch too
 09:38 lucas       true
 09:38 ogra_ibook  and crimsun
 09:38 siretart    ok, so I count 4 + 2 proxies, which need approval by TB, yes?
 09:38 ogra_ibook  so we were at least 5
 09:38 dholbach    we need elmo to sync (or maybe to do approvals), let's raise
                   the issue at the TB
 09:38 dholbach    we can still decide  then
 09:39 ogra_ibook  yuo
 09:39 siretart    ok
 09:39 ogra_ibook  err yup
 09:39 sistpoty    next item?
 09:39 ogra_ibook  elmo also need the list ...
 09:39 lucas       ok, packages that FTBFS (fail to build from source)
 09:39 lucas       who will do the mass testing ? how ? (pbuilder ?)
 09:39 \sh         upcoming todos
 09:39 sistpoty    lucas: not so fast...
 09:39 lucas       ah
 09:39 lucas       sorry
 09:39 lucas       missed 2 items :-)
 09:40 dholbach    lucas: test rebuild on the buildds?
 09:40 lucas       the buildd don't pbuild
 09:40 dholbach    we can infinity to do this
 09:40 \sh         so....bug fixing, unmet deps are the most common workloads
                   these days after uvf
 09:40 dholbach    they sbuild, yes
 09:40 sistpoty    ok, well I named the point "upcoming todo's" to try to list
                   what should be our next priorities after uvf
 09:40 siretart    dholbach: yes, we should ask lamont for that. but earlier
                   than for breezy!
 09:40 dholbach    siretart: absolutely, of infinity rather
 09:40 elmo        eh?
 09:40 \sh         ftbfs issues we can sort out with infinity/lamont and their
                   "testbuilds of the universe"
 09:40 elmo        what are you guys talking about WRT me?
 09:41 ogra_ibook  elmo, uvf exception handling
 09:41 ogra_ibook  elmo, and who is your MOTU contact to approve stuff
 09:41 siretart    elmo: we agreed on proxies who are allowed to request syncs
                   after UVF && FF from you
 09:42 elmo        oh, ok, fine
 09:42 LaserJock   I hate to be a pain but I gotta leave in 3 min. is there
                   anything needing I or MOTUScience team?
 09:42 sistpoty    LaserJock: from the agenda, nothing science-specific
 09:42 sistpoty    LaserJock: for the rest you can read the irc-logs or the
                   minutes (once they are there)
 09:43 LaserJock   I just wondered about the LP team item
 09:43 sistpoty    ok, back to "what's priorities after uvf"
 09:43 ogra_ibook  bugs
 09:43 sistpoty    I guess one of the big priorities should also be reviewing
                   packages... then we have unmet deps and bugs
 09:43 dholbach    new packages
 09:44 dholbach    yeah
 09:44 ogra_ibook  as its for main
 09:44 dholbach    i'll do the import as well :/
 === freemanen [] has left
 #ubuntu-meeting ["Konversation]
 09:44 dholbach    but bugs, of course
 09:44 dholbach    the more the better
 09:44 dholbach    we have a *bunch* piled up on launchpad
 09:44 sistpoty    ok, for unmet deps, ajmitch wanted to write some stuff
                   iirc... hopefully we'll have some webtool for it as well
 09:45 raphink     hehe
 09:45 siretart    sistpoty: I have this:
 09:45 sistpoty    ah, yes, I forgot ;)
 09:45 lucas       which kind of deps ? build-deps ?
 09:45 siretart    lucas: no, binary dependencies
 09:46 \sh         ok...can we agree on "prio 1) bugs, prio 2) unmet deps prio
                   3) poke buildd when it's necessary to rebuild universe?"
 09:46 siretart    lucas: basically the output of apt-cache -i unmet
 09:46 sistpoty    \sh: and 4) reviewing new packages
 09:46 \sh         sistpoty: ok..that whould be 1b)
 09:46 \sh         not 4
 09:46 siretart    \sh: 3 does not necessarily block human ressources. I think
                   it should be started quite quickly
 09:47 raphink     hehe
 09:47 sistpoty    siretart: you might want to talk to ajmitch, he said
                   bout britney ;)
 09:47 lucas       we could run piuparts on the whole universe
 09:47 \sh         siretart: yepp...
 09:47 dholbach    if we all concentrate on a review day, we can achieve quite
 09:47 lucas       this would catch them all
 09:47 sistpoty    lucas: catch what?
 09:47 raphink     yep I think so
 09:47 lucas       missing deps
 09:47 raphink     if we do better than last time ;)
 09:48 lucas       packages that don't install etc
 === byteunix [n=byteunix@] has joined #ubuntu-meeting
 === allee [] has joined #ubuntu-meeting
 09:48 sistpoty    we might do many things, if s.o. volunteers ;)
 09:49 raphink     :)
 09:49 sistpoty    ok, next item?
 09:49 lucas       maybe there are some plans for this on the ubuntu scale
 09:49 lucas       not MOTU
 09:49 lucas       we should ask in TB
 09:49 sistpoty    oh, sorry, I forgot another important point that falls under
 09:49 \sh         lucas: what plans?
 09:49 lucas       plans for pbuilder builds + piuparts runs
 09:50 dholbach    sistpoty: fire away
 09:50 sistpoty    point is: soyuz...
 09:50 \sh         lucas: hmmm..if, then it will be soyuz :) and buildd
                   integration in launchpad :)
 09:50 sistpoty    will it come, when, what will change, are we going to die?
 09:50 lucas       \sh: I'm talking about dapper
 09:51 \sh         sistpoty: dapper +1 :)
 09:51 lucas       not dapper+x ;)
 09:51 \sh         lucas: I don't think infinity will deal now with pbuilder :)
 09:51 lucas       I'll take care of the issue with infinity and the TB
 09:51 sistpoty    \sh: ah, good to know... thought I heard some rumors of soyuz
                   being available very next days :)
 09:51 siretart    sistpoty: we are definitly going to die, except the immortals
                   ;) - but hopefully not related to ubuntu work
 09:51 sistpoty    hehe
 09:51 lucas       I'm interested in providing CPU power too anyway
 09:52 ogra_ibook  lucas, for unmet deps, get familiar with germinate ...
 09:52 \sh         sistpoty: could be as well a release cycle like
                   "hurd" :)
 09:52 lucas       piuparts catches much more than germinate
 09:52 sistpoty    \sh: or longwait?
 09:52 raphink     \sh: you mean 1.0 is released in 20 years ?
 09:53 \sh         ASK #launchpad :)
 09:53 sistpoty    ok, I guess we're getting offtopic... let's move on to next
 09:53 dholbach    :)
 09:53 raphink     sistpoty: yep
 09:53 siretart    MOTU Team Reorg?
 09:53 \sh         ok..lp motu teams reorg
 09:53 sistpoty    lucas: your stage ;)
                   There is currently a high number of MOTU-related teams on
                   Launchpad. I proposed a new organization on
 09:53 lucas which (I think)
                   makes it easier to understand and use. Please read the
                   wikipage and comment.
 09:54 \sh         ah well..
 09:55 \sh         the blue teams: members of the blue teams don't need to be
                   members of MOTU
 09:55 \sh         everyone is normally allowed to enter :)
 09:55 lucas       there are no members of MOTU
 09:55 \sh         actually for MOTUIM :)
 09:55 lucas       except the owner + teams
 09:55 raphink     lucas : then the "normal" MOTUs are in Ubuntu-dev only?
 09:55 lucas       yes
 09:55 \sh         no
 09:56 \sh         ubuntu-dev means only people with universe upload rights
 09:56 raphink     \sh: according to the scheme I mean
 09:56 lucas       \sh: elaborate
 09:56 lucas       ok, so some people with universe upload rights are not MOTUs
 09:56 lucas       (that was my question on the list)
 09:56 \sh         lucas: yes
 09:57 \sh         lucas: every core dev has universe upload rights, but is not
                   always a MOTU, neither interested in MOTU
 09:57 raphink     you have to be a dev to be a MOTU
 09:57 raphink     but being a dev doesn't make you a MOTU
 09:57 \sh         raphink: no..
 09:57 lucas       ok
 09:57 raphink     right?
 09:57 raphink     ...
 09:57 lucas       \sh: who are MOTUs then ?
 09:57 \sh         ubuntu-dev means only "universe upload rights"...
 09:57 raphink     yes
 09:58 ogra_ibook  ubuntu-core-dev is a member of ubuntu-dev
 09:58 raphink     and I mean MOTUs are necessarily ubuntu-dev
 09:58 raphink     s
 09:58 ogra_ibook  ubuntu-dev includes all MOTUs
                   lucas: MOTUs is a bunch of people who wants to work on the
 09:58 \sh         universe repos and/or working on the distro as
                   volunteer...they can go further with universe uploads rights,
                   but they don't have to
 09:58 raphink     so among ubuntu-dev you have MOTUs, ubuntu-core-dev and
 09:58 ogra_ibook  \sh, nope
 09:58 ogra_ibook  \sh, a MOTU is approved to upload
 09:59 \sh         ogra_ibook: no :) MOTUs includes all ubuntu-devs...but MOTUs
                   are more ( regarding the team lists)
 09:59 raphink     hmm
 09:59 ogra_ibook  \sh, i was there when we wrote the definition
 === sistpoty is confused
 09:59 raphink     do MOTUs belong to ubuntu-dev or ubuntu-dev belong to MOTUs ?
 09:59 ogra_ibook  \sh, MOTUs are all memebers of ubuntu-dev
 09:59 \sh         ogra_ibook: in my POV MOTUs are Hopefuls + ubuntu-devs
                   (reading the team names)
 09:59 raphink     sistpoty: same here
 09:59 \sh         ogra_ibook: not when I see the LP team list
 10:00 ogra_ibook  \sh, nope, there are MOTUs and there are MOTU hopefuls
 10:00 ogra_ibook  its ever been like this
 10:00 raphink     adjime
 10:01 siretart    ogra_ibook: whats the difference between the lp group MOTU
                   and ubuntu-dev? can't we merge them?
 10:01 lucas       ok, so how do we transpose this to LP teams ? :-)
 10:01 ogra_ibook  and there is a definition somewhere in the wiki
 10:01 ogra_ibook  ...from the mataro conference
 10:01 siretart    it causes much confusion
 10:01 \sh         ogra_ibook: sorry...I was mistaken...what the lp teams are
 10:01 ogra_ibook  siretart, yes, we should
 10:01 sistpoty    siretart++
 10:01 ogra_ibook  siretart, mdz didnt know about the exiatance of the MOTU
                   launchpad group
 10:01 raphink     confusing
 10:02 lucas       ogra_ibook: can you comment on the proposed scheme on
 10:02 ogra_ibook  so he created ubuntu-dev, which is the official MOTU team now
 10:02 lucas       I used the MOTU as a way to join MOTU Hopefuls and ubuntu-dev
 10:03 siretart    ogra_ibook: ubuntu-dev is used for upload permissions, MOTU
                   is used for bug triage/management atm
 === lucas realizes nobody read his wiki page despite the announcement sent to
 ubuntu-motu@ ;)
 10:03 ogra_ibook  siretart, hmm, we should probably keep them distinct
 10:03 \sh         ogra_ibook: and we left the MOTU team because of the -bug
                   mail address right?
 10:03 ogra_ibook  yup
 10:04 sistpoty    lucas: what is your rationale/use case behind this proposal?
 10:04 ogra_ibook  i doubt the TB would be happy if we used ubuntu-dev for bugs
 10:04 siretart    right
 10:04 siretart    because main developers won't probably care that much about
                   bugs in universe, I assume
 10:04 lucas       sistpoty: it seemed it matched what I understood from this
                   complex stuff ;)
                   lucas, our policy for teams was always: everybody can join,
 10:05 ogra_ibook  it must be one MOTU and one point of contact in the team
                   (they may be the same person) and teams organize themselves
 10:05 sistpoty    what do you want to achieve with this proposal?
                   well..what we want to achieve? seeing a team which is there
 10:06 \sh         because of managing upload rights, and a more theoretical
                   team named MOTU which can be the mother of all MOTU* teams :)
                   in a more practical way
 10:06 ogra_ibook  to me it looks like you want to restrict access to cretain
                   teams ...
 10:06 lucas       sistpoty: make things easier to understand from the user or
                   potential MOTU Hopeful point of view
 10:06 ogra_ibook  *certain
 10:07 lucas       ogra_ibook: ? my proposal is not about teams like
                   MOTUScience, MOTURuby, etc
 10:07 sistpoty    lucas: I'm not quite sure if using lp team relations will be
                   succesful in making things clearer
 10:07 ogra_ibook  Teams accepting direct members are in blue. All other teams
                   have no direct members except owner/admins.
 10:07 sistpoty    lucas: instead of e.g. a wiki-page with some drawings like
 10:07 ogra_ibook  lucas^^^
 10:07 lucas       ogra_ibook: yes, and ?
 10:08 lucas       I never talked about team creation
 === mvo [] has joined #ubuntu-meeting
 10:08 ogra_ibook  why would you restrict reviewers or mergers ?
 === raphink is subscribed to reviewers and mergers
 10:09 lucas       because we don't need them if everybody is in MOTU through
                   inclusion relationships
 10:09 ogra_ibook  i just wouldnt put up rules for mergers or reviewers ...
 10:09 \sh         lucas: and people who are not team members of any team?
 10:09 janimo      so can MOTUxxxxx teams have not-yet-motu members on
 10:09 lucas       \sh: they are MOTU Hopefuls
 10:09 siretart    I think lucas proposal reflects reality better than the
                   current situation in launchpad
 10:09 lucas       \sh: which is blue, too
 10:09 ogra_ibook  yes, everybody is a merger or reviewer in motu, why are there
                   teams ?
 10:10 \sh         lucas: well in the MOTU IM team I have someone, who is not
                   even a motu hopeful, but wants to work on packages...
 10:10 sistpoty    ogra_ibook: for bug-mails
 10:10 ogra_ibook  sistpoty, hmm, confusing
 10:10 sistpoty    ogra_ibook: and for grouping bugs... that were the primary
 10:10 lucas       ogra_ibook: because you can assign a bug to motureviewers to
                   mark it as 'I think it's ready, review needed'
 10:10 siretart    ogra_ibook: I think you have a point there. every ubuntu-dev
                   should be a reviewer rather than every motu
 10:10 \sh         ogra_ibook: to assign bugs towards those teams, that a mail
                   is generated
 10:11 sistpoty    ogra_ibook: so that you can search for all bugs assigned to
                   motu-merges (e.g.)
 10:11 lucas       \sh: no problem, he is part of the MOTU 'galaxy' too
 10:11 \sh         lucas: if "MOTU galaxy" is the MOTU team , then no
 10:11 lucas       MOTU IM is in blue, next to MOTU RUby ;)
 10:11 \sh         lucas: if you see it separated from the team view in LP then
 10:11 ogra_ibook  sistpoty, yes, i understand, i just find the need for a full
                   team page confsing
 10:11 lucas       \sh: I don't understand what you mean
 10:11 ogra_ibook  but thats a LP limitation
 10:12 sistpoty    unfortunately :(
 10:12 lucas       \sh: with my proposal, MOTUIM is included in MOTU. So anybody
                   in MOTUIM is also in MOTU
                   lucas: the LP view is quite different from the idea of MOTU
 10:13 \sh         galaxy :) everybody who is bringing in patches to universe
                   etc. belongs to the "MOTU galaxy" but they are not shown up
                   in the LP team view of MOTU :)
 10:13 ogra_ibook  "What about universe maintainers not willing to do MOTU work
 10:13 ogra_ibook  what does this mean ?
                   lucas: with your proposal, every bug assigned to
 10:13 siretart    MOTUReviewers would be assigned to ubuntu-dev and
                   ubuntu-core-dev, too
 10:13 siretart    lucas: so we would bother to many ppl with bugs we don't want
                   them to bother
 10:13 lucas       ogra_ibook: ubuntu-dev members who don't do MOTU work
 10:13 ogra_ibook  lucas \sh: with my proposal, MOTUIM is included in MOTU. So
                   anybody in MOTUIM is also in MOTU
 10:14 lucas       siretart: yup, what's exactly the point ogra just raised
 10:14 \sh         lucas: so ubuntu core dev :)
 10:14 ogra_ibook  ^^^that cant work
 10:14 lucas       so maybe we need a 'MOTU Developers' team instead of
 10:14 ogra_ibook  since MOTUIM can have non MOTU members
 10:14 ogra_ibook  as every team can
 10:14 lucas       or MOTUWithUploadRights team ;)
 10:14 ogra_ibook  you would make them MOTU automatically
 10:14 raphink     loooool
 10:15 lucas       ogra_ibook: please read 'MOTU' on the diagram as 'MOTU
 10:15 lucas       if you prefer
 10:15 ogra_ibook  no, please dont
 10:15 \sh         okokokok
 10:15 lucas       if we :
 10:15 \sh         one moment...
 10:15 lucas       s/ubuntu-dev/MOTU/
 10:15 ogra_ibook  currently you refer to the LP team
 10:15 lucas       s/MOTU/MOTUGalaxy/
 10:15 lucas       on a diagram
 === allee [] has left #ubuntu-meeting
 10:15 lucas       would it be ok ?
 10:15 ogra_ibook  and this should only contain approved MOTUs
 10:16 ogra_ibook  thats even more confusing ...
 10:16 lucas       ok, so let's create a MOTU Galaxy team which includes all
 10:16 siretart    lucas: what do you gain from another team?
 10:16 lucas       siretart: currently, there are members of all MOTU related
 10:16 ogra_ibook  yes, thats what i'm asking as well here
 10:16 lucas       some people are members of several teams
 10:16 \sh         technical solutions can't solve social problems
 10:16 lucas       which is useless, etc
 === raphink still doesn't see the point
 10:16 lucas       there's a lot of redundancy
 10:16 ogra_ibook  its just bringing up more confusion
 10:16 sistpoty    \sh++
 10:16 ogra_ibook  i'd keep the LP teams distinct ...
 10:17 lucas       I'd just like a clean mapping of the reality to launchpad
 10:17 raphink     I don't see a pb with redundancy in teams
 10:17 \sh         so which view do you have: the social view of MOTU or the
                   technical LP view of MOTU?
 10:17 raphink     I'm subscribed to ML that send me the same bugs three times
 10:17 raphink     and that's ok
 === sistpoty agrees to ogra_ibook
 10:17 raphink     redundancy in work or bugs or so can be a pb
 10:17 siretart    what about breaking all inclusion relationsships in the MOTU
 10:17 raphink     but in teams ... well I don't see the pb
 10:17 lucas       MOTUIM is part of MOTU I think
 10:17 lucas       that's wrong, then
 10:17 lucas       so we do no relationships between LP teams ?
 10:17 ogra_ibook  yes
 10:17 \sh         lucas: no
 10:18 ogra_ibook  MOTUIM is a team with at least one MOTU
 10:18 ogra_ibook  but its not member of MOTU as whole team
 10:19 lucas       ok, let's reject the item, and just say that our policy
                   regarding LP is 'join as much teams you can' :-)
                   lucas: there is no relation between the MOTUIM team and the
 10:19 \sh         MOTU team .. the only connection to the MOTU team is me (and
                   nafallo, slomo) but nothing
 10:19 ogra_ibook  lucas, it isnt
 10:19 sistpoty    I guess the policy is come to #ubuntu-motu and talk to
 10:19 lucas       ah sorry
 10:20 lucas       MOTURuby is member of MOTU
 10:20 ogra_ibook  lucas, join the teams you like to work with is and was the
 10:20 lucas       not MOTUIM
 10:20 ogra_ibook  nope
 10:20 ogra_ibook  it cant
 10:20 lucas       why is MOTURuby member of MOTU, and not MOTUIM ?
 10:20 lucas       it is.
 10:20 lucas
 === ogra_ibook removes
                   lucas: I'm in the ubuntu-dev team, because of the upload
 10:20 \sh         rights, I'm in the MOTU team, because I'm a MOTU and I'm team
                   lead of MOTU IM...oh yes and the Kubuntu team
 10:21 lucas       ok, so let's remove inclusion relationships between team
 10:21 lucas       s
 10:21 siretart    any objections?
 10:21 siretart    It seems to reduce confusion
 10:21 sistpoty    no objections... let's move to the next item
 10:21 ogra_ibook  hmm who added the teams there ?
 10:21 janimo      maybe MOTU should be just the groups of people doing regular
                   merges, transitions etc
 10:21 raphink     yeah next item :)
 10:21 siretart    ogra_ibook: confused ppl (like probably me)
 10:22 janimo      while the MOTUxxx groups usually care about one singel area
                   and set of pacvkages
 10:22 lucas       that's me again
 10:22 \sh         not me
 10:22 lucas       next or not next ?
 === sistpoty keeps the spotlight focused on lucas
 10:22 sistpoty    go on
                   We currently accept a lot of packages through REVU. After
 10:22 lucas       they are uploaded, the maintainer is free to totally forget
                   about it and leave us maintain them. I'd like to raise two
                   issues :
                   * Maybe we should find a way (writing a policy ?) to actually
 10:22 lucas       make REVU uploaders feel more responsible of what they upload
                   in the long term.
                   * Maybe we should consider removing some of the 300+ universe
 10:22 lucas       packages that are not in Debian. What's the procedure for
                   this ? (note that popcon.u.c is broken, so we can't determine
                   which packages are actually used).
 10:23 ogra_ibook  siretart, heh
 10:23 \sh         lucas: why?
 10:23 lucas       \sh: why what ?
 10:23 \sh         lucas: ubuntu decided in the beginning not to have this
                   maintainer thingy
 10:23 lucas       ok, but who cares about the packages ?
 10:23 lucas       I know we are not doing security updates for universe
 10:23 siretart    lucas: everyone and nobody, thats how universe works
                   lucas: so actually I don't mind to touch packages which are
 10:23 \sh         not directly mine...but because they're in universe they're
                   mine and yours and dholbachs and siretarts somehow
 10:24 ogra_ibook  lucas, they disappear if nobody cares for them
 10:24 lucas       but every ubuntu user adding universe potentially get lots of
                   root holes ;)
 10:24 ogra_ibook  thats normal evolution :)
                   and if there is a new version in Deiban, it'll overwrite the
 10:24 raphink     package in universe anyway, which is likely to be for many of
                   them since DDs are much more numerous
 10:25 lucas       also, since we don't check if packages still work, there
                   might be a lot of broken packages in universe
                   apart from that most of the ppl. of revu hang around in -motu
 10:25 sistpoty    or can be reached by mail... so it's easy to do a "nmu": just
 10:25 siretart    ogra_ibook: uuh, I think the 'dissapear' part is worth
                   another point on the agenda
 10:25 ogra_ibook  siretart, why ? thats what happens ...
 10:25 lucas       sistpoty: I'm not concerned about packages which are actually
                   used by a lot of users
 10:25 lucas       I'm concerned about the invisible ones
 10:25 \sh         siretart: if they disappear from debian, they disappear from
                   ubuntu at some very special time...
 10:26 lucas       potentially broken, or with security issues
 10:26 ogra_ibook  siretart, if nobody cares for them, they'll not survive a
                   transition etc
 10:26 \sh         lucas: e.g.?
 10:26 lucas       no idea, because nobody here obviously know about them ;)
 10:26 lucas       ok, example: xnetcardconfig, a ruby packagez
 10:26 siretart    ogra_ibook: how many package actually got removed that way
 10:26 lucas       not in debian
 10:26 lucas       uploaded once, never updated
 10:26 lucas       some users might have install it
 10:27 lucas       it might be rootable
 10:27 ogra_ibook  siretart, none, because we cared for most of them :)
 10:27 siretart    ogra_ibook: what about packages which got removed in debian
                   but are still in ubuntu?
 10:27 \sh         lucas: hmmm...sure...there is a ruby team..and this team can
                   decide if ubuntu needs this package or not
 10:27 ogra_ibook  siretart, if someone wants to care for them :)
 10:27 sistpoty    basically I dislike the idea of removing packages, just
                   because nobody uses them
 10:27 lucas       ok
 10:27 siretart    I think we should work on a process for package removals
 10:27 lucas       problem is, I'm not using it
 10:27 lucas       but I don't know if somebody else is
 10:27 lucas       how can I know ?
 10:28 siretart    ogra_ibook: how to you know when 'nowbody cares anymore for a
 10:28 raphink     I used to use xnetcardconfig lucas
 10:28 \sh         lucas: I'm not using actually 95% of universe but should I
                   propose to elmo to remove 95% of universe?
 10:28 raphink     once
 10:28 lucas       it was just an example
 10:28 lucas       \sh: that's exactly the problem
 10:28 \sh         lucas: but I do care about my universe work..and therefore I
                   have to touch those packages, so I do care :)
                   if nobody uses these/nobody has these installed, it's not a
 10:29 sistpoty    probrem if a packages has issues. if ppl. have it installed,
                   it's likely that they'll report bugs
 10:29 \sh         even if i'm not using it in my daily work
 10:29 sistpoty    or even start caring for the package
 10:29 raphink     how many packages do we even merge that we won't ever use
 10:29 raphink     ;)
 10:29 ogra_ibook  siretart, if it lies broken on the floor in front of me and
                   nobody complains ;)
 10:29 lucas       sistpoty: not likely. not many people report bugs
 10:29 \sh         raphink: a lot :)
 10:29 lucas       syncs/merges are different, since debian maintains them
 10:29 raphink     \sh: yes ;)
 10:29 sistpoty    and maybe some people use even the source (sourcepackage)
 10:30 siretart    ogra_ibook: cool. that would apply to mythtv!
 10:30 lucas       ogra_ibook: what about blog entries like 'ubuntu is crap, I
                   installed this and it doesn't work at all!'
 10:30 \sh         lucas: hmmm...nope...many packages are not compatible with
                   debian anymore....gajim is a good example...and I know why :)
 10:30 ogra_ibook  siretart, drop it then :) (but also deal with mdz afterwards
                   ;) )
 10:31 siretart    ogra_ibook: he orphaned it and asked for an adopter
 10:31 ogra_ibook  lucas, look for a comment section and add a link to malone ;)
                   lucas: well...we have settled communication channels like
                   malone for bugs...we can't read all blog pages about "this
 10:31 \sh         and that is not working". there was one colleague of mine,
                   who tried to do it, and forced us to read forum
                   posts...well...he's gone now :)
 10:31 ogra_ibook  siretart, oh, he probably bought a TV now :)
 10:31 \sh         lucas: it doesn't work
 10:31 ogra_ibook  who knows
                   poll: do you prefer: (A) get as many packages in, even if we
 10:32 lucas       can't make sure all of them work as expected. (B) maintain a
                   smaller amount of packages, but be reasonably sure they work.
 === sistpoty casts a
 10:32 raphink     a
 10:32 \sh         lucas: how do you determine the need of (B)?
 10:33 siretart    lucas: a is how universe is constructed and expected to work
 10:33 \sh         lucas: and don't mention popcon
 10:33 lucas       \sh: by using popcon would be great
 10:33 \sh         lucas: no
 10:33 raphink     we want A
 10:33 raphink     A provides bugs
 10:33 raphink     and bugs make software better
 10:33 sistpoty    vote, \sh! ;)
 10:33 raphink     )
 10:33 raphink     :)
 10:33 lucas       raphink: you won't know anything about those bugs
 10:33 raphink     lucas: if they are reported, we will
 10:33 ogra_ibook  lucas, i agree with sabdfl on a ...
 10:33 ogra_ibook  its a declared target
                   sistpoty, dholbach, lucas, siretart: just updated the
 10:33 doko_       libstdc++ list, the allocator list is currently updating, no
                   need to rebuild, they were all tried and failed. just fix ;)
 10:33 lucas       since joe doesn't know about bug reports and will only blog
                   that ubuntu sucks
 10:34 crimsun     doko_: thanks
 10:34 \sh         software comes and the dinos
 10:34 siretart    doko_: thanks!
 10:34 dholbach    doko_: rocking, thanks.
 10:34 raphink     I consider open-source users to be generally a bit more
                   responsible about reporting bugs than proprietary soft ones
 10:34 sistpoty    doko_: are they rebuilt on a daily basis?
 10:34 sistpoty    (the lists)
 10:34 sistpoty    and thanks doko_ btw ;)
 10:34 \sh         doko_: merci :)
 10:35 raphink     thanks doko_
 10:35 lucas       \sh: what's the problem with popcon ?
 10:35 \sh         lucas: it's off by default I think
                   ok, since ogra_ibook had the ultimate vote (sabdfl's), what
 10:36 sistpoty    about considering a) the agreement and move to the next
 10:36 lucas never get refreshed
 10:36 lucas       just a note
 10:36 \sh         lucas: and if it wouldn't be switched of by default, I would
                   blog about breaking my private environment of ubuntu
 10:36 doko_       sistpoty: no, takes too long, I'll rebuild these on request
 10:36 lucas       does MOTURuby has the right to request removal of a
                   ruby-related package ?
 10:36 sistpoty    ok, thx doko_:
 10:36 \sh         sistpoty: there is no vote, because there is no mathematical
                   solution for b)
 10:36 ogra_ibook  sistpoty, this came up at hoary time when we discussed
 10:37 lucas       if MOTURuby doesn't want to hear people saying that ruby
                   sucks in dapper ?
 10:37 sistpoty    but can we agree to move to the next topic (at least :P)?
 10:37 crimsun     lucas: as opposed to fixing it?
 10:37 lucas       crimsun: yes
 10:37 lucas       because it's not integrated in debian, and nobody seems to
 10:38 crimsun     it's going to have to be fixed _somewhere_, but yes, let's
                   move on
 10:38 \sh         lucas: welcome to the world of volunteers :)
 10:38 raphink     :)
 10:38 sistpoty    ok, next item: Collaborative maintenance on tiber via svn or
                   other means
 10:38 sistpoty    who listed this? siretart?
 10:38 raphink     there are always people to criticize volunteer and not do
                   anything to help ;)
 10:38 \sh         I'm publishing my bzr archives on tiber in my public_html dir
 10:39 lucas       but there's no bzr-buildpackage
 10:39 siretart    sistpoty: yes, that was me
 10:39 lucas       also, collaborative maintenance != bzr model ;)
 10:39 \sh         lucas: so? I can use bzr and be able to export :) and use
                   debuild and pbuilder...
 10:39 sistpoty    siretart: grab the mic ;)
 10:39 siretart    this touches a bit the previous point
 10:39 raphink     is that link to buxy's proposal?
 10:39 siretart    yes, sort of
 10:39 ogra_ibook  i do all my development in bzr (public available on p.u.c) as
                   all main devs do
 10:40 raphink     s/link/linked/
 10:40 siretart    buxy's proposal was to have a common svn repo, where
                   interested ppl can just commit
 10:40 lucas       ogra_ibook: using bzr is a PITA when you don't have an
                   account on tiber or somewhere else
                   since launchpad will offer access to packages in bzr as well,
 10:40 ogra_ibook  i think you need to khave a working gateway layer to svn for
                   this proposal
 10:40 siretart    we have quite some packages, which are activley maintained by
                   us MOTUs and have no debian upstream
 10:41 ogra_ibook  lucas, that will change with the supermirror
 10:41 siretart    since we are doing team maintenance, I think it is reasonable
                   to have a common repository for them
 10:41 lucas       ogra_ibook: ETA ?
                   lucas: why? some webspace is enough..and it can be
 10:41 \sh         anywhere..if someone wants that I merge his branch, he should
                   give me the location.
 10:41 ogra_ibook  lucas, no idea
 10:41 ogra_ibook  but soon i guess
 10:41 dholbach    i have a visitor here, i will leave now - but i'll read the
                   irclog from now on.
 10:41 \sh         when hct is deployed
 10:41 dholbach    have a nice evening.
 10:41 siretart    I don't consider bzr suitable for group package maintenance
                   yet, so I'd propose svn
 10:41 sistpoty    bye dholbach
 10:41 ogra_ibook  dholbach, have fun
 10:41 siretart    bye dholbach
 10:41 dholbach    thanks a lot
 10:42 raphink     bye dholbach
 10:42 siretart    we could host that repo on tiber and grant individuals svn
                   access. this is basically buxys proposal for debian, right
 10:42 raphink     mhm
 10:43 lucas       yeah, why not do that on alioth ?
                   my question is: does anyone have objections about this? - and
 10:43 siretart    should the different MOTU Teams have different repos or
                   should everything go into ONE big archive?
 10:43 lucas       it would benefit more people
                   siretart: what packages do you think of? all that became
 10:43 sistpoty    uploaded from revu? or just a subset of ppl. willing to do
                   siretart: I thought buxys proposal was "collaborative work
 10:43 \sh         between ubuntu and debian or vice versa"...which means,
                   debian is going away from maintainership
 === lucasd [n=lucas@] has left #ubuntu-meeting ["Ex-Chat"]
 10:43 siretart    lucas: because we are ubuntu and cannot occupy debians
                   ressources for ubuntu development
 10:43 crimsun     siretart: would be best to stick to one big one
 10:43 ogra_ibook  lucas, because we have LP ?
 10:43 lucas       siretart: buxy proposed we do
 10:44 siretart    \sh: I didn't get buxy's proposal that way
 10:44 raphink     ogra_ibook: many DDs will refuse to work with LP :(
 10:44 lucas       \sh: buxy doesn't have the power to propose this ;)
 10:44 siretart    lucas: he is an alioth admin, why not?
 10:44 raphink     lucas: buxy has quite some power ;)
 10:44 lucas       siretart: I was talking about moving away from maintainership
 10:45 raphink     being one of the 3 or 4 alioth admins
 10:45 sistpoty    siretart: I'm already having a package on alioth (min12xxw)
                   to test the collaborative maintenance
 10:45 siretart    lucas: oh, your right, sorry
                   lucas: that's what I mean, how can they "pray" for a
 10:45 \sh         collaborative work, when they don't have such a system. svn
                   doesn't mean, everyone is allowed to branch and merge and
                   commit to one package at all
 10:45 ogra_ibook  raphink, LP will be the core of ubuntu development
 10:45 siretart    sistpoty: If I find some time, I will apply, too
 10:45 raphink     yes ogra_ibook, so it's fine for us ubuntu devs and
                   but I don't know how many ppl. from debian side are caring
 10:45 sistpoty    for that alioth-project... if we come with 20 devs it might
                   be overkill for alioth
 10:45 lucas       we could start on alioth using the collab-maint project, and
                   move to LP when LP is ready (for dapper+1 or +2)
 10:45 sistpoty    (at least now)
                   i dont discuss debian development here ... and i thought the
 10:46 ogra_ibook  topic is collaboration, not forc one or the other to use the
                   others tools ;)
 10:46 siretart    ogra_ibook: you're right. I proposed using tiber, not alioth
 10:46 raphink     and I tend to agree
 10:46 lucas       siretart: how will you handle security ?
 10:47 siretart    ogra_ibook: some packages could be maintained on alioth, that
                   would be more or less 'upstream work'
 10:47 ogra_ibook  siretart, thats fine
 10:47 siretart    lucas: security in what way?
 10:47 lucas       if you give svn access to lots of people
                   yes, basically I agree, siretart. we might have public read
 10:47 sistpoty    access and probably some few persons who can be naibed
                   (bringing packages to utnubu/alioth)
 10:47 siretart    lucas: what do you want to protect from whom?
 10:47 ogra_ibook  i think its fine for the debian side to use alioth though
                   regarding MOTUIM, I'm going to do the work with
                   gajim is bzr conform..xterm is bzr conform...and everybody
                   who wants to branch, can branch, and if someone is giving me
 10:47 \sh         a pointer to a bzr archive and tells me, my patch is quite
                   nice, I'll consider merging it, and daniels can take it over
                   again, when ever he wants...and debian can use those archives
                   as well...
 10:48 \sh         and nafallo is doing bzr as well :)
 10:48 siretart    \sh: do you have a list where can I branch what of 'your'
                   siretart: guys who get their system rooted, got no
 10:48 lucas       passphrase, and therefore give access to tiber from the
 10:48 ogra_ibook  lucas, thats why i prefer one controlled bzr archive ...
 10:48 siretart    lucas: I don't intend to give out shell access at all
                   siretart: and you
 10:49 \sh         find all patch branches in separate branches :) take what you
                   need :)
 10:49 lucas       ogra_ibook: svn-{inject,buildpackage} really rocks for
                   collaborative maintenance compared to bzr
 10:49 \sh         siretart: the description of the directories is straight
                   forward, if you are conform with the upstream development
 10:49 sistpoty    \sh: didn't you want to focus a bit on programming? what
                   about bzr-buildpackage ;)
 10:50 \sh         sistpoty: it's called hct :) and keybuk is working on it :)
 10:50 raphink     :)
 10:50 sistpoty    but it's not ready yet :P
 10:50 \sh         sistpoty: well...until then I'm doing it the manual way
 10:51 lucas       siretart: have you contacted buxy about his proposal ?
 10:51 lucas       (also about REVU2)
 10:51 siretart    lucas: what do you mean exactly?
                   back to topic again, I basically like the idea of having
 10:51 sistpoty    packages around at one central place, or at least one central
                   place to know what packages reside where
 10:51 siretart    lucas: I joined the discussion on the mailing list
 10:51 lucas       well, maybe his opinion could be interesting
 10:52 raphink     buxy is on #ubuntu-motu currently
 10:52 raphink     ;)
 === claud1 [] has left #ubuntu-meeting []
 10:52 lucas       just a poll: we should use (A) svn on tiber or alioth, to be
                   determined (B) bzr
 === lucas votes A
 10:52 raphink     maybe he could jump in and give us his opinion
 10:53 sistpoty    erm... what about another suggestion: everybody to his likes
                   sistpoty: to be honest, my central place to work with
                   packages is and a deb-src line in
 10:53 \sh         my sources.list...which means, all patches are inside the
                   packages, or in the .diff.gz which I can read and understand
 === raphink has no opinion on this matter
 10:53 lucas       sistpoty: what would you use ?
 10:53 lucas       it's a poll, not a vote
 10:53 siretart    \sh: the point is to give svn access to ppl which are not in
                   the ubuntu keyring (yet)
 10:53 sistpoty    I'd prefer a), but if there is a package with b) there, I'd
                   use b)
 10:53 ogra_ibook  lucas, you dont understand ...
 10:54 \sh         siretart: the keyring has nothing to do with "populating
                   changes towards packages".
 10:54 ogra_ibook  there will be a central mirror for ubuntu packages in bzr
                   format in the future, so you need to use bzr
 10:54 sistpoty    \sh: and I also wrote that I'd like at least a list, where I
                   can get to bzr or svn packages
                   \sh: the same point is raised by buxy, btw. he wants to give
 10:54 siretart    ppl with no strong commitment to packages the chance to
                   contribute to a collaborative development
 10:54 ogra_ibook  or a layer that imports it in your preferred system
 10:55 siretart    \sh: svn commit is way faster than filing patches via malone
                   maybe we could provide svn on tiber, and have a wiki-page
 10:55 sistpoty    that states if a package is in svn or if it's in bzr and
                   where to get it
                   siretart: but this is contrary to the debian philosophy, and
 10:55 \sh         I see his proposal more in this way of a collaborative work
                   between MOTUs and debian maintainers.
 === buxy [] has joined #ubuntu-meeting
 10:56 sistpoty    hi buxy
 10:56 raphink     hi buxy
                   \sh: I don't think buxy proposale about collaborative
 10:56 siretart    maintenance was 'just' about collaboration between ubuntu and
                   siretart: patches are small and if someone has to provide
 10:56 \sh         something, he can file a bug. or he is involved directly in
                   #ubuntu-motu :)
 10:56 siretart    huhu buxy
 10:56 siretart    \sh: I want to reduce overhead.
 10:57 \sh         siretart: and can send me a debdiff, bzr archive url, svn
                   access, or what ever, if he's not a member of ubuntu-dev :)
 10:57 buxy        hi everyone, I'm sorry to join so late in the discussion but
                   I've just been invited by sirestart and raphink :)
 10:57 raphink     ;)
 10:57 raphink     buxy: well I guess you're still the best guy to talk about
                   your proposal and make it cleare
 10:58 raphink     s/cleare/clearer/
 10:58 buxy        Ok, if you think it's needed I can try explain the context
 === raphink wonders why it's so silent here all of a sudden
                   buxy: from this discussion here, I'm a bit confused. Did you
 10:59 siretart    really invite all MOTUs to commit and work on packages for
                   ubuntu (and debian as well this way) in the collab-maint svn
 11:00 \sh         following the last discussion at the Debian-QA meeting on
                   Darmstadt, it
 11:00 \sh         appears that the proposal called "Collaborative maintenance"
                   is of generic
 11:00 \sh         interest :
 11:00 \sh         - for Debian sponsors and Debian mentors
 11:00 \sh         - for QA which may use the infrastructure for orphaned
 11:00 \sh         - for Ubuntu's MOTU School
 11:00 \sh         this is the first paragraph of the mail :)
                   siretart: it's a possibility that I offered yes, but as I
 11:01 buxy        told, the important part is what's above "svn" and we could
                   make the infrastructure support more than just svn
 11:01 raphink     and I've actually been wondering what was meant by "MOTU
 11:02 siretart    buxy: yes. I see.
 11:02 \sh         raphink: he means MOTU motu school is something
                   different..but quite popular :)
 11:02 buxy        raphink: The MOTU school is the "mentoring process inside
                   Ubuntu" for me :)
 11:02 raphink     oh ok ;)
 11:03 sistpoty    oh, he, no... it's irc lessons about a specific topic
 11:03 raphink     buxy: MOTU school is something else for us but ok :)
 11:03 raphink     at least I get it :)
 11:03 ogra_ibook  buxy, #ubuntu-motu is the mentoring process we use ;)
 11:03 lucas       buxy: you mean REVU actually
 11:03 lucas       (basically)
                   \sh: yes the context is summed up in the wiki page, the
                   project started for managing orphaned packages but we found
 11:04 buxy        out that it could be a good way to handle packages from new
                   maintainers and in general for packages maintained by
                   contributors outside of Debian (and MOTU are contributors
                   outside of Debian for me)
 11:05 buxy        "contributors outside of Debian" is badly said, I should have
                   said "non-DD contributors"
                   buxy: so does it mean, debian will go away from the
 11:05 \sh         maintainership of packages and let everybody who wants touch
                   packages? without being killed or flamed of the former
 11:06 lucas       \sh: the proposal is about *some* packages, not all packages.
                   lucas: even orphaned packages are still maintained..the
 11:06 \sh         former maintainer will help the new maintainer to take over
                   the package..
                   \sh: this can't be a one-day change, but maintainers who are
 11:06 buxy        willing to go in that direction could put their packages in a
                   pool where many people could work on it
 11:06 \sh         lucas: (in the best situation)
 11:07 buxy        \sh: but not all packages will be managed that way
 === segfault_ [] has joined #ubuntu-meeting
 11:09 siretart    buxy: does the debian QA team has a 'common' svn repo for
                   orphaned packages?
                   buxy: so it can be possible to branch this package source and
 11:09 \sh         provide an archive url towards the package maintainer...if I
                   want to work on this particular package...
 11:09 \sh         buxy: despite the fact of a centralized package repository
 11:09 buxy        siretart: not yet, but QA people have nothing against that
 === lucasd [n=lucas@] has joined #ubuntu-meeting
                   buxy: because this is my meaning of collaboration...if I want
 11:10 \sh         to contribute, the maintainer of package is always the last
                   point of decision if he wants my patch or not
                   buxy: currently, the utnubu team has its own 'common' svn
 11:10 siretart    repo. are they expected to keep their own repo or merge it
                   with the collab-maint one?
 11:10 \sh         means: there is no need of something centralized..
 11:11 buxy        siretart: that's a topic that I haven't brought up yet, but
                   of course I'd like to push in that direction
 === tseng [] has joined #ubuntu-meeting
 11:12 tseng       eh
 11:12 \sh         moins tseng
 11:12 buxy        \sh: collaboration is not only a tool, it's a behaviour
                   \sh: if you work n a branch on your side, and tell the
 11:12 buxy        maintainer what you did and where he can get the stuff to get
                   integrated, that's fine
 11:13 \sh         buxy: yes...and a nice one...but again...the maintainer is
                   the last resort of the decision
 11:13 \sh         buxy: that's what I said, yes :)
 11:13 sistpoty    ok, let's try to get back to the topic?
 11:13 siretart    yes, please
 11:14 sistpoty    ok... what prosals are there/can we agree on or should
                   we defer this?
 11:14 siretart    buxy: the discussion was to instantiate a common svn repo for
                   us motus
 11:15 siretart    I proposed to host it on tiber, mainly because I did not want
                   to abuse alioth for mainly ubuntu work
                   sistpoty: what proposal...if it's regarding buxy, we are
 11:15 \sh         speaking of something to be made between debian and ubuntu,
                   if we are talking about "motu collaboration" we have actually
 11:15 siretart    we want to maintain there package which we motu's activly
 === ajmitch prefers to do normal debian maintenance for those
 11:16 siretart    so the question is: should this be rather on tiber or on
                   alioth. buxy: what do you think?
 11:16 ajmitch     for my packages, that is
                   if we want to maintain the packages for ubuntu, then we
 11:17 \sh         should discuss an ubuntu way...if we are talking about debian
                   and ubuntu, we should postpone this discussion to a better
                   time and with all people involved in this....]
                   siretart: difficult to say, but hosting on alioth is ok for
 11:18 buxy        me as long as we agree that all packages which are not
                   ubuntu-specific should also be integrated in Debian (even if
                   the upload is in fact done by utnubu)
 11:18 lucas       \sh: can you define "all people involved in this" ?
 11:18 \sh         lucas: all debian responsibilities and as well all ubuntu
 11:19 \sh         lucas: because this is nothing for the motu meeting at
          touches more then "svn repos for motu on tiber"
 11:19 ajmitch     lucas: it'd involve others from the utnubu team
                   buxy: I think mostly about packages which are interesting for
 11:20 siretart    debian, too, but I didn't care enough for searching for a
                   sponsor, because I did not wanted to be the only maintainer.
                   I think there are quite some packages of this kind
 11:21 siretart    buxy: for packages which are only of interest for ubuntu,
                   thats a clear matter
 11:21 siretart    buxy: what is the procedure to get svn access to the collab
                   maint svn?
 11:21 buxy        siretart: okay, then I think alioth is a good choice
 11:22 tseng       siretart: anyone can get an account on alioth
 11:22 buxy        siretart: mail me and tell me your alioth login name and why
                   I should add you to the project :)
 11:22 tseng       siretart: team members can give you access to the svn
 11:22 buxy        tseng: team admin only
 11:22 ajmitch     buxy: can I join too? :)
 11:22 buxy        ajmitch: sure :)
 11:22 siretart    buxy: great. will do. (my login is siretart-guest ;)
 11:23 ajmitch     I'll get over my dislike of svn one day
 11:23 siretart    ok. I think we are done with this point
 11:23 siretart    next?
 11:23 sistpoty    siretart++
 11:23 sistpoty    next point is "Brainstorming/Ideas how to organize divergence
                   in our universe"
 11:23 sistpoty    who's one was that?
 11:23 ogra_ibook  "divergence in our universe" ??
                   lucas: I think
 11:24 siretart is
                   really rocking! I wanted to say you a big THANK YOU for that
 11:24 sistpoty    ogra_ibook: copy'n'paste from wiki
 11:24 siretart    ogra_ibook: I'm talking about divergence from our upstream:
 11:24 lucas       :-) thank you for hosting me
 11:24 lucas       and thank sistpoty for providing the merge comments :)
 11:24 sistpoty    he, np
 11:25 siretart    lucas: you have a coloum there for notes on individual
                   packages which can be edited via the wiki
 11:25 lucas       siretart: yes ?
 11:25 \sh         siretart: when debian will adjust to our infrastructure, e.g.
                   modular xorg etc. those diffs will automagically go away
                   I'd like that everyone who touches a package in ubuntu makes
 11:25 siretart    a note about what kind of divergence the package is in
                   ubuntu. perhaps you remember my posting to the mailinglist
 11:26 siretart    \sh: exactly thats my point
                   siretart: transitions...well, if they are announce earlier
 11:26 \sh         for debian then ubuntu, then we will have less packages to
                   touch, if not..well you know the fun :)
 11:26 ajmitch     \sh: xlibs-dev is removed from sid now - I think it's just
                   the gl libs that are a hassle
 11:26 siretart    \sh: I'd like to know when all patches e.g. because of xorg
                   are obsolete
 11:26 lucas       siretart: I started that for ruby packages, but not sure if
                   there should be a 'MUST' here
 11:26 ajmitch     siretart: that would require us to identify by patch that
                   it's a build-depends change :)
 11:27 ajmitch     siretart: it *could* be done with grep & a fair bit of work
 11:27 sistpoty    I already feared, you would say that, ajmitch ;)
                   siretart: there was last time a blog post of the xorg
 11:27 \sh         maintainer, and he is pushing the modular xorg now into
                   debian, so it can be, that for dapper+1 those changes are
 11:27 ajmitch     sistpoty: why do you say that?
 11:27 sistpoty    ajmitch: that it could be done automatically ;)
                   ajmitch: there are many types of divergence. I'd like to have
 11:28 siretart    some more overview and statistics about how far we are
                   diverged from debian and why
 11:28 ajmitch     sistpoty: nah, I didn't say automatically
 11:28 \sh         siretart: means dapper+1 will be a fcking sync orgy
 11:28 sistpoty    ajmitch: come on, you implied it :P
 11:28 ajmitch     sistpoty: certainly, and we can identify a few of those
                   automatically, to keep sistpoty happy :)
 11:28 ajmitch     heh
 11:28 sistpoty    hehe
 11:28 siretart    \sh: that would be really awesome, because I think we have
                   diverged from debian to much. and way too often unnecessarily
 11:29 ajmitch     siretart: of course, and it's always a matter of what time we
                   have to sort this out
 11:29 sistpoty    siretart, lucas: where should we post/submit the divergence?
 11:29 ajmitch     in between the bugfixing
                   siretart: well...patches like launchpad integration etc.
 11:29 \sh         which are not taken by debian upstream neither real upstream
                   will stay in ubuntu, so we will always have an ubuntuX
 11:29 siretart    sistpoty: and now we come to the point I wanted to raise
 11:29 lucas       sistpoty:
 11:30 ajmitch     siretart: not filing bugs, is it?
                   sistpoty: I think we have 2 options:
 11:30 siretart, or some more magic with
                   postgresql and javascript.
                   ajmitch: would you really file a new bug for each diverged
 11:30 siretart    package explaining why it diverged? that would be true
 11:30 sistpoty    siretart: I don't like the 2nd option... we'd need some kind
                   of user management for this to work
 11:30 siretart    sistpoty: why?
 11:31 sistpoty    siretart: because otherwise everyone could change the type of
 11:31 siretart    sistpoty: a wiki doesn't need usermanagement, too
 11:31 siretart    sistpoty: *Shrug*. wikipedia works too
 11:31 sistpoty    siretart: it does... and it has revision control as well
 11:32 lucas       siretart: I don't care, just generate or help me generate a
                   text file with the MOTUNotes syntax
 11:32 lucas       I can add several other columns to the reports if needed ;)
                   to be honest, we can't avoid to be different in some areas
 11:32 \sh         from debian, and we shouldn't want to avoid it.
                   infrastructure reasons are one point, but special ubuntu
                   patches or patches we can provide upstream is something else
 11:32 siretart    \sh: I strongly disagree
 11:33 siretart    \sh: I think we should avoid divergence where possible,
                   because we are really lacking ressources
 11:33 \sh         siretart: you can't force debian to apply our gnome patches
                   e.g. for launchpad
                   \sh: the advantage would be to have "all packages with
 11:33 sistpoty    motuglutransition" at hand, and once debian and ubuntu are
                   back in sync, this might save a lot of work
 11:33 \sh         sistpoty: this is "infrastructure" which will go away
                   \sh: please don't overread the 'where possible and necessary'
 11:34 siretart    part. I certainly know that we want some divergence, but I
                   think we have way too much of it
 11:34 \sh         sistpoty: the same applies for we saw from
                   breezy to dapper :)
 11:34 \sh         siretart: don't blame us, blame the slowliness of the
                   transitions in debian...honestly
 11:34 sistpoty    exactly, but what do you mean with infrastructure, that will
                   go away?
 11:34 siretart    \sh: I don't want to blame anyone, I want to solve problems
                   siretart: the system how debian works is really different
 11:35 \sh         from ours...and even if we're less people then debians DDs
                   and NMs, we are quite faster in those transitions.
 11:35 siretart    \sh: so what?
 11:35 \sh         siretart: so you can't avoid it...and thinking about sabdfls
                   speech at debconf5 those deltas are really normal
 11:36 \sh         siretart: for ubuntu.
 11:36 \sh         siretart: the solution is "time"
 11:36 lucas       some of them are normal, some of them aren't
 11:36 \sh         lucas: which aren't normal?
 11:36 lucas       bugs fixed in ubuntu but not reported upstream, for example
 11:36 siretart
                   lists about 900 packages, which of same upstream version in
                   both ubuntu and debian (but ubuntu hast 'local' changes)
                   \sh: but I still think we might gain much time, if we could
 11:36 sistpoty    categorize the reason, why a package diverges from debian,
                   whilst doing merges
 11:37 lucas       we have to stay at a stable distance from debian. not
                   increase this distance release after release
 11:37 siretart    \sh: I suspect a big part of them to be unnecessary. and 900
                   diverged packages is definitly way to much for us
 11:37 siretart    lucas: how often is that list updated?
 11:37 \sh         ok ok..
 11:38 \sh         short summary
 11:38 \sh         what do we have:
 11:38 lucas       every 6 hours
                   \sh: consider that you can just see: ah siretart last
 11:38 sistpoty    uploaded foo and transitioned it to c2a... debian/changelog
                   states the same, then you'll only need to check if the debian
                   package did it right
 11:38 lucas       siretart: read ;)
 11:38 \sh         we have packages with more actual upstream version
                   means  0UbuntuX
 11:38 siretart    82 packages
 11:38 \sh         sistpoty: yes..that's what we did in dapper with the c2
 11:39 \sh         sistpoty: and we will do the same for dapper+1 with all c2a
 11:39 \sh         we have packages which were renamed from us, but not renamed
                   by debian
 11:39 \sh         (but will be in time)
                   \sh: please. 900 packages is really ridiculous. our main
 11:40 siretart    divergence should be in main, not in universe. we simply
                   don't have the ressources to maintain it
 11:40 \sh         we have packages, which have special ubuntu patches applied,
                   those patches debian never will apply
                   \sh: yes, and that's the reason to categorize the
 11:41 sistpoty    divergence... to see if patches need to be reapplied or if
                   it's probably a sync candidate
                   \sh: now you slowly get the point. I want a list where I can
 11:41 siretart    look of what kind of divergence (i.e. why the package was
                   diverged from debian) a given package has
 11:42 \sh         siretart: so we need a tool which fetches the debian source
                   package and fetches the ubuntu source package and run a diff
 11:42 \sh         siretart: and we need someone who has knowledge about all the
                   changes and he can classify them
 11:43 buxy        \sh: people.u.c/~scott/patches/ :)
 11:43 sistpoty    \sh: the tool is mom... but that doesn't classify them
 === ealden [] has joined #ubuntu-meeting
                   \sh: and I'd propose lets do that marginally. everytime
 11:43 siretart    someone touches a package causing divergence or working on
                   merges he should add a note what kind of divergence that
                   package has
                   siretart: most propably we will find out, that our people
 11:43 \sh         were doing the dpatch/simple-patchsys way, debian is doing
                   the diff.gz way...or the other way around...
 11:43 sistpoty    hehe, buxy
 11:44 ajmitch     \sh: sounds like a job for an unemployed motu like me ;)
 11:44 \sh         siretart: and then we have ubuntu packages where we fixed a
                   bug from our bugtrackers...
 11:44 \sh         or simple .desktop files
 11:44 lucas       we could start by making very verbose changelog entries
                   siretart: if you keep that info somewhere, please make it
 11:44 buxy        parsable by a program so that I can make that information
                   available together with "sctottish pacthes" for Debian
 11:44 lucas       so we know *exactly* what changed
 11:45 buxy        in the Package Tracking System
 === sistpoty has just an idea
 11:45 ajmitch     buxy: good idea
 11:45 \sh         lucas: what means "verbose changelog entries" ?
 11:45 siretart    buxy: I have in mind that this information is valuable to
                   both debian and ubuntu, as it helps minimizing divergence
 11:45 lucas       \sh: no need to read the rest of the debdiff to know what
 11:45 buxy        because actually Debian maintainer can grab the diff but they
                   don't always know why the changes have been made
                   lucas: added .desktop file is quite simple and meaning
 11:46 \sh         full...reading the source and debian/rules should be
                   accomplished by someone who is working on packages at all
                   siretart: if we use revu logins, we already have a
 11:46 sistpoty    user-system... I guess I could easily h4ck up the merge list
                   to store some catagories as well
 11:46 \sh         lucas: that is wrong
 11:46 \sh         lucas: because you need to know more then only the changelog
                   and the diff.gz.
 11:46 \sh         lucas: today one DD gave me an example....source package ppp
 11:46 ogra_ibook  siretart, sistpoty, err, isnt revu2 supposed to be included
                   in LP ?
                   sistpoty: we could also use revu for authentication. but I'm
 11:46 siretart    not convinced that we would need authentication at all,
                   because I don't think there is much interest for vandalism
                   with wrong entries
 11:46 siretart    ogra_ibook: yes
 11:47 ogra_ibook  siretart, sistpoty, in which case LP logins will apply ...
 11:47 \sh         doko wrote after the merge something like this in the
                   changelog: "
 11:47 lucas       \sh: the changelog, if verbose enough, is enough to
                   categorize packages
 11:47 \sh         * Synchronise with Debian unstable.
 11:47 \sh           * Still keep the pppoe_on_boot stuff.
                   ogra_ibook: tiber isn't whitelisted for lp yet... if it was,
 11:47 sistpoty    I guess it would be trivial (at least from reading the
                   interface specs)
 11:47 siretart    ogra_ibook: yes. my point stand, I don't think that we would
                   need authentication at all, but I could live with lp accounts
 11:47 ogra_ibook  siretart, yup
 11:48 sistpoty    siretart: if I make a web interface w.o. accounts, everyone
                   could change the catagory... I don't like that
                   lucas: reading this, is verbose enough, because I know that
 11:48 \sh         we have a pppoe on boot functionality...reading the diffs but
                   shows me, that this feature was just gone in the debian
                   package long ago, but we need it
 11:48 sistpoty    siretart: other possibility was to hack up lpbugs and handle
                   this by bugs in malone
 11:49 siretart    sistpoty: I want everyone to be able to change the category
                   and even to introduce new categories
 11:49 siretart    sistpoty: do you fear much vandalism?
 11:49 sistpoty    siretart: i'm pretty paranoid ;)
                   \sh: and the interesting stuff is to understand why this
 11:50 buxy        feature is needed by Ubuntu and why it has been removed in
                   Debian :) did the Debian maintainer have a nicer solution to
                   the problem ?
 11:50 siretart    what do others think? is there a big danger from vandalism?
 11:50 \sh         buxy: no :)
 11:50 sistpoty    siretart: possibility was to use wiki, but that would mean to
                   have a "divergence" in catagories
 11:50 \sh         buxy: that's why he complained today :)
 11:51 \sh         buxy: but he didn't want to read the diff..but my opinion is,
                   as package maintainer you should
 11:51 lucas       siretart: you need to be able to restore a previous version
 11:51 lucas       siretart: I'm not sure such a page would be enough.
 11:51 \sh         buxy: and if I need some more info, I'll ask the guy who did
                   the merge :)
                   buxy: we'll always run into problems when we make some
 11:51 ajmitch     changes without proper understanding of the package, just for
                   a quick fix :)
                   so we have 4 possibilities: (a) don't categorize since
 11:51 siretart    uneccesary work (b) categorize via wiki/MergeNotes (c)
                   categorize via webtool and login (d) categorize via webtool
                   without login
 11:51 lucas       we need to be able to put a package into several categories
 11:52 siretart    lucas: right
 11:52 ajmitch     I know I'd even be wary of MOTUs patching some of my debian
                   packages :)
 11:52 sistpoty    and a user should be able to add a catagory
 11:52 lucas       (e) categorize via bugs, or a specific interface in LP
 11:52 sistpoty    :(
 11:52 \sh         ajmitch: hmmm? :)
 === siretart votes for (d)
 === lucas not sure yet
 11:53 ajmitch     siretart: why no login?
 11:53 ogra_ibook  sounds like a cool database project :)
 11:53 lucas       we want knowledgeable people to do the tagging
 === sistpoty votes for (c)
 11:53 lucas       so login is fine
 11:53 \sh         ogra_ibook: long term :)
 === ajmitch thinks (c)
 11:53 ogra_ibook  yup
 === slomo_ is for (c) too
 11:54 \sh         oh wow...a lot to read for me for the minutes :)
 11:54 slomo_      (hi btw, sorry for beeing that late, didn't notice that there
                   was a meeting :/ )
 11:54 sistpoty    hi slomo_
 11:54 siretart    ajmitch: no login because I don't fear vandalism and I want
                   to make it as easy as possible to use
 11:54 ajmitch     slomo_: don't worry, I was 2 hours late
 11:54 siretart    hi slomo_
 11:55 siretart    ok, the majority seems to be (c)
 11:55 ajmitch     slomo_: being 3 hours late is no obstacle, we're still going
 11:55 siretart    I think I'll meet with sistpoty in person and get details
                   about this discussed with him, ok?
 11:55 siretart    sistpoty: ok?
 11:55 sistpoty    siretart: sure
 11:55 ajmitch     ah, closed secret meetings? ;)
 11:55 buxy        a town name please !
 11:55 siretart    ajmitch: of course, secret cabal and such ;)
 11:56 siretart    buxy: we are at the same university, in erlangen ;)
 11:56 ajmitch     siretart, sistpoty: we need to discuss some REVU2 coding
                   sometime also
 11:56 Lathiat     motu m eeting?
 11:56 sistpoty    buxy: erlangen probably, or nuremberg
 11:56 siretart    ajmitch: right
 11:56 ajmitch     Lathiat: yes
 11:56 Lathiat     *still* going? :)
 11:56 ajmitch     Lathiat: yes
 11:56 buxy        hehe, the famous erlangen meeting !
 11:56 Lathiat     ok :)
 11:56 ajmitch     buxy: better than vancouver :)
 11:56 siretart    lol
 11:56 \sh         ejabberd is in erlangen
 11:56 sistpoty    ajmitch: oki
 === BxL [] has joined
 11:57 sistpoty    ok... what's left to discuss? date and time of next meeting?
 11:57 siretart    I think so
 11:57 siretart    3h meetings are too long
 11:57 sistpoty    definitely
 11:57 ajmitch     yes
 11:57 ajmitch     far too long
 11:58 sistpoty    I guess it would be good just after uvf?
 11:58 ajmitch     2 weeks from now?
 11:58 ajmitch     nah
 11:58 lucas       siretart: please mail a summary of what you intend to do to
                   ubuntu-motu. I'm interested in this :-)
 11:58 \sh         wasnt it the first meeting after ubz?
 === ajmitch will be at LCA in 2 weeks ;)
 11:58 ajmitch     lucas: they will have to
 11:58 sistpoty    ajmitch: sure, that's what I call "just after uvf" ;)
 11:58 lucas       siretart: and setup those backups for tiber ;)
 11:59 siretart    lucas: I'll try :) - most of this was already said in my
                   first post this year
 11:59 ajmitch     lucas: I also want to discuss some things with you..
 11:59 siretart    lucas: yes, thats on my list, too
 11:59 siretart    next meeting in 2 weeks?
 11:59 lucas       ajmitch: now ?
 11:59 siretart    objections?
 11:59 sistpoty    time, 20.00 utc?
 11:59 lucas       time is fine for me.
 11:59 ajmitch     lucas: whenever suits
 11:59 Lathiat     mm 4am :)
 11:59 sistpoty    time for objections left: 5
 12:00 sistpoty    4
 12:00 ajmitch     sistpoty: hm, I'll be busy then
 12:00 sistpoty    ajmitch: propose another time
 12:00 \sh         3...2...1...
 12:00 ajmitch     nah, it doesn't matter
 === ajmitch is just another face in the crowd
 12:00 siretart    ok. I need to go now, sorry
 12:00 buxy        ajmitch: you're an important face
 12:01 sistpoty    no, we can't meet at 20.00h... -meeting is busy there
 12:01 sistpoty    gn8 siretart
 12:01 slomo_      bye siretart :)
 12:01 siretart    I wish you a good night, sleep well everyone!
 12:01 ajmitch     bye siretart
 12:01 \sh         sistpoty: put a date and time on the wiki page..I'll promote
                   them in the minutes :)
 12:01 buxy        we don't have so many people with double hat MOTU/DD outside
                   of the core developers paid by Canonical
 12:02 sistpoty    \sh: I vote for ajmitch to put it there ;)
 12:02 ajmitch     buxy: no, I think I'm one of the few who can upload to main,
                   universe & debian who's not employed :)
 12:02 \sh         whatever :)_
 12:03 ajmitch     sistpoty: 2000 UTC is 9am for me, I'm busy all that week of
                   the 23rd-28th
 12:03 ajmitch     so I can't hold others back
 12:03 \sh         damn..I forgot to kiss ajmitch's feet while I had the time
                   during UBZ ,)
 12:03 ajmitch     \sh: you'd get a kick in the mouth :P
 12:03 \sh         ajmitch: hehe :)
 12:03 sistpoty    ajmitch: there is status meeting at 20.00 utc, so we can't
                   meet at that time and I don't have any preferences
   12:04        ajmitch      most people are in europe now, what's a suitable
                             time for you?
   12:04        sistpoty     he, I'm a student, so my time is a bit different
                             then normal peoples time ;)
   12:05        lucasd       ajmitch, where are you from?
   12:05        ajmitch      lucasd: new zealand
   12:05        lucasd       oh, I see..
   12:05        sistpoty     22.00 utc?
   12:05        sistpoty     24.00h utc?
   12:05        ajmitch      eek
   12:05        ajmitch      that's getting late for europeans who actually
                             work ;)
   12:05        sistpoty     8 utc?
   12:06        sistpoty     *g*
   12:06        ajmitch      8utc might be better, could be too early for you
   12:06        lucas        what about 22.00 utc the day before ?
   12:06        ajmitch      shall we take it to the list?
   12:06        lucas        or 2000 utc
   12:06        ajmitch      get an agreement for a meeting in 2-3 weeks,
                             settle on a time in the next week
   12:06        sistpoty     yeah... defer it to the list... we need this
                             meeting to be over now ;)
   12:07        lucas        ok
   12:07        ajmitch      or a launchpad poll! ;)
   12:07        sistpoty     yeeehaa!
   12:07        \sh          well..good night :)
   12:07        sistpoty     meeting adjourned ;)
   12:07        sistpoty     gn8 \sh
   12:07        ajmitch      night \sh
   12:07        \sh          doing the minutes somehow tomorrow or
                             saturday...depends on my timeframe of action
   12:07        sistpoty     phew... that was long
   12:07        slomo_       gn8 everybody :)
   12:08        sistpoty     gn8 slomo_

MeetingLogs/MOTU_2006-01-12 (last edited 2008-08-06 16:31:24 by localhost)