> -----Original Message----- > From: Dominic Lowe [mailto:[email protected]] > Sent: Monday, 13 July 2009 11:04 > To: [email protected] > Cc: Kralidis,Tom [Ontario] > Subject: Re: [Community] OWSLib release strategy? > > Hi All, > > Okay I've just done a big OWSLib commit and merged all the > code from the soswfsbranch into the trunk. > > http://trac.gispython.org/lab/changeset/1317 > > One of the CSW tests (csw_devgeo.txt) is failing.
Try it again? Should be working now. I think there were some DNS issues. > couldn't find any tests for SOS - Tom, do you have any code > you can convert into a doctest? > I will check. > Also I agree with Sean that we probably need to have an > interface sanity check - I haven't really paid any attention > to it during this merge. > > Cheers > Dom > > > On Wednesday 08 July 2009 18:01:50 Kralidis,Tom [Ontario] wrote: > > I say let's release and get it out there. > > > > ..Tom > > > > > > > > -----Original Message----- > > From: [email protected] on behalf of > Sean Gillies > > Sent: Wed 08-Jul-09 05:42 > > To: gispython.org community projects > > Subject: Re: [Community] OWSLib release strategy? > > > > On Jul 7, 2009, at 1:15 PM, Dominic Lowe wrote: > > > Hi all, especially OWSLib commiters, > > > > > > There's a lot of new stuff that has gone into OWSLib recently - > > > some of it is in the trunk and some is lurking in a > branch yet to be > > > merged with the trunk. > > > Most of it is still work in progress. > > > > > > In the trunk recent additions include: > > > > > > * CSW support > > > * ISO 19115 metadata parsing (needed for CSW support I assume) > > > * Several improvements to WCS support (caching, url checking) > > > * OWSCommon classes to share between services > > > * A general Utils module for common functions > > > > > > In branches/soswfsbranch there is also: > > > * Support for WFS "2.0" (IS019142) > > > * Support for SOS (sensor observation service) > > > > > > > > > My preference would be to merge soswfsbranch into the > trunk sooner > > > rather than later to prevent divergence - however this leaves the > > > trunk with a lot of 'alpha' code in it (WFS2/SOS/CSW), > compared to > > > the more mature > > > WMS/WFS1 > > > and WCS support. > > > > > > What do people think about this? > > > > > > Should we just accept that some of the services are > better supported > > > than others and release them all anyway, say as OWSLib > version 3.5 > > > or 4.0 ? > > > > > > Or should we just carry on as is in the trunk without a > new release > > > - the > > > downside being that improvements/patches such as the WCS patches > > > don't get released onto Pypi for a while. > > > > > > Or should be make an effort to branch off code into stable and > > > unstable branches and move modules across individually > when 'ready' > > > (whatever ready means)? > > > > > > Or should we perhaps package some things within OWSlib as > > > experimental modules e.g. "owslib.experimental.sos" and move them > > > across when 'ready'. > > > > > > There are pros and cons to each of these. Are there other > options we > > > should consider? > > > > > > My preference is to take the simple option and put > everything in the > > > trunk and put out a new release with the caveat that some > services > > > are better developed than others. Of course we'd need to run the > > > tests and creating new ones where needed. > > > > > > My concern about having stable and unstable branches and > therefore > > > waiting for code to be 'finished' is that we don't have much > > > development effort on this project - a few people do a > bit here and > > > there but only as time allows. I'm not sure things will ever be > > > finished as such, just improved upon. I think the incremental > > > approach is therefore going to suit the project better. > > > > > > If something is really unstable then yes it should > probably be in a > > > branch temporarily, but I think the default approach should be to > > > get code into the trunk (and version released) sooner rather than > > > later. > > > > > > Anyway, it's up for discussion, what do others think? > > > > > > Cheers, > > > > > > Dom > > > > I'm +1 with an incremental approach and getting code into the trunk > > quickly. > > > > Another release strategy to consider is to make owslib a namespace > > package, and separately distribute owslib.wms, owslib.wfs, etc. > > > > Before we make more releases, let's revisit the interfaces that Dom > > and I came up with (interfaces.py) and make sure the SOS > and CSW stuff > > implement them. The interfaces themselves may need some > adjustment to > > accomodate. > > > > Sean > > > > -- > > Sean Gillies > > Software Engineer > > Institute for the Study of the Ancient World New York University > > > > _______________________________________________ > > Community mailing list > > [email protected] > > http://lists.gispython.org/mailman/listinfo/community > > > > _______________________________________________ > > Community mailing list > > [email protected] > > http://lists.gispython.org/mailman/listinfo/community > > > _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
