also, at this point, it's not certain at this point that my move next week necessarily implies a closed door as far as MC infrastructure, so in reality the bus number *might* not change.
i'm not 100% sure on that (need to talk to sysadmins) but just putting that out there if it eases minds. e On Thu, Mar 5, 2009 at 18:33, Tim Schaub <tsch...@opengeo.org> wrote: > Hey- > > Christopher Schmidt wrote: > > On Thu, Mar 05, 2009 at 03:21:48PM -0700, Tim Schaub wrote: > >> Hey- > >> > >> MetaCarta graciously hosts our project infrastructure. > >> > >> Chris handles all (or nearly all) admin work. I assume this is all in > >> his free time. > > > > The OpenLayers server maintenance -- that is, maintaining the website > > itself -- is supported by MetaCarta, but almost all other work is done > > in my 'free time'. (So, mostly right, but if the website dies, I get a > > phone call, even if I am on vacation. :)) > > > >> Erik has taken responsibility for accepting license agreements and trac > >> account requests. I assume he manually adds people to an htpasswd file > >> when doing the latter. I suggested the AccountManager plugin to remove > >> the manual step - but I'm not sure exactly how permissions are handled > >> (for sandbox or core contributions). > >> > >> With Erik's departure, we reduce our bus number by one - with respect to > >> the number of people with access to our project infrastructure. > >> > >> I'd like to hear discussion again on the following: > >> 1) Giving access to non-MetaCarta employees for the current servers. > > > > This one can't really happen with our current setup. > > > >> 2) Moving to OSGeo infrastructure. > > > > This is the one I'd prefer. I'm glad to do it if someone else volunteers > > a weekend of time to help. It will probably require at least some prep > > work, and an acceptance of the community of downtime during the > > transition. (My biggest reason for not transitioning yet is becasue i > > think there will be a period of hours/days/possibly a week during which > > we work out kinks, and I get enough abuse as is on the project that I > > don't want to invite more on my own.) > > > > If someone else is interested, the best thing to do is to: > > * Speak up here > > Great. I'm interested in helping out. > > > * Help concoct a plan > > I agree about waiting until after 2.8 for any downtime. If we can do > any work before, I'll be more available at the end of next week. > > I look forward to talking more detail later. > > Tim > > > * Join the SAC committee list on the osgeo servers, and start > > discussing it > > > > Over the past year, I have worked out most of the technical kinks to the > > OSGeo infrastructure with regard to OSGeo in prep for us moving thee, so > > at this point, it's just accepting the downtime and moving forward. > > > > I would propose that we wait to have this downtime until *after* 2.8. > > Currently, our milestone needs to have 4 tickets a day closed or moved > > in order to get us to a release on time, and migrating to OSGeo takes > > away valuable time towards that goal. > > > > > >> I guess my motivation boils down to this: if Chris ever decides to take > >> a real vacation, nobody can do squat to manage the infrastructure (for > >> practical purposes). > > > > Agreed. This has been weighing on my mind, and motivated the change to > > the account admin changes. > > > > Note that technically, John Frank also has access to the servers, and > > the documentation for managing them is mostly in the wiki, but I agree > > that this is only a last-defense; informative in case I *actually* > > get hit by a bus before we move to OSGeo, but I completely > > agree we should move to OSGeo long term. > > > > Regards, > > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > Dev@openlayers.org > http://openlayers.org/mailman/listinfo/dev >
_______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
