Nabble - MapGuide Internals

RE: Trac versions

2008-11-27T15:40:52Z

I remembered that Bob did the work to add the External ID field. I asked him if he could add the SVN revision field and he said he would do it.

Cheers
Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Jason Birch
Sent: Thursday, November 27, 2008 4:28 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Trac versions

Hi Frank,

Tom does have TRAC_ADMIN for the MapGuide trac, but I'm pretty sure that
what he wants (adding an optional new field on the ticket form to track
revision number) isn't available through the admin UI.

Jason

-----Original Message-----
From: Frank Warmerdam
Sent: Thursday, November 27, 2008 14:37
Subject: Re: [mapguide-internals] Trac versions

Someone with mapguide trac admin priveledges would normally have to do
it.
I see I don't have them. If an appropriate representative from the
mapguide
PSC files a SAC ticket, I can extend mapguide trac admin rights to
additional
people (provide the osgeo userids). Once that is done, you shouldn't
need
SAC to add new milestones, etc.
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

RE: Trac versions

2008-11-27T15:28:19Z

Hi Frank,

Tom does have TRAC_ADMIN for the MapGuide trac, but I'm pretty sure that
what he wants (adding an optional new field on the ticket form to track
revision number) isn't available through the admin UI.

Jason

-----Original Message-----
From: Frank Warmerdam
Sent: Thursday, November 27, 2008 14:37
Subject: Re: [mapguide-internals] Trac versions

Someone with mapguide trac admin priveledges would normally have to do
it.
I see I don't have them. If an appropriate representative from the
mapguide
PSC files a SAC ticket, I can extend mapguide trac admin rights to
additional
people (provide the osgeo userids). Once that is done, you shouldn't
need
SAC to add new milestones, etc.
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Re: Trac versions

2008-11-27T14:36:54Z

Tom Fukushima wrote:
> OK, I'll hold off on adding Maestro release versions for now.
>
> I don't seem to have the privileges to add the revision field to the
> tickets. Perhaps we have to create a SAC ticket for this. Does anyone know
> the process here?

Tom,

Someone with mapguide trac admin priveledges would normally have to do it.
I see I don't have them. If an appropriate representative from the mapguide
PSC files a SAC ticket, I can extend mapguide trac admin rights to additional
people (provide the osgeo userids). Once that is done, you shouldn't need
SAC to add new milestones, etc.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

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

RE: Trac versions (was: MapGuide RFC 57 - Refining the linux buildprocess and generating install packages)

2008-11-27T14:00:37Z

OK, I'll hold off on adding Maestro release versions for now.

I don't seem to have the privileges to add the revision field to the tickets. Perhaps we have to create a SAC ticket for this. Does anyone know the process here?

Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Kenneth Skovhede, GEOGRAF A/S
Sent: Thursday, November 27, 2008 1:27 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linux buildprocess and generating install packages

Yes, that would be nice, but would it complicate using trac for MapGuide?
If so, I can live without it. I have not seen any problems that would be
easier fixed if there was a milestone.

The version filed could use an "SVN" option and perhaps a revision field
for reporting bugs, for MapGuide as well as Maestro.

Regards, Kenneth Skovhede, GEOGRAF A/S

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

Re: Autodesk.MapGuide.Studio.Site.LayerInfo.Save

2008-11-27T12:35:26Z

So it is actually a problem with a pure .Net solution?
I have not seen this reported for .Net ever before.
I will try out your setup, but it will be a while before I get around to it.

I can see that the MgLocalizor is implented in .Net so it makes sense
that is gets slow,
if there is a problem with IndexOf on certain locale settings.
The AJAX viewer is also implented in .Net so that would also happen.

But I cannot see how any of this would affect Maestro, unless you are
trying to
set a locale on the Maestro application itself.

It usually takes less than a second for me to save a layer.

Regards, Kenneth Skovhede, GEOGRAF A/S

ljv skrev:

