[mapguide-internals] RFC60 ??? - at least a sandbox please

Fri Sep 18 15:08:46 EDT 2009

I agree.  If you are using AJAX for your site, the current code base is probably ready to rock and roll.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Martin Morrison
Sent: September 18, 2009 1:03 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Trevor,

I'm going to correct your misspelling...

"2.1 is WWWWWWAAAAAAAAAAAAAAAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY overdue."  

<G> 

Of course, somebody will probably chime in that I didn't add enough characters...

Just keep in mind there are some pretty decent fixes for the AJAX viewer that are being held up.  I say put the release out and let whoever is going to use Fusion patch it until the next release is out.  If I'm correct there isn't an absolute date that they are saying Fusion is guaranteed ready by is there?  

As far as the PNG32 performance goes, if you are after pure performance use JPG, yes it doesn't look as good.  Besides as far as 2.11 goes, if we are following the rules and schedule precisely, nothing else would be added at this point.

Yes, I refuse to use a beta or release candidate on a production box as a matter of policy/liability.

Thanks,
Martin

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 2:43 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Hi Martin,

I have not personally taken a run at the latest code base so I do not know how good Fusion is right now.  But I personally believe a usable, working Fusion is key to the success of this release.  In other words, a think it is a "must have".

The RFC 60 work would probably fall into the "nice to have" category but switching to PNG8 with an appropriate palette can reduce network bandwidth by a factor of 3x or more when serving tiles.  The current bandwidth usage for PNG32 easily makes it a non-starter for internet apps.  PNG32 tiles are beautiful but they take a really long time to download.  It will make your ISP happy but that's about it.

without palette support, PNG8 rendering is simply problematic due to color skew.  A feature that is supposed to be red can turn out purple if red gets overlooked during quantization. 

I totally agree though.  2.1 is WAYYY overdue.  But I consider, and I suspect the rest of the PSC will too, a new Fusion drop and RFC 60 to be new Features.  According to the published release process that we are trying to follow, neither of these can be put into 2.1.1.  If we follow the process, they would have to wait until 2.2.

If additional defects related to a new drop of Fusion and RFC 60 are found in 2.1, those can be fixed in 2.1.1 because they are simply defects on a released feature.

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Martin Morrison
Sent: September 18, 2009 12:07 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Here I go sticking my nose in where it probably doesn't belong again...

In my mind if we add RFC60 and Fusion fixes/updated version we are going to need to start completely over on the testing at the beta stage.  (forget release candidate status).  I'm not knocking any of the fixes/changes that are in these, I'm just saying we can't keep adding new features without an end in sight.  (yes, I consider the Fusion fixes a new feature)  Do a release 2.11 in a month or so and put these fixes in.  Just don't keep holding a final 2.1 release pending more bigger and better things.

I will go wipe my nose now...

Martin

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 1:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Ok.  An empty sandbox has been created.  Based on some of the other sandboxes, it looks as though we are only checking changed files into the sandbox.  I think this is reasonable since it gives better visibility to the changes which have occurred.

UV, once access has been approved I think it would be a good idea to first check in a set of unchanged files from the current branch of MapGuide and then apply your changes.  That way, all differences will be visible in Trac.

PSC members - is this RFC still slated for MGOS 2.1?  It would be a nice feature to include but the extended community would have to be on board to ensure code reviews, fixes, testing, etc happen before we send out a release candidate.  According to our published release process http://mapguide.osgeo.org/releaseprocess.html,

"Under no circumstances will new features be admitted to a version following a release candidate.".

Autodesk PSC members - are there any internal scheduling issues with RFC 60 going into trunk?

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom Fukushima
Sent: September 18, 2009 11:06 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Our ticket for sandbox access (http://trac.osgeo.org/osgeo/ticket/400) has not been resolved yet.  We will need to give UV full access to the vault, as we do with current sandbox committers.

Trevor please create the sandbox, I can give UV the rights to commit.  UV, what is you OSGeo user id? Capitalization is important.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Friday, September 18, 2009 10:57 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RFC60 ??? - at least a sandbox please

Based on UV's discussion, I think the RFC 60 work does require a sandbox.  There are still outstanding items related to new stylize compatibility which need to be addressed.  However, there has already been significant headway made by UV and it would be disappointing to lose a significant server side code contribution from a developer outside of Autodesk.

I can set up a sandbox for RFC 60 but I do not know where commit rights lie.  From what I recall, there was an outstanding request with SAC to enable commit rights only on sandboxes.  Has this been resolved?  If so, how do we grant sandbox commit rights to UV?

Based on previous mapguide-internals "discussions", I do not believe full commit rights for UV would be accepted yet.

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: September 18, 2009 9:28 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC60 ??? - at least a sandbox please

It seems like RFC60 will not be included in any release on the basis 
that it does not support the new stylization.
In this context I would like to request a sandbox to be able to upload 
at least a working configuration.
Adapting the pach to the ever changing code base is an ever increasing task.

i have been asking a few times for sample test maps to implement this 
additional functionality  I only been shown some unit test code and 
never a real map.
For the complexity of this feature this is not sufficient and I am still 
lacking resources to do an efficient job.
Furthermore nobody seems to use that stylization so it seems that RFC60, 
a simple addition in functionality, would do no harm and not disturb any 
maps using new stylization.

I am very disappointed about working months for this project an nobody 
would even allow me to
contribute anything to the code base after fixing the issues in the patch.
something seems missing in the open source here ...

our customer now has a big problem to continue with updating MGOS as the 
missing patch is very visible
on his site. thank you very much.

to keep at least the code base i am requesting

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals