Log from the Debian Installer team meeting of March 16th, 2009, 21:00UTC
------------------------------------------------------------------------

People who speak below:

brother-	: Martin Bagge
bubulle		: Christian Perrier
cjwatson	: Colin Watson
dondelelcaro	: Don Armstrong
elmig		: Miguel Figuereido
franklin	: Franklin Piat
Ganneff		: Joerg Jaspert
jmw		: Jonathan Wiltshre
luk		: Luk Claes
Lunar^		: Jérémy Bobbio
mvz		: Max Vozeler
OdyX		: Didier Raboud
otavio		: Otavio Salvador
Ryan52		: Ryan Niebur
sepski		: Ronny Aasen
Sledge		: Steve McIntyre
tbm		: Martin Michlmayr
vorlon		: Steve Langasek
waldi		: bastian Blank
xoswald		: Xavier Oswald
youpi		: Samuel Thibault

Nicknames mentioned during the meeting though these people were not attending:

fjp		: Frans Pop
joeyh		: Joey Hess

Hours below are UTC +0100:

21:55  * bubulle waves...just in time
21:55  * otavio waves too
21:56 < bubulle> Meeting in 5 minutes....time for all participants to say hi
21:56 < otavio> bubulle: Hi!
21:56 < mvz> hi all :)
21:56 < OdyX> Hi
21:56 < Ryan52> hi
21:57 < cjwatson> hello
21:57 < bubulle> luk tbm waldi vorlon youpi : ?
21:57 < luk> hi
21:57 < brother-> hi
21:58 < tbm> I'm around
21:58 < otavio> 2min
21:58 < bubulle> from ppl who answered on Doodle we're missing Franklin and Anibal
21:58 < otavio> oh ok
21:59 < otavio> anyway we can start on time and they'll still be able to catch up with it if they appear few minutes later
21:59 -!- bubulle changed the topic of #debian-boot to: D-I team meeting | http://wiki.debian.org/DebianInstaller/Meetings/Coordination
21:59 < otavio> :-)
22:00 < bubulle> OK, time..:-)
22:00 < bubulle> Hello everybody....as you'll notice I didn't prepared the meeting that much
22:00 < bubulle> so, well, the main point is talking about the D-I team
22:01 < bubulle> My own feeling about the current status is summarized on 
22:01 < bubulle> http://wiki.debian.org/DebianInstaller/Meetings/Coordination
22:01 < waldi> bubulle: pong
22:01 < bubulle> I suggest we do a round table with about 1min per participant to give his|her view of the current status of the D-I team
22:02 < bubulle> otavio: would you mind beginning, as RM?
22:02 < otavio> bubulle: sure not.
22:02 < otavio> bubulle: It was a pleasure to me to work with all you (plural). 
22:02 < otavio> oops
22:02 < otavio> bubulle: not for you
22:02 < otavio> heh
22:02 < otavio> So ...
22:02 < Ryan52> :)
22:03 < otavio> We really had serious problems during the cycle itself. Many of them were my fault.
22:03 < bubulle> (not to interrupt otavio, but please prepare to comment in the following order: hen luk mvz tbm waldi vorlon cjwatson youpi xoswald then others....)
22:03 < bubulle> s/hen//
22:04 < otavio> Obviously we ought to do much better in Squeeze but I also belive we had few good points during it too 
22:04 < otavio> Personally I notice new people working from time to time in the installer
22:04 < otavio> and few of them has turned to be more or less regular developers of it 
22:04 < otavio> Franklin, mvz, and others fit on this group. 
22:05 < otavio> So even though we had problems I think we've done a  great job. I had a lot of fun (most of time) working with you all  
22:05 < otavio> But I really want to know the view of others.
22:05 < bubulle> (please say "over" or something else when you think you're done with your "overview" comment)
22:06 < otavio> over
22:06 < otavio> :-)
22:06 < bubulle> luk: care to be the next one commenting?
22:06 < otavio> This is my global view of it.
22:06 < luk> I think the D-I team did their best to deliver a good quality installer, but did have a shortage of manpower in general and especially of people managing/delegating which was very visible in the end
22:07 < luk> the times I coordinated with the D-I team they were always very helpful and willing
22:07 < bubulle> luk: who did you view as "D-I team"?
22:08 < luk> and I want to start helping to have a more stabilised installer
22:09 < luk> for me the D-I team is actually anyone working on it, though in particular otavio, bubulle, Lunar^, fjp
22:09 < bubulle> anything else to add on that topic?
22:09 < luk> I probably foget lots of contributors, not because they are less worthy or anything, but because I think the named people were the ones doing most management
22:10 < luk> I like the positive attitude of otavio's comment :-)
22:10 < luk> over
22:10 < bubulle> mvz, you're next...
22:10  * Lunar^ is here (Sorry to be late)
22:10 < mvz> I wasn't involved much in the last release cycle, so I can't comment usefully on the (recent) past or current state.
22:10 < mvz> The installer seems robust, largely feature complete and seems to just work for most people, so I'm not sure where we are "heading" next. 
22:11 < mvz> I'm planning to get active again and to look a bit beyond the small crypto corner that I worked on in the past. :)
22:11 < mvz> and over
22:11 < bubulle> tbm: up to you....
22:11 < tbm> I think the main problem is lack of leadership. Otavio has good
22:11 < tbm> intentions but not enough time and noone else seems to want to
22:11 < tbm> take leadership responsibilities (with the exception of bubulle to
22:11 < tbm> some degree). Another problem is lack of people working on core
22:11 < tbm> components of d-i.  (Having said this, I only have time/skills
22:11 < tbm> myself to focus on my ports and not help with core work.)
22:11 < tbm> over.
22:11 < waldi> I see the problem with lack of manpower in several teams I participate.
22:11 < waldi> Especially the core components are not that well documented (yes, I have to pick my own nose) which does not make it easier for
22:11 < waldi> newcomers to help.
22:12 < vorlon> bubulle: "hi" :)
22:12 < waldi> over
22:12 < bubulle> vorlon: your turn..:-)
22:12 < bubulle> (then cjwatson youpi xoswald)
22:13 < otavio> bubulle: maybe skip to cjwatson and let vorlon to prepare it
22:13 < bubulle> yes
22:13 < cjwatson> I may have a different view from many here. My biggest irritation with lenny was the amount of time we spent with trunk frozen and no *shared* place to commit development work; I ended up largely giving up and going off to do other things for some time just because that was more productive.
22:13 < cjwatson> I certainly recognise the need for release preparation, but personally my interests lie in straight development work and want to be able to get on with it more often.
22:13 < cjwatson> Most healthy projects need more developers than release managers. We seem to be managing to get releases out, even though it is a lot of effort; from my perspective the resource we seem to be lacking more urgently is developers willing to do extensive work. The best way to attract those is to make it relatively easy for them to get things done. d-i used to be a really freewheeling, fun development project, and of late I ...
22:13 < cjwatson> ... think we've got more rigid with the increased need for stable releases. This is understandable but perhaps we should be trying to encourage more ambitious development.
22:13 < cjwatson> I have a variety of plans for squeeze, and generally hope to be able to spend on the order of 5-10 hours a week on d-i.
22:13 < cjwatson> over
22:14 < bubulle> youpi is maybe not around
22:14 < bubulle> xoswald: you're next
22:14 < xoswald> I didn't follow closely d-i since about 2 years, so about this topic, I don't have an important opinion. I just want to say that Im back working on parted and such so I will help in d-i about partition related things
22:14 < xoswald> over
22:15 < bubulle> Lunar^: ready to comment?
22:15 < Lunar^> nearly
22:15 < vorlon> bubulle: you can consider that my contribution to the round table, fwiw; I agree with tbm and cjwatson, don't really have anything of my own to add
22:15 < bubulle> if other people attending want to give their view about the current status of the team, raise hand!
22:15  * bubulle raises hand..
22:16 < otavio> bubulle: please comment
22:16 < bubulle> My own view. We have the problems that D-I leading *and* release management was done until etch by ppl with loot of time and considerable personal involvment for it to happen
22:17 < bubulle> (namely joeyh then fjp)
22:17 < bubulle> so that gave the team a work method that's not really well adapted when the "leader" (otavio during the last cycle) has less time and availability
22:18 < bubulle> I do not consider myself as a leader fwiw and I can barely try to shake the tree from time to time but that's nearly all
22:18 < bubulle> the technical skills (or lack of) is not the main problem...more some commitment in the long term which I'm not sure to be able to handle
22:19 < bubulle> I think we need to switch to a more loose model (see cjwatson comment) but probably need time for it...and still some release management work done
22:19 < bubulle> more or less over (otherwise I talk too much)
22:19 < otavio> Lunar^: ?
22:19 < Lunar^> My comment, mostly on a personal level: I had fun moments working on d-i during the past cycle. And less fun moments crashing under the pressure that the project puts on me. I can only blame myself, for that though.
22:20 < Lunar^> It's a good thing than I better now my limits now. Unfortunately, my priorities have shifted quite away from d-i, and I do not intend to spend much time in the next months. But now that I gathered all that knowledge about how d-i works, I would really like to share it, and help others getting things done. I have several ideas of stuff that could be done in the back of my head, but I need to take time to write them down somewhere.
22:20 < Lunar^> over
22:20  * Ryan52 raises hand
22:20 < bubulle> Ryan52: go
22:20 < Ryan52> I agree with mvz that it's not really clear where "we" (err, you all :) ) are heading. and I agree that some things are not very well documented to help newcomers (like my self) try to figure stuff out. I have the willingness, ability (I think), and time to help...however it's hard to get started in a new project, and d-i seems harder than most.
22:21 < Ryan52> over
22:21  * xoswald agree
22:21 < bubulle> anyone else?
22:21  * vorlon raises his elbow
22:21 < luk> lol
22:21 < Ryan52> :-)
22:21  * bubulle slaps vorlon 
22:21 < bubulle> ;-)
22:21  * vorlon interprets that as a "go"
22:21 < bubulle> yay
22:21 < vorlon> fwiw, I don't think cjwatson's comments imply a loose model.  I think they imply a clear delineation between ongoing development and release-targeted work.
22:22 < cjwatson> yes, indeed
22:22 < cjwatson> although I see where bubulle was going with that I think
22:22 < otavio> yes
22:22  * bubulle is not sure to see where himself is going, but still..
22:22 < otavio> While I agree that we did few mistakes, and I fully agree that
22:22 < otavio> the period of time we were in freeze were too long, I also belive
22:22 < otavio> that it was due a lot of things that went bad at that time. We
22:22 < otavio> had kernel changing and a lot of last time migrations that lead
22:22 < otavio> to us not being able to release.
22:22 < cjwatson> I have a few comments in response to bubulle and Ryan52
22:23 < bubulle> cjwatson: go
22:23 < cjwatson> re bubulle's leadership comments: the thing I really find myself missing from joeyh's d-i team leadership is the technical direction. I've been trying to help out with that in reviews and the like but it doesn't half take time away from development - perhaps that is inevitable
22:24 < cjwatson> re Ryan52 and waldi's comments on documentation, absolutely, and sometimes that itself can be a fantastic way for newcomers to start ...
22:24 < sepski> I dont have much of an opinion on the cycle, since i did not follow it.  But just like to comment that i think -boot is a very helpful place. whenever i have (stupid) questions i allways get helpful and knowledgable answers. i do d-i integration for the debian-edu installer and we hope to be 100% assimilated so i (resources permitting) will spend more time in the real d-i world 
22:24 < cjwatson> ("figure thing out, document it, get it reviewed, next thing")
22:24 < cjwatson> (over)
22:25  * Ryan52 nods
22:25  * otavio nods too
22:25 < bubulle> commenting on sepski remark: one of the fear I have is precisely -boot becoming less and less helpful, because less people care answering install reports, bugs, etc.
22:25 < xoswald> as a good example, the perl team is doing great for newcomers !
22:25 < cjwatson> installation reports are something I haven't had time for since about 2005 :-/
22:25  * luk hopes someone else will write the docs as I would probably make them way too short and incomprehensible :-)
22:25 < cjwatson> I just have to cherry-pick the occasional one
22:26 < cjwatson> signal-to-noise from other threads is much better
22:26 < vorlon> are install reports something that we think we're failing to handle appropriately and need more manpower for, or are there other priorities and installation-reports should be handled on a best-effort basis?
22:26 < Lunar^> The amount of work that needs to be done on bug reports feels crazy to me. Now that I care less, I simply delete most of them, but I still have more than 30 on which I would like to take a
22:26 < Lunar^> look at some point... but that list keeps growing by 1 or 2 eac
22:26 < Lunar^> h weeks.
22:27  * bubulle would like to propose another round table about *release management* and get the views of everybody about it. I think this is the first thing we probably need to "solve" out...unless we find it is solved already
22:27 < bubulle> otavio: care to comment about your views for future release management?
22:28 < bubulle> fwiw I also pinged Sledge in case he wants to comment at any moment..:)
22:28 < otavio> I'd like to know from people what you all think I did right and wrong. This is quite important for me to know if I should continue as RM or not.
22:28 < otavio> Is anyone willing to comment on it?
22:28  * bubulle raises hand
22:28 < otavio> bubulle: please do
22:29 < bubulle> otavio: I think you got overwhelmed (en?) by working both on release management *and* technical development
22:29 < bubulle> to follow cjwatson advice, we maybe need to have things done in both directions
22:29 < otavio> bubulle: put on the list managing a company too ;-)
22:29 < cjwatson> I'd have been happy with a shared "experimental" branch
22:29 < cjwatson> I think
22:29 < bubulle> this is what I conclude from the various discussions, including the hot ones, we had with fjp
22:30 < cjwatson> that would have taken a lot of the pressure off
22:30 < otavio> cjwatson: yes; I agree completely
22:30 < vorlon> otavio: from what I saw, you were very good at being a visible leader, which is important, and generally did a good job of keeping people informed of The Plan (though your availability was a problem at some point).
22:31 < vorlon> I think you were far too lenient with allowing kernel changes in, though :)
22:31 < cjwatson> I thought we wasted a lot of time with fighting between developers wanting to get stuff committed and off their disks, and release folks wanting to freeze to get images out
22:31  * youpi there
22:31 < cjwatson> this was interesting since I was viewing it from the opposite side of the fence from my normal side :-)
22:31 < otavio> vorlon: please, lenient means?
22:31  * vorlon grins
22:31 < vorlon> otavio: relaxed, permissive
22:31 < otavio> vorlon: ok ok
22:32 < vorlon> i.e., I think we shouldn't have waited, repeatedly, for the kernel to be "just right" before releasing the rc
22:32 < bubulle> ok....that was mostly otavio's turn in the round table about elease management
22:32 < bubulle> luk: care to comment about release management in general?
22:33 < bubulle> (d-i RM of course)
22:33 < luk> lol
22:33 < cjwatson> otavio: there were several instances where you did an RM-type action and then fjp popped up to point out that there was some mistake and it should have been done some other way. Have the Right Ways in question been documented where appropriate so we can at least make new and exciting mistakes next time? :-)
22:34 < otavio> One thing I did wrong was trying to avoid doing more RCs. All the time I tried to have less RCs instead of release more fastly
22:34 < bubulle> (then, after luk mvz tbm vorlon cjwatson youpi xoswald)....
22:34 < cjwatson> this arises naturally from RCs taking forever
22:34 < luk> I think otavio did a great job in general, but otavio was sometimes not available in very inconvenient times
22:34 < luk> for the rest I agree with vorlon
22:35 < luk> and I think it's a good idea to have an 'experimental' branch
22:35 < bubulle> ok, then mvz if you have comments about RM
22:35 < mvz> I'll mostly pass
22:35 < bubulle> tbm?
22:35 < tbm> I mostly agree with what has been said
22:35 < otavio> cjwatson: yes; I did a lot of mistakes but most of them were mostly due my lack of time to prepare everything calmly. 
22:35 < mvz> just one thought:
22:35 < tbm> (oveR)
22:36 < bubulle> (vorlon commented already...but you may want to add something)
22:36 < mvz> the task seems to be extremely demanding of time and attention
22:36 < mvz> though I don't know why exactly, and which works needs to be done
22:36 < bubulle> mvz: I'd say very regular commitment...not necessarily lot of time
22:36 < otavio> Personally I belive all problems we had has raised the attention for two things: 
22:36 < otavio>  - the required amount of time to properly manage a project like d-i
22:36 < mvz> perhaps we can automate more of it, or decentralize some more tasks (e.g. build kernel udebs from linux-2.6).. but just thinking alound
22:37 < otavio>  - the coordination required between the teams
22:37 < otavio> mvz: heh; this is a bad example ;-)
22:37 < otavio> mvz: heheh
22:37 < mvz> ok, I wouldn't know :)
22:37 < cjwatson> otavio: *nod*
22:38 < otavio> I felt lose a lot of times during the management about the plans of kernel team
22:38 < Lunar^> d-i RM is something really hard. The number of issues to track is really huge, and most of the time, when there is problems, I have the feeling that most of the time no one pops up to say "I'll take care of that". Which means that solving those problems often falls down on RM shoulders.
22:39 < brother-> Regarding more RCs for D-I and RCs for Debian was a pain in the * for support (and I think publicity). If it can be done in some other way in the future I think we could try it (more codenames?).
22:39 < otavio> and this still happens; with RM people it is far more easier since they usually reply fastly. This is mostly due the size of the team (RM team is bigger then the active members on kernel team) 
22:39 < bubulle> Lunar^: that's a consequence of historically having very committed  D-I RM's...able to take out of their free time to fill these holes
22:40 < bubulle> OK...may I try to summarize things about this release management topic or do ppl want to add something here?
22:40 < otavio> bubulle: nod
22:41 < elmig> just an 'outsider' comment: for the management i believe the team needs more/better goals - both technical and features for the release. imho there is a shortage of goals that could help to focus, lead and challenge people. also there is a need to work more (together) together with other teams (kernel - take care of kernel for di and be responsible for it, release team also with goals for the release, ...?) - which other teams can help d-i/r
22:41 < otavio> bubulle: give me 2min
22:41 < vorlon> I was going to add a comment, but the channel didn't seem to be waiting for me and I didn't want to interrupt ;)
22:41 < bubulle> vorlon: go....
22:42 < cjwatson> elmig: cut off at "d-i/r"
22:42  * Sledge catches up on backlog
22:42 < elmig> which other teams can  help d-i/release? how can this be improved for the future? what  can be their responsability? also, reports *need* to be  delegated, it's valuable info. And some (core people) can  improve integration of new membrers, document (more) procedures,  ideas...
22:42 < elmig> cjwatson: those were the last 5 lines
22:43 < Sledge> one question I'd like to ask...
22:43 < otavio> I belive that we really need to improve the tools behind of d-i development ... making them more integrated and also trying to get britney to handle udebs more properly. This all will reduce the amount of work a bit.
22:43 < vorlon> the biggest challenge to release management on a project like d-i is always finding a sucker^W noble volunteer to do the work.  I think all the problems we've discussed about how the release management was done in the past cycle are ones we broadly agree upon; some of them are fixable with experience, some are a constant problem because of limited time.  So it's really more about finding someone willing to put up with the job than anything else, and ...
22:43 < vorlon> ... if we get someone willing to do that we should treasure them :)
22:44 < bubulle> Y.E.S.
22:44 < Sledge> d-i releases seem to take a very long time to prepare (as an outsider)
22:44 < Sledge> why is that?
22:44 < youpi> see vorlon's point above :)
22:44 < cjwatson> otavio's point too. There's a lot of fairly tedious manual shuffling that seems to need to be done to make it all work.
22:45 < bubulle> Sledge: I don't know why but the process is documented on http://wiki.debian.org/DebianInstaller/ReleaseProcess
22:45 < Lunar^> Sledge: bulding time of all the necessary bits, in the right order, on 11 archs
22:45 < Sledge> ok; can we improve on that, make it less manual?
22:45 < cjwatson> BTW, I think we upload debian-installer (the build system package) far too rarely
22:45 < otavio> Sledge: and all the checking needed during all the cycle
22:45 < otavio> cjwatson: yes; I'd like to change it
22:45 < cjwatson> this has the consequence that any time we try to upload it we have to spend a while fixing it all up :-)
22:46  * Sledge nods cjwatson 
22:46 < otavio> cjwatson: and I also want to have Alpha builds
22:46  * luk nods Sledge
22:46 < otavio> cjwatson: instead of jumping to beta1
22:46 < vorlon> fundamentally, the d-i development iteration cycle is multiple archive cycles long, so there's a certain sluggishness anyway compared to the rest of Debian.  This was one of the reasons joeyh pushed for more frequent dinstall. :)
22:46  * bubulle nods everybody but we're going in too many directions at a time..:-)
22:46 < cjwatson> yes, anything longer than a working day => loss of attention span, which doesn't help
22:46 < Sledge> it's not clear that having multiple builds per day is necessarily going to be better, but...
22:46 < luk> otavio: alpha dailies are the next dailies on my list (after the mips ones which I'm initiating now)
22:47 < otavio> luk: nice
22:47 < cjwatson> luk: I think he means alpha as in pre-beta, not alpha as in the architecture
22:47 < otavio> luk: but I want alpha releases
22:47 < otavio> luk: not arch ;-)
22:47 < bubulle> So, we obviously see that improving the process to take some load out of the RM should be done....
22:47 < luk> ah even better :-)
22:47 < otavio> luk: just do two, three or four alphas before beta1
22:48 < bubulle> ....but, before that do we still have someone wanting to be *the* RM?
22:48 < Sledge> one of the things that was spoken about at FOSDEM was making things more automatic
22:48 < Ganneff> .oO(there wont be more dinstalls than four for some considerable time) :)
22:48 < Sledge> i.e. doing more of d-i through the normal buildds and normal archive, instead of special-casing it
22:49 < bubulle> otavio: after all these comments and going back to your view of the release management, what is your own plan?
22:49 < Sledge> would that make sense to people here?
22:49 < otavio> bubulle: well ...
22:49 < otavio> first I think people on the team need to decide if they want me as RM or not. 
22:50 < otavio> Obviously I did mistakes but I also belive we have improved some areas. At least for me, it looks that more people is starting to having interest to work in d-i development then we had at Etch and Sarge  
22:50 < vorlon> Sledge: I'm not even sure what it is you're suggesting
22:51 < cjwatson> Sledge: you mean udeb propagation to testing?
22:51 < cjwatson> I know that's pretty manual still
22:51 < Sledge> sec...
22:51 < cjwatson> s/know/understand/
22:51 < otavio> Sledge: yes; even though some disagrees I'd still believe that debian-installer should be uploaded every two weeks or so
22:51 < luk> cjwatson: that definitely, me and adeodato will be working on it
22:52 < otavio> cjwatson: he means debian-installer uploads
22:52 < Sledge> at the moment, the daily d-i builds are made directly from svn on a range of machines scattered all over
22:52 < otavio> cjwatson: not only udebs
22:52 < bubulle> luk: so reaching that would take out some load from the D-I RM, right?
22:52 < otavio> cjwatson: and also udebs being uploaded more ofthenly 
22:52 < Sledge> then uploaded to people.d.o/~<foo>
22:52 < cjwatson> otavio: I'd be happy to have you as RM, although I think perhaps we should consider that separately from technical direction/leadership
22:52  * bubulle nods
22:52 < otavio> cjwatson: please explain
22:52 < luk> bubulle: very probably, though it would also mean having to follow it more closely to not break I guess (especially in the beginning)
22:52 < cjwatson> Sledge: oh, right. Yes, we used to do daily builds in Ubuntu with a cron job on the buildds, and they ended up in dists/foo/main/daily-installer-bar
22:52 < cjwatson> that worked quite well
22:52 < luk> Sledge: I'm working on that
22:53 < Sledge> (as an outsider) it would seem to make more sense to have regular source uploads to trigger builds on normal buildds
22:53  * Sledge nods cjwatson 
22:53 < bubulle> cjwatson: I agree on the idea of having different ppl to manage releases and technical lead
22:53 < Sledge> pushing to experimental rather than sid, most likely
22:53 < cjwatson> otavio: the main time sink of RM seems to be working through all the mechanics, and prodding people to make sure vital issues get fixed
22:53 < waldi> Sledge: uploads to the archive needs to be signed, no chance to do that automaticaly
22:53 < luk> Sledge: though I'm only taking one step at a time as I'm rather new to how things are done in d-i
22:53 < Sledge> but then when we have stuff that is expected to work, push a source upload to sid and let the buildds and dak fo the work
22:53 < otavio> cjwatson: right
22:53 < vorlon> Sledge: I think we should have regular source uploads.  I think having dailies is also useful...
22:54 < Ganneff> if we get many more uploads, i do want a better way of cleaning up the installer-*/ dirs, especially in unstable. :)
22:54 < cjwatson> otavio: I think this involves a very different mindset from thinking about the long-term technical direction of the project, code review for newcomers, that kind of thing
22:54  * Lunar^ would like to point out that frequent builds does not help if no one test them
22:54 < Sledge> Lunar^: yup
22:54 < vorlon> wrt udebs, we really ought to solve the britney propagation problem.  Now that britney is completely managed by the release team, what's holding that up?
22:54 < bubulle> hmmmmmm people we're having two different discussions at the same time right now and that doesn't help!
22:54 < cjwatson> and trying to have one person doing both as the "d-i lead" or whatever tends to result in overload
22:54 < cjwatson> (I'm done)
22:55 < bubulle> may we delay the talk about technical solutions to reduce the load to *later* please?
22:55 < bubulle> from my understanding there's a general agreement that something needs to be done. Talking about what can happen later, maybe..:-)
22:56 < Sledge> bubulle: agreed
22:56 < otavio> in theory we have people involved in areas and those should, in my pov, be taken as "leader" on that area.
22:56 < otavio> For example, I usually ping you, Lunar^ or fjp when something needs to be done on partman side
22:56 < otavio> you == cjwatson on this context, sorry
22:57 < cjwatson> yeah, that probably works out OK for now at least
22:57 < otavio> but it somewhat failed few times since people felt pushed.
22:57 < otavio> and then I stoped to push it too much
22:57 < bubulle> otavio: in such scheme with noth an RM and a "technical lead" (whether this is one person or not to be decided later) would you sign again for release management?
22:58 < bubulle> s/noth/both
22:58 < bubulle> or does someone around volunteer for release management? Or does someone think we do not need any D-I RM?
22:58  * jmw raises hand
22:59 < otavio> jmw: shoot
22:59 < jmw> from the outside, and being very new to the whole release process in general, I thought it was reassuring to know that someone had a good overview of what was happening
23:00 < jmw> and its good to hear from them from time to time
23:00 < jmw> but, it seemed a technical lead (or something similar) would be a bonus, to really drive development along (while the RM doesn't need to get bogged down in this)
23:00 < jmw> (done)
23:00 < bubulle> that seems to be another voice to "we need an RM"
23:01 < Ganneff> you should s/an/a team of RMs/
23:01 < otavio> Ganneff: that is something I'd be interested
23:01 < bubulle> Ganneff: sure, but to start a team we first need one person..:)
23:01 < vorlon> I'm struggling to understand how there would even be a question of not having an RM; bubulle, since you keep mentioning this option, do you have some idea yourself of how that would work?
23:02 < Lunar^> How about giving d-i RM to the release team?    (Just joking)
23:02 < cjwatson> let's not get too sidetracked with the "technical lead" bit. otavio's right that d-i is modular enough that this is probably not really something to worry about very much for the moment
23:02 < Ganneff> well. sure. but dont rely on one only. have two or better three people. who share the work.
23:02 < bubulle> vorlon: I'm not insisting on not having an RM, at all. But I'm trying to shake all options
23:02 < cjwatson> (but having more people doing code review would be a good way to build that kind of thing up)
23:02 < vorlon> bubulle: well, I don't see how that's even an option, so I'm wondering how you think that would be viable
23:03 < bubulle> that is probably not viable...but that's my opinion
23:03 < otavio> cjwatson: yes; I'm finally starting to try to do that again ... 
23:03 < bubulle> and if we have nobody, we have no choice..:)
23:03 < cjwatson> bubulle: I agree with vorlon, we should take "no RM" off the table, it's a distraction
23:03 < bubulle> ok
23:04 < bubulle> So, there is at least one RM
23:04 < cjwatson> admittedly in the early part of a Debian release cycle the RM doesn't necessarily have to be all that busy
23:04 < otavio> Folks .... 
23:04 < bubulle> well, at least follow if things are still building properly, etc.
23:05 < otavio> For me to stay as RM I'd like to have someone to help me with other tasks. Specially the ones that need to be done near of releases. 
23:05 < otavio> bubulle has done a great job on those, since RC1 and it worked well 
23:05  * bubulle runs away...
23:06 < otavio> it was much easier to me to work on the RM side without needing to take care of website and like
23:06 < luk> maybe Franklin is interested in that, a pity he's not present
23:06 < Lunar^> As the initial idea was to have a team, I really think it would be good if someone would volunteer to make RM a team again
23:07  * bubulle is OK to manage the release Todo list, errata preparation and website stuff
23:07 < youpi> my view is indeed that a RM doesn't necessarily actually do things, but instead knows people who can and have the time to do them
23:07 < otavio> for me also looks logical that bubulle has acted as RM assistent more of time and if he's willing to continue on that boat
23:07 < bubulle> grmbl
23:07 < luk> lol
23:07 < otavio> youpi: this doesn't work on d-i. We're short in people :( 
23:07 < otavio> youpi: so many times RM needs to do things
23:08 < youpi> :/
23:08 < bubulle> seriously speaking, I think that the most I can do is what I did for the RC's, not really more
23:08 < youpi> (recurrent problem in debian..)
23:08 < dondelelcaro> vorlon: if you find a good sucker, I need someone to RM for debbugs, too. ;-)
23:08 < vorlon> heh
23:08 < otavio> youpi: d-i RM is not only a lead but someone that needs to have a average level of skills to solve or at least identify potention origin of problems.
23:09 < youpi> yes, know the stuff
23:09 < youpi> but not do it :)
23:09 < franklin> Hi all, Sorry I missed the schedule, because busy because moinmoin was upgraded during the WE (when I was offline)
23:09 < bubulle> we probably need another person to act as "assistant" on the technical stuff
23:09 < otavio> youpi: unfortunately, I ended up doing stuff from time to time.
23:09 < otavio> dondelelcaro: heh
23:10 < otavio> So again, I belive we need to form a team
23:10 < bubulle> that "technical assistant" role was help by fjp in some way, during the final release cycle....even though Frans wasn't particularly happy of the way it was done
23:10 < otavio> Yes 
23:11 < bubulle> what could help also would be having an RM team member to be involved more closely in the D-I "core" release management
23:11 < lxsameer> hi how can i download just debian/dists/testing/main/debian-installer with apt or some thing else?
23:12 < bubulle> lxsameer: you're in the moddle of a team meeting...could you please wait for the team to end up? Thanks in advance
23:12 < bubulle> s/moddle/middle
23:12 < Lunar^> bubulle: I exepect improvements on that side if luk gets more involved in d-i
23:12 < luk> bubulle: one of the reasons I'm present, I want to get involved more closely
23:12 < Lunar^> luk: good :)
23:12 < bubulle> luk: yep, I was thinking about you, actually..:)
23:12 < lxsameer> bubulle: sorry
23:13 < otavio> luk: this is a really great news :-)
23:13 < bubulle> Lunar^: I know you probably don't want to be nominated as such but you're in some way what I think could be that "technical RM assistant" person...
23:14 < Lunar^> I won't be able to do so until next autumn, probably
23:14 < otavio> From my side, Lunar^ was really helpful during the release
23:14 < otavio> and it was really sad when he leaved the team (RM team)
23:15 < Lunar^> The only way I can think of getting back some time to do work on d-i would be to stop following the mailling-list actually ; and that do not feel like the better way
23:15 < bubulle> Lunar^: why not?
23:15 < vorlon> Lunar^: why's that?  too much bug noise or something?
23:16 < bubulle> after all, otavio could just prod you when some specific help/advice is needed
23:16 < luk> Lunar^: mailing list seems to be rather quiet atm
23:16 < otavio> Lunar^: you're welcome to stop to follow the ml :)
23:16 < luk> lol
23:16 < otavio> Lunar^: I ping you when I need an advice :P
23:17 < Lunar^> Well, I would not have been aware of the "oldstable" issue for exampe
23:17 < otavio> Well; this is another point
23:17 < otavio> We need to start to prepare the 5.0.1 installer
23:17 < otavio> and collect fixes for it
23:18 < Lunar^> but catching up emails ate the time needed to come up with a better patch than the one I sent... That's a particular example, but relevant of the really small amount of time I can dedicate to d-i these days :(
23:18 < otavio> fjp did it for Etch AFAIK he is not willing to do it for Lenny.  
23:18 < bubulle> otavio: would such team make sense: otavio as lead RM, bubulle as "the one doing the nasty boring non technical stuff" luk as "the RM link" and Lunar^ as "Super Expert we call when in trouble" make sense to you, then?
23:18 < otavio> bubulle: that works fine for me
23:19 < otavio> bubulle: cjwatson should join the boat together with Lunar^ 
23:19 < otavio> bubulle: I ping him ofthenly too
23:19  * Lunar^ is willing to try
23:19 < bubulle> that would definitely be great
23:19 < Lunar^> but we _do_ need other contributors
23:19 < bubulle> (the cjwatson option)
23:19 < otavio> Lunar^: sure; we _DO_
23:19 < Lunar^> the recent collection of improvemnts made by cjwatson really made me smile quite a lot in the past weeks
23:20 < cjwatson> otavio: I'm not sure what I can promise, but I'm willing to try
23:20 < bubulle> otavio, Lunar^: if we manage to set release goals with a good idea of ppl able to work on them, that can happen, imho
23:20 < cjwatson> I'm very bad at following the mailing list consistently, I'm afraid
23:20 < otavio> cjwatson: this is not a big problem; I and bubulle can ping you and Lunar^ when needed
23:20 < cjwatson> (which I think annoyed fjp ...)
23:20 < bubulle> cjwatson: well, those who might need to follow the list would be, in that scheme, otavio, /me and, to some extent, luk
23:21 < otavio> Could I propose few things I have in mind? For this start of cycle?
23:21 < Lunar^> Should we discuss what other people here could do?
23:22 < franklin> please do.
23:22 < bubulle> otavio: I'd love to but I have a "small" problem....
23:22 < otavio> franklin: was it for me or for Lunar^ ? heh
23:22 < bubulle> I'm falling asleep as of now; litelraly
23:22 < otavio> bubulle: oh dear!
23:22 < bubulle> and I can't stand for a logner meeting
23:23 < otavio> bubulle: ok
23:23 < bubulle> (my typo rate is increasing!)
23:23 < youpi> :)
23:23 < otavio> Maybe we could have another meeting in a cuple of weeks?
23:23 < otavio> What people think?
23:23 < bubulle> what I propose is having a meetign focused on technical stuff, such as release goals and the like
23:23 < cjwatson> there's one thing I'd like to ask now, because it affects travel plans
23:24 < otavio> Sure, plz
23:24  * Ryan52 thinks he came to the wrong meeting. heh.
23:24 < cjwatson> are we going to hold a d-i session at debcamp?
23:24 < bubulle> Would March 30th fit?
23:24 < cjwatson> I'd like to, if others are going to be there
23:24 < otavio> cjwatson: I'd like to
23:24 < bubulle> cjwatson: I'm OK for a D-I session at Debcamp, yes
23:24  * Lunar^ would be there
23:24 < otavio> cjwatson: I plan, but it depends on accessibility issues I have with DebConf :( 
23:24  * bubulle plans to arrive on July 22nd
23:24 < tbm> I canot make debcamp
23:24  * youpi could make it
23:24 < cjwatson> I'm coming with the whole family (well, at least for debconf), and thus need to make travel plans earlier rather than later :)
23:25 < luk> I'll very probably be at DebCamp
23:25 < cjwatson> be careful or I shall wield a cute baby in your general direction
23:25 < vorlon> heh
23:25 < otavio> cjwatson: heh 
23:25 < bubulle> cjwatson: I suck for tehnical work but I'm good with babies...:-)
23:26 < luk> and I'll see bubulle next month in person, so hopefully we could discuss some d-i stuff then too :-)
23:26 < otavio> Well folks. I also need to leave. I need to go to University
23:26 < otavio> Anything need from my side?
23:26 < youpi> maybe just to give a comment from the debian-accessibility side
23:26 < cjwatson> ok, same time two weeks from now is good for me, anyway
23:26 < bubulle> so, everybody OK for meeting focused on release goals on March 30th?
23:26  * youpi fine
23:26 < bubulle> 21 UTC is OK?
23:26 < otavio> bubulle: yes
23:26 < cjwatson> bubulle: aye
23:26 < mvz> ack
23:26 < franklin> ack
23:27  * Lunar^ proposes that we collect all ideas on the wiki previous to the meeting
23:27 < otavio> Lunar^: ack
23:27 < xoswald> ack
23:27 < Lunar^> (all already existing ideas)
23:27 < bubulle> Ryan52: that time, talking tech will be OK.;:-)
23:27 < vorlon> I can do that, yes
23:27 < otavio> tbm: I'll look into the kernrel patches once I'm back
23:27 < bubulle> Lunar^: http://wiki.debian.org/DebianInstaller/SqueezeGoals
23:27 < otavio> cya!
23:27 < luk> will be hard (as I will be very tired already), though I can try to make it
23:27 < youpi> About accessibility, I'd just like to say that although it took quite some time and (sometimes heated) discussions, I was happy to see that with some patience we could reach agreements and achieve some really useful things. In particular I appreciated that some people actually took the time to try the accessibility features as I described in the wiki :)
23:27 < bubulle> maybe add a section with "ideas in the wild" at the end
23:28 < otavio> I'll be back in 2hs
23:28 < Ryan52> bubulle, k :)
23:28  * Lunar^ would like to point out that it's nice to see so many faces
23:28 < cjwatson> note that clocks go forward in the EU on the 29 March
23:28 < Lunar^> I really hope people will stay around
23:29 < cjwatson> so careful of your calendars
23:29  * bubulle waves....I'll try to put the log on the meeting available immediately,then cook up "real" minutes
23:29 < bubulle> cjwatson: crap....21UTC means 23:00 for the continent
23:29 < cjwatson> I don't mind if you want it to be constant French time :-)
23:30 < luk> me neither :-)
23:30 < vorlon> ah, moving it forward an hour becomes trickier for me; we'll see
23:30 < bubulle> so, it mostly depends if otavio, vorlon and everybody at UTC-<a lot> agree for 20:00UTC
23:32 < cjwatson> ask on the mailing list and we'll see