> Ohh, everything was slow.
>
> I have isolated the cause of the problem.
>
> culture="se-SE" causes ALL string operations to become utterly slow. This is
> easy to test, add
>
> <globalization
> culture="se-SE"
> />
>
> to webconfig for viewer and servers..
>
>
> I'm unsure where (maestro, server, viewcode) uses the string functions. I
> know that the MgLocalizer.Localize is heavily affected due to the string
> functions that is used.
>
> I have verified that dot-net behave in this maner, to following code is runs
> at 10sec at se-SE and close to 0 sec at "sv-SE".
>
>
> Dim SoSlow As String = ""
>
> Response.Write(System.Globalization.CultureInfo.CurrentCulture.EnglishName &
> "<br>")
> Response.Write(Now & "<br>")
> For lFiller As Long = 1 To 10 * 1000
> SoSlow = SoSlow & Chr(Rnd() * 24 + 65)
> Next
> Response.Write(Now & "<br>")
> For lSearcher As Long = 1 To 10
> If SoSlow.IndexOf(Chr(Rnd() * 24 + 65) & Chr(Rnd() * 24 + 65)) >
> 0 Then
> Response.Write("+")
> Else
> Response.Write("->")
> End If
> Next
> Response.Write(Now & "<br>")
>
> Since I do not plan to use culture "se-SE" this is no longer a real problem
> for me, but mastero, mapserver and viewer is heavily affected by culture
> settings.
>
> Saving layerinfo still takes a few seconds for 2k of data. Is that normal?
>
>
>
>
> Kenneth Skovhede, GEOGRAF A/S wrote:
>
>> I still cannot guess where exactly the problem occurs.
>> Is it when you load the page?
>> Is it when you save a layout from Maestro?
>> Is it when you create a temp layout in custom .Net code?
>> Is it in the viewer code?
>> Is it in a sample application?
>>
>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>
>>
>>
>> ljv skrev:
>>
>>> Thx, i will check with em.
>>>
>>> But the server has the same problem, without the culture set (as default)
>>> all text search and replace takes very long time (used when parsing
>>> layouts). To use the map without setting culture is impossible. The
>>> problem
>>> is in the dotnet code. If a create an empty web app that search and
>>> replaces text in the same manner as the mapserver the response is also
>>> slow. It's around 1000 times slower than if you set the culture.
>>>
>>>
>>>
>>> ljv wrote:
>>>
>>>
>>>> I find this (Autodesk.MapGuide.Studio.Site.LayerInfo.Save) functions
>>>> slow,
>>>> 2-4 seconds to save 2kb.
>>>>
>>>> There is no problem with server or network, most functions are fast.
>>>>
>>>> Except for this: In web.config globalization Culture="xxxx" must be
>>>> set.
>>>> Unless the culture is explicite set all strings functions like search
>>>> become so slow that the application is useless. Both maestro and
>>>> mapstudio
>>>> benefit from adding culture to web.config. we have used our
>>>> culture="sv-SE" and English variants and setting the culture speeds the
>>>> viewer and application.
>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals@...
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>>
>
>

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

Re: MapGuide RFC 57 - Refining the linux buildprocess and generating install packages

2008-11-27T12:26:46Z

Yes, that would be nice, but would it complicate using trac for MapGuide?
If so, I can live without it. I have not seen any problems that would be
easier fixed if there was a milestone.

The version filed could use an "SVN" option and perhaps a revision field
for reporting bugs, for MapGuide as well as Maestro.

Regards, Kenneth Skovhede, GEOGRAF A/S

Tom Fukushima skrev:
> BTW, maybe we should be creating special milestones and versions for Maestro. Maybe calling it "Maestro 1.0.9" or something like that. Kenneth, I think you had asked for something like this before. Well it seems that we can do it; are you interested?
>
> Tom
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

RE: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-27T10:46:23Z

Hi Helio,

Your signed agreement is on file.

Cheers
Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Helio Chissini de Castro
Sent: Wednesday, November 26, 2008 3:49 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

