We are in agreement here, i don't think we have to continue debating over
2.2.x or not. I have already tried to articulate our initial reasoning for
including just the api changes so i am not going to do that anymore.
Clearly this discussion has brought to light that even the api changes are
not fleshed out well enough at this point to be included short term. Great,
that is what the proposal process is for. I have also tried to apologize
for the miscommunication on our part (mostly my fault) regarding this. Not
sure what more I can do there also... maybe I deserve to be
blacklisted/suspended for my misstep, ejection from the PSC perhaps... not
sure.
What I will do is try to articulate without ambiguity the current stance
and expectations from our side. We are in no way shape or
form targeting the 2.2.x branch with this work. Our only goal at this point
is to gather feedback from the community about the new api, which is
currently happening and that is great. Once discussion ramps down and we
have settled on what the initial api can look like we would like to start
working toward committing it to whatever the suitable unstable branch is at
that time, 2.3.x, 2.4.x, etc...
On Sat, Apr 28, 2012 at 2:30 PM, Andrea Aime
<[email protected]>wrote:
> Moving forward with the discussion about the code being "proof of concept".
>
> By "proof of concept" I don't mean that the code is bad, I mean that it's
> a stage
> where it proofs the concept but it's not ready to be integrated in a code
> based that was meant to become stable soon, simply because it's last minute
> (last minute changes are rarely good) and imcomplete.
>
> This one is mostly about what's happening above the catalog.
> Right now we have some exemplar use cases, which have been indeed picked
> up with care.
> However they are only three, that's my biggest worry, I'm pretty sure that
> by
> developing the full switch you might have seen more use cases and found
> more
> bugs in the implementations.
>
> Now, in order to reap the benefits of the scalable API one has to make the
> code
> actually use the new scalable methods whenever large amounts of data is
> read
> from the catalog, meaning switching also most other capabilities documents,
> the Describe* methods (most of them can take no layer/coverage/feature type
> identifier and describe the whole server as a result), the GUI, I guess
> some parts of RESTConfig.
>
> Now, let's say we commit the proposal as it is now, with only the exemplar
> cases.
> You argue it is done to minimize the risk. I say the net effect is that
> it actually makes it way too easy, if not natural, to do all of the above
> work outside of the proposal framework with little scrutiny, because
> everything
> related to scalability is turned to "bug" or "improvement" jiras,
> forgetting that
> these jira wire up with code that is not as well tested as the rest, and
> thus
> put us at risk of getting something fundamentally broken while we are
> doing bugfix releases.
> So in the end the same amount of work gets done in the 2.2.x series, but
> with
> very little scrutiny, and the proposal looks less scary because it changes
> less
> code. Seems like a trick, that's why I called it the "trojan horse".
>
> Even if you "promise" not to do any of these changes in the 2.2.x series
> the
> fact remains that these changes are getting in very late in the game, after
> 3 months since I asked to start the release process and was told to wait
> "two weeks".
> As much as you feel my feedback is unfair, try to put on the other plate
> of the
> scale how much unfair it has been already for me.
>
> I'd much prefer to see the work done in a new trunk, done fully, done
> well,
> and eventually be backported later if we don't find a compromise on timed
> releases.
> Again, this is negative feedback but I don't want to be a show stopper, if
> everybody
> else feels the proposal should go on I'll vote -0 on it.
>
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
