On Mon, Oct 06, 2008 at 11:48:11AM -0400, Matthias Julius wrote: > Knut Arne Bjørndal <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 06, 2008 at 09:51:32AM -0400, Matthias Julius wrote: > >> Besides that, I don't see [EMAIL PROTECTED] as a sub-project of > >> osmarender. I would > >> leave tilesAtHome/ where it is now and move everything else into > >> osmarender/ which would become the only external in tilesAtHome/. > >> This would only require a couple of path changes in the client and a > >> simple 'svn up' will update all the clients out there through the > >> auto-update mechanism. > > > > Aren't you contradicting yourself here? With my layout a checkout of > > the top osmarender dir would give you everything needed for [EMAIL > > PROTECTED], > > except maplint which absolutely shouldn't be moved under rendering > > anyway. If tilesAtHome is moved away from osmarender we will have to > > use externals to get everything, and we will be back where we are now. > > Yes, but only one instead of four of them. > > > > > Sub-project is perhaps not the right word, not many things are really > > sub-projects of osmarender, but they are related projects. And, well, > > the only reason for [EMAIL PROTECTED] is to do osmarender renderings > > suitable for > > use on a tileserver... > > I would take 'osmarender' out of that sentence and say that [EMAIL PROTECTED] > just > happens to use osmarender as one of its tools. But, of course I might > be wrong here since I havn't been involved in [EMAIL PROTECTED] for that long.
As far as I know the reason for [EMAIL PROTECTED] was osmarender, and I've never seen any support for other osm->svg renderers in there, so how it can not be seen as an osmarender-related project is besides me. > > Yes, switching checkout paths are a pain, but I think it's the way to > > go to get a single checkout tree of all this related code, which would > > be really nice to have. > > I guess I just don't have so bad feelings about externals. I don't > mind them at all. It makes for a mess when developing. I already have a couple of osmarender checkouts, and that extra for each of the couple of [EMAIL PROTECTED] checkouts I have makes it even harder to keep track of where everything is. > And I would really like to avoid requiring a couple hundred client > users to switch to a different path. > > Changes to the client that require actions from the users should be > kept to the absolute minimum, IMHO. > > We have added a couple of dependencies to perl modules. This of > course will make it necessary for users to install those or their > clients will stop working some day after an update. Therefore we > should compose a list of all of them to post here and maybe on the > wiki well in advance of the migration to stable. Yes, we should try to limit disruptive changes, but I don't think we should keep the current workarounds (yes, I consider our svn externals workarounds for a proper dir layout) just to save client renderers from running one command. Why don't we use this situation as an opportunity, call it a big version upgrade, and list the things people have to do: * Install Error.pm * Install IPC::Run * Install Class::Accessor * svn switch ... -- Knut Arne Bjørndal aka Bob Kåre [EMAIL PROTECTED] [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