On Quarta 26 Novembro 2008, Zac Spitzer wrote:
> as a 'Project Contributor' can I ask the 'Project Developers' to
> consider nominating Helio? :)
>
> the developers page could do with a little TLC,
>
> Areas of Need needs a few version numbers bumped up
> and I think the MapGuideArchitecture wiki page is worthy addition for
> the developer resources
>

I did the whole process for FDO some time ago, including sign the agreement
and faxed.
Never got any return for my application

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

RE: MapGuide Architecture document (was Project Sponsorship)

2008-11-27T08:09:43Z

Tom,

That server to server interaction should be marked as "Future" because the infrastructure is there it is just not used right now. I think I wrote down some incorrect class names and haven't verified them yet (they were from memory :) ).

Thanks,
Bruce

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Tom Fukushima
Sent: Wednesday, November 26, 2008 5:40 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] MapGuide Architecture document (was Project Sponsorship)

Bruce,

There is an "interaction between servers" diagram in the document (Figure 3), when does that happen?

I did a couple minor tweaks with formatting. I also tried referencing code from the classes described in the document (Operation, OperationRequest, etc.) but I couldn't find the corresponding ones. I did make one for Operation though by pointing it to ServiceOperation.h; hope that was correct.

Like everyone else is saying, this is a great document and thanks for doing it. I think that it will be a tough job for a single person to maintain when it is done (and to create for that matter). We should try to get more people involved with it---I hear that developers like writing documentation :)

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Bruce Dechant
Sent: Wednesday, November 26, 2008 10:56 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RE: Project Sponsorship

Kenneth,

...

I have updated the architecture documentation to include the operation processing information you have requested. http://trac.osgeo.org/mapguide/wiki/MapGuideArchitecture#OperationProcessing

Note: There is still lots more to add to the architecture document that I am still working on.

Thanks,
Bruce

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

RE: MapGuide Architecture document (was ProjectSponsorship)

2008-11-26T19:26:28Z

I'm having difficulty finding the plugin on that page... what does it do?

________________________________

From: Zac Spitzer
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide Architecture document (was ProjectSponsorship)

one thing which would help with this document is the trac plugin, like the
one on this page

http://ortus.svnrepository.com/coldbox/trac.cgi/wiki#HandsOnGuides

i know there has been some reluctance to complicate the trac install with
plugins

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

Re: MapGuide Architecture document (was Project Sponsorship)

2008-11-26T16:50:43Z

one thing which would help with this document is the trac plugin, like the
one on this page

http://ortus.svnrepository.com/coldbox/trac.cgi/wiki#HandsOnGuides

i know there has been some reluctance to complicate the trac install with
plugins

On Thu, Nov 27, 2008 at 11:40 AM, Tom Fukushima
<tom.fukushima@...>wrote:

> Bruce,
>
> There is an "interaction between servers" diagram in the document (Figure
> 3), when does that happen?
>
> I did a couple minor tweaks with formatting. I also tried referencing code
> from the classes described in the document (Operation, OperationRequest,
> etc.) but I couldn't find the corresponding ones. I did make one for
> Operation though by pointing it to ServiceOperation.h; hope that was
> correct.
>
>
> Like everyone else is saying, this is a great document and thanks for doing
> it. I think that it will be a tough job for a single person to maintain when
> it is done (and to create for that matter). We should try to get more people
> involved with it---I hear that developers like writing documentation :)
>
>
>
> -----Original Message-----
> From: mapguide-internals-bounces@... [mailto:
> mapguide-internals-bounces@...] On Behalf Of Bruce Dechant
> Sent: Wednesday, November 26, 2008 10:56 AM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] RE: Project Sponsorship
>
> Kenneth,
>
> ...
>
> I have updated the architecture documentation to include the operation
> processing information you have requested.
> http://trac.osgeo.org/mapguide/wiki/MapGuideArchitecture#OperationProcessing
>
> Note: There is still lots more to add to the architecture document that I
> am still working on.
>
> Thanks,
> Bruce
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

RE: MapGuide Architecture document (was Project Sponsorship)

2008-11-26T16:40:02Z

Bruce,

