[02:07] <shwag> regarding  https://help.ubuntu.com/6.10/ubuntu/serverguide/C/network-configuration.html
[02:07] <shwag> shouldnt the example block starting with "iface eth1 inet static"   include the "auto eth1" line as the example above it does ?
[02:07] <robotgeek> one sec
[02:09] <robotgeek> yes, if you want it to come up at boot
[08:31] <poolkey172> anyone home ?
[08:48] <mdke> morning
[08:49] <mdke> Laser_away: sure, I guess so. Go ahead and add it to the page
[08:49] <Burgundavia> morning mdke
[08:49] <Burgundavia> Mako has a good blog post, no?
[08:50] <mdke> I need to read it
[08:50] <mdke> nixternal: still breaking string freeze!!??
[08:51] <mdke> Burgundavia: yes. I agree completely
[08:55] <Burgundavia> robotgeek: why are you not on planet.ubuntu ?
[08:58] <mdke> Burgundavia: do you know if there is anyone actually in favour of shipping binary drivers?
[08:58] <mdke> all the developers I've seen comment are against it
[08:58] <Burgundavia> Mark and the beryl people
[08:58] <mdke> Mark?
[08:59] <Burgundavia> sabdfl
[08:59] <mdke> oh god
[08:59] <Burgundavia> that was apparently how it broke down at UDS
[08:59] <Burgundavia> nobody else would have the power to make it go on this long
[08:59] <mdke> strange.
[09:00] <mdke> he knows full well that if free software is to succeed, it has to do it on its own terms, not by giving up in certain areas
[09:00] <Burgundavia> jono and I talked about it
[09:00] <Burgundavia> he and Mark seemed to be concerned we need to do this to "achieve parity" with other OSes
[09:01] <Burgundavia> basically, if it is not beautiful, they won't come
[09:01] <mdke> Yeah, I know the argument
[09:01] <mdke> That doesn't work, I don't think
[09:02] <mdke> it runs up against the slippery slope problem
[09:02] <Burgundavia> I argued that we can cleanup our icons and make better artwork and win more people over
[09:02] <Burgundavia> plus, if we are going to further go down that path, it strikes me we should be solving the multimedia issue before the bling one
[09:02] <mdke> users will come to expect us to ship non-free software to compete, and we'll come to depend on it
[09:03] <Mithrandir> drivers have always been special, though
[09:03] <Burgundavia> yes, they have
[09:03] <Burgundavia> however, Mako makes an excellent point about just working != extra bling
[09:04] <Mithrandir> it's a fine line to draw.
[09:04] <Burgundavia> something I said to Jono when we talked on Sunday
[09:04] <Mithrandir> (is dual screen working bling or not?)
[09:04] <Burgundavia> and Jono pointed that out. For some, just working == bling
[09:04] <mdke> coming to depend on non-free software is really dangerous though, not just for our own sake, but also because it doesn't give those who won't open up the incentive to change
[09:04] <mdke> and to see that free software can work as a model
[09:05] <mdke> if Mark believes that it can work, he should stick to it
[09:05] <Burgundavia> however, I still hold that if we are going to sacrifice our freedom further, we should solve the multimedia issue first
[09:05] <mdke> well, we are solving it
[09:06] <mdke> install on demand for codecs is a solution
[09:06] <Burgundavia> we can do the same for drivers then
[09:06] <mdke> 100% agreed
[09:07] <crimsun> I've always found it interesting that people are willing to "look the other way" for, say, wifi drivers
[09:07] <mdke> that's true.
[09:10] <mdke> Mithrandir: changing the subject, any ideas on that freeze thing?
[09:12] <Mithrandir> mdke: for stable releases, I think we should require that any string changes are either accompanied by translation updates (for non-typo fixes)
[09:12] <Mithrandir> or are just typo fixes, in which case the translation ought to not have the typo
[09:14] <Mithrandir> for normal string freezes, I think having the same rules in effect, but be a bit more lax in what updates we accept.
[09:14] <Mithrandir> (the stable updates have to go through the full SRU procedure which is enough, I believe)
[09:14] <Mithrandir> mdke: ^^ thoughts?
[09:16] <mdke> Mithrandir: just reminding myself of what the SRU procedure is
[09:17] <mdke> Mithrandir: string changes don't satisfy anything in the "When" section
[09:17] <Mithrandir> instructions which are directly harmful is an example of the last one.
[09:18] <mdke> Mithrandir: ah, ok. So only things like that
[09:18] <mdke> that sounds sensible
[09:18] <Mithrandir> you could argue a glaring typo (think misspelling "Ubuntu" in the main help title) is a severe regression from the previous release.
[09:19] <Mithrandir> apart from those kind of things, I don't think stable releases should be updated.  They're released, after all.
[09:19] <mdke> yeah, ok.
[09:20] <mdke> the procedure for determining which bugs can be addressed in the unstable release?
[09:21] <Burgundavia> sru
[09:22] <mdke> eh?
[09:22] <mdke> that's a bit stiff
[09:22] <Mithrandir> string freeze is about three weeks prior to release (for edgy), about a month and a half prior to release for feisty, so the procedure could be roughly what it is for other package updates:  - maintainer's call until the archive's frozen (but soliciting input from a release team member is of course of), - release manager's call after that.
[09:23] <mdke> sounds fine.
[09:23] <Mithrandir> we don't want to freeze it too deeply too early; if so, the freezes are useless (since they'll be equivalent for a release, from a string pov)
[09:23] <mdke> what were you going to say after "is of course of"
[09:24] <Mithrandir> s/of/ok/
[09:24] <Mithrandir> so "is of course ok"
[09:24] <mdke> gotcha
[09:25] <mdke> thanks for your help
[09:25] <Mithrandir> we need to write this down as a procedure somewhere, probably on the StringFreeze page; can one of you do that?
[09:25] <mdke> sure
[09:26] <Mithrandir> I'll be happy to review it to make sure it matches my interpretation of what we agreed to.
[09:26] <mdke> i've started doing that
[09:26] <Mithrandir> excellent, thanks.  Please ping me when it's shaping up.
[09:28] <mdke> Mithrandir: ping
[09:28] <Mithrandir> oh, you're quick.  *chuckles*
[09:28] <mdke> https://wiki.ubuntu.com/DocumentationStringFreeze
[09:29] <Mithrandir> how do we communicate with translators to ensure they get the message about updates?
[09:30] <mdke> by mailing list
[09:30] <mdke> I'll add that
[09:32] <Mithrandir> hmm, we understood that you wanted just one string freeze, not a docstringfreeze and a stringfreeze when we did the release schedule.  Is that wrong?
[09:34] <mdke> I haven't heard anything about that
[09:34] <mdke> traditionally DocumentationStringFreeze has always been separate to the programs string freeze
[09:35] <mdke> but since StringFreeze seems quite late, it sounds fine to me to have them at the same time
[09:39] <mdke> Mithrandir: the only problem might be where an application changes a string and this affects the documentation. That's the case with menu entries.
[09:39] <mdke> it would be nice to get warning of late-ish changes of that nature
[09:41] <mdke> still, since in the past docSF seems to have come before normal SF, I suppose this is an improvement :)
[09:50] <Mithrandir> mdke: I'll be happy to work with you on finding something which works for you; I must say I'm fairly string-ignorant myself so it's not one of the itches I scratch..
[09:52] <mdke> Mithrandir: alright, thanks. Let's leave it like this and see
[02:00] <jsgotangco> ive transferred ownership of ubuntu-doc in lp to mdke just fyi
[03:45] <robotgeek> Burgundavia: i emailed Jeff Waugh a couple of times, but i got no response. i just gave up
[05:04] <nixternal> mdke: the only reason i did that is because we don't ship nor translate that doc
[07:11] <shwag> it would be nice if  /etc/network/interfaces  by default had a bunch of commented out lines showing how to do basic things like a static ip address assignment.
[07:12] <LaserJock> I suppose the idea is that you shouldn't have to mess around with it unless you know what you're doing
[07:12] <LaserJock> but I don't find that we are quite there :-)
[08:07] <LaserJock> nixternal: ping
[08:23] <LaserJock> mdke: ping
[08:48] <mdke> LaserJock: hello?
[08:49] <mdke> nixternal: ah, I didn't realise it wasn't shipped. In that case, it shouldn't even be in the branch
[08:49] <LaserJock> mdke: hmm, what was I going to say
[08:49] <LaserJock> oh yeah
[08:49] <LaserJock> did you do a spec for building doc team tools?
[08:50] <mdke> LaserJock: yes, I mailed it to you! Lemme dig it out
[08:51] <mdke> LaserJock: it needs a lot of work.
[08:51] <mdke> https://blueprints.launchpad.net/distros/ubuntu/+spec/simplify-ubuntu-docs-build-process <- LaserJock
[08:52] <LaserJock> I found it
[08:52] <LaserJock> ok, I wanted to add it to my todo list
[08:52] <mdke> wow!
[08:53] <LaserJock> but I couldn't remember if we had a spec for it or not
[08:53] <mdke> one often requested feature is to add support for individual translation maintainers to import a single language. We'll have to look at adding that
[08:53] <mdke> let's work together. It's already a lot better than it was for Edgy
[08:53] <mdke> {everyone} the presentation is starting soon for the Open Week. Who is attending?
[08:53] <LaserJock> I'll be around
[08:54] <LaserJock> well, I see what I can do
[08:55] <LaserJock> I already have a ton of things to do for Feisty
[08:55] <mdke> sure
[08:55] <LaserJock> trying to make core-dev soonish
[08:55] <mdke> we'll prioritise parts of it
[08:55] <mdke> ah, nice. About time
[08:55] <LaserJock> anyway, at least finishing a spec of and writing down what we want
[08:56] <LaserJock> we can even get some interested person to do the actual coding
[08:56] <LaserJock> if we don't have time to do it all
[08:56] <mdke> yeah
[08:56] <LaserJock> but I do enjoy doing this shell/python scripting stuff
[08:57] <mdke> do you know how to get shell scripts to take arguments?
[08:57] <LaserJock> sure
[08:57] <mdke> ok, that should be enough :)
[08:57] <LaserJock> python has better handling of them
[08:57] <LaserJock> but it's certainly possible in a shell script
[08:57] <LaserJock> much of /usr/bin is a shell script ;-)
[08:57] <mdke> ok. It's mainly debian/rules and the translate.sh scripts that need work
[08:58] <LaserJock> yeah, I think a good general approach is to write some individual shell scripts
[08:58] <LaserJock> that do a particular task, like translate.sh
[08:58] <LaserJock> and then pull them all together in a nice package with python
[08:58] <LaserJock> in MOTU we have something similar
[08:59] <mdke> oh bloody hell. The open week presentation is tomorrow, not today.
[08:59] <LaserJock> oh
[08:59] <LaserJock> oh right, simon's on now
[08:59] <mdke> yeah
[08:59] <mdke> alright, I'll do something else this evening then
[09:00] <mdke> cya soon!
[09:00] <LaserJock> cya
[09:04] <Burgwork> mdke: how do you edit the fridge calendar?
[09:08] <nixternal> LaserJock: pong?
[09:08] <LaserJock> nixternal: regarding bzr
[09:08] <nixternal> did i break it?
[09:08] <LaserJock> bzr checks out the entire history of the repo
[09:08] <LaserJock> svn doesn't
[09:09] <nixternal> ahh
[09:09] <LaserJock> so that's why it is slower to grab and larger
[09:09] <LaserJock> but the whole history of the repo is local
[09:09] <nixternal> ok, so say for instance, i do a booboo and commit to the dapper repo, i can bzr revert it instantly ?
[09:09] <nixternal>  ;)
[09:09] <LaserJock> yes
[09:09] <LaserJock> at least locally
[09:09] <LaserJock> you commit locally
[09:09] <LaserJock> publish remotely
[09:09] <nixternal> if you branch you commit locally
[09:09] <nixternal> if you checkout you commit regular
[09:10] <LaserJock> right
[09:10] <LaserJock> bzr can basically be run in an "SVN" mode
[09:10] <nixternal> ya, that is the same as doing a checkout
[09:11] <nixternal> i have Ichthux branched, or used to branch, and i would commit locally and then push
[09:11] <nixternal> my only issue with Bazaar would be 1) To slow, and 2) Space consuming
[09:11] <nixternal> s/issue/issues
[09:11] <LaserJock> on the other hand
[09:12] <LaserJock> you can go to a computer that has fast internet and download the repo to a usb stick
[09:12] <LaserJock> and you have the complete history with you
[09:12] <nixternal> i have an 8mb down connection, is that fast enough?
[09:12] <nixternal> and it still took over an hour to do a checkout
[09:12] <LaserJock> yep
[09:12] <LaserJock> but we can also make a tarball
[09:12] <nixternal> the problem isn't bandwidth, i can tell you that now
[09:13] <nixternal> i sniffed packets and watched them drop constantly at the bazaar server
[09:13] <LaserJock> the easiest thing for people to use would be a tarball of the repo
[09:14] <LaserJock> yeah, there's some issues for sure
[09:14] <LaserJock> for a long time (not sure if it still does it) bzr would die on my home DSL router
[09:14] <LaserJock> because it made so many DNS requests
[09:14] <LaserJock> so a bzr branch would fail 4 out of 5 times
[09:16] <nixternal> ya, it is quite horrid..but i think as soon as they get that fixed it will rock on..definitely a bright future for it
[09:17] <LaserJock> yes, I think between the latest releases of bzr and having access to bazaar.launchpad.net we might be able to make it work
[09:17] <LaserJock> the nice thing about bazaar.launchpad.net is we have an easy way to control access
[09:17] <nixternal> w/o a doubt that is a nice thing about it
[09:18] <LaserJock> however, svn has been working fine for us so far, with the exception of access control
[09:19] <nixternal> well, access control hasn't been that big of an issue has it? mdke pretty much requests it through rt and boom usually within a day it is taken care of
[09:20] <LaserJock> it certainly wasn't always that way
[09:21] <LaserJock> it took me something like a month to get mine
[09:21] <LaserJock> but that's way back when elmo did everything
[09:22] <nixternal> ya
[09:22] <LaserJock> I'm not really sure why Riddell is pushing bzr so much
[09:22] <nixternal> what is cool with Bazaar is you can sign your commits and everythign just like you would packaging
[09:22] <LaserJock> I know he lost his svn password
[09:22] <nixternal> hehe
[09:22] <LaserJock> but surely he can get that back
[09:23] <nixternal> well, i think the Bazaar push might be coming from higher maybe?  I know pretty much every project is utilizing it to some extent
[09:23] <nixternal> uniformity
[09:23] <dsas> possibly it's just easier to only have to remember one RCS.
[09:23] <LaserJock> perhaps
[09:23] <nixternal> dsas: that is true...i started checking out instead of branching with bzr to make it more svn like
[09:24] <LaserJock> but KDE isn't using bzr
[09:24] <LaserJock> so I would think he'd be used to using svn anyway
[09:24] <nixternal> well KDE isn't "buntu" either
[09:24] <LaserJock> sure
[09:24] <LaserJock> but I'm just saying for him I'd bet he still uses svn a fair amount
[09:24] <nixternal> i know that Riddell uses bzr for the kubuntu-default-settings
[09:25] <LaserJock> well, bzr should be used for most ubuntu packaging tasks
[09:25] <nixternal> of course...he does a lot of committing to KDE, so he is using svn like mad on a daily basis
[09:25] <LaserJock> that's pretty normal
[09:25] <LaserJock> anyway
[09:25] <LaserJock> I know there is a push for us to use bzr
[09:25] <LaserJock> and I like it
[09:25] <LaserJock> but IMO it just doesn't seem to fit our repo well
[09:26] <LaserJock> we don't really need the decentralized aspects
[09:26] <LaserJock> the only nice thing I can see is using the LP team for access control
[09:27] <nixternal> ya...i am for whatever works honestly
[09:28] <nixternal> svn works and so does bzr..i will let the politicians choose
[09:28] <LaserJock> :-)
[10:49] <Mithrandir> LaserJock: you're aware that bzr can check out svn directly?
[10:49] <LaserJock> how so?
[10:49] <LaserJock> bzr can checkout a svn repo?
[10:49] <Mithrandir> install bzr-svn, do bzr branch svn+ssh://host/repo
[10:49] <LaserJock> hmm
[10:50] <LaserJock> I don't know if that's be much help to us
[10:50] <LaserJock> perhaps
[10:50] <LaserJock> that's a very cool idea
[10:50] <Mithrandir> oh, more as a comment to the "but riddell has to use svn anyway" bit you said.
[10:50] <LaserJock> ah
[10:50] <LaserJock> yes, that makes sense
[10:55] <mdke> Burgwork: add an event
[10:55] <mdke> Burgwork: or edit an existing one
[10:56] <Burgwork> ok, I will add another one
[10:58] <Burgwork> mdke: do I need a body?
[10:59] <mdke> Burgwork: yeah, it's desirable, although not technically necessary
[11:00] <Burgwork> ok
[11:01] <mdke> nixternal: note that you can also use revert with svn
[11:16] <mdke> what do people think of the categories on https://wiki.ubuntu.com/TopicBasedHelp? Any ideas for reshuffling/adding/removing them?
[11:18] <LaserJock> seems good to me
[11:18] <stelis> Perhaps split Internet into "Web" and an Email+IM topic
[11:19] <LaserJock> I guess I would put "#
[11:19] <LaserJock> I guess I would put "Adding, Removing and Updating Applications
[11:19] <LaserJock> #
[11:19] <LaserJock> higher
[11:19] <LaserJock> sorry, that didn't come out right ;-)
[11:21] <mdke> got it. I don't get the Internet split though
[11:21] <mdke> maybe we could merge "Administrative Tasks" into Linux Basics, and move "Add/Remove etc" up to follow that
[11:22] <stelis> There's a lot of overlap between Email and IM, but not much between Web browsing and messaging
[11:22] <mdke> stelis: what do you mean by overlap?
[11:22] <stelis> Plus people may tend to look specifically for an Email topic
[11:23] <stelis> They work very similarly (conceptually)
[11:23] <mdke> If anything, I can see a reason to separate "Connecting to the internet" from "Using the Internet", but I don't think we have enough space to start treating a single internet task separately to others
[11:25] <stelis> Well, I tend to the think of "Internet" as a technical bracket, more than one that end-users use
[11:25] <stelis> I agree that connectivity is a different issue to using the Internet
[11:26] <mdke> hmm. Maybe "Using the Internet" and "Communicating" or something similar
[11:26] <mdke> but, the applications menu groups internet applications... so keeping that would be an advantage
[11:27] <stelis> I suppose it depends on how task orientated you want the topics to be
[11:27] <dsas> I'd wager that most people use email through their browser.
[11:28] <dsas> Communicating seems vague too.
[11:29] <mdke> let's cling to the menu structure a bit
[11:32] <dsas> "Using your desktop" should probably be "using your computer"
[11:34] <dsas> Or something, it doesn't seem obvious to me what is in there, but based on my knowledge of the DG the games/office/photos sections?
[11:34] <stelis> http://www.fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide
[11:34] <mdke> well, those have separate sections
[11:34] <mdke> it would be the Gnome user guide, basically
[11:34] <dsas> ah, cool.
[11:34] <mdke> maybe we can come up with a better description though, definitely
[11:35] <stelis> For comparison
[11:42] <nixternal> g'nite