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