[09:58] <dholbach> hellas
[09:59] <dholbach> hey pitti :-)
[10:00] <pitti> dong, 2000 UTC
[10:01] <dholbach> hey jani
[10:01] <jani> hey dholbach :)
[10:01] <zul> hey pitti 
[10:02] <ogra> hi robitaille :)
[10:02] <fabbione> yo
[10:02] <robitaille> hi ogra
[10:02] <seb128> evening
[10:02] <dholbach> hey seb128, fabbione :-)
[10:02] <seb128> hi dholbach 
[10:06] <mdke> :)
[10:07] <mdz> morning
[10:07] <dholbach> hey mdz 
[10:07] <mdz> Keybuk: ping
[10:07] <mdz> pinged sabdfl also
[10:07] <Keybuk> mdz: yo
[10:08] <mdz> are the people who proposed the two agenda items present?
[10:08] <mdz> they didn't give names in the wiki
[10:08] <dholbach> brb
[10:09] <jani> mdz, here
[10:09] <jani> second item
[10:10] <mdz> the zwiki history doesn't tell us who added the other item
[10:10] <mdz> so we'll defer that one, I guess
[10:10] <mdz> jani: would you like to present your issue?
[10:10] <jani> ok
[10:11] <jani> I propose that we allow selected new packages to enter hoary universe
[10:11] <jani> if techically feasible
[10:11] <jani> that's it :)
[10:11] <jani> I am thinking of packages
[10:11] <pitti> after the usual MOTU review?
[10:11] <jani> that are often requested
[10:11] <smurfix> Do you have any specific pakages in mind?
[10:11] <jani> usual or harsher MOTU review considering it's special
[10:12] <jani> nvu is what I have in mind
[10:12] <jani> it's the moist requested since warty
[10:12] <jani> and has it's own wiki page abot how to install it
[10:12] <ogra> jani, universe is stable
[10:12] <jani> fabbione I remember that
[10:12] <mdz> I was under the impression that nvu was not packaged yet; that's why it isn't in Ubuntu already
[10:12] <Keybuk> "moist requested" ?  it makes people moist, so they request it? ;)
[10:12] <ogra> jani, the nvu package wasnt reviewed
[10:12] <jani> I found a nvu package and adapted it toi ubuntu a bit
[10:12] <jani> ogra I know hence my request ;)
[10:13] <ogra> mdz, there is one on MOTUNewPackages
[10:13] <Kamion> how about hoary-updates/universe rather than hoary/universe, if that's required?
[10:13] <mdz> Kamion: I think that's a given
[10:13] <Kamion> I feel quite strongly that hoary/* should be static after hoary release
[10:13] <jani> last meeting (march 23rd) decide that it ws not worth it because it could possibly destabilize stuff
[10:13] <mdz> Kamion: for the same reason
[10:13] <Kamion> mdz: ok, it wasn't clear
[10:13] <Keybuk> my gut tells me that new things belong in the new distro, not retro-actively put in the released one
[10:13] <jani> tjhat's why I only propose new packages 
[10:13] <jani> which do not need any dependency besides what;s in hoary already
[10:14] <fabbione> jani: hoary is released.. why not focusing on breezy?
[10:14] <mdz> jani: I think the result would be a "one upload only" policy
[10:14] <jani> mdz, sure
[10:14] <mdz> which I think would be frustrating, since there are always problems with the first upload, which need to be fixed
[10:14] <jani> I will focus on breezy
[10:14] <ogra> jani, do you really think thats needed ?
[10:14] <fabbione> i mean.. it's a 6 months release cycle
[10:14] <ogra> jani, yeah
[10:14] <jani> ogram I think _users_ will appreciate it
[10:14] <jani> I do not use nvu and do not intend to
[10:14] <pitti> why can't these packages be put onto a private archive?
[10:15] <ogra> pitti++
[10:15] <pitti> we don't stop anybody from shipping stuff on breakmybuntu.org
[10:15] <mdz> pitti: that's backports, and we want to avoid that fragmentation
[10:15] <fabbione> jani: did you consider how much overhead it would take to ensure that the package will work on an "old" release?
[10:15] <ogra> and get imported in breezy then
[10:15] <dholbach> mdz++
[10:15] <jani> pitti, so we keep as many users away from sources.list
[10:15] <pitti> mdz: well, we cannot forbid hoary inclusion _and_ private archives
[10:16] <Keybuk> is there any use case for this other than "are we there yet?"
[10:16] <fabbione> jani: i think there is enough to do in universe on each release that it would be impossible for MOTU's to care about an old release too
[10:16] <jani> if it's a private archive it will prolly have other stuff in it whic may destabilize and produce sputrious bugreports
[10:16] <pitti> mdz: what's wrong with e. g. people.u.c./~foo/mycrack/ ?
[10:16] <Keybuk> I can see more complaints that we don't have Firefox 1.2 than a new package
[10:16] <Keybuk> (for example)
[10:16] <jani> fabbione, that's why  Ipropose harsher acceptance criteria so we do not abuse this
[10:17] <jani> so no backports-like stuff
[10:17] <jani> keybuk, firefox would be upgrade not a new package
[10:17] <fabbione> jani: by the time you enforce the criteria and upload, breezy will be out
[10:17] <pitti> jani: do you want to extend your proposal "only new packages" to "only packages that have been added after hoary"? (which is much harder to keep track of)
[10:17] <mdz> pitti: if there is a real demand for such software, we should try to accomodate it within Ubuntu rather than force it out to private repositories
[10:17] <mdz> it is much more manageable that way
[10:17] <jani> fabbione, what do you mean if I upload in two week from now breezy will be out already ;) ?
[10:18] <mdz> I'm concerned that this would lead us to a slippery slope, though
[10:18] <mdz> if new packages were allowed, why not new versions of existing packages?
[10:18] <fabbione> jani: no, but if you need to do a real and serious testing cycle, it might take longer than that
[10:18] <mdz> we do have good reasons for having a stable release
[10:18] <jani> mdz, because new versions could have regressions
[10:18] <mdz> also, new packages are not entirely risk-free
[10:18] <fabbione> mdz++
[10:18] <jani> new packages while not rsik-free do not have regeressions
[10:19] <pitti> mdz: I'm against changing hoary, too, but single-shot uploads make even less sense than changing hoary
[10:19] <mdz> they do not have regressions, but they can break pre-existing packages
[10:19] <jani> mdz, only if packaged badly or malware I suppose?
[10:20] <Kamion> consider a package that drops a filename into a part of the filesystem namespace owned by another package without permission
[10:20] <mdz> jani: the package could be buggy, or taken out of context.  I'm not particularly concerned about malicious packages
[10:20] <Kamion> a later version of the second package can then fail to install if you have the first package installed, and require a Replaces: where none should have been necessary
[10:20] <mdz> Kamion: worse, consider a package which supersedes an existing binary package
[10:20] <mdz> that's what happened with hplip
[10:21] <jani> mdz, it is universe. we don't know we don;t have such packages already fixed/uploaded in tha past 2 weeks
[10:21] <jani> mdz,kamion this is why I proposed more than the usual MOTU process
[10:21] <Kamion> jani: experience suggests it's better to draw a line every so often and stop worrying about the old release
[10:22] <jani> even only a selected uploader (fro
[10:22] <mdz> we have finite resources available for package QA review
[10:22] <Kamion> you can only focus on so many branches at once
[10:22] <mdz> I would rather spend those resources getting new packages into breezy, than on hoary backports
[10:22] <jani> kamion, hoary is a new release :) will be installed 6 months from now
[10:22] <ogra> mdz++++
[10:22] <Kamion> jani: yes, and we've finished it; we had 6 months to work on it
[10:22] <fabbione> jani: it will, because people will know that is stable
[10:22] <jani> ok I rest my case :)
[10:22] <Kamion> we will now have a further 6 months to work on breezy, and make that stable
[10:23] <dholbach> jani: i will review it tomorrow
[10:23] <Kamion> and the more MOTU effort that's available to work on breezy, the better it will be
[10:23] <ogra> yeah
[10:23] <mdz> I've added an item to the agenda for Sydney to discuss this
[10:23] <jani> kamion, breezy/hoary is too black/white
[10:23] <jani> users are more important
[10:24] <dholbach> jani: i feel comfortable with one universe to maintain :-/
[10:24] <ogra> jani, i'm sure users will get used to it after a while....
[10:24] <ogra> its the second release...
[10:24] <seb128> 2 versions to maintain that way is a lot of extra work ...
[10:24] <ogra> yep
[10:24] <jani> I know about all this, my proposal was to try getting most benefits with minimum effort
[10:25] <jani> not parallel hoary/breezy universes
[10:25] <jani> seb128 no need to maintain
[10:25] <jani> single upload, and that's it 
[10:25] <mdz> the best QA process we can provide for new packages is for them to go through the normal 6-month release cycle
[10:25] <Kamion> jani: useful black and white, though, and a distinction many of our users rely on
[10:25] <mdz> jani: what happens if the upload is broken?  for example, it doesn't build?
[10:25] <seb128> jani: "single upload" = no fix on the new uploads ?
[10:26] <jani> mdz, lot's of universe packages had 2 day QA cycle :)
[10:26] <Mithrandir> jani: 2 days is a lot more than "single upload"
[10:26] <seb128> better to focus on the current branch imho
[10:26] <jani> mdz, I havent htougjh of that
[10:26] <dholbach> jani: we have quite a lot of packages that didnt make it in this time... hope you dont feel too disappointed
[10:26] <ogra> jani, sadly, yes.... we'd like to improve that
[10:26] <ogra> (the 2 days QA that is)
[10:26] <jani> dholbach, I don't
[10:27] <jani> don't get me wrong people. I only bring this up because nvu is a recurring question on users list.
[10:27] <jani> and it's a web-design prog that seems popular
[10:27] <ogra> jani, note that MOTU didnt even exist before dec. so we had not the full 6 months
[10:27] <jani> btw only lispire offers it already ;)
[10:27] <mdz> did it only become a recurring question after Hoary?
[10:27] <Mithrandir> jani: then somebody should just provide a package and point people to that ; 6 months isn't that long.
[10:27] <jani> mdz, nope thoughout warty
[10:27] <jani> but the package wa sonly recently released
[10:27] <ogra> mdz, nope, it was a while on UniverseCandidates already
[10:28] <mdz> I don't see why nvu is a justification for this policy, then; its popularity would have been justification to let it into hoary before release, though
[10:28] <jani> mdz, there was no time to make it lintian clean and reviewed by enough motus
[10:29] <mdz> the user community has conflicting desires (even each user has conflicting desires)
[10:29] <jani> true
[10:29] <Kamion> the best review for a package is to have it in the archive and have users file bugs on it
[10:29] <mdz> we try to strike a balance with our release process
[10:29] <Kamion> the problem with updating packages after release is that there's no opportunity for such review before it's unleashed on everyone
[10:29] <dholbach> jani: how would you feel about the people.u.c/~someone/nvu-solution with a mailing list announcement/wikipage?
[10:29] <dholbach> jani: as a pre-breezy-solution
[10:30] <jani> dholbach, that's as bad as backports isn;t it ? :)
[10:30] <mdz> Kamion: that's one of the most significant factors for new versions of existing packages, but doesn't apply as clearly to new packages
[10:30] <jani> nah, people can dl a binaty installer from nvu.com
[10:30] <dholbach> jani: if it's our "backport"
[10:30] <dholbach> jani: not ...
[10:30] <jani> not having it in universe requires about the same effort I think
[10:31] <jani> whether it's modding sources.list or dling the binary installer
[10:31] <pitti> adding an apt source will be more robust, though
[10:32] <dholbach> jani: i think it's the cleaner solution, "rules are rules" sounds dumb, but i think it's good to have this all discussed one time, and to have a released universe sounds like the best thing to me
[10:32] <pitti> ++
[10:32] <ogra> +++
[10:32] <Mithrandir> dholbach: agreed
[10:32] <jani> fine by me too, as I said I do not use nvu :) noone I know does
[10:33] <dholbach> jani: i think, we'll take care of it, put it on some webspace, announce it to the mailinglists and are set - people who really want to use it, will grab it from there
[10:33] <jani> dholbach, and we'll build it for all architectures?
[10:33] <mdz> shouldn't we rather encourage users to test it on breezy?
[10:33] <mdz> so that they are helping to improve the quality of the eventual release?
[10:33] <ogra> mdz++
[10:33] <dholbach> jani: i think so :-)
[10:33] <jani> mdz, yes that's fine
[10:34] <ogra> no backports if avoidable
[10:34] <mdz> we will discuss the situation with backports in Sydney and see if we can come up with new ideas to satisfy that use case
[10:34] <dholbach> mdz: i thought of it as a interim solution, for the days where breezy will be too bumpy for "web-developers"
[10:34] <mdz> but for now, I think we should be cautious with the release
[10:35] <Mithrandir> dholbach: that'll be three-ish months if we follow on hoary's path
[10:35] <ogra> and note that we have quanta, bluefish, screem....
[10:35] <jani> ogra, and vi ;)
[10:35] <dholbach> Mithrandir: i know, i feel ok with it, since most of the work (reviewing, building, testing) will happen anyway
[10:36] <dholbach> hey mvo
[10:36] <ogra> jani, yay
[10:36] <mvo> hey dholbach 
[10:36] <jani> ok,  thanks for the inputs, I think we can move forward :)
[10:37] <mdz> great
[10:37] <dholbach> good
[10:37] <mdz> has the party who added the first agenda item joined us meanwhile?
[10:37] <\sh> ogra: i think the problem is with nvu: nvu runs on windows...the same with firefox thunderbird and stuff like this...that's the reason why users wants to see nvu on ubuntu :(
[10:37] <mdke> yeah
[10:37] <mdz> "Possible interaction between Devel team and Documentation team, esp. with regard to impact of last minute technical changes on documentation (i hope this is On Topic)."
[10:37] <mdke> sorry for being late, i assumed there would be more time on MaintainerCandidates etc
[10:37] <\sh> ogra: and they will take whatever package is there (this applies to any software ;))
[10:38] <mdke> mdz, i just basically wanted to raise the discussion which you participated on this week in the docteam list
[10:38] <ogra> \sh, yeah, but we dont want backports currently, so its not feasable now to introduce them ourselves...
[10:38] <mdz> mdke: understood
[10:38] <mdz> I'm not sure that there's a decision to be taken here, either by the tech board or the community council
[10:38] <mdz> is there something specific that you feel needs an official decision?
[10:39] <\sh> ogra: backports are a nono...
[10:39] <mdke> i'm happy to be guided by you on what is the appropriate forum
[10:39] <ogra> \sh, this would be one (selfintroduced)
[10:39] <\sh> ogra: but backports are for the users a "solution"
[10:39] <ogra> \sh, we'll discuss it in sydney for breezy...
[10:39] <mdke> mdz, the issue was just on whether it is possible for the docteam to be kept informed on issues which might affect the documentation, and maybe so that we can explain how decisions will affect documentation
[10:40] <mdz> I think the best approach to solving this problem is to build a strategy into the release cycle
[10:40] <mdke> sometimes I suppose this might be a factor to be taken into account when making technical decisions
[10:40] <\sh> ogra: nice :) u know my point of view ;) 
[10:40] <mdz> we would declare a freeze date for items which will affect documentation (the doc team will need to tell us what those are)
[10:40] <ogra> \sh, yep
[10:40] <mdz> and allow enough time for documentation to be updated after that
[10:40] <dholbach> ogra, \sh: you're offtopic NOW :-)
[10:40] <mdz> how much time do you think would be needed?
[10:40] <mdke> mdz, i think it depends on the issue
[10:41] <mdke> mdz, in terms of the artwork which caused a problem, its a question of doing screenshots
[10:41] <\sh> dholbach: sry...but I had this discussion in my gtoo days ;)
[10:41] <mdke> we hope to get screenshots done in all languages, but not sure how much this sort of thing would take
[10:42] <mdz> we want to be able to allow translation updates as late as possible
[10:42] <mdz> in order to get more translations in for the release
[10:42] <mdke> sure
[10:42] <mdz> of course, not all translation updates will affect documentation
[10:42] <mdz> but neither the documentation authors nor the developers know whether this is the case
[10:42] <mdke> yeah
[10:43] <mdz> I don't think we can rely on either party informing the other
[10:43] <mdke> well as far as the artwork is concerned, its just the fact that our screenshots are out of date re: the theme
[10:43] <mdke> and as you say, lots of changes are unforeseeable (like the nautilus one)
[10:43] <mdz> and so our only hope would be to schedule in advance
[10:43] <pitti> well, we really shouldn't repeat such drastic changes like the nautilus one
[10:44] <mdz> we have a BOF scheduled for Sydney to discuss changes in the release cycle
[10:44] <mdke> pitti, fingers crossed
[10:44] <mdz> so if you can provide me with your feelings about how much time we should allow, I will factor it in
[10:44] <pitti> so we should rather restrict our release policy to obey feature freeze
[10:44] <mdz> mdke: perhaps you could discuss with the rest of the team, and get back to me?
[10:44] <mdke> mdz, i think really its a question of having good communication in both directions
[10:44] <mdke> we'll follow the devel list as much as possible
[10:44] <mdz> I don't think that scales
[10:45] <mdke> what do you mean?
[10:45] <mdz> it is a lot of information to process, in order to try to pick out a very few relevant bits
[10:45] <mdke> yes that is true
[10:45] <mdz> I would rather set expectations up-front
[10:45] <mdke> ok
[10:45] <mdz> so that you can depend on being able to consider things final at a certain phase of the release
[10:45] <mdz> and if any exceptions are made to that policy, you can be informed
[10:45] <mdz> because they will require approval
[10:45] <mdke> yes I think that would be very appreciated
[10:46] <mdke> you think that is possible, even for artwork?
[10:46] <mdz> can you discuss with the team and send me a proposal?
[10:46] <mdke> mdz, certainly, perhaps we can carry on the same thread
[10:46] <mdz> mdke: I intend to try very hard to make that happen, yes
[10:46] <mdz> mdke: the artwork caused just as many problems for development as for documentation, I expect
[10:46] <mdke> heh
[10:47] <mdz> we did in fact set a deadline; we simply did not meet it :-/
[10:47] <mdke> maybe more: it didn't impact the docs, just the professionality of the screenshots
[10:47] <mdke> ok cool
[10:47] <mdke> sorry if this issue was not raised in the appropriate place
[10:47] <doko> if the artwork is a problem, we shouldn't release around 1st April ;)
[10:47] <mdz> if you can send me 1) a list of items that we should be aware of which affect documentation (artwork?  translations?  desktop behaviour?), and 2) a conservative estimate of the time it would take to adjust for a change in one of those areas
[10:47] <mdz> then I will feed that into the discussion in Sydney
[10:47] <mdke> mdz, thank you
[10:48] <mdz> now that we have been through a full release cycle, operating in a very community-involved mode, we will be making adjustments to the release process for the next cycle
[10:48] <mdz> based on what we have learned
[10:48] <mdz> this is one example
[10:48] <mdke> :)
[10:49] <mdke> ok great
[10:49] <mdz> ogra: is the maintainercandidates page up to date?
[10:49] <mdz> is there in fact anyone here who is seeking tech board approval for uploads?
[10:49] <ogra> yep, i think so....
[10:49] <ogra> (up to date)
[10:50] <ogra> we have a problem with some ppl getting their keys signed....
[10:50] <mdz> there are perhaps 30 names on that list
[10:50] <ogra> but i'd like to suggest tritium for MOTU, he has done a good bunch of packages already ....
[10:51] <mdz> it seems that the process is not quite as smooth as we would like, yet ;-)
[10:51] <ogra> it think dholbach agrees here
[10:51] <dholbach> ogra: i do
[10:51] <mdz> candidates do not seem to know what they need to do in order to apply
[10:51] <ogra> mdz, the key stuff is holding up everthing
[10:52] <ogra> mdz, oh, they know.... but no signed CoC without key....
[10:52] <mdz> ogra: don't we have a notarization process for that now?
[10:52] <ogra> mdz, yep...
[10:52] <mdz> between that, and finding local people in the strongly connected set, this should not be such a big obstacle
[10:52] <mdz> do we need to provide better facilities for coordinating keysignings?
[10:52] <mdz> perhaps use biglumber or something?
[10:53] <mdke> launchpad would be easy
[10:53] <ogra> mdz,  some sort of gpg location maps of ubuntites would be nice
[10:53] <mdz> is the problem finding people to sign the key, or is it a problem that people don't want to make the effort?
[10:53] <dholbach> mdz: finding people
[10:53] <ogra> mdz, not sure about that, but my impression is, that its hard to find ppl
[10:53] <mvo> biglumber seems to be a pretty good place, lot's of people on it apparently
[10:53] <mdz> I believe biglumber has ICBM coordinates, too
[10:54] <mdz> LUGs sometimes have keysigning events
[10:55] <mdz> the key signing requirement is actually very minimal; it would be irresponsible for us to do any less verification
[10:55] <dholbach> ok... seems like we have to do more encouraging and link-collecting work :-)
[10:55] <ogra> mdz, something derived from UbuntuWorldWide where people willing to sign others could list themselves would be nice.... i know dholbach already thought about i
[10:55] <ogra> t
[10:55] <mdz> tritium: what is your name?
[10:55] <tritium> mdz, Michael Rimbert
[10:56] <mdz> ogra suggested that you were interested in applying for maintainership, but I don't see you on the MaintainerCandidates page
[10:56] <ogra> mdz, mako removes peple after they get members afaik
[10:56] <tritium> mdz, my original plan was to pursue universe maintainership
[10:56] <mdz> ogra: and they need to re-add themselves to apply for maintainer?
[10:57] <ogra> (we'll need two lists i guess)
[10:57] <mdz> ogra,dholbach: you both support tritium for upload to universe?
[10:57] <dholbach> absolutely
[10:57] <ogra> mdz, the maintainership page says they need to add themselves on the TB agenda....
[10:57] <ogra> mdz, yup
[10:58] <mdz> Keybuk, sabdfl: ?
[10:59] <Keybuk> mdz: no opinion, not seen anything from him
[10:59] <mdz> hmm, we're due for a process clarification following the Hoary release, aren't we?
[10:59] <dholbach> http://lists.ubuntu.com/archives/ubuntu-users/2005-April/028373.html lists a lot of packages, tritium worked on
[11:00] <ogra> hoary-changes lists 14 uploads 
[11:00] <ogra> at least
[11:00] <ajmitch_> hi
[11:00] <mdz> I am willing to defer to ogra and dholbach in general, for universe candidates
[11:00] <ogra> mdz, discussing it in UdU....?
[11:00] <mdz> but I think we need to revise the published process, for which we need sabdfl
[11:00] <dholbach> apart from that, he works nice within the team and i'm confident completely in him
[11:01] <mdz> the web page states that a vote is necessary, but doesn't go into more detail than that
[11:01] <mdz> I support tritium for universe maintainership
[11:01] <crimsun> I can also vouch for tritium, having worked with him on several packages.
[11:02] <mdz> given that Keybuk has abstained, and sabdfl is not present, I'm unsure whether that's sufficient to carry the motion
[11:02] <mdz> tritium: have you been before the community council yet?
[11:02] <Keybuk> I'm willing to accept ogra's and dholbach's opinion
[11:02] <Keybuk> so if they both agree, I'll agree on that basis
[11:02] <Keybuk> which carries the motion
[11:02] <tritium> mdz, no, I have not.
[11:03] <Keybuk> I just have no personal opinion, having not worked with the guy
[11:03] <ogra> tritium, ??
[11:03] <ogra> tritium, i thought so
[11:03] <mdz> Keybuk: we've acknowledged that in many cases we need to rely on testimonials from those directly involved; we can't know everyone
[11:03] <mdz> I trust their judgement in this area
[11:03] <mdz> CC approval is still pending
[11:03] <tritium> ogra, I've attended meetings.
[11:03] <mdz> but we'll consider tritium to have tech board approval
[11:03] <mdz> tritium: preliminary congratulations
[11:04] <tritium> Thank you very much :)
[11:04] <mdz> anyone else, or any other business?
[11:04] <ogra> tritium, put yourself on the CC agenda then please.
[11:04] <mdz> ok, tech board meeting adjourned
[11:04] <tritium> ogra, will do.
[11:04] <mdz> thanks, everyone
[11:05] <dholbach> thanks mdz
[11:05] <mdz> CC meeting is tomorrow, this week
[11:05] <doko> mdz: just a short look at the toolchain.
[11:05] <mdz> I'm not sure when the next tech board meeting will be; I'll be in Australia for the next two Tuesdays
[11:05] <mdz> I'll see if we can hold the meeting at the normal time
[11:05] <mdz> and will update the wiki accordingly
[11:05] <mdke> mdke, i sent you a query, hope this is ok
[11:06] <mdz> doko: can we discuss on #ubuntu-devel, or do you feel there is a TB decision to be made?
[11:06] <mdke> mdz ^^
[11:06] <doko> mdz: devel is ok
[11:06] <Keybuk> mdz: given sabdfl's proposed "Maximum Burnout" schedule for UDU, I'd rather like it to be somewhere near our local timezone at the time
[11:07] <fabbione> Keybuk: next TB meeting will be at 04:00 UTC as scheduled
[11:07] <fabbione> just decide the date since everything got messed up for the release
 I'll see if we can hold the meeting at the normal time
[11:08] <doko> fabbione: we could have the meeting at 04:00 UTC every time
[11:08] <Keybuk> the "normal time" would be (runs out of fingers), uh, 6am local?
[11:08] <Keybuk> 2000UTC -> 6am Wednesday I think?
[11:08] <fabbione> Keybuk: a few meeting ago sabdfl agreed in starting a time rotation
[11:09] <fabbione> if after 2 meetings we start with exceptions it will all be more confusing
[11:09] <Keybuk> are you sure you're not confusing TB with CC?
[11:09] <Keybuk> we've not agreed to changing the TB meeting time
[11:09] <fabbione> Keybuk: yes we did agree to change both of them
[11:09] <Keybuk> where?
[11:09] <fabbione> somewhere.. mako should have sent a mail out a long time ago
[11:09] <Keybuk> he didn't
[11:10] <Keybuk> certainly hasn't been discussed in a TB meeting
[11:10] <fabbione> and right now we are using only this channel topic
[11:10] <doko> Keybuk: there should be no problem with rotating the meeting time
[11:10] <dholbach> doko++
[11:10] <mdz> Keybuk: on the normal days, I mean
[11:11] <fabbione> + 4:00 UTC should be on tuesday
[11:11] <Keybuk> other than the fact it might be at a time the members can't actually turn up?
[11:11] <fabbione> to keep always the same day of the week
[11:11] <mdz> I think I can probably spare an hour next tuesday, but probably not during UDU
[11:11] <fabbione> at different time
[11:11] <mdz> according to the normal alternating schedule, TB would be scheduled during UDU
[11:11] <fabbione> Keybuk: as it is now we have people that NEVER shows up becuase it's in the middle of the night
[11:11] <mdz> and CC during LCA
[11:12] <fabbione> Keybuk: so a bit of sacrifice from everybody will make it possible
[11:12] <Keybuk> fabbione: it's always during _someone_'s night
[11:12] <fabbione> Keybuk: exactly.. so we can share the pain
[11:12] <fabbione> and have the possibility to get everybody here
[11:12] <Keybuk> if there was a 0400UTC meeting, I would simply not attend
[11:13] <fabbione> Keybuk: sabdfl agreed on the rotation... you can take it up with him