There is an "interaction between servers" diagram in the document (Figure 3), when does that happen?

I did a couple minor tweaks with formatting. I also tried referencing code from the classes described in the document (Operation, OperationRequest, etc.) but I couldn't find the corresponding ones. I did make one for Operation though by pointing it to ServiceOperation.h; hope that was correct.

Like everyone else is saying, this is a great document and thanks for doing it. I think that it will be a tough job for a single person to maintain when it is done (and to create for that matter). We should try to get more people involved with it---I hear that developers like writing documentation :)

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Bruce Dechant
Sent: Wednesday, November 26, 2008 10:56 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RE: Project Sponsorship

Kenneth,

...

I have updated the architecture documentation to include the operation processing information you have requested. http://trac.osgeo.org/mapguide/wiki/MapGuideArchitecture#OperationProcessing

Note: There is still lots more to add to the architecture document that I am still working on.

Thanks,
Bruce

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

RE: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T15:58:12Z

I've fixed up that page. Feel free to enter task tickets for any web page changes; I think that this will help to keep the noise on this mailing list down.

The MapGuide Architecture page is available from here: http://trac.osgeo.org/mapguide/
and indirectly from here: http://mapguide.osgeo.org/developer.html (which is the "As a Contributor" link from the main page). Where are you thinking of adding another link? (BTW, this also could be added as a task ticket).

Thanks
Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Zac Spitzer
Sent: Wednesday, November 26, 2008 3:24 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

as a 'Project Contributor' can I ask the 'Project Developers' to
consider nominating Helio? :)

the developers page could do with a little TLC,

Areas of Need needs a few version numbers bumped up
and I think the MapGuideArchitecture wiki page is worthy addition for
the developer resources

On Thu, Nov 27, 2008 at 9:11 AM, Tom Fukushima
<tom.fukushima@...> wrote:

> This page talks about how to become a contributor: http://mapguide.osgeo.org/developer.html
>
> Note the statements:
> Project Developers can nominate a Project Contributor who has sent in solid, useful patches for Project Developer status. The PSC then votes to officially elect the individual to Project Developer status, at which time commit rights are granted.
>
> But I think that for install and build work, we are willing to forgo the above prerequisite for patches with the caveat that the submissions will be limited to the build work in the sandbox (and for the merge when back to trunk when it is done and approved).
>
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Zac Spitzer
> Sent: Wednesday, November 26, 2008 2:44 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages
>
> Jason, that makes sense with regards to trac, I've been knee deep in JIRA for
> a while and we approach things a bit differently given the extra
> flexibility that
> JIRA provides (primarily multiple components, affects version(s) and
> fix version(s) . )
>
> that also makes complete sense with regards to requiring the
> contributors agreement
> http://wiki.osgeo.org/wiki/Contributor_Agreement
>
> Thanks for the info Frank about subversion
>
> Is there anything else we need to discuss prior to putting the up for
> a PSC vote?
>
> The only thing is approval process for the sandboxers... how does that work?
>
> if you have an a valid osgeo contributors agreement and want to get
> in, you get access?
>
> z
>
>
>
>
> On Thu, Nov 27, 2008 at 8:26 AM, Jason Birch <Jason.Birch@...> wrote:
>> I feel that we could give sandbox committers full access and expect them
>> to "do the right thing". My personal take is that if we do this we
>> should require that our sandbox committers sign a contribution agreement
>> though.
>>
>> Other projects like gdal and openlayers create the sandbox at the same
>> level as trunk, branches, etc, and as far as I know don't set up Trac
>> components for the sandbox. We could either overload the "Build"
>> component, or create a new component for CMake I guess.
>>
>> Jason
>>
>> -----Original Message-----
>> From: Zac Spitzer
>> Sent: Wednesday, November 26, 2008 13:10
>> Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the
>> linuxbuildprocess and generating install packages
>>
>> With regards to undertaking this work in a sandbox, how is that going
>> to work with commit rights?
>>
>> Will SVN ACL's be used to provide commit access to the people working
>> on the sandbox
>> without giving the commit access to the whole tree?
>>
>> As it was mentioned that 2.1 was going to appear as a beta (back in
>> oct?) is the trunk in a
>> reasonable state for branching off into a sandbox?
>>
>> What's the best approach with trac? a special milestone?
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals@...
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Re: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T14:48:30Z

