20:00:19 <bubulle> #startmeeting
20:00:20 * mvz edits
20:00:32 <bubulle> Here we go. Let's see what we can do
20:00:36 <luk> halp :-)
20:00:45 <mvz> halp? :)
20:00:58 <bubulle> I propose we go over last meetings topics
20:01:07 <luk> I guess it should be 'help' for MeetBot
20:01:20 <bubulle> #topic alpha release
20:01:47 <luk> parted still did not move to testing and is not entangled with the KDE transition
20:01:52 <bubulle> without a release manager, that will be hard. Let's try anyway: what is currently preventing us from releasing something?
20:01:54 <luk> s/not/now/
20:02:11 <bubulle> So, parted transition is one blocker...
20:02:22 <luk> though KDE should not take that long anymore to be ready
20:02:33 <luk> it was at DebConf, so I guess it still is?
20:02:44 <luk> the kernel transitioned in the mean time (luckily)
20:02:47 <cjwatson> (hi, on an Eee keyboard so excuse slow typing)
20:03:10 <bubulle> luk: ah, I didn't even notice the kernel transition
20:03:15 <cjwatson> grub2 is a bit in the middle of things right now
20:03:17 <bubulle> so, *that* is good news, then
20:03:45 <cjwatson> we really need to sync up grub-installer with the new world order as of a couple of days ago, but there are still a couple of blocking bugs
20:03:58 <cjwatson> the password thing that fezie's been working on, and dmraid and multipath
20:03:59 <luk> yes, a pitty that parted did not migrate yet, though that was related to a late built that got entangled with a transition
20:04:14 <cjwatson> perhaps we can ignore the last two and continue to use grub legacy for those
20:04:49 <cjwatson> wouldn't hurt to have agreement on this os-prober thing (see -devel) either
20:04:52 <aurel32> and also the double message about installing grub, one from grub2, the other from grub-installer
20:04:53 <bubulle> ok, let's avoid talking about two things at the same time..:-)
20:05:00 <bubulle> so, parted first, please
20:05:01 <cjwatson> aurel32: I have a patch forthat
20:05:16 <cjwatson> bubulle: ok
20:05:20 <bubulle> luk: any idea about what is tBD and who could do it?
20:05:23 <aurel32> cjwatson: :)
20:06:02 <luk> parted should migrate once KDE is ready, kde maintainers are working hard to get it ready for migration AFAICS
20:07:23 <bubulle> luk: ok, so noearly nothing we can do in the d-i team, then
20:07:38 <cjwatson> aside from leaving parted alone ;-)
20:07:49 <fezie> the password support isn't currently high priority for me, the squeeze grub2 doestn't support it and it doestn't look like we can get sid version into it soon
20:07:52 <luk> right, as well as parted's reverse deps
20:07:59 <bubulle> #action leave parted alone, it has to enter testing..:-)
20:08:38 <luk> http://release.debian.org/migration/testing.pl?package=parted mentions the packages involved
20:08:41 <bubulle> luk: anything the release team could do to ensure that nothing comes to break something in the transition plan?
20:08:52 <luk> partitionmanager is the one entangling it with KDE
20:09:43 <bubulle> well, apparently nothing to add about parted....let's move to GRUB stuff
20:09:53 <bubulle> # alpha release - GRUB things
20:10:22 <bubulle> fezie: anything blocking there?
20:10:31 <cjwatson> personally, I wouldn't much like to release with pre-1.97~beta grub2
20:10:47 <cjwatson> so I think perhaps we should look at what's blocking the sid version
20:10:58 <fezie> the ATI gfxterm breakage
20:11:03 <cjwatson> grub2 has been moving really, really quickly of late
20:11:32 <luk> iFTBFS on sparc
20:12:16 <cjwatson> I'd love to help with the ATI thing but I have no relevant hardware. I don't suppose you've considered blacklisting ATI hardware from gfxterm in the cause of getting this into testing?
20:12:41 <fezie> I said that once in #grub (but more as a joke) and didn't get any reply to this
20:12:58 <cjwatson> I can ask our kernel team at work to see if anyone's up for fixing it
20:12:59 <fezie> the sparc FTBFS is strange, can't find libgcc but we build depend on gcc-multilib on sparc
20:13:00 <mvz> I have an ATI card, something I can do to help?
20:13:28 <bubulle> anyway, #topic alpha release - grub
20:13:35 <fezie> mvz: if the sid grub2 with gfxterm enabled breaks booting for you see the RC bugs
20:13:36 <bubulle> #topic alpha release - grub
20:13:40 <bubulle> (late topic update)
20:13:45 <fezie> nyu is providing snapshots to find out the commit which broke it
20:13:59 <cjwatson> you have to be really careful that you've actually run grub-install
20:14:04 <mvz> fezie: alrady using grub2, let me enable gfxterm and try. will let you know
20:14:09 <fezie> oh ok the sparc FTBFS isn't strange
20:14:11 <cjwatson> we've had quite a lot of confusing feedback due to people forgetting
20:14:12 <fezie> I fix that now
20:14:34 <bubulle> fezie: ah, at least this metting will have been useful for one thing..:-)
20:15:00 <cjwatson> does anyone care if we continue to use grub legacy for dmraid and multipath for now?
20:15:04 <luk> gcc-4.4 with gcc-multilib 4.3, maybe that's not an ideal couple for static linking?
20:15:15 <bubulle> so, could we summarize this to "the grub team is working hard to fix issues in GRUB2"
20:15:16 <cjwatson> I plan to work oon dmraid support but it will take a little while
20:15:31 <fezie> luk: yep just fixed that now :)
20:15:46 <fezie> bubulle: yes
20:16:22 <waldi> cjwatson: what is the problem with grub2 and multipath?
20:16:45 <cjwatson> err, there's a bug for it on grub-installer, I don't have the details to hand
20:16:46 <fezie> waldi: the problem is current design of how grub-probe works to map linux devices to grub devices
20:17:01 <fezie> which also applies to dmraid
20:17:03 <cjwatson> it's one of the bugs Frans filed as blocking grub2 by default
20:17:12 <waldi> fezie: ah, this
20:17:15 <mvz> #link http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483971
20:17:28 <cjwatson> so, I'm planning on converting grub2 to use by-id links by default
20:17:34 <cjwatson> for install_devices
20:17:44 <cjwatson> as it is, it's unreliable across reboots
20:17:59 <cjwatson> (though probably no worse than grub legacy)
20:18:14 <bubulle> #info the grub team is working hard to fix issues in GRUB2. Goal: testing transition
20:18:23 <cjwatson> that will probably involve fiddling about with the device mapping code a fair bit
20:19:11 <bubulle> an�hing alse to add about GRUB stuff or could we move to other things related to release preparation?
20:19:23 <cjwatson> nothing from me
20:19:32 <fezie> neither from me
20:19:51 <bubulle> I propose we try to check where we are about kernel stuff
20:20:02 <bubulle> # topic alpha release - kernel
20:20:06 <mvz> 2.6.30-6 is still affected by the pat bug, but IMHO we could document the workaround and have it not block alpha1
20:20:35 <waldi> or just add it to the syslinux config ...
20:20:36 <bubulle> # info 2.6.30 is in testing..:-)
20:20:46 <bubulle> #info 2.6.30 is in testing..:-)
20:20:49 <bubulle> (gree)
20:21:18 <bubulle> so, assuming we could release by now, would we have evertything ready wrt kernel?
20:21:37 <mvz> waldi: temporary change to syslinux seems fine too
20:21:42 <cjwatson> agreed
20:21:43 * bubulle hasn't followed things related to kernel udebs....
20:21:58 <waldi> nothing related to udebs
20:22:49 <luk> the PATA issue was the only blocking one remaining AFAIR
20:23:28 <waldi> PAT, not PATA
20:23:30 <luk> s/PATA/PAT/
20:24:07 <luk> sorry, to used to think in terms of SATA/PATA etc :-)
20:24:30 <bubulle> so, wrt kernel everything is ready as I see nobody claiming anything else..:-)
20:24:41 <mvz> luk: they will be interesting too in the near future afaics (pata -> libata) :)
20:25:03 * bubulle is half-convinced while writing this
20:25:50 <bubulle> #action Kernel-related issues should be checked by otavio
20:26:00 <bubulle> I think this is the right conclusion here..:-)
20:26:31 <waldi> mvz: ide->pata ...
20:27:09 <bubulle> What other blockers are the few of us who are around aware of?
20:27:17 * joeyh waves
20:27:40 <bubulle> joeyh: hey, welcome in the meeting..
20:27:41 <cjwatson> do we want the dh7 conversions uploaded before release, or generally to hold off?
20:27:51 <cjwatson> I'm being super-careful with them but there
20:28:00 <cjwatson> 's always a chance of problems
20:28:31 <bubulle> cjwatson: well, I'd say that we can go for them.
20:28:38 <cjwatson> perhaps I should instead ask if we want to make a special effort to get them all in
20:28:43 <bubulle> #topic alpha release - dh7 transitions
20:28:53 <cjwatson> no effect on users of course
20:29:00 <luk> I don't think we should focus on them for the alpha release
20:29:07 <cjwatson> ok
20:29:10 <bubulle> yep, just aligning the uploaded packages with what we have in svn
20:29:21 <luk> though I don't think it hurts to convert some more before we release
20:29:30 <cjwatson> if we want to do a translation sync, of course, that will involve uploading them anyway
20:29:39 <bubulle> yes
20:29:49 <cjwatson> almost all of the conversions are done, I think it's just console-setup and one or two others
20:29:53 <bubulle> but translation sync is only needed for partman stuff you changed recently
20:30:00 <cjwatson> ok
20:30:15 <bubulle> these ones are certainly worth an upload
20:30:42 <cjwatson> I uploaded them today, but I don't think there were many translations yet
20:30:52 <bubulle> apart from them, we did a full translation sync back in late June, so I think it's OK for an hypothetical alpha release
20:31:04 <mvz> cjwatson: thanks for doing so much of the conversion work :)
20:31:18 <mvz> has been a joy to read di-commits
20:31:37 <cjwatson> glad you like it:)
20:32:02 <cjwatson> I can't think of other blockers, but I'm not sure I'm well up on our RC bugs
20:32:21 <cjwatson> there's a fair bit of udeb testing migration to do
20:32:23 <bubulle> cjwatson: the problem is: nobody is
20:32:42 <bubulle> (up on RC bugs)
20:33:21 <luk> http://qa.debian.org/developer.php?login=debian-boot@lists.debian.org
20:33:22 <cjwatson> mm
20:33:35 <bubulle> I sometimes feel like we should release whatever crap we have. At least that would better unveil what's RC..:-)
20:33:40 <mvz> oh, quite a few RC bugs there
20:34:00 <bubulle> #topic alpha release - RC bugs
20:34:06 <bubulle> #link http://qa.debian.org/developer.php?login=debian-boot@lists.debian.org
20:34:28 <mvz> bubulle: certainly getting alpha1 out soon (in whatever shape) would be a good thing IMHO
20:35:18 <mvz> of course not with "total data destruction" kind of bugs ;)
20:35:19 <cjwatson> doesn't look entirely unmanageable
20:35:26 <cjwatson> I think that rescue bug is old
20:36:09 <mvz> is discover-data still used in d-i?
20:36:12 <bubulle> I think I actually fixed #532842
20:36:25 <luk> cjwatson: old as in obsolete or long overdue to get fixed? :-)
20:37:06 <cjwatson> luk: oh, the latter, but since it's rescue it doesn't affect normal installation
20:37:48 <cjwatson> #536683 looks like the only serious one, really#
20:38:06 <cjwatson> I can look at that if nobody beats me to it
20:38:32 <cjwatson> tomorrow, probably
20:38:41 * bubulle just fixed one of these RC bugs by closing #532842
20:39:19 <luk> lol
20:39:50 <bubulle> luk: well, the real work was done quite a while ago..:-)
20:40:08 <luk> sure, but that was not what you said ;-)
20:40:40 <luk> anyway, lets move on
20:40:41 <bubulle> #agreed alpha release - we're nearly ready to release: we just need a Release Manager for that, mostly
20:40:57 <bubulle> that probably is a good summary
20:41:18 <bubulle> I propose going over release goals...or talk about the git conversion
20:41:35 <luk> the release goals please
20:41:43 <bubulle> #topic Release goals
20:42:11 <bubulle> #link http://wiki.debian.org/DebianInstaller/SqueezeGoals
20:42:14 <luk> there is now proper udeb support in britney (both version 1 and 2) !!!
20:42:19 <mvz> so just as an aside, if you have javascript enabled, you might see automatic status indication of bugs referenced on SqueezeGoals ;)
20:42:20 <bubulle> #topic Release goals - Persistent device naming for disks
20:42:39 <bubulle> mvz: oh, yes, nice
20:42:56 <bubulle> cjwatson: what about this persistent device naming?
20:43:09 <cjwatson> luk: woo! so will udebs be unfrozen by default?
20:43:25 <bubulle> cjwatson: from the wiki page, the last remaining bit is "Need support in bootloaders (for grub, can be done by moving to to GRUB2). "
20:43:38 <cjwatson> bubulle: continuing to chip off bits of it; the grub2 by-id stuff I mentioned is the last major piece
20:43:42 <cjwatson> that
20:43:44 <cjwatson> that
20:43:47 <cjwatson> argh
20:43:50 <cjwatson> i hate this keyboard
20:44:01 <luk> cjwatson: I guess we could do that indeed, fjp always argued against unblocking all of them though
20:44:08 <bubulle> ok. Seems like we'll achieve that goal
20:44:09 <cjwatson> that's one of ~4 things currently on my plate re grub2
20:44:22 <cjwatson> we'll achieve it by squeeze,I think, yes
20:44:53 <bubulle> #topic Release goals - Switch to udhcpc DHCP client from busybox
20:45:02 <bubulle> luk: ?
20:45:25 <bubulle> I haven't seen much report but very quick tests (successful)
20:46:16 <luk> has been done, not sure if there is still something remaining to finish it completely though?
20:46:37 <luk> before switching it to default
20:47:02 <bubulle> switching it to default? :-)
20:47:13 <luk> using it by default instead of dhcp3
20:47:44 <bubulle> I'd say yes but you guys know I like danger..:-)...so we should leeave this to otavio
20:48:28 <bubulle> #agreed otavio should decide about switching to udhcpc by default instead of dhcp3
20:49:03 <bubulle> #topic Release goals - Switch from console-data to console-setup
20:49:13 <bubulle> #link http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch
20:49:36 <bubulle> youpi: around?
20:49:38 <youpi> yes
20:50:23 <bubulle> I just edited the wiki page to confirm that we're halfway...
20:50:34 <bubulle> Step 1 (use c-s without udebs) is done
20:51:47 <bubulle> so, the main point is now using c-s-udeb in place of kbd-chooser
20:53:14 <bubulle> youpi: I think the main blocker here are fjp's concerns about size and complexity
20:53:39 <youpi> I believe too
20:53:50 <bubulle> but nobody is really working on it..:-)
20:53:58 <youpi> I guess the reasonable way is to use my script to get a list and hand-tune it
20:54:09 <bubulle> yep
20:54:20 <bubulle> any chance you can propose something?
20:54:45 <youpi> not in the near future (new school year)
20:55:31 <bubulle> hmmm, well that's not a blocker but at some moment we'll need to decide if we can still make it for squeeze or if we stay half-way
20:55:38 <bubulle> (which works)
20:56:19 <bubulle> #agreedwe're halfway and have no foreseable idea about the moment of the final switch
20:56:24 <youpi> I believe I can take the time to work on it, say, not next week but the week after
20:56:29 <bubulle> #agreed we're halfway and have no foreseable idea about the moment of the final switch
20:56:47 <bubulle> #topic Release goals - Add ext4 support
20:56:51 <bubulle> cjwatson: ^^
20:56:55 <cjwatson> ext4 is in place as an option and grub-installer deals with it by default
20:57:15 <cjwatson> the main missing piece is checks in bootloader installers that don't support it
20:57:17 <bubulle> so, yet another thing related to grub?
20:57:19 <cjwatson> that's still on my plate
20:57:27 <fezie> grub2 supports it fine
20:57:30 <cjwatson> the grub bit is done *shrug*
20:57:49 <bubulle> ah, yes, correct info is in the wiki page
20:57:59 <cjwatson> after this alpha, I'd like us to consider switching to ext4 by default on architectures that can cope
20:58:29 <bubulle> cjwatson: is the fact that other bootladers don't check it a real blocker?
20:58:31 <cjwatson> maybe after the next kernel update or something
20:58:34 <cjwatson> bubulle: no
20:58:43 <bubulle> that could be documented in the errata if we release?
20:58:48 <cjwatson> but we should try to help users not to shoot themselves in the foot
20:58:53 <cjwatson> sure
20:59:00 <cjwatson> it's an issue but not a blocker
20:59:13 <bubulle> #agreed Last remaining bit for ext4: checks in bootloaders that don't support it
20:59:32 <bubulle> #topic Release goals - Finish last bits of UdebSupport (udeb transition)
20:59:35 <bubulle> luk:
21:00:06 <bubulle> you said "there is now proper udeb support in britney (both version 1 and 2)"
21:00:44 <luk> yep, both the legacy version of britney as the new one (which we like to use before Squeeze) handles them like they handle normal packages
21:01:09 <luk> there is also support for blocking/unblocking specific for udebs
21:01:18 <fezie> the britney2 git seems to be much outdated (last commit from 2009-02-23)
21:01:23 <bubulle> so, that goal is '''done'''?
21:01:30 <luk> so that we cannot accidently unblock etc
21:02:00 <luk> it still needs some cleanup in the hints and in the input files, but nothing infrastructure related anymore
21:02:25 <bubulle> luk: so, OK for me to put "done" in the release goals page?
21:02:40 <luk> fezie: hmm, either you're looking at a wrong git tree or a wrong branch ;-)
21:02:56 <fezie> http://git.debian.org/?p=tools-release/britney2.git;a=summary
21:03:13 <fezie> britney.git is up2date
21:04:13 <trave11er> fezie: http://git.debian.org/?p=debian-release/britney2.git
21:04:22 <luk> tools-release is the wrong tree
21:04:28 <fezie> ah
21:04:37 <fezie> then maybe someone should remove it?
21:04:46 <bubulle> mvz: are you still editing the release goals wiki page?
21:05:18 <mvz> bubulle: oops, no. just canceled the edit
21:05:41 <bubulle> #agreed Finish last bits of UdebSupport is done
21:05:57 <bubulle> luk: maybe see if http://wiki.debian.org/UdebSupport is still needed
21:06:01 <mvz> there are some more rc bugs hidden in installation-reports; I'll take a look and try to reassign
21:06:49 <bubulle> #topic Release goals - General cleanup
21:06:59 <mvz> one more question about udeb migration please :)
21:07:01 <bubulle> not sure that much happened recently here
21:07:02 <luk> the wiki page mentions some interesting ideas
21:07:15 <bubulle> luk: ah then keep it..:)
21:07:27 <mvz> does the britney change have immediate implications for d-i work? just wondering..
21:08:08 <cjwatson> general cleanup is kind of something we do when bored, I don't know that it's too interesting to discuss it here?
21:08:13 <bubulle> #topic Release goals - Finish last bits of UdebSupport (revisited)
21:08:26 <bubulle> let'zs answer mvz question first
21:08:31 <bubulle> luk:
21:08:50 <luk> mvz: we should have a look at what packages we want to block for the alpha release (aka which one could stay unblocked now)
21:09:07 <bubulle> luk: but all are blocked right now, yes?
21:09:11 <luk> and later which ones could get unblocked after the alpha release without much trouble
21:09:18 <mvz> do I understand correctly that udebs are no longer blocked by default?
21:09:19 <luk> yes, currently all are still blocked
21:09:22 <mvz> ah, ok
21:09:33 <bubulle> but at some moment the default for udebs will be "unblocked"
21:10:20 <mvz> this will make lots of maintainer's lives easier :)
21:10:21 <luk> there are already 2 lists, Release Team has been trained to unblock ones of the non strict list easily already :-)
21:10:22 <fezie> nice so I don't need anymore to send unblock requests for reiser4progs which doestn't get used by d-i at all
21:11:12 <bubulle> fezie: if reiser4progs is in the "unblocked" list, yes. Currently you still need it
21:11:21 <luk> fezie: once we have the confirmed list that does not need any ack anymore
21:11:34 <fezie> ah
21:11:37 <bubulle> luk: the release team is working on these lists, right?
21:11:51 <bubulle> and will ask -boot when in doubt?
21:12:03 <luk> http://release.debian.org/britney/hints/freeze
21:12:41 <luk> the first list is the one we will not block anymore unless there is any objection from d-i
21:13:02 <luk> the second list is the one we need to have a closer look at to see which ones can usually be unblocked/blocked
21:13:03 <fezie> oh reiserfsprogs too nice
21:13:22 <fezie> though I doubt there will come much uploads :)
21:13:22 <bubulle> luk: I'm not sure about directfb and all such things related to g-i
21:13:44 <luk> I guess I should s|otavio/joeyh|d-i team|
21:14:00 <bubulle> they quite probably need coordination with us (assuming we still have someone who has enough clues about g-i)
21:14:44 <luk> according to otavio they could be in the first list as they only needed to be really blocked near d-i releases
21:15:05 <bubulle> #agreed the D-I RM should look at http://release.debian.org/britney/hints/freeze and give clues to the release managers about udebs that can trnasition without agreement from D-I team
21:15:29 <bubulle> ah well, so there has already been discussions with otavio about this list
21:15:52 <bubulle> so, ok, let's move back to other goals (it's laaaate)
21:16:15 <bubulle> #topic Release goals - General cleaning
21:16:25 <bubulle> #agreed no real point to talk about it now..:-)
21:16:34 <luk> lol
21:16:50 <bubulle> #topic Release goals - Improve support for Intel-based Apple MacBook systems; current support is a bit of a kludge and needs restructuring
21:17:08 <bubulle> cjwatson: that's one of the Colin "I have a patch" Watson's babies..:-)
21:17:09 <cjwatson> I'm not working on this at the moment - I don't know if anyone else is
21:17:42 <bubulle> cjwatson: very certainly not
21:17:43 <cjwatson> if anyone wants to, give me a shout and I'll point you to where to start
21:17:54 <cjwatson> otherwise let's move on
21:18:03 <bubulle> #agreed nothing happens there. If someone wants to, talk to cjwatson
21:18:33 <bubulle> #topic Release goals - Allow selecting disks with GRUB with multiple controllers
21:18:43 <bubulle> Ryan52: ?
21:18:46 <mvz> bubulle: I'd like to add git migration to the agenda (perhaps before more of the less central goals, before we run too late)
21:18:58 <bubulle> mvz: ok
21:19:19 <cjwatson> multiple controllers? how's this different from multiple disks?
21:19:38 <bubulle> mvz: actually, that release goal was the one I wanted to reach
21:19:48 <bubulle> others don't have much activity as of now
21:19:57 <mvz> :)
21:20:30 <bubulle> cjwatson: from the release goals page, I don't see the difference..:-)
21:20:51 <cjwatson> not clear that Ryan52 is here
21:20:52 <Ryan52> oh look a meeting
21:20:59 <cjwatson> aha
21:21:17 <bubulle> Ryan52: talking about "your" release goal
21:21:19 <Ryan52> umm, haven't gotten around to it, don't have much interest in helping D-I anymore.
21:21:50 <cjwatson> something we said?
21:22:13 <Ryan52> heh, no.
21:22:40 <Ryan52> you guys should probably just make somebody else do it or drop it from release goals..
21:22:42 <luk> moved to other interesting areas, I guess?
21:22:50 <bubulle> so, I think we should move this to the "wishlist" part of the list.....waiting for someone to take care of it....but first answer cjwatson question "how's this different from multiple disks?"
21:23:09 <cjwatson> yeah, I was just wondering if it overlapped with the stuff I'm planning
21:23:17 <Ryan52> it's..not?
21:23:40 <cjwatson> ah, ok. in that case I think my by-id project should cover it
21:23:45 <bubulle> moved
21:23:52 <bubulle> #topic Git migration
21:24:00 <Ryan52> yay cjwatson
21:24:04 <bubulle> before everybody collapses
21:24:21 <cjwatson> (that's not asserting ownership btw, just that I seem to be the one most motivated to do it right now...)
21:24:42 <joeyh> right.. I have not seen any more comments on my test conversion
21:24:44 <mvz> last meeting we got (I think) rough consensus that we want do to the migration
21:24:59 <mvz> (please disagree now! ;)
21:25:18 <mvz> frans has not commented yet?
21:25:29 <joeyh> I didn't see him comment
21:25:44 <cjwatson> he's had a month now ...
21:25:49 <bubulle> neither did I but he promised to do so and when Frans promises something that happens
21:26:37 <mvz> either way I think we could start talking about the next steps to take (even if we don't take them just yet)
21:27:35 <bubulle> Frans commented on Aug 16th: "I've started to look at this. Will reply in a few days."
21:28:09 <mvz> I think all known issues with the converted repos have been sorted out
21:28:17 <bubulle> joeyh: I'd suggest a followup to Frans mail, asking him if he can send his comments as they are now, even if not polished
21:28:32 <bubulle> (I can do it)
21:28:40 <joeyh> bubulle: ok
21:28:45 <mvz> question remained how to to the "meta" repo which provides something like current svn trunk
21:28:50 <gaudenz> bubulle, thanks
21:29:11 <mvz> personally I'd be happy with joey's mr solution
21:29:15 <cjwatson> is the history of the meta repo particularly interesting>
21:29:16 <cjwatson> ?
21:29:57 <cjwatson> history going forward is interesting (i.e. tracking new modules)
21:30:01 <joeyh> cjwatson: not if the manual and po parts are split out of it somehow, but that is not done yet
21:30:33 <cjwatson> right, I meant just of the submodule list
21:32:37 <mvz> didn't get a chance to look into the l10nsync branch idea further
21:33:42 <mvz> could we just take gitdemo and run with it?
21:33:49 <cjwatson> l10n sync branches give me the fear that we'll end up doing huge merges full of po file conflicts
21:33:57 <cjwatson> been there done that slit wrists
21:33:58 <mvz> ah, manual and po are still unsolved
21:34:52 <joeyh> manual and po are intended to stay in svn
21:35:29 <mvz> cjwatson: my idea was roughly to have the chances by translators represented as individual changesets (with attribution). having it on a branch was more of an idea to tidy the history (all the l10nsync autocommits)
21:35:56 <cjwatson> since git log doesn't collapse merges it hardly matters much, really ...
21:35:57 * mvz notes that po merges are not something one wants to do ;)
21:36:08 <mvz> cjwatson: yep, agreed
21:36:09 <cjwatson> would be just as easy to filter out commits by author
21:36:33 <cjwatson> though I do like preserving attribution obviously
21:37:19 <cjwatson> svn post-commit hook that does git commits? :)
21:37:20 <joeyh> did the freebsd branch get merged yet?
21:37:31 <bubulle> aurel32: ^^^^^
21:37:35 <mvz> the l10n branch thing is mostly a potential improvement going forward, so lets feel free to skip it for now
21:37:44 <cjwatson> right, not a regression
21:38:12 <bubulle> mvz: I'd appreciate if we don't make things complicated wrt l10n now. I already fear enough the transition
21:38:19 <aurel32> joeyh: the diff is about 500 lines
21:38:30 <aurel32> but I have problem to merge the remaining
21:38:32 <joeyh> I think that, and deciding whether to break a few tags during the da.po explosion, or bloat the repo by 5 mb, are the only things todo from my side
21:38:35 <bubulle> (because I have no idea of the impact on the l10n-sync script)
21:38:56 <aurel32> we have to find a solution for partman* packages
21:39:09 <aurel32> because we have close but different scripts
21:39:17 <aurel32> and the package is arch all
21:39:26 <bubulle> joeyh: from your summpary mail, I'd say we can live with a few mistags because of the da.po explosion
21:39:27 <aurel32> so either we switch them to arch any
21:39:28 <joeyh> aurel32: if the branch is still there, I can promote it to a git branch in each of the affected packages
21:39:49 <aurel32> or we add code to select the os at runtime
21:39:50 <cjwatson> shouldn't be that bad in l10n-sync, more sysadmin than anything else
21:39:51 <aurel32> joeyh: that's fine
21:39:59 <mvz> joeyh: we can retrieve the broken tags from svn if need be, so I'd go ahead with those unfixed
21:40:09 <cjwatson> well, there's a race condition since git doesn't have bound branches
21:40:29 <cjwatson> (i.e. what happens if somebody commits while l10n-sync is running?)
21:40:31 <cjwatson> but I think that
21:40:37 <cjwatson> 's the case for svn too
21:40:56 <bubulle> cjwatson: yes, there are race conditions with the current setup
21:41:11 <cjwatson> aurel32: point me to the partman stuff you're having trouble with and I'll have a look
21:41:37 <CIA-6> debian-installer: 03joeyh * r60678 10scripts/togit/d-i.conf: uncomment lines to drop da.po miscommits, at the expense of changing 17 tags
21:41:58 <bubulle> joeyh: with all this, can you propose a schedule for the switch?
21:42:33 <cjwatson> aurel32: (pref. by mail)
21:42:56 <joeyh> bubulle: I could chew through an updated conversion with freebsd branches and including the recent commits in a couple days
21:43:07 * mvz proposes doing a "git migration guide" on the wiki
21:43:12 <aurel32> cjwatson: ok I'll send a mail
21:43:19 <joeyh> then some testing, then we just have to lock repo, update it one more time, and switch
21:43:20 <mvz> (and sort of volunteers, but would love to join with others)
21:43:22 <aurel32> probably not before tomorrow morning though
21:43:59 <cjwatson> that's ok, about to fall over
21:44:02 <joeyh> the updated demo could live on git.debian.org and be writable (all commits lost later)
21:44:13 <joeyh> that would allow testing things out fully and writing docs etc
21:44:16 <bubulle> mvz: you're aware that proposing this makes you the volunteer for it, right?
21:44:48 <mvz> bubulle: yes, no way around that :)
21:44:59 <bubulle> I'd be OK for an updated demo so that I can figure out what I need to change in l10n-sync
21:45:05 <cjwatson> I should probably try out the demo with bzr-git ...
21:45:20 <gaudenz> I volunteer to test as well
21:45:21 <bubulle> #agreed mvz volunteers for doing a "git migration guide" on the wiki
21:45:26 <bubulle> screwed..:-)
21:45:30 <mvz> hehe
21:45:47 <gaudenz> not for writing the migration guide, but for testing
21:46:00 <bubulle> #agreed joeyh will update his conversion with freebsd branches
21:46:19 <bubulle> anything else to add about git conversion?
21:46:31 <mvz> yes
21:46:45 <mvz> I would appreciate if people could send questions to me for the migration guide
21:46:56 <mvz> (irc, mail, ..)
21:47:07 <mvz> that'll make it easier to see what needs documenting
21:47:28 <bubulle> if nobody wants to add a topic I'm tempted to close the meeting
21:49:11 <bubulle> Thanks to everybody for attending. That was yet again another hectic meeting but I think it was productive, still
21:49:36 <bubulle> this is your last chance before I really close the meeting..:)
21:49:58 <mvz> ah..
21:50:01 <mvz> just joking :P
21:50:15 <bubulle> #endmeeting