04:01   dholbach        OK everybody - welcome to the MOTU meeting
04:01   Gloubiboulga    I can only stay ten minutes :/
04:01   dholbach        We try to keep this meeting short, as we all want to get back to fixing the last bugs in Edgy. :-)
04:01   dholbach        Our agenda is quite short, it's over here:
04:01   dholbach        First point on the agenda is: "Prepare check lists for Universe/Multiverse for release."
04:02   dholbach        In the previous release cycles we always had lists of things we wanted to get done
=== Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-meeting
=== minghua [] has joined #ubuntu-meeting
04:02   dholbach        like the python transition, the unmet dependency lists, ftbfs lists and other transitions
04:02   dholbach        not to forget: Bug lists!
04:02   dholbach        What do we have on the plate for Edgy release?
04:03   Fujitsu We ideally need to get a FTBFS list, 'cause an unmet deps. list is trivial...
=== StevenK [] has joined #ubuntu-meeting
04:03   dholbach        Ok
04:03   dholbach        1) UnmetDeps list - easy to do, we can massfile bugs on that one
04:03   Fujitsu Yup.
04:04   dholbach        2) for the FTBFS list we can take the list of failed builds on launchpad
04:04   dholbach        because I think that Adam (infinity) is too busy to do an archive rebuild at this stage.
04:04   Fujitsu dholbach, not really. A lot of things haven't been built in ages.
04:04   Fujitsu Yeah, true.
04:04   dholbach        if anybody else has a feasible idea on that one, I'm all ears. :-)
=== sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #ubuntu-meeting
04:05   dholbach        Do we have any open transitions we don't get by looking at the unmet deps list?
=== givr1 [] has joined #ubuntu-meeting
04:05   sivang  dholbach: what about the python transition, is it all done ?
04:06   dholbach        sivang: for Universe: I doubt it
04:06   sivang  I see :-/
04:06   dholbach        sivang: doko_ fixed a lot and synced a lot from Debian, but I guess it's not complete (for Universe)
04:06   sivang  yes, I see
04:06   dholbach        Ok - anything else specific for the last days before release?
=== _MMA_ [] has joined #ubuntu-meeting
04:07   dholbach        (If you can think of anything later on, just mail ubuntu-motu@)
04:08   siretart        dholbach: we have that gnustep transition open
04:08   dholbach        siretart: ah! how many packages does that involve?
04:08   siretart        dholbach: you surely remember a series of UVF exceptions the last dats
04:08   dholbach        siretart: yeah I do - are there other packages involved?
04:08   siretart        dholbach: I'm not sure as I'm not familiar with gnustep at all
04:08   dholbach        I see
04:09   dholbach        I'll follow up with him.
04:09   siretart        I remember a message from, that this transition isn't complete even in debian/etch
04:09   dholbach        I'll write him after the meeting - let's hope we get that done for release
04:09   siretart        ok
04:10   sistpoty        what's that transition about... I remember quite a bunch of gnustep uploads at the beginning of edgy...
04:10   geser   the gnustep transition will need several packages to be rebuilt or synced but I haven't checked in detail yet
04:10   geser   I'm still trying to get all pieces built
04:10   minghua gnustep transition is almost finished in Debian from what I read from debian-release list
04:11   minghua some packages are still in NEW
04:11   geser   gnustep-back needs to be built
04:11   sivang  yes, also curious to know what the gnustep transition is about
04:11   sistpoty        maybe s.o. could investigate and post to ubuntu-motu@l.u.c?
04:11   dholbach        Ok, that sounds as if we're on a good way to get it fixed.
04:12   siretart        yes, lets not block the meeting with that transitions. let's move on
04:12   dholbach        For Universe/Multiverse Bugs:         1   75  of 2778 results            is, what I currently see.
04:12   dholbach        What is a good way to address those bugs?
04:12   dholbach        ( )
04:12   StevenK dholbach: Close the lot of them, of course.
04:12   dholbach        ;-)
04:12   dholbach        Right.
04:13   Fujitsu Write a script that iterates through and rejects them. Problem solved.
04:13   StevenK dholbach: Some of those 2778 probably apply to Hoary which can be found and slaughtered.
04:13   Fujitsu We have a bug-free universe.
04:13   dholbach        I'm sure that a lot of old ones can indeed be rejected.
04:13   Fujitsu StevenK, probably.
04:13   dholbach        that's rather a task for the opening of edgy+1
04:14   Fujitsu True...
04:14   dholbach        in the process of uploading a fix for universe and multiverse in the last days we should always make sure to check the bugs in launchpad for that package
04:14   dholbach        that way we can easily find bugs that can be closed with the upload and some even point to the debian bug with a patch
04:14   Fujitsu I've generally tried to do that for all of my uploads.
04:14   dholbach        Fujitsu: Good work!
04:15   dholbach        1   75  of 157 results     Uni/Multiverse bugs with patches
04:15   dholbach        those are lowhanging fruit, I guess
04:15   siretart        dholbach: I don't really see what we as motu team can decide or discuss about high bugnumbers, besides encouraging to participate in bug squashing sessions
04:15   dholbach        I'll write a mail to ubuntu-motu@ about that later on
04:15   dholbach        siretart: I only try to identify low-hanging fruit
04:16   dholbach        things we can get fixed easily.
04:16   siretart        dholbach: what we can do is to try to create reports about how many bugs we have open, how many are confirmed, important and have a patch, and list them in a report
=== StevenK makes a note to look at some of the bugs with patches when uni work has sent him insane.
04:16   dholbach        siretart: nice idea - that would go well into a MOTU section on UWN
04:16   sistpoty        from taking a glimpse on some bugs, some basic triaging (getting info etc.) might help... maybe we could do a hug day?
04:16   siretart        in the hope that this encourages uploaders actually looking at bugs. debian has a weekly report about RC bugs
04:16   dholbach        sistpoty: sure - sfllaw will be happy to see some people working on universe packages
04:17   dholbach        Ok, I'll write a mail about Universe bugs.
04:17   sistpoty        dholbach: great!
04:17   dholbach        Who wants to massfile bugs on unmet deps?
04:18   dholbach        I have a script for that - but if somebody else wants to do that, that's cool
04:18   Fujitsu I can do it, if others won't :)
04:18   dholbach        Fujitsu: I think I'll also point to the failed builds on launchpad
04:18   dholbach        Fujitsu:
04:18   Fujitsu Thanks.
04:18   sistpoty        would be good to have the packagename in the bug title (i guess that was a script bug last time *g*) ;)
04:18   dholbach        hehe :-)
04:18   dholbach        ok, let's move on - if some of you have clever ideas which bugs/fixes to address - follow up on the mailing list
04:19   siretart        and tag them! :)
04:19   dholbach        2) Find agreement on StableReleaseUpdates for Universe/Multiverse
04:19   dholbach
04:19   Fujitsu Yes, that's particularly important to me, as I've got an update or two that need doing ;)
04:19   siretart        dholbach: 1st question: do we have a -proposed upload target for universe?
04:19   dholbach        Usually shortly after releases we get lots of requests for updates to <stable>-updated
04:19   dholbach        -updates
04:20   dholbach        siretart: I'm not quite sure, I'll investigate and let you all know.
=== dous [n=dous@ubuntu/member/dous] has joined #ubuntu-meeting
04:20   sistpoty        just curious: did anyone do a SRU for uni/multiverse recently?
04:20   dholbach        not recently
04:20   siretart        dholbach: is someone only who we can ask? because I think this could be important for our further discussion of this point
04:21   siretart        s/only/online/. gnarf
04:21   siretart        sistpoty: I think LaserJock tried to do one, but mdz told him that we need a process for that first
=== lfittl is now here too, sry for being late
04:21   siretart        sistpoty: thats why we are discussion that here
04:21   dholbach        I asked in #ubuntu-devel
04:22   siretart        thanks
04:22   sistpoty        imo the entry barrier as proposed in SRU-updates is too high for universe...
04:22   dholbach        that's my feeling too, sistpoty
04:22   Fujitsu siretart, I see an SRU for matplotlib by LaserJock.
04:22   sistpoty        maybe we could get like motu-uvf in place for SRU policies and just get a final ack after the -proposed upload from ubuntu-archive?
04:22   siretart        Fujitsu: oh. i see
04:22   dholbach        <dholbach> What is the current state of -proposed? Does it work? Does it work for universe and multiverse as well?
04:22   sivang  what's the SRU?
04:22   dholbach        <Kamion> dholbach: working but restricted by policy (StableReleaseUpdates); yes; yes
04:22   dholbach        sivang: STABLE RELEASE UPDATES
04:22   sivang  dholbach: ah, right, sorry ! :-)
04:22   dholbach        *cough* :)
04:23   sivang  hehe
=== StevenK waits for his ears to stop ringing.
04:23   siretart        I like sistpoty's idea (in fact, I wanted to propose something similar)
04:23   dholbach        sistpoty: how do you think the testing process should work?
=== mindspin [] has joined #ubuntu-meeting
04:23   dholbach        ... testing part of the process ...
04:24   sistpoty        dholbach: just some ideas so far...:
04:24   sistpoty        only updates allowed with bug numbers
=== mindspin [] has left #ubuntu-meeting ["Konversation]
04:24   sistpoty        then we could "abuse" the ppl. filing the bugs to participate in testing
04:25   siretart        (they are likely interested in actually testing fixed packages)
04:25   sistpoty        the motu-uvf-alike team would also need to do some basic tests I guess
04:25   dholbach        yeah that's the interesting part of the question: who do we ask to test?
04:25   dholbach        bug reporters: good idea
04:26   siretart        dholbach: the bug submitters and subscribed ppl to that lp bug
04:26   dholbach        motu-uvf: bad idea - too much mails already ;-)
04:26   dholbach        siretart: do you think that's enough?
04:26   siretart        dholbach: let's call that group 'motu-sru'
04:26   sistpoty        yay
04:26   sistpoty        of course the uploader needs to test thoroughly *g*
04:27   siretart        dholbach: I think yes. we cannot afford the same level of testing as in main
04:27   dholbach        and that would be people who agree to do tests in the stable release now and then?
04:27   rmjb    uvf?
04:27   dholbach        rmjb: upstream version freeze
04:27   dholbach        What about mailing them to UWN and announcing them - for people to test and have a look?
04:27   siretart        dholbach: I don't understand, announce what exactly?
04:27   dholbach        that would make sure we have a reasonably big tester community
04:28   dholbach        "fixed packages of <...> available for testing."
04:28   siretart        in form of a report section of UWN? sounds great!
04:28   dholbach        yeah
04:28   minghua sounds a good idea, but I'm not sure how well that will work
04:28   Fujitsu Although some bugs already have large communities built up around them, so have a large testing ground already :P
04:28   sistpoty        dholbach: sounds great... maybe we could increase the testing time a little bit (2-4 weaks?)?
04:28   Toadstool       dholbach: and point the testers to the sru bug report, otherwise we'll get a whole load of dupes :)
04:29   sivang  Yes, sounds like UWN would encourage people to do testing.
04:29   siretart        minghua: we have to test. do you have another proposal?
04:29   dholbach        because we need to get thorough testing done: be honest: all of us run the development release and seldomly test stuff in the last stable
04:29   minghua I have some input method related package I want to propose for SRU, but I doubt many testers are interested in testing them
04:29   sistpoty        dholbach: so that proposed will become a kind of testing *g*
04:29   dholbach        sistpoty: >= 2 weeks - yes, what I thought
04:29   sivang  dholbach: well, setting up a dapper chroot is not hard :)
04:29   siretart        dholbach: how does the -propsed queue work? do uploads get automatically built and published?
04:29   minghua siretart: not really, but I think the uploader/proposer should be more responsible
04:30   dholbach        sivang: thoroughly using it, is
04:30   dholbach        minghua: we have a cjk-testers team in launchpad - maybe you could subscribe them to that bug?
04:30   dholbach        siretart: yes, in the <stable>-proposed section
04:30   sistpoty        just a side though: we should try to limit new upstream versions though, maybe only for utterly broken packages or small diffs, since these would be a target for -backports imo
04:30   sivang  so, that measn testers will have to have another box runnign dapper..
04:31   minghua dholbach: a lot of bugs I want to fix have cjk-testers subscribed, not much activity from what I see
04:31   dholbach        sistpoty: agreed
04:31   siretart        dholbach: cool. I imagined that would be a moderated queue, similar to NEW or something
04:31   sivang  sistpoty: indeed, make a lot of sense.
04:31   dholbach        minghua: you could try to prod jono about making the team more active - maybe ask in the loco teams to get people involved there
04:31   Fujitsu sistpoty, of course.
04:31   minghua dholbach: sure, I'll think more about this
04:31   dholbach        Wow, looks like we got some good ideas on that one.
04:32   siretart        :)
04:32   minghua I'm just expressing my interest on SRU for universe here :-)
=== tomveens [] has joined #ubuntu-meeting
04:32   sistpoty        for testing, maybe we could make some silly "acks >= n" guidelines for packages, to see if updating in fact makes sense
04:32   dholbach        Anyone wants to add something to it?
04:32   dholbach        minghua: :-)
04:32   freeflying      minghua: anything relate to zh_CN, ubuntu-cn would like test
04:32   minghua I think strict ack >= n is a good idea
04:33   dholbach        might be a bit tough for obscure packages
04:33   sivang  sistpoty: I'd say not >= , but they will have to provide X benefits on ground which we will update them.
04:33   dholbach        but this is something we'll figure out along the way
04:33   minghua freeflying: not really, the things I have in my head is scim-chewing and scim-m17n
04:33   minghua freeflying: but thanks for the information
04:33   sivang  so having something like "Does it fulfill A,B,C and E? okay let's update"
04:33   dholbach        We need to flesh out this process perfectly, so it'll be easy for people to get involved in approving, forwarding, testing, etc
04:33   minghua freeflying: on the other hand, most zh_CN related scim stuff are in main anyway
04:33   sistpoty        I wouldn't make it a strict policy (as dholbach just mentioned)... but rather a guideline which the sru-team could still override
04:33   freeflying      minghua: but we wtill can test
04:33   dholbach        yeah
04:34   rmjb    testing on stable can be done in a virtual appliance? if users are running development?
04:34   dholbach        Ok - let's put all of this into a wiki page later on and work on it together
04:34   sivang  rmjb: for sure
04:34   minghua back to the ack >= n thing - if we can't get enough acks, it should mean not many users are interested in this package, shouldn't it?
04:34   siretart        did we agree on a 'motu-sru' team? how many members and what quorum do we want to have?
04:35   sivang  and when Xen is ready in edgy, it will even come out of the box IIRC.
04:35   dholbach        I have the feeling that we won't solve the process entirely today.
04:35   sivang  we need to start with somethign modest,
04:35   sivang  and refine the process as we go
04:35   sistpoty        minghua: it would... but some obscure packages that are utterly broken anyway would get of starved from this... so I'd make it just a guideline which can be overridden...
04:35   sivang  *something
04:36   Fujitsu dholbach, of course, there is a lot to be decided.
04:36   dholbach        Yes
04:36   sivang  We can start with a very basic set of guidlines, and see what more we require by experience
04:36   rmjb    the sru will also apply to dapper since that's LTS or does that already have something in place?
04:36   sistpoty        minghua: also, testing by s.o. who's really knowing what he's doing is worth more then 5 tests of ppl. who don't have much clue ;)
04:36   minghua freeflying: you mean ubuntu-cn can still test packages in main, or test packages not about zh_CN?
04:36   dholbach        I'll start on later on and will try to make the wiki page so everybody can add their proposal in easily
04:36   dholbach        we should discuss the strict guidelines in another meeting
=== lukas_ [] has joined #ubuntu-meeting
04:36   siretart        or perhaps on the mailing list
04:37   dholbach        good idea too
04:37   sistpoty        +1
04:37   sivang  +1
04:37   Fujitsu +1
04:37   dholbach        so it gets some eyeballing before we finally agree in a meeting
04:37   freeflying      minghua: we'd like test anything we can do :)
04:37   siretart        next item?
=== bddebian [] has joined #ubuntu-meeting
04:37   minghua sistpoty: very true.  if some one is willing to be responsible for the upload, then things can be overridden. :-)
04:38   dholbach        MOTU Build Farm and Donation (HW, CPU time, and $) process (JordanMantha)
04:38   dholbach        laserjock is not here
04:38   dholbach        I think we probably should leave this one out for the next meeting - what do you guys think?
04:38   sistpoty        yep
04:38   minghua is TheMuso here?
04:38   TheMuso TO be honest, I think its something that should be discussed on the ml.
04:38   siretart        dholbach: perhaps you can give some details about this proposal?
04:38   minghua the proposal mail to -motu is his
04:38   TheMuso Its not something thats easily talked about on IRC>
04:38   bddebian        I think some should just send me a PPC, Sparc, and amd64 and be done with it.. ;-P
04:39   siretart        bddebian: I have a spare ultra1 ;)
04:39   dholbach        siretart: I have no idea
04:39   dholbach        siretart: it's his item :)
04:39   siretart        ic
04:40   siretart        hm. the original proposal was from Luke Yelavich
04:40   siretart        dholbach: can we abuse edgy-proposed for that?
04:40   TheMuso A few of us were talking about it in -motu earlier today, and were throwing ideas around, but due ot the complexity of what might have to be done, I feel it it would be easier on the mailing list.
04:40   dholbach        siretart: for what?
04:40   TheMuso IMO
04:40   Fujitsu I think this is fairly important, because I've run into a couple of bugs/FTBFSes in various things that only appear in PPC or [insert other obscure architecture here] . It's pretty much impossible to debug this sort of stuff without access to machines of the target architecture.
04:40   siretart        dholbach: testuploading packages to see if they build on all architectures or for testing of patches?
04:40   Fujitsu And not all of us have non-x86 machines.
04:40   dholbach        hmrmhrmhmrmhrmhrmhrmhrmhr
04:41   dholbach        I don't like the idea much - the buildds are usually somewhat blocked already
04:41   TheMuso I wasn't thinking of using the build servers.
04:41   siretart        dholbach: buildds can be prioritized. I imagine that very low priority
04:41   Fujitsu *cough* openoffice *cough* kde *cough*
04:41   dholbach        not blocked, but you know that other stuff will be delayed
04:41   dholbach        I don't like the idea much
04:42   TheMuso I am very well aware of their busy schedule.
04:42   dholbach        you can ask on #ubuntu-devel - as it's not my decision
04:42   sistpoty        imo it's not so much the problem to test if a package builds on all arches before a package is uploaded, but rather to get access to arch-xy if there is a build-failer on that arch
04:42   TheMuso Has everybody here read the original email I sent?
04:42   sistpoty        failure even
04:43   minghua TheMuso: I read :-)
=== sivang looks for the email
04:43   minghua I think TheMuso's idea is not really a build farm, but something like Debian's developer's machine for all archs
04:44   minghua which MOTUs can log in and do test builds or debugging
04:44   minghua TheMuso: is that correct?
04:44   minghua and in that case we don't need the official buildds
04:44   minghua some machines in a MOTU's house works just fine
04:45   TheMuso minghua: SOmewhat. I was thinking of something where anybody who has hardware can donate its use for building/testing, but on a purely volintary basis.
04:45   Fujitsu Like what a couple of people do now.
04:45   TheMuso And have such systems in place so that if a user donates hardware, but has low bandwidth, their systems only build small packages. Same with CPU speed, and times of day.
04:45   TheMuso Fujitsu: Exactly.
04:46   TheMuso ajmitch raised some interesting points about security. I'd have to dig back through my -motu logs to find them however.
04:46   _MMA_   Hello all. LaserJock and I talked at some length about this. I have a AMD AM2 4600+ machine that I would like to compile packages on. Currently I cant package. I wanna learn but my current situations gives me limited time to learn new things. So we discussed I could process files without configuring everything.
04:47   _MMA_   I also wanted to donate some $ for hardware.
04:48   dholbach        Can we start getting ideas together on a wiki page for that?
04:48   dholbach        It looks like it's not something we can decide easily
04:48   TheMuso Thats a good idea.
04:48   sistpoty        hm... just as a side idea: maybe we could also form amd64/sparc/ppc/whatever teams, that have access to that hw and to whom we could assign arch-specific bugs to. usually it's easy for s.o. who has that arch to fix the bug because he will know what's the problem
04:49   StevenK That's a big assumption.
=== hub [] has joined #ubuntu-meeting
04:49   sistpoty        well.. usually as in for the easy fixes... of course there are tough tasks, which the team could reject then
04:49   StevenK I own an sparc64 and a parisc, doesn't mean I know anything about how the software functions in comparsion to an i386
04:49   TheMuso StevenK: Same with myself and my ppc.
=== phanatic_ [] has joined #ubuntu-meeting
04:50   rmjb    sistpoty: with this proposal the person with the knowledge of the package can fix the bug since they'll have access to the different arches
04:50   dholbach        we could add a subpage to the wiki about people and their hardware
04:50   sistpoty        rmjb: sure... it was just an extra idea on top of that
04:50   dholbach        and decide on a process to form those teams, etc
04:50   tomveens        wiki idea: need a spokesperson for the page a one point to communicatie with about HW donation
04:51   dholbach ;-)
04:51   sistpoty        the motu-machines :)
04:51   TheMuso heh
04:51   dholbach        we can add all the security worries, process ideas, lists, mail addresses, everything to it
04:51   tomveens        who's first?
04:52   dholbach        I suggest we do that before we start to decide on something :)
04:52   dholbach        but it was great to see some ideas thrown into the mix ;-)
04:52   TheMuso dholbach: Agreed. I just wanted to get it out in the open.
04:52   dholbach        TheMuso: thanks a lot for that.
04:52   TheMuso np
04:52   dholbach        next time and date?
04:52   dholbach        I'd like to have it after the release
=== lbm [n=lbm@] has joined #ubuntu-meeting
04:53   Fujitsu A couple of days after?
04:53   TheMuso Does anybody mind if I create the wiki page dholbach suggested above
04:53   dholbach        Fujitsu: sounds good
04:53   Fujitsu Go ahead, dholbach.
04:53   tomveens        okay
=== DBO [n=DBO@unaffiliated/dbo] has joined #ubuntu-meeting
04:53   TheMuso SO I can flesh out my original proposal a little more?
04:53   dholbach        between release and UDS, after?
04:53   Fujitsu Oops, *TheMuso, not dholbach.
04:54   TheMuso :)
04:54   dholbach        Ok, we can handle that on the mailing list as well.
04:54   dholbach        Thanks a lot everybody for coming to the meeting!
04:55   TheMuso np
04:55   sistpoty        thanks for the meeting ;)
04:55   dholbach        Have a good time until the release - I know you're all going to ROCK!
04:55   Fujitsu THanks for running it :)
=== StevenK [] has left #ubuntu-meeting []
04:55   dholbach        de rien :)

MeetingLogs/MOTU-2006-10-9 (last edited 2008-08-06 16:25:11 by localhost)