On Quarta 26 Novembro 2008, Zac Spitzer wrote:
> as a 'Project Contributor' can I ask the 'Project Developers' to
> consider nominating Helio? :)
>
> the developers page could do with a little TLC,
>
> Areas of Need needs a few version numbers bumped up
> and I think the MapGuideArchitecture wiki page is worthy addition for
> the developer resources
>

I did the whole process for FDO some time ago, including sign the agreement
and faxed.
Never got any return for my application

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
mapguide-internals mailing list
mapguide-internals@...
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

Re: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T14:23:42Z

as a 'Project Contributor' can I ask the 'Project Developers' to
consider nominating Helio? :)

the developers page could do with a little TLC,

Areas of Need needs a few version numbers bumped up
and I think the MapGuideArchitecture wiki page is worthy addition for
the developer resources

On Thu, Nov 27, 2008 at 9:11 AM, Tom Fukushima
<tom.fukushima@...> wrote:

RE: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T14:11:59Z

This page talks about how to become a contributor: http://mapguide.osgeo.org/developer.html

Note the statements:
Project Developers can nominate a Project Contributor who has sent in solid, useful patches for Project Developer status. The PSC then votes to officially elect the individual to Project Developer status, at which time commit rights are granted.

But I think that for install and build work, we are willing to forgo the above prerequisite for patches with the caveat that the submissions will be limited to the build work in the sandbox (and for the merge when back to trunk when it is done and approved).

Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Zac Spitzer
Sent: Wednesday, November 26, 2008 2:44 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

Jason, that makes sense with regards to trac, I've been knee deep in JIRA for
a while and we approach things a bit differently given the extra
flexibility that
JIRA provides (primarily multiple components, affects version(s) and
fix version(s) . )

that also makes complete sense with regards to requiring the
contributors agreement
http://wiki.osgeo.org/wiki/Contributor_Agreement

Thanks for the info Frank about subversion

Is there anything else we need to discuss prior to putting the up for
a PSC vote?

The only thing is approval process for the sandboxers... how does that work?

if you have an a valid osgeo contributors agreement and want to get
in, you get access?

z

On Thu, Nov 27, 2008 at 8:26 AM, Jason Birch <Jason.Birch@...> wrote:

> I feel that we could give sandbox committers full access and expect them
> to "do the right thing". My personal take is that if we do this we
> should require that our sandbox committers sign a contribution agreement
> though.
>
> Other projects like gdal and openlayers create the sandbox at the same
> level as trunk, branches, etc, and as far as I know don't set up Trac
> components for the sandbox. We could either overload the "Build"
> component, or create a new component for CMake I guess.
>
> Jason
>
> -----Original Message-----
> From: Zac Spitzer
> Sent: Wednesday, November 26, 2008 13:10
> Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the
> linuxbuildprocess and generating install packages
>
> With regards to undertaking this work in a sandbox, how is that going
> to work with commit rights?
>
> Will SVN ACL's be used to provide commit access to the people working
> on the sandbox
> without giving the commit access to the whole tree?
>
> As it was mentioned that 2.1 was going to appear as a beta (back in
> oct?) is the trunk in a
> reasonable state for branching off into a sandbox?
>
> What's the best approach with trac? a special milestone?
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

RE: MapGuide RFC 57 - Refining the linux buildprocess and generating install packages

2008-11-26T13:49:40Z

Hi Zac,

My comments...

> As it was mentioned that 2.1 was going to appear as a beta (back in
> oct?) is the trunk in a
> reasonable state for branching off into a sandbox?
Yes

> What's the best approach with trac? a special milestone?
If you are planning to put some separate builds out to the community that are not part of the normal releases a special milestone might be best. We have the capability to create special milestones and version such as "cmake". And then we can remove them later when no longer needed.

