OWSLib release strategy?

[Dominic Lowe-2]

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



_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

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
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Kralidis,Tom [Ontario]]

I say let's release and get it out there.

..Tom



-----Original Message-----
From: community-bounces@... 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
Community@...
http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Dominic Lowe-2]

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. Also I couldn't find any
tests for SOS - Tom, do you have any code you can convert into a doctest?

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: community-bounces@... 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
> Community@...
> http://lists.gispython.org/mailman/listinfo/community
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Kralidis,Tom [Ontario]]

 

> -----Original Message-----
> From: Dominic Lowe [mailto:dominic.lowe@...]
> Sent: Monday, 13 July 2009 11:04
> To: community@...
> 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: community-bounces@... 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
> > Community@...
> > http://lists.gispython.org/mailman/listinfo/community
> >
> > _______________________________________________
> > Community mailing list
> > Community@...
> > http://lists.gispython.org/mailman/listinfo/community
>
>
>

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community