we also scored a rather nice set of sponsors for the event:

collabora is sponsoring a party on Sunday evening.

codethink is providing the coffee and snacks for the summit.

finally, google has provided monetary support that is being used to cover travel costs.

one last nag: if you haven’t already, please add yourself to the list of participants: https://live.gnome.org/Montreal2011/Participants.

i hope everyone has a safe trip. see you on saturday!

https://live.gnome.org/Travel

what this macro means is that changes to your Makefile.am will not automatically result in the Makefile being regenerated unless –enable-maintainer-mode is given to ./configure. i’m almost sure that this isn’t what you want. it’s also breaking jhbuild whenever you add a new source file (since people pull the updated version and end up trying to build it with the old Makefile).

*not* using “AM_MAINTAINER_MODE” means that your makefiles will always be updated in response to changes to Makefile.am.

“AM_MAINTAINER_MODE([enable])” is acceptable. this means that Makefile updates are enabled by default but you have the option to pass “–disable-maintainer-mode” to disable them. i personally think that this is stupid, but i understand that some distributions think that this is kinda useful for some strange reason. since it’s useful to them and causes no harm to me, this is actually what i recommend.

fredp made a report page for packages using AM_MAINTAINER_MODE. green mean no “AM_MAINTAINER_MODE” at all (good). yellow “low” means “AM_MAINTAINER_MODE([enable])” which is also fine (perhaps better than green, in fact). orange “average” means that your package is currently broken and needs to be fixed.

note: many packages attempt to work around this issue by passing –enable-maintainer-mode to ./configure at the bottom of their autogen.sh. i do not consider this to be a particularly good solution.

https://mail.gnome.org/archives/foundation-list/2011-September/msg00001.html

the reason for this (as confirmed on #gnome-hackers after being suggested by ray) is ipv6 support: when network-manager connects to a network, it has to assume that there might be an ipv6 router advertisement. it waits for this (and usually doesn’t hear it). that’s the delay.

if you don’t care about ipv6, the fix is quite simple: in network settings, under wireless, click “options”, go over the ipv6 tab and select “ignore” from the dropdown.

that fixes it up for one connection. i’m not sure if there is a way to do it globally.

if you haven’t heard from us then please email us to let us know that something got lost along the way.

we will be opening proposals for BoF sessions soon. if your talk was rejected for the main programme, it might still be appropriate to propose a BoF. stay tuned.

one more thing: now is the right time to send applications to the travel committees to request sponsorship.

somewhat annoyed to discover the the “GNOME 3″ release hackfest that i traveled to india for will not actually result in any sort of a release. it’s true that things have been pretty crazy, but it really seemed like it was going to happen this time around.

i’m also not sure i believe that the “doubts” being discussed about gnome shell are particularly constructive, but i digress…

to all of the (likely many) people who will be upset by today’s announcement, i’d just like to mention one thing: these guys have been working like crazy the past week. this is not being caused by any form of lazy behaviour and i doubt that they’d do it unless it was absolutely necessary.

everyone’s stickers are probably looking a bit beat up by now…

i’ve never witnessed a release process this up-close-and-personal before, and i have to say that it’s totally insane. i have no idea how we ever get a release out the door. the amount of work being done by the release team is crazy. vincent and frederic have barely slept at all. andre says he had about 2 hours last night.

if you want proof, look for yourself: this month on release-team@. the gzipped archive is over 20 times the size of the month before. seems that “hard code freeze” really means “okay! go really fast now!”…

i’d feel guilty about my past transgression in this regard except for the fact that (release team member) vincent untz is busy landing a 15000 line set of changes to the panel at the moment.

the three of them disappeared today along with andreas and brian for a couple of hours. i’m not sure where they went but i think it has something to do with ingesting large amounts of crystal meth.

in other news, the location is pretty interesting. we got a chance to hang out at the intel offices and now we’re at a local university. the weather has been cooler than i expected (which is nice) and the traffic is really fantastic. we’ve come close to being dead in a terrible accident only 175 times or so. i still have to write my slides for my talk….

the hackfest was hosted by CDOT (the centre for development of open technology) at seneca college in (very) north toronto. these guys are really cool — a bunch of fedora and mozilla hackers as an official department of a college. a big thanks to anyone there who is reading this post; it was really awesome to hold a hackfest in such a cool place.