BTW, maybe we should be creating special milestones and versions for Maestro. Maybe calling it "Maestro 1.0.9" or something like that. Kenneth, I think you had asked for something like this before. Well it seems that we can do it; are you interested?

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

Re: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T13:43:41Z

Jason, that makes sense with regards to trac, I've been knee deep in JIRA for
a while and we approach things a bit differently given the extra
flexibility that
JIRA provides (primarily multiple components, affects version(s) and
fix version(s) . )

that also makes complete sense with regards to requiring the
contributors agreement
http://wiki.osgeo.org/wiki/Contributor_Agreement

Thanks for the info Frank about subversion

Is there anything else we need to discuss prior to putting the up for
a PSC vote?

The only thing is approval process for the sandboxers... how does that work?

if you have an a valid osgeo contributors agreement and want to get
in, you get access?

z

On Thu, Nov 27, 2008 at 8:26 AM, Jason Birch <Jason.Birch@...> wrote:

RE: RE: GDAL Stability (Was: Project Sponsorship)

2008-11-26T13:29:49Z

Hi Zac,

I'm sure I could be blamed for some part of this as well. Sorry.

Learning and improving is a good thing.

To address what happened here, I think that it would be great if those community members who are watching trac tickets do the following: Check to see if the ticket has enough information for you to reproduce the problem in a short amount of time (guideline of less than 10 minutes---not including the time it takes to download the data). If it doesn't then make a request to the ticket creator to add the missing information.

Thanks
Tom

-----Original Message-----
From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Zac Spitzer
Sent: Wednesday, November 26, 2008 1:57 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RE: GDAL Stability (Was: Project Sponsorship)

My bad for not filing a test case earlier :( sorry

that said, I'm disappointed that I wasn't pinged about this (even off list)
as I have been rather vocal about this issue and given the limited knowledgeable
development resources that the time was wasted simply trying to
reproduce the bug

This is a good example of how the development process could be improved

z

On Thu, Nov 27, 2008 at 3:57 AM, Tom Fukushima
<tom.fukushima@...> wrote:

> The bad news is that we already allocated our time trying to reproduce the defect (without success) and have moved on.
>
> However, I think that Steve will have time to be able to work on this in the new year.
>
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Zac Spitzer
> Sent: Tuesday, November 25, 2008 7:17 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RE: GDAL Stability (Was: Project Sponsorship)
>
> The good news is Tom was finally able to reproduce the bug using the
> package I created :)
>
> On Wed, Nov 26, 2008 at 8:24 AM, Zac Spitzer <zac.spitzer@...> wrote:
>> Link to the package is against the ticket
>>
>> http://trac.osgeo.org/mapguide/ticket/462
>>
>> z
>>
>> On Wed, Nov 26, 2008 at 8:20 AM, Frank Warmerdam <warmerdam@...> wrote:
>>> Tom Fukushima wrote:
>>>>
>>>> We didn't do any testing with MrSID and ECW.
>>>>
>>>> We don't plan on doing MrSID and ECW, because if there are problems we
>>>> don't
>>>> have any control of those libraries so we would have to add workarounds in
>>>> the GDAL provider code; and that is more work than we can take on.
>>>> Threading problems are one of the worst time sinks.
>>>
>>> Jason,
>>>
>>> It was also my advice to Tom to focus first on a "well behaved" driver like
>>> GeoTIFF. The lesson is that the problems are likely GDAL driver specific
>>> rather than relating to how the GDAL FDO provider is implemented.
>>>
>>> Best regards,
>>> --
>>> ---------------------------------------+--------------------------------------
>>> I set the clouds in motion - turn up | Frank Warmerdam,
>>> warmerdam@...
>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>> and watch the world go round - Rush | Geospatial Programmer for Rent
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals@...
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>
>>
>>
>> --
>> Zac Spitzer -
>> http://zacster.blogspot.com
>> +61 405 847 168
>>
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

RE: MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

2008-11-26T13:26:05Z

