MOTU_2006-01-12
09:00 \sh it's 20:00 UTC...welcome ladies and gentlemen
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] 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
/usr/share/common-licenses/GPL-2?
09:03 siretart hu folks
09:03 sistpoty hi siretart
=== janimo [n=jani@Home03207.cluj.astral.ro] 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
GPL-2
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
now
=== 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
imo
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
version
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
specified
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 [n=claude@151.87.79.83.cust.bluewin.ch] has joined #ubuntu-meeting
09:08 crimsun err, not /usr/share/doc/$foo/copyright but COPYING in the
source
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
(gcc-3.3)
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
doko..so 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
again
09:15 siretart lucas: they most probably where tried to be rebuild but
failed
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
wiki-page?
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
that!)
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
too
09:20 \sh well..merging/updating/new apps are prio 1 i think until the
19th
09:20 dholbach raphink: NEW packages have time until feature freeze (= Feb
23)
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
February
09:23 \sh https://wiki.ubuntu.com/DapperReleaseSchedule
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
anymore
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 [n=dean@host86-129-20-159.range86-129.btcentralplus.com] has joined
#ubuntu-meeting
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 https://wiki.ubuntu.com/DapperReleaseProcess
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 https://wiki.ubuntu.com/DapperReleaseProcess explicitly
contradicts that, but we'll be flexible with exceptions for
universe
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
time
09:30 raphink ogra_ibook: I understnad new packages are not considered new
versions ?
09:30 dholbach lucas: https://wiki.ubuntu.com/DapperReleaseProcess
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,
alright?
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 [n=freemane@c83-248-210-247.bredband.comhem.se] has joined
#ubuntu-meeting
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
considered
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 apt-get.org import as well :/
=== freemanen [n=freemane@c83-248-210-247.bredband.comhem.se] 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:
http://tiber.tauware.de/~siretart/unmet/
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 s.th.
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
much
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@200.223.10.10] has joined #ubuntu-meeting
=== allee [n=ach@allee.exgal.mpe.mpg.de] 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
"TODO"
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: well...it 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
point?
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 https://wiki.ubuntu.com/MOTUMeetingTeamReorg 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
others
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
https://wiki.ubuntu.com/MOTUMeetingTeamReorg ?
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
etc
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
internally
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
yours
10:07 ogra_ibook lucas^^^
10:07 lucas ogra_ibook: yes, and ?
10:08 lucas I never talked about team creation
=== mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de] 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
launchpad?
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
reasons
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
yes
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
ubuntu-dev
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
galaxy'
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 [n=ach@allee.exgal.mpe.mpg.de] has left #ubuntu-meeting
["Konversation]
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
subteams
10:16 siretart lucas: what do you gain from another team?
10:16 lucas siretart: currently, there are members of all MOTU related
teams
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
Teams?
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 else...it
10:19 ogra_ibook lucas, it isnt
10:19 sistpoty I guess the policy is come to #ubuntu-motu and talk to
people...
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
policy
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 https://launchpad.net/people/motu
=== 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
ask
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
yet?
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
package'?
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 goes....like 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
topic?
10:36 lucas http://popcon.ubuntu.com 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
apt-get.org inclusion
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
care
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
comaintenance?
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@200.209.160.94] 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
contributors
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 bzr...so
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'
packages?
siretart: guys who get their system rooted, got no
10:48 lucas passphrase, and therefore give access to tiber from the
outside
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: http://revu.tauware.de/~shermann/packages/ 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 [n=claude@151.87.79.83.cust.bluewin.ch] 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 archive.ubuntu.com/ubuntu 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 [n=nnnnnrap@arrakeen.ouaza.com] 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
debian
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
repo?
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
packages
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
School"
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
maintainer?
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_ [i=carlos@prognus.com.br] 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@200.209.160.94] 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 [n=tseng@brandonhale.us] 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 s.th. 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
maintain
=== 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
reponsibilities.
11:19 \sh lucas: because this is nothing for the motu meeting at
all..it 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 http://tiber.tauware.de/~lucas/versions/unimultiverse.html 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:
debian
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
gone
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
package
11:29 siretart sistpoty: and now we come to the point I wanted to raise
11:29 lucas sistpoty: http://wiki.ubuntu.com/MOTUNotes
11:30 ajmitch siretart: not filing bugs, is it?
sistpoty: I think we have 2 options:
11:30 siretart http://wiki.ubuntu.com/MOTUNotes, 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
overkill
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
divergence?
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 transitions..as 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
\sh:
11:36 siretart http://tiber.tauware.de/~lucas/versions/unimultiverse.html
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 http://tiber.tauware.de/~lucas/versions/ ;)
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
transitions.
11:39 \sh sistpoty: and we will do the same for dapper+1 with all c2a
transitions
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 [n=ealden@ipdial-166-146.tri-isys.com] 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
maintainer
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
changed
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
easily
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 [n=BxL@modemcable097.172-131-66.mc.videotron.ca] has joined
#ubuntu-meeting
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)