Good morning all! PSC meeting beginning now... mostly to discuss the 8.0 Release Plan status: https://github.com/mapserver/mapserver/wiki/MapServer-8.0-Release-Plan

/msg NickServ IDENTIFY EvenR test

hi Jeff, hi Even

hi

hi guys

hi

i've requested edit rights to update the MapServer slide at https://docs.google.com/presentation/d/1brbBb7-sKRI6U4dZ7LKnBT_-NnWzyS2TaZqVXzy8RDo/edit#slide=id.g2...

regarding feature freeze I think we need to push a week or two - config file RFC hasn't been created or voted on (pull request is pretty good tho)

sorry for that delay, on it today finally i lost a few weeks due to my father's visit

well this is not a last minute new feature, so I don't see the need to push the feature freeze

i'd also like a few weeks to test the config stuff and provide feedback on windows

what's probably missing is the documentation side of things

2 weeks would be:

can't we just drop the betas ? Nobody tests betas

agree on docs, just the RFC for config file and ogcapi, not sure about other additions

indeed i'm the only tester on windows for PROJ and GDAL betas and RCs

Just one beta would be more than enough I believe

+1 on one beta

the rc1 can be postponed a bit if their significant rework due to feedback on beta1

next proposal:

maybe FF on 9/17, 8.0 final on 10/8

+1

up to you Steve depending on how much time you need to polish things and submit the RFC

for info the State of MapServer talk is on 29th of September so it can be announced then

updated dates:

i think the config file RFC is good. Only missing functionality is forcing plugins to reference the config file. Should be easy but it's not an area I'm familiar with.

lots of MS4W work happening also, so this will be great timing for the Windows community (8.0 release in MS4W)

we should note that Jerome and I will work on a MapCache release for this timing as well

sdlime - just for confirmation - all MapServer users will need to use the config file for MapServer to work after the v8 release?

seth_ that's correct - at least for the mapserv(.exe) binary. MapScript is optional...

sdlime: deal

EvenR handled polishing up the internals (whew)

sdlime_ - thanks just wanted to check. there will be updates required for all demos (MS docs, OSGeoLive etc) as they will no longer work

We need new demos anyway

sdlime_: on Unix, will the config file be looked automatically in /etc ?

There is no default location baked in at the moment. The value comes from the environment - basically the only thing pulled from the environment.

we should definitely have a fallback to the ${sysconfir} or the equivalent setting in cmake parlance

sdlime: what about wildcards, for an entire directory of mapfiles? (MS4W has 80+ mapfiles now?!)

setting env variables is annoying

or do users/me have to manually include each mapfile in the config file?

jmckenna, if you want to use aliases, yes... Path-based map= settings are still allowed but we require the use of MS_MAP_PATTERN from the config file.

right. this will be unfortunately MS4W's job (me), to solve to make it easy for new users

I'll try to provide an enhancement commit trying ${sysconfdir}/ if the env variable isn't set

I believe MS_MAP_PATTERN can be a regex so it can be used to enable a directory of mapfiles

EvenR, yes env variables are annoying and with all the differences between fastcgi and OSes the config file should help. Suggestions related to a compile-time or alternate run-time setting are most welcome.

dmorissette: cool, thanks, will try

MS_MAP_PATTERN is a regex. It works with MS_MAP_BAD_PATTERN and is easy to set

is it possible to look for a default config file in the same directory as mapserv.exe?

i think the config file should not be exposed to the web server

I agree with EvenR that we should lookup default location if the env var is not set., I was thinking $prefix/etc/mapserver.conf, since I was not familiar with $sysconfdir... but that may be even better

seth_: or perhaps dir_of_mapserv.exe/../etc/mapserv.conf ?

on Windows, it will be something like C:/MS4W/apps/MapServer

finding files relative to the binary is a bit more involved. I've done that for PROJ. That involves OS dependent code

on Windows there is no real use of /etc folders. most ini type files can be placed next to their .exes though

EvenR awesome, thanks for the link

(whereas mapserv.exe would live in C:/MS4W/Apache/cgi-bin/)

well, if we use the make install target of cmake, then everybody should have the binaries in bin/ , the lib in lib/ etc . So having a etc/ is natural

hum... I'll stay away from the relative finding of things

it should also be possible to have multiple configs on a single server, 1 for each virtual host. users will have to use envvar in that event.

priority would be : use envvar if set, otherwise fallback to path hardcoded at build time

+1

+1

i can update the wiki version of the rfc with this - being light on specifics until it's implemented

if you update shortly i'll convert to html

that will be the 2 big questions from the current draft - how to point to * mapfiles, where does MapServer look for the config file

msautotest, etc... are all passing (thanks EvenR) so there's an super simple config file used there. There are also examples in the build check that tests the cgi/fastcgi. There's also a sample config in source/etc/mapserver-sample.conf.

sdlime - i'll add a couple of slides on this to the FOSS4G presentation.

any reaction to the short SECURITY.md thread on mapserver-dev - in terms of what versions get security updates?

I do like your suggestion to go by year

+1 to "only support the current stable release, and the previous branch"

+1 for updates to last major release for 1 year (unless someone submits pull requests or funding?)

supporting < 7.6 doesn't seem reasonable to me

the key for me is considering the branches with in a major release (e.g. 7) on a continuum so you patch the latest. There really shouldn't be a reason not to go from 7.4 to 7.6. Perhaps someone needs to ping the USGS...

i agree, i say this publicly every time, but every time a report comes we have to handle for 7.4, 7.2, 7.0 even 6.4 (?!??!)

I find that going back 1 year is not much, when people have systems in production they cannot update versions that easily... but we can't go back all the way to 6.x either ... we need to find the right balance

(agreed with EvenR )

people are free to cherry-pick patches if they need to support older/ancient versions, but that shouldn't be our burden

I wonder what packagers think?

packagers cherry-pick patches (which is somewhat idiotic since they lack other needed previous commits)

i think also missing is (can of worms) support versions for MapScript

at least I was refering to typical way Linux distros work

unfortunately I have a hard stop at 9am - I'll update the config file RFC and send Jeff a note in the next couple of hours

roger, thanks

next meeting date: 30 September

thanks. bye!

thanks all - bye

bye all

thanks all! try to enjoy the last hot days of summer

This may have been suggested before, but perhaps the rule could be to patch the last release branch of the two most recent major releases. So at the moment that would be 7.6 and 6.4, and the day that 8.0 is released that becomes 8.0 and 7.6 (and 6.x becomes officially unmaintained)

... this works only as long as we don't break compatibility between release branches within a given major release

dmorissette: i like this. i think this was suggested but you put it more elegantly here