I feel that we could give sandbox committers full access and expect them
to "do the right thing". My personal take is that if we do this we
should require that our sandbox committers sign a contribution agreement
though.

Other projects like gdal and openlayers create the sandbox at the same
level as trunk, branches, etc, and as far as I know don't set up Trac
components for the sandbox. We could either overload the "Build"
component, or create a new component for CMake I guess.

Jason

-----Original Message-----
From: Zac Spitzer
Sent: Wednesday, November 26, 2008 13:10
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the
linuxbuildprocess and generating install packages

With regards to undertaking this work in a sandbox, how is that going
to work with commit rights?

Will SVN ACL's be used to provide commit access to the people working
on the sandbox
without giving the commit access to the whole tree?

As it was mentioned that 2.1 was going to appear as a beta (back in
oct?) is the trunk in a
reasonable state for branching off into a sandbox?

What's the best approach with trac? a special milestone?

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

Re: MapGuide RFC 57 - Refining the linux buildprocess and generating install packages

2008-11-26T13:18:52Z

Zac Spitzer wrote:
> With regards to undertaking this work in a sandbox, how is that going
> to work with commit rights?
>
> Will SVN ACL's be used to provide commit access to the people working
> on the sandbox
> without giving the commit access to the whole tree?

Zac,

We have the ability to maintain a secondary commit group with access only
to a restricted area, like /sandbox. Read up for details at:

http://wiki.osgeo.org/wiki/Subversion (see under Authz Rules)

If the MapGuide PSC decides it would like to do this, someone can coordinate
with me to set up the SVN side of things.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

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

Re: MapGuide RFC 57 - Refining the linux buildprocess and generating install packages

2008-11-26T13:10:29Z

With regards to undertaking this work in a sandbox, how is that going
to work with commit rights?

Will SVN ACL's be used to provide commit access to the people working
on the sandbox
without giving the commit access to the whole tree?

As it was mentioned that 2.1 was going to appear as a beta (back in
oct?) is the trunk in a
reasonable state for branching off into a sandbox?

What's the best approach with trac? a special milestone?

z

On Thu, Nov 27, 2008 at 5:54 AM, Tom Fukushima
<tom.fukushima@...> wrote:

> Thanks for taking the initiative on this Zac.
>
> I took the liberty of adding a statement about the AGG version issue to the RFC.
>
> Also, for GEOS 3.0 we have a patch somewhere (that probably doesn't work anymore) to update MGOS for it. Let me see if I can dig it up; I'll create a ticket for it and attach the patch.
>
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces@... [mailto:mapguide-internals-bounces@...] On Behalf Of Jason Birch
> Sent: Tuesday, November 25, 2008 11:07 PM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] MapGuide RFC 57 - Refining the linux buildprocess and generating install packages
>
>
> Thanks for putting that together Zac.
>
> I'm not sure which OEM components have been modified specifically for MapGuide. I'm pretty sure that AGG has been, and we have to make sure that we only bundle the older 2.4 version with any releases that we do to avoid contaminating our code with GPL. Are there any other OEM components that have modifications that haven't been contributed/adopted upstream? I see that at least GEOS and GD (libpng) have had some code modifications made to support 64 bit compilation.
>
> Tom, I'd agree that the Windows build process is easy, but maybe too easy :) I'd love to try swapping out some of the OEM components in the Windows build/packages for 2.1, especially Apache, PHP, and GEOS. Unfortunately, I think that this may be a bit optimistic given that some packages (such as ACE) haven't been updated in over four years, and I don't have the developer chops to fix anything I run into.
>
> Jason
>
> ________________________________
>
> From: mapguide-internals-bounces@... on behalf of Zac Spitzer
> Sent: Tue 2008-11-25 6:50 PM
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] MapGuide RFC 57 - Refining the linux buildprocess and generating install packages
>
>
>
> Following up on the various discussions about the linux build process
> I have created a draft RFC
> for refining the linux build process and generating install packages.
>
> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc57
>
> z
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com <http://zacster.blogspot.com/>
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals@...
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>