MOTU Meeting Summary, 24th August 2005

Trent Lloyd lathiat at bur.st
Thu Aug 25 11:07:00 CDT 2005


Hey Guys,

I've made an attempt to sum up the meeting, and provide relevant bits of
chat log.

They are out of order etc, as I reordered them to put sense making bits
together.

If you want, you can get the whole log here
http://bur.st/~lathiat/motu-meeting.log

Text file attached.
(and the attached file is at http://bur.st/~lathiat/motu_meeting)


Trent

-- 
Trent Lloyd <lathiat at bur.st>
Bur.st Networking Inc.
-------------- next part --------------
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
  nafallo: http://www.magicalforest.se/tmp/give-backs_amd64.txt

  - slang1 -> slang2, second priority -
  slomo: Most of this is done now, some are problematic upstream
  https://wiki.ubuntu.com/MOTUSlang2Transition

  < 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
  see http://wiki.ubuntu.com/MOTUGLUTransition

  - ghc6 (haskell) -
  < 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

 * 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 :)
 
 SUMMARY:
 Test builds should start happening soon, when they do we should try to
 tackle as many of the failing builds as possible

 * 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.
  SUMMARY:
   * 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

  SUMMARY:
   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
 
 SUMMARY:
  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

 jblack kindly comes and has a chat to us about baz/bzr

END OF MEETING
  

DISLCAIMER: Portions of this meeting probably affecting the outcome may
            and probably were edited out.


More information about the ubuntu-devel mailing list