Ubuntu MOTU Meeting, 23rd of Auguest 2005
Appologies: ogra has problems with his DSL, cannot attend. dholbach is busy, "have fun with the meeting" ajmitch thinks dholbach has a poor excuse
Lathiat volunteers to write-up the meeting minutes
- Transitions *
- - libcairo1, first priority - 47 packages to transition
- slang1 -> slang2, second priority -
- slomo: Most of this is done now, some are problematic upstream
< lathiat-> a quick count puts libcairo1 at 47, libqt3c102-mt at 37, libgmp3 at 30 and libdps1 at 16, unmet wise
< lathiat_> libdps1 seemed to be simple rebuilds, not sure about qt3 or gmp3
< lathiat_> i think theyre just cxx cruft leftover
< \sh> I'll take libqt3c102-mt
< lathiat > iwill work on libdps1, libgmp3 - gl/glu transition -
- infinity has done alot of this, but there is still stuff to go
< siretart> lathiat_: no, we are still waiting for new ghc6 releas
< ajmitch> sistpoty: any news of a release tere?
< sistpoty> it's not yet there...
< sistpoty> but a daily tarball from yesterday seems to do the gcc4 trick
< sistpoty> should we go for it?
< lathiat_> is there any indication of a rough timeline?
< lathiat_> like is it likely to be within a week or two or alot longer ?
< siretart> sistpoty: you already did package it?!
< sistpoty> siretart: some kind of... but more a ugly hack than a package
< siretart> lathiat_: it should have been there last week
< siretart> sistpoty: oh. ok. Let's talk about this later SUMMARY ghc6 won't build due to gcc4, waiting for new upstream release to fix this then we can upload the bootstrap (lamont will do this) and then fix all th eother packages
- - libcairo1, first priority - 47 packages to transition
- Automatic test-builds of universe / Universe QA *
< \sh> next point: Automatic testbuilds of universe
< \sh> Lamont: ping is it possible without any hassle for u or infinity/elmo?
< siretart> how up to date is this? http://people.ubuntu.com/~lamont/buildLogs/Test/
< lamont> I think the import is running now, meaning that none of it is current
< lamont> wanna-build -b i386/build-db -dbreezy-autotest --list=all | tail
< lamont> Total 0 package(s)
< lamont> once the import finishes, the buildd
< lamont> 's will just start going.
< ajmitch> so then we can get stuck in & get buried with FTBFS packages
< \sh> as ogra said today, universe won't be in shape for release this time..but that was the truth since the beginning
< ajmitch> we'll get it into as good a shape as possible then
< \sh> for breezy+1 : 1. prio fixing, polishing
AptGetOrg / NEW packages *
< siretart> I did not really get that APT-GET.ORG Project. I thought there would exist some script that automatically check random source repositories on apt-get.org, right?
< ajmitch> siretart: yes, but we have to check the packages for worthiness
< lathiat_> siretart: yes, see https://wiki.ubuntu.com/AptGetOrg
< \sh> ajmitch: for sure..but many sources are unmaintained, but still in the archives..
< Mitario> is there a number of sources unmaintained somewhere?
< \sh> unmaintained == no upstream activity anymore && upstream != debian
< ajmitch> and it'll get worse for the apt-get.org mass imports coming up
< \sh> ajmitch: it was his goal for breezy I think but it looks like, that we have to postpone this goal to breezy+1
< \sh> !!! ATTENTION !!!
< from ogra, via \sh>
< \sh> APT-GET.ORG IS A MUST OF MARK!
< \sh> 2. apt-get.org is a SABDFL have to be included very important project
< \sh> but ogra told me : THIS IS IMPORTANT !
< siretart> I'm rather confused how that fits into 'NO MORE NEW PACKAGES'
< ajmitch> siretart: pre-existing goal
< lathiat_> i think we should try get the big transitions out the way first
< ajmitch> lathiat_: yes, please
< \sh> mvo: actually...we don't have the time and the power to do all reviewing of those packages and building the stuff, fixing for breezy
< mvo> it's a sabdfl goal, so there is little room to argue. but it's certainly up to the reviewer to decide what to include and what not
< ogra> note that dholbach did apt-get.org alone in three weeks for hoary, its a task a team of two or three can do relatively fast...
< siretart> so lets rediscuss this topic again in 2 weeks
< mvo> dholbach will probably work fulltime on it for some days/weeks
< siretart> we are busy enough with those 6 transitions
< mvo> I would start with the stuff that actually builds and looks interessting. that should be a fairly short list
< ogra> mvo, yes, but mdz requested it to be done early because these packages come in external and should recieve more testing then last time as i understood it
< siretart> and how much manual work does it involve?
< lathiat_> siretart: get sources, compare to upstream, security/sanity check all the debian specific stuff, make sure it builds, check that its likely to be maintainable, do a license check and make sure its distributable
< lathiat_> siretart: preferebly check the author is likely to maintian them
< lathiat_> just check out what the package is, some stuff like kernel stuff can probably just be thrown out
< lathiat_> etc
< ogra> in any case it think we shouldnt waste manpower to NEW stuff, if external people come with packages its nice to have them in revu, but they should be aware that their packages might not make breezy
< Yagisan> what is said packages are both on apt-get.org, and in revu ?
< ajmitch> so spend less time reviewing on REVU, more time fixing?
< mbreit> but again: so what's the opinion about uploading the packages which are already on revu? is that still okay?
< mbreit> ogra: then uploading packages on revu is still okay?
< ogra> mbreit, we need to draw a line anywhere
< \sh> imho it's better to have packages in revu then on apt-get.org... so we have to encourage the maintainers to come to us...and not we to them < \sh> The reasoning behind this is obvious:
< \sh> let us have a look at those packages, provide them through Ubuntu and make sure people don't have to add random repositories to their /etc/apt/sources.list.
- apt-get.org is a must of marks, it has to be done
- transitions are more important, we will do them first
- We should not do any NEW packages until transitions and preferebly
- apt-get.org are done
- We will re-discuss this in 2 weeks at the next meeting.
- Reducing REVU votes from 3 to 2 MOTUS *
< siretart> ogra: I think its a bit unfair: ppl preparing packages on apt-get.org get packages in universe with one MOTU vote, and ppl using revu or wiki need 3 motus. I think that barrier should really be lowered
< siretart> I wouldn't insist on equal vote, but 3 is imo too high
< sistpoty> i would go for 2 revu votes, just a stomache feeling however
< siretart> any objections?
< ajmitch> sistpoty: I'd be inclined to agree
< Nafallo> 2 votes, we can always raise that number again
< slomo> ok, i'm for two votes... and when that doesn't work we talk about it then
- Yagisan likes two votes
- mbreit agrees, too
< lathiat_> ok i think we're sold on that
- We will now only require 2 MOTU votes to accept packages in REVU
- Sending patches to upstream / debian *
< \sh> there is this utnubu project of debian
< siretart> ajmitch: this meens manual work for each diff, right?
< ajmitch> siretart: if you have the time for it, yes
< \sh> right now they're fetching our patches somehow.and applying some of them to debian packages
< sistpoty> sh: you mean utnubu?
< sistpoty> + \
< ajmitch> if you look on packages.qa.debian.org/fillinpackagenamehere, then there's an ubuntu patch link where we've done some work
< \sh> moment
< ajmitch> although the utnubu team exists, IMHO it doesn't excuse us from contacting the debian maintainers
- After breezy we begin the fun merging process again, this means we will need to send patches upstream to debian to make it much easier We should also send patches to where upstream where appropriate (e.g. gcc4 builds fixes)
- Next Meeting *
< \sh> ok...2005-09-07?
< ajmitch> \sh: yes, what time?
< \sh> lets say again: 22:00 UTC?
< \sh> ok....that's setteled
< \sh> 2005-09-07 22:00 UTC?
< lathiat_> ok
END OF MEETING
DISLCAIMER: Portions of this meeting probably affecting the outcome may
- and probably were edited out.