From rbray at robertbray.net Mon Oct 16 17:54:00 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: Bootstrapping the MapGuide PSC
Message-ID: <4533FF78.1030208@robertbray.net>
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/501a74a2/attachment.html
From Jason.Birch at nanaimo.ca Mon Oct 16 18:30:35 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
Message-ID: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
Hi,
That IRC meeting time conflicts with OSGeo WebCom, which I'm chairing :(
I like the time slot though; Tuesday or Thursday works for me on a
recurring basis.
Should there be a requirement that any submitted functionality come with
a plan for funding the development, or will this be a purely merit-based
process. If merit-based, how to we prioritise once the features have
been let past the gate? On a funding basis? What if we have some
funding floating around because of generous donations to the project?
I think that the voting provision for removing members should be
clarified, and perhaps we should consider another exit strategy in the
case that there is a rogue member that continues to participate, but in
a way that is counter to the goals of the project as a whole. And yes,
my glass is half-empty.
There should be some work done on a proposal template and suggested
evaluation criteria but that's not in scope here.
Jason
________________________________
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Monday, October 16, 2006 14:54
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
All,
Welcome to the MapGuide PSC. I created this mailing list as a means for
us to communicate as we get the PSC up and running. The mailing list is
open to all, but I simply added this your e-mail addresses to get things
going. Please review and comment (back to this list) on the PSC
guidelines that can now be found at:
https://mapguide.osgeo.org/psc.html.
I would also like to propose an initial bootstrap meeting of the PSC on
Wednesday at 2:00 PM (EST) / 12:00 PM (MST) / 11:00 AM (PST). The agenda
for that first meeting is:
* Review and discuss the PSC Guidelines
* Development and/or PSC Meetings on IRC
* The psc vs dev mailing list. Do we need both?
* Initial PSC size and member nominations.
As per open source custom, the meeting will be held on IRC. For IRC
newbies Chatzilla is probably the best way to get going. It works with
Firefox and once installed you can log onto the channel by pointing your
browser at: irc://irc.freenode.net/#mapguide. You can download Chatzilla
from: http://www.hacksrus.com/~ginda/chatzilla/
.
Daniel you have been included in the PSC mailing list and the meeting
invite so that you can monitor how things progress as we strive to
satisfy our final incubation requirement.
Please let me know if the meeting time works for you and if not please
propose a new time.
Thanks,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/a05e4817/attachment.html
From Jason.Birch at nanaimo.ca Mon Oct 16 18:46:45 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
Message-ID: <8E468917B01800408B91984428BE03DD030D55A5@starfish.nanaimo.ca>
Oh.
Does this committee have responsibility for FDO as well, or is that
going to have its own project structure?
Jason
________________________________
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Monday, October 16, 2006 14:54
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
All,
Welcome to the MapGuide PSC. I created this mailing list as a means for
us to communicate as we get the PSC up and running. The mailing list is
open to all, but I simply added this your e-mail addresses to get things
going. Please review and comment (back to this list) on the PSC
guidelines that can now be found at:
https://mapguide.osgeo.org/psc.html.
I would also like to propose an initial bootstrap meeting of the PSC on
Wednesday at 2:00 PM (EST) / 12:00 PM (MST) / 11:00 AM (PST). The agenda
for that first meeting is:
* Review and discuss the PSC Guidelines
* Development and/or PSC Meetings on IRC
* The psc vs dev mailing list. Do we need both?
* Initial PSC size and member nominations.
As per open source custom, the meeting will be held on IRC. For IRC
newbies Chatzilla is probably the best way to get going. It works with
Firefox and once installed you can log onto the channel by pointing your
browser at: irc://irc.freenode.net/#mapguide. You can download Chatzilla
from: http://www.hacksrus.com/~ginda/chatzilla/
.
Daniel you have been included in the PSC mailing list and the meeting
invite so that you can monitor how things progress as we strive to
satisfy our final incubation requirement.
Please let me know if the meeting time works for you and if not please
propose a new time.
Thanks,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/213b3a4a/attachment.html
From rbray at robertbray.net Mon Oct 16 19:07:42 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To: <8E468917B01800408B91984428BE03DD030D55A5@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD030D55A5@starfish.nanaimo.ca>
Message-ID: <453410BE.2040704@robertbray.net>
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/df89214e/attachment.html
From pspencer at dmsolutions.ca Mon Oct 16 21:25:13 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
Message-ID:
Jason, you hog! You've taken all the good questions ;) But I have a
couple more ...
There is nothing about requiring a quorum for voting ...
Should we allow proxy votes? I think we should state something explicit
The Change Request process has a significant gray area ... I think we
should say something about anything questionable can/should be
brought up to the PSC for a decision on whether the change requires a
change request or not. Basically, if you are not sure, ask and we
will decide.
Finally, re guiding development efforts, I think as a minimum +1
voters need to stay engaged with a particular change request ...
Cheers
Paul
On 16-Oct-06, at 6:30 PM, Jason Birch wrote:
> Hi,
>
> That IRC meeting time conflicts with OSGeo WebCom, which I'm
> chairing :( I like the time slot though; Tuesday or Thursday works
> for me on a recurring basis.
>
> Should there be a requirement that any submitted functionality come
> with a plan for funding the development, or will this be a purely
> merit-based process. If merit-based, how to we prioritise once the
> features have been let past the gate? On a funding basis? What if
> we have some funding floating around because of generous donations
> to the project?
>
> I think that the voting provision for removing members should be
> clarified, and perhaps we should consider another exit strategy in
> the case that there is a rogue member that continues to
> participate, but in a way that is counter to the goals of the
> project as a whole. And yes, my glass is half-empty.
>
> There should be some work done on a proposal template and suggested
> evaluation criteria but that's not in scope here.
>
> Jason
>
> From: Robert Bray [mailto:rbray@robertbray.net]
> Sent: Monday, October 16, 2006 14:54
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
>
> All,
>
> Welcome to the MapGuide PSC. I created this mailing list as a means
> for us to communicate as we get the PSC up and running. The mailing
> list is open to all, but I simply added this your e-mail addresses
> to get things going. Please review and comment (back to this list)
> on the PSC guidelines that can now be found at: https://
> mapguide.osgeo.org/psc.html.
>
> I would also like to propose an initial bootstrap meeting of the
> PSC on Wednesday at 2:00 PM (EST) / 12:00 PM (MST) / 11:00 AM
> (PST). The agenda for that first meeting is:
> Review and discuss the PSC Guidelines
> Development and/or PSC Meetings on IRC
> The psc vs dev mailing list. Do we need both?
> Initial PSC size and member nominations.
> As per open source custom, the meeting will be held on IRC. For IRC
> newbies Chatzilla is probably the best way to get going. It works
> with Firefox and once installed you can log onto the channel by
> pointing your browser at: irc://irc.freenode.net/#mapguide. You can
> download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.
>
> Daniel you have been included in the PSC mailing list and the
> meeting invite so that you can monitor how things progress as we
> strive to satisfy our final incubation requirement.
>
> Please let me know if the meeting time works for you and if not
> please propose a new time.
>
> Thanks,
> Bob
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Mon Oct 16 22:06:50 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F778@starfish.nanaimo.ca>
I only managed to do that because Bob posted later in the day. I'm sure you wouldn't have left me with any scraps if he'd posted earlier :)
On reflection, a lot of my questions had to do with funding, where they really should have talked about funding and/or developer time. I'm showing my work-bias here; I have been keeping consultants busy more than I've been running internal development projects recently.
Jason
________________________________
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Mon 2006-10-16 6:25 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] Bootstrapping the MapGuide PSC
Jason, you hog! You've taken all the good questions ;) But I have a
couple more ...
There is nothing about requiring a quorum for voting ...
Should we allow proxy votes? I think we should state something explicit
The Change Request process has a significant gray area ... I think we
should say something about anything questionable can/should be
brought up to the PSC for a decision on whether the change requires a
change request or not. Basically, if you are not sure, ask and we
will decide.
Finally, re guiding development efforts, I think as a minimum +1
voters need to stay engaged with a particular change request ...
Cheers
Paul
On 16-Oct-06, at 6:30 PM, Jason Birch wrote:
> Hi,
>
> That IRC meeting time conflicts with OSGeo WebCom, which I'm
> chairing :( I like the time slot though; Tuesday or Thursday works
> for me on a recurring basis.
>
> Should there be a requirement that any submitted functionality come
> with a plan for funding the development, or will this be a purely
> merit-based process. If merit-based, how to we prioritise once the
> features have been let past the gate? On a funding basis? What if
> we have some funding floating around because of generous donations
> to the project?
>
> I think that the voting provision for removing members should be
> clarified, and perhaps we should consider another exit strategy in
> the case that there is a rogue member that continues to
> participate, but in a way that is counter to the goals of the
> project as a whole. And yes, my glass is half-empty.
>
> There should be some work done on a proposal template and suggested
> evaluation criteria but that's not in scope here.
>
> Jason
>
> From: Robert Bray [mailto:rbray@robertbray.net]
> Sent: Monday, October 16, 2006 14:54
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
>
> All,
>
> Welcome to the MapGuide PSC. I created this mailing list as a means
> for us to communicate as we get the PSC up and running. The mailing
> list is open to all, but I simply added this your e-mail addresses
> to get things going. Please review and comment (back to this list)
> on the PSC guidelines that can now be found at: https://
> mapguide.osgeo.org/psc.html.
>
> I would also like to propose an initial bootstrap meeting of the
> PSC on Wednesday at 2:00 PM (EST) / 12:00 PM (MST) / 11:00 AM
> (PST). The agenda for that first meeting is:
> Review and discuss the PSC Guidelines
> Development and/or PSC Meetings on IRC
> The psc vs dev mailing list. Do we need both?
> Initial PSC size and member nominations.
> As per open source custom, the meeting will be held on IRC. For IRC
> newbies Chatzilla is probably the best way to get going. It works
> with Firefox and once installed you can log onto the channel by
> pointing your browser at: irc://irc.freenode.net/#mapguide. You can
> download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.
>
> Daniel you have been included in the PSC mailing list and the
> meeting invite so that you can monitor how things progress as we
> strive to satisfy our final incubation requirement.
>
> Please let me know if the meeting time works for you and if not
> please propose a new time.
>
> Thanks,
> Bob
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8398 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/24bf0951/attachment.bin
From rbray at robertbray.net Mon Oct 16 23:29:17 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F778@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca> <8E468917B01800408B91984428BE03DD0385F778@starfish.nanaimo.ca>
Message-ID: <45344E0D.90502@robertbray.net>
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/114a5edd/attachment.html
From rbray at robertbray.net Tue Oct 17 01:32:16 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
Message-ID: <45346AE0.6030703@robertbray.net>
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061016/bad01c1c/attachment.html
From rbray at robertbray.net Tue Oct 17 01:45:40 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To:
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca>
Message-ID: <45346E04.4070908@robertbray.net>
Paul,
I have addressed the last two comments. As for the first two that is a
little more interesting. The document is intentionally a little vague
about whether voting takes place on a mailing list or in a meeting. That
is because I have not really decided and wanted to leave it open for
discussion. MapServer primarily uses the dev list for voting. Other
projects GeoServer, GeoTools, etc use IRC meetings for voting where
having a quorum can actually be detected.
So which should approach should we use? The advantage of the e-mail
approach is that it is easier to get world representation onto the PSC
without anyone getting up in the middle of the night for a meeting. The
advantage of IRC is the interactive nature of the dialog.
Thoughts?
Bob
Paul Spencer wrote:
> Jason, you hog! You've taken all the good questions ;) But I have a
> couple more ...
>
> There is nothing about requiring a quorum for voting ...
>
> Should we allow proxy votes? I think we should state something explicit
>
> The Change Request process has a significant gray area ... I think we
> should say something about anything questionable can/should be brought
> up to the PSC for a decision on whether the change requires a change
> request or not. Basically, if you are not sure, ask and we will decide.
>
> Finally, re guiding development efforts, I think as a minimum +1
> voters need to stay engaged with a particular change request ...
>
> Cheers
>
> Paul
>
>
> On 16-Oct-06, at 6:30 PM, Jason Birch wrote:
>
>> Hi,
>>
>> That IRC meeting time conflicts with OSGeo WebCom, which I'm chairing
>> :( I like the time slot though; Tuesday or Thursday works for me on
>> a recurring basis.
>>
>> Should there be a requirement that any submitted functionality come
>> with a plan for funding the development, or will this be a purely
>> merit-based process. If merit-based, how to we prioritise once the
>> features have been let past the gate? On a funding basis? What if
>> we have some funding floating around because of generous donations to
>> the project?
>>
>> I think that the voting provision for removing members should be
>> clarified, and perhaps we should consider another exit strategy in
>> the case that there is a rogue member that continues to participate,
>> but in a way that is counter to the goals of the project as a whole.
>> And yes, my glass is half-empty.
>>
>> There should be some work done on a proposal template and suggested
>> evaluation criteria but that's not in scope here.
>>
>> Jason
>>
>> From: Robert Bray [mailto:rbray@robertbray.net]
>> Sent: Monday, October 16, 2006 14:54
>> To: psc@mapguide.osgeo.org
>> Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
>>
>> All,
>>
>> Welcome to the MapGuide PSC. I created this mailing list as a means
>> for us to communicate as we get the PSC up and running. The mailing
>> list is open to all, but I simply added this your e-mail addresses to
>> get things going. Please review and comment (back to this list) on
>> the PSC guidelines that can now be found at:
>> https://mapguide.osgeo.org/psc.html.
>>
>> I would also like to propose an initial bootstrap meeting of the PSC
>> on Wednesday at 2:00 PM (EST) / 12:00 PM (MST) / 11:00 AM (PST). The
>> agenda for that first meeting is:
>> Review and discuss the PSC Guidelines
>> Development and/or PSC Meetings on IRC
>> The psc vs dev mailing list. Do we need both?
>> Initial PSC size and member nominations.
>> As per open source custom, the meeting will be held on IRC. For IRC
>> newbies Chatzilla is probably the best way to get going. It works
>> with Firefox and once installed you can log onto the channel by
>> pointing your browser at: irc://irc.freenode.net/#mapguide. You can
>> download Chatzilla from: http://www.hacksrus.com/~ginda/chatzilla/.
>>
>> Daniel you have been included in the PSC mailing list and the meeting
>> invite so that you can monitor how things progress as we strive to
>> satisfy our final incubation requirement.
>>
>> Please let me know if the meeting time works for you and if not
>> please propose a new time.
>>
>> Thanks,
>> Bob
>
> +-----------------------------------------------------------------+
> |Paul Spencer pspencer@dmsolutions.ca |
> +-----------------------------------------------------------------+
> |Chief Technology Officer |
> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
From rbray at robertbray.net Tue Oct 17 01:52:19 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
Message-ID: <45346F93.3020102@robertbray.net>
All,
I have update the text with some of Jason and Paul's initial comments
(look for [Updated 10/16/2006] for the updated sections). See my
responses to their e-mail where further discussion is still required. As
for an updated meeting time (since Jason has a conflict), how about:
Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
Does that work for everyone?
FYI - I'll be in Ottawa for that one.
Thanks,
Bob
From pspencer at dmsolutions.ca Tue Oct 17 07:54:35 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC
In-Reply-To: <45344E0D.90502@robertbray.net>
References: <8E468917B01800408B91984428BE03DD030D55A3@starfish.nanaimo.ca> <8E468917B01800408B91984428BE03DD0385F778@starfish.nanaimo.ca> <45344E0D.90502@robertbray.net>
Message-ID: <29473D0B-6456-4476-A933-72D6CD96EA42@dmsolutions.ca>
Bob,
I don't think this needs to be covered right now.
Re ADSK contributions, I didn't even think to ask! What you are
saying makes sense and if I'd been asked about it, I would have
probably assumed that was the case.
Paul
On 16-Oct-06, at 11:29 PM, Robert Bray wrote:
> Funding is an interesting one. In most projects I have been
> involved with or researched recently, the party that brings the
> request forward funds its development (or does it him/her self). We
> should discuss this one some more and consider how we accept
> donations for development as per the foundation. I'd like to make
> that future item for consideration by the PSC at this point, unless
> someone objects and wants to cover it as part of this document.
>
> Neither of you ask what about Autodesk contributions? To me they
> (wow now there is a typo) are now like everyone else, if we want
> something done we need to bring a proposal forth, get it approved,
> and be prepared to develop it.
>
> I'll work in the comments received so far and make another pass,
> somehow highlighting the changes.
>
> Thanks for the great comments guys...
>
> Bob
>
> Jason Birch wrote:
>> I only managed to do that because Bob posted later in the day. I'm
>> sure you wouldn't have left me with any scraps if he'd posted
>> earlier :) On reflection, a lot of my questions had to do with
>> funding, where they really should have talked about funding and/or
>> developer time. I'm showing my work-bias here; I have been keeping
>> consultants busy more than I've been running internal development
>> projects recently. Jason ________________________________ From:
>> Paul Spencer [mailto:pspencer@dmsolutions.ca] Sent: Mon 2006-10-16
>> 6:25 PM To: psc@mapguide.osgeo.org Subject: Re: [mapguide-psc]
>> Bootstrapping the MapGuide PSC Jason, you hog! You've taken all
>> the good questions ;) But I have a couple more ... There is
>> nothing about requiring a quorum for voting ... Should we allow
>> proxy votes? I think we should state something explicit The Change
>> Request process has a significant gray area ... I think we should
>> say something about anything questionable can/should be brought up
>> to the PSC for a decision on whether the change requires a change
>> request or not. Basically, if you are not sure, ask and we will
>> decide. Finally, re guiding development efforts, I think as a
>> minimum +1 voters need to stay engaged with a particular change
>> request ... Cheers Paul On 16-Oct-06, at 6:30 PM, Jason Birch wrote:
>>> Hi, That IRC meeting time conflicts with OSGeo WebCom, which I'm
>>> chairing :( I like the time slot though; Tuesday or Thursday
>>> works for me on a recurring basis. Should there be a requirement
>>> that any submitted functionality come with a plan for funding the
>>> development, or will this be a purely merit-based process. If
>>> merit-based, how to we prioritise once the features have been let
>>> past the gate? On a funding basis? What if we have some funding
>>> floating around because of generous donations to the project? I
>>> think that the voting provision for removing members should be
>>> clarified, and perhaps we should consider another exit strategy
>>> in the case that there is a rogue member that continues to
>>> participate, but in a way that is counter to the goals of the
>>> project as a whole. And yes, my glass is half-empty. There should
>>> be some work done on a proposal template and suggested evaluation
>>> criteria but that's not in scope here. Jason From: Robert Bray
>>> [mailto:rbray@robertbray.net] Sent: Monday, October 16, 2006
>>> 14:54 To: psc@mapguide.osgeo.org Subject: [mapguide-psc]
>>> Bootstrapping the MapGuide PSC All, Welcome to the MapGuide PSC.
>>> I created this mailing list as a means for us to communicate as
>>> we get the PSC up and running. The mailing list is open to all,
>>> but I simply added this your e-mail addresses to get things
>>> going. Please review and comment (back to this list) on the PSC
>>> guidelines that can now be found at: https:// mapguide.osgeo.org/
>>> psc.html. I would also like to propose an initial bootstrap
>>> meeting of the PSC on Wednesday at 2:00 PM (EST) / 12:00 PM
>>> (MST) / 11:00 AM (PST). The agenda for that first meeting is:
>>> Review and discuss the PSC Guidelines Development and/or PSC
>>> Meetings on IRC The psc vs dev mailing list. Do we need both?
>>> Initial PSC size and member nominations. As per open source
>>> custom, the meeting will be held on IRC. For IRC newbies
>>> Chatzilla is probably the best way to get going. It works with
>>> Firefox and once installed you can log onto the channel by
>>> pointing your browser at: irc://irc.freenode.net/#mapguide. You
>>> can download Chatzilla from: http://www.hacksrus.com/~ginda/
>>> chatzilla/. Daniel you have been included in the PSC mailing list
>>> and the meeting invite so that you can monitor how things
>>> progress as we strive to satisfy our final incubation
>>> requirement. Please let me know if the meeting time works for you
>>> and if not please propose a new time. Thanks, Bob
>> +-----------------------------------------------------------------
>> + |Paul Spencer pspencer@dmsolutions.ca |
>> +-----------------------------------------------------------------
>> + |Chief Technology Officer | |DM Solutions Group Inc http://
>> www.dmsolutions.ca/ |
>> +-----------------------------------------------------------------+
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From tom.fukushima at autodesk.com Tue Oct 17 10:59:10 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
References: <45346F93.3020102@robertbray.net>
Message-ID:
That works for me.
Tom
-----Original Message-----
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Mon 2006/10/16 23:52
To: psc@mapguide.osgeo.org
Cc:
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
All,
I have update the text with some of Jason and Paul's initial comments
(look for [Updated 10/16/2006] for the updated sections). See my
responses to their e-mail where further discussion is still required. As
for an updated meeting time (since Jason has a conflict), how about:
Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
Does that work for everyone?
FYI - I'll be in Ottawa for that one.
Thanks,
Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4166 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061017/10d692d3/attachment.bin
From pspencer at dmsolutions.ca Tue Oct 17 11:36:26 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: regular meeting time
Message-ID:
Bob,
is Thursday 2PM EST going to be the regular meeting time?
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From amorsell at spatialgis.com Tue Oct 17 12:45:25 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
In-Reply-To: <45346F93.3020102@robertbray.net>
Message-ID: <00be01c6f20b$a5a93650$6501a8c0@SPINAJM>
All,
I apologize, but I will not be able to attend the meeting. I am working
on-site at a client all this week.
Thanks,
Andy
-----Original Message-----
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Monday, October 16, 2006 10:52 PM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
All,
I have update the text with some of Jason and Paul's initial comments (look
for [Updated 10/16/2006] for the updated sections). See my responses to
their e-mail where further discussion is still required. As for an updated
meeting time (since Jason has a conflict), how about:
Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
Does that work for everyone?
FYI - I'll be in Ottawa for that one.
Thanks,
Bob
From Jason.Birch at nanaimo.ca Wed Oct 18 01:33:45 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
References: <45346F93.3020102@robertbray.net>
Message-ID: <8E468917B01800408B91984428BE03DD0385F784@starfish.nanaimo.ca>
I'll be there this Thursday, but the following Thursday I'll be in Vancouver for a regional MapGuide users group meeting. Anybody going to be in town and want to come? :)
I'm also wondering if the change request process will be the only mechanism that determines the roadmap, or if there will be some kind of strategic planning mechanism so that we don't end up with patchwork...
Jason
________________________________
From: Robert Bray [@robertbray.net]
Sent: Mon 2006-10-16 10:52 PM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
All,
I have update the text with some of Jason and Paul's initial comments
(look for [Updated 10/16/2006] for the updated sections). See my
responses to their e-mail where further discussion is still required. As
for an updated meeting time (since Jason has a conflict), how about:
Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
Does that work for everyone?
FYI - I'll be in Ottawa for that one.
Thanks,
Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4160 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061017/7df627dd/attachment.bin
From rbray at robertbray.net Wed Oct 18 12:35:13 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F784@starfish.nanaimo.ca>
References: <45346F93.3020102@robertbray.net> <8E468917B01800408B91984428BE03DD0385F784@starfish.nanaimo.ca>
Message-ID: <453657C1.1040209@robertbray.net>
All,
I have posted an agenda for the meeting on the OSGeo wiki, it can be
found here:
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006. Feel
free to add agenda items.
I'll try and make one more pass at the PSC document today, so please
give it another read tomorrow morning. Andy it is unfortunate you are
not available this week, but I think the PSC should meet anyway. Please
post any comments you have on the doc to the mailing list and we will
strive to work them in.
Thanks,
Bob
Jason Birch wrote:
>
> I'll be there this Thursday, but the following Thursday I'll be in Vancouver for a regional MapGuide users group meeting. Anybody going to be in town and want to come? :)
>
> I'm also wondering if the change request process will be the only mechanism that determines the roadmap, or if there will be some kind of strategic planning mechanism so that we don't end up with patchwork...
>
> Jason
>
> ________________________________
>
> From: Robert Bray [@robertbray.net]
> Sent: Mon 2006-10-16 10:52 PM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
>
>
>
> All,
>
> I have update the text with some of Jason and Paul's initial comments
> (look for [Updated 10/16/2006] for the updated sections). See my
> responses to their e-mail where further discussion is still required. As
> for an updated meeting time (since Jason has a conflict), how about:
>
> Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
>
> Does that work for everyone?
>
> FYI - I'll be in Ottawa for that one.
>
> Thanks,
> Bob
>
>
>
From Jason.Birch at nanaimo.ca Wed Oct 18 14:02:29 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: Changes to IRC
Message-ID: <8E468917B01800408B91984428BE03DD030D55DA@starfish.nanaimo.ca>
I made some minor changes to the IRC page meeting info:
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006#Meeting_
Info
Jason
From amorsell at spatialgis.com Wed Oct 18 17:19:02 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
In-Reply-To: <453657C1.1040209@robertbray.net>
Message-ID: <00d501c6f2fb$09789b90$46f9fe0a@SPINAJM>
Hi All,
My client where I am on-site this week is kindly letting me take some time
to participate in this meeting. I will see you on IRC tomorrow morning.
Andy
-----Original Message-----
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Wednesday, October 18, 2006 9:35 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
All,
I have posted an agenda for the meeting on the OSGeo wiki, it can be found
here:
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006. Feel free
to add agenda items.
I'll try and make one more pass at the PSC document today, so please give it
another read tomorrow morning. Andy it is unfortunate you are not available
this week, but I think the PSC should meet anyway. Please post any comments
you have on the doc to the mailing list and we will strive to work them in.
Thanks,
Bob
Jason Birch wrote:
>
> I'll be there this Thursday, but the following Thursday I'll be in
> Vancouver for a regional MapGuide users group meeting. Anybody going
> to be in town and want to come? :)
>
> I'm also wondering if the change request process will be the only
mechanism that determines the roadmap, or if there will be some kind of
strategic planning mechanism so that we don't end up with patchwork...
>
> Jason
>
> ________________________________
>
> From: Robert Bray [@robertbray.net]
> Sent: Mon 2006-10-16 10:52 PM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] Bootstrapping the MapGuide PSC - Revised
>
>
>
> All,
>
> I have update the text with some of Jason and Paul's initial comments
> (look for [Updated 10/16/2006] for the updated sections). See my
> responses to their e-mail where further discussion is still required.
> As for an updated meeting time (since Jason has a conflict), how about:
>
> Thursday 10/19 - 1 PM EST / 11 AM MST / 10 AM PST
>
> Does that work for everyone?
>
> FYI - I'll be in Ottawa for that one.
>
> Thanks,
> Bob
>
>
>
From Jason.Birch at nanaimo.ca Thu Oct 19 14:04:47 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: MapGuide PSC nomination
Message-ID: <8E468917B01800408B91984428BE03DD030D5607@starfish.nanaimo.ca>
Hi Haris,
Would you be interested in standing nomination for the MapGuide Open
Source project steering committee?
Jason
From pspencer at dmsolutions.ca Thu Oct 19 14:34:53 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: irc transcript
Message-ID: <78CCD09F-FED4-4230-84F2-8892E8E3F7C1@dmsolutions.ca>
attached.
-------------- next part --------------
[12:55p] danmo joined the chat room.
[12:55p] jasonbirch joined the chat room.
[12:56p] jasonbirch : Hi all
[12:56p] pagameba : Hi jasonbirch
[12:57p] danmo : Hola
[12:59p] TomF joined the chat room.
[1:00p] bdechant joined the chat room.
[1:00p] Andy_Morsell joined the chat room.
[1:00p] brayr joined the chat room.
[1:02p] brayr : Welcome
[1:02p] jasonbirch : Thanks.Ê Is there a logging service for #mapguide?Ê Perhaps qgis could help?
[1:02p] Andy_Morsell : Hello.
[1:02p] TomF : Hi
[1:02p] bdechant : Hi
[1:02p] pagameba : hi
[1:03p] brayr : No not at the moment. That is one of the things we need to sort out. Logging.
[1:03p] brayr:I am an IRC newbie, so help would be appreciated.
[1:04p] brayr:Looks like everyone is here. So let's start with the first item on the agenda.
[1:04p] brayr:I did not get to make another pass at the document this morning (as you probably noticed).
[1:04p] brayr:There was a couple of things in the e-mails I want to work in.
[1:05p] brayr:First is the PSCs responsibility for defining a RoadMap. (thanks Jason)
[1:06p] brayr:My thinking is that the roadmap would help guide some of the feature decisions. Thoughts?
[1:06p] pagameba : I agree
[1:06p] jasonbirch : Agreed.Ê Obviously, Autodesk has some plans for the product.Ê Can we see those plans and use to help bootsttrap our roadmap?
[1:06p] Andy_Morsell : Would this be more high-level, or very feature specific?Ê Didn't Sean Sternfeldt start something that is still posted on the Wiki?
[1:06p] jasonbirch : That's a wishlist.Ê Diffferent beast.
[1:07p] brayr : yes, we can certainly bootstrap the process with our internal roadmap. But I would really lilke this group to take some ownership and supply inout.
[1:08p] brayr:input
[1:08p] jasonbirch : not just input, control.Ê Control ControlÊ (sorry, got carried away)
[1:08p] pagameba : How specific do you see the road map being?
[1:08p] brayr : yes that is really what I meant.
[1:09p] pagameba : and will we use the roadmap to seek contributions (funding, code etc)
[1:09p] brayr : Long term roadmaps tend to be theme driven. Short term, e.g next release are more specific.
[1:09p] brayr:Yes
[1:09p] pagameba : ok
[1:09p] jasonbirch : I think there are two categories.Ê Architectural change, and feature implementation.Ê Big features should be in roadmap
[1:10p] brayr : Yes, roadmaps are about big features. Things like Geocoding, or WCS, or ...
[1:11p] jasonbirch : Do changes drive architecture, or do we identify inefficiencies and do architectural change as features when required?
[1:11p] brayr : Could be both.
[1:12p] brayr:I think at this point, architecture is mostly feature driven.
[1:12p] brayr:But there may come a day when that is not true.
[1:12p] brayr:So I'll draft a section on roadmap and then we can iteratate.
[1:13p] jasonbirch : Sounds great.
[1:13p] brayr : Another item in the doc is Process.
[1:13p] jasonbirch : Out of left field... Version numbers. 1.1 is development, 1.2 is release, etc?
[1:13p] brayr : The doc did not clarify if decisions are made and voted on at a meeting like this or the mailing list.
[1:14p] brayr:NO
[1:14p] brayr:I really do not like the even odd thing. Let's table that for a future meeting and we can sort it out.
[1:14p] jasonbirch : OK.
[1:14p] jasonbirch:Do we need quorum?Ê If not, email vote should be fine.
[1:14p] Andy_Morsell : It seems like voting via mail list would be the best as not everyone will always be able to attend each meeting.
[1:14p] brayr : So do we want all decisions made in an IRC meeting or via e-mail, or leave it open for both
[1:15p] brayr:I like e-mail because of timezones, travel, etc.
[1:15p] pagameba : it is sometimes more efficient to do it in an IRC meeting ... how about ...
[1:15p] jasonbirch : And because of lasting record.Ê But that shouldn't prevent us frmo making decisions inÊ IRC
[1:15p] pagameba : if we have a quorum at a meeting (2/3) then we can make a decision
[1:16p] jasonbirch : Sounds reasonable to me.
[1:16p] brayr : That makes sense.
[1:16p] Andy_Morsell : Sounds reasonable
[1:16p] pagameba : but there is an opportunity for the non-participants to veto within x days
[1:16p] jasonbirch : 24 hours so we don't get surprised.
[1:16p] brayr : Yea, it needs to be pretty short.
[1:16p] jasonbirch : after putting in lots of work
[1:17p] brayr : Any decision made in IRC needs to be broadcast via e-mail.
[1:17p] brayr:24 hours from the e-mail seems right.
[1:17p] pagameba : I like it
[1:17p] jasonbirch : I think that the email should be a courtesy, and official from posting of minutes.
[1:18p] jasonbirch:Email is not all that reliable, so members need to take responsibility to check minutes.
[1:18p] brayr : yea that is fine. But I know many people read minutes in spare cycles, but e-mail regularly.
[1:18p] brayr:Its the old push / pull thing
[1:18p] Andy_Morsell : I would like to see minutes emailed and posted
[1:19p] pagameba : I have another process question
[1:19p] jasonbirch : Agreed, but it pervents the "I never got that email" argument.Ê Agreed Andy.
[1:19p] brayr : Yea I like Andy's suggestion.
[1:19p] brayr:Ok, I'll draft that in as well.
[1:19p] brayr : Ask away Paul.
[1:19p] pagameba : MapServer has a TSC as opposed to a PSC ..
[1:20p] pagameba:it makes technical decisions
[1:20p] brayr : They are moving to a PSC. Is that correct Daniel?
[1:20p] pagameba : should we have the concept of a TSC that includes all committers
[1:20p] brayr : I am not sure they intend to keep the TSC.
[1:20p] pagameba : PSC + committers
[1:20p] jasonbirch : That's just elitist bunk (grin)Ê I want to be involved in technical decisions even though I'm not a developer
[1:21p] pagameba : PSC + committers
[1:21p] jasonbirch : Oh :)
[1:21p] brayr : The real question here is "does the commiter community get a vote"
[1:21p] pagameba : I'm just thinking that committers may have some valid input/concerns over purely technical issues that currently the PSC would vote on
[1:21p] jasonbirch : I think that we should be able to refer items to the dev@ list for discussion, but retain final decision.
[1:21p] pagameba : yes, exactly !!!
[1:22p] brayr : Well here is a good question. Should the PSC mailing list go away, and all PSC communication happen on dev?
[1:22p] jasonbirch : Or, all technical discussion on the dev list, and process on psc
[1:22p] brayr : Could do
[1:22p] jasonbirch : separate functions. I think anyway.
[1:22p] pagameba : I'm worried that Jason will push for things that are hard to do ;)
[1:22p] jasonbirch : Lol, bad experiences Paul?
[1:22p] pagameba : lol ... no, I swear!
[1:23p] brayr : That is the role of a user in the PSC IMO
[1:23p] brayr:To push
[1:23p] pagameba : I like having separate lists
[1:23p] brayr : Or part of the role anyway. Also to bring balance and end user perspective to decisions
[1:23p] danmo : sorry for the delayed answer... yes the MapServer PSC will *replace* the TSC.
[1:24p] jasonbirch : Let's keep em separated. (hmmm, now I have a song stuck in my head)
[1:24p] brayr : Thanks Daniel!
[1:24p] Andy_Morsell : Separate lists.Ê I have not participated in the dev list to date, but will obviously have to at least start reading the messages.
[1:24p] pagameba : ok ... I would be happy if the process document says that the PSC advertises for comments on the dev list prior to making a decision
[1:24p] jasonbirch : Not much activity yet.
[1:24p] brayr : OK so Process on PSC, development of features, technical stuff on DEV
[1:24p] Andy_Morsell : Jason - a closet Offspring fan?
[1:25p] jasonbirch : Fraid so.
[1:25p] brayr : Yes I would agree. Any technical item, feature request, etc gets floated on DEV
[1:25p] jasonbirch : Sounds good.Ê Do we have to vote? :)
[1:25p] pagameba : +!
[1:25p] brayr : My concern is that we will see a lot of cross postings.
[1:25p] pagameba : +1
[1:26p] brayr : +! is that a new type of dictorial decision?
[1:26p] pagameba : lol
[1:26p] jasonbirch : it's an override :)
[1:26p] brayr : Yes lets vote on that. DEV for technical, PSC for process. All technical stuff gets floated on DEV.
[1:26p] brayr:+1
[1:27p] jasonbirch : +1
[1:27p] TomF : +1
[1:27p] bdechant : +1
[1:27p] Andy_Morsell : +1
[1:27p] brayr : Done. I'll draft that in as well.
[1:28p] jasonbirch : The dev list has been pretty quiet.Ê Will that change asn this moves to be more of a community project?
[1:28p] brayr : Yes. It is quiet IMO because ADSK does most development. That has to change
[1:28p] danmo : ¥ danmo just joined the -dev list and didn't see much activity yet, but I think -dev becoming more alive will be a requirement for graduation from OSGeo incubation
[1:29p] brayr : That makes sense.
[1:30p] pagameba : The various project tracking lists are reasonably busy :)
[1:30p] jasonbirch : Bob, will all Autodesk developers be encouraged/allowed to take a community role, or will they be in a contracted employee role?
[1:30p] brayr : Any objection to me moving the addition and remoaval of members to the process section. Similar to MapServer TSC/PSC doc?
[1:30p] jasonbirch : No objection
[1:30p] pagameba : no
[1:30p] Andy_Morsell : No objection
[1:30p] brayr : They will be encouraged to take a community type of role.
[1:31p] brayr:All ADSK development will be floated via RFC and discussed in dev.
[1:31p] pagameba : like Traian :)
[1:31p] brayr : yea
[1:31p] jasonbirch : lol
[1:31p] brayr : Let me just say it is not easy to break old habits.
[1:32p] brayr:OK, I will move the addition/removal of members to Process.
[1:32p] pagameba : for RFCs is there a format?
[1:33p] jasonbirch : We need to work on one, with suggested elements, etc.
[1:33p] brayr : We need to create one.
[1:33p] brayr:yea
[1:33p] brayr:Let's get this doc settled first. Then move on to that. We should make a list on the Wiki of things to do.
[1:33p] jasonbirch : Let's spend some time on that in the interimand flesh it out at next week's meeting (I won't be here)
[1:34p] brayr : Nice
[1:34p] Andy_Morsell : Is this the regular day and time for the meeting then?
[1:34p] brayr : That is next on the agenda. Meetings.
[1:34p] brayr : Anything else on the document before we move on?
[1:34p] Andy_Morsell : Sorry to jump ahead......
[1:34p] brayr : Np
[1:35p] brayr:Going once.
[1:35p] jasonbirch : I'm happy with the doc.Ê Weekly meetings always going to be required, or weekly to start and then biweekly?Ê If we don't have to make decisions in meetings...
[1:35p] brayr : Ok, I'll update the doc and we'll discuss/approve on the mailing list.
[1:36p] brayr:That is the first question. How often should the PSC meet?
[1:36p] brayr:On IRC that is
[1:36p] Andy_Morsell : Is every two weeks not enough?
[1:37p] brayr : I propose weekly or bi-weeekly until we get things running, then we decide.
[1:37p] jasonbirch : I think that biweekly should be fine, especially since decisions can and generally willÊ be made via email.Ê But weekly for the first month or so.
[1:37p] brayr : +1
[1:38p] Andy_Morsell : +1
[1:38p] jasonbirch : I have to jump through major hoops to get on IRC from work, so can't always be tuned in.Ê Prefer email.
[1:38p] jasonbirch:+1
[1:38p] pagameba : +1
[1:38p] bdechant : +1
[1:39p] brayr : I prefer e-mail as well, so long term I would prefer we mostly operate by e-mail. This is bootstrap time.
[1:39p] brayr:Now for a bigger question. What about DEV meetings.
[1:39p] brayr:Should dev meet weekly by IRC?
[1:39p] pagameba : being a developer, I would say yes :)
[1:40p] brayr : Might force more of an open communication than we are seeing now.
[1:40p] TomF : yeah, I prefer email
[1:40p] jasonbirch : Do you have any problems with corporate firewall Bob?
[1:40p] brayr : No
[1:41p] Andy_Morsell : I agree.Ê But, would it be expected for PSC members to attend each?Ê Or would reviewing the DEV minutes be sufficent?Ê I'm having trouble understanding where the roles overlap.
[1:41p] brayr : e-mail would be fine, but again we are just not using DEV today as much as we should be.
[1:41p] jasonbirch : I don't think that it should be required for PSC to participate in DEV.Ê Just know what's going on enough to vote and guide development of features they have voted on.
[1:42p] brayr : Good question. I think PSC members who are commiters would have to attend the dev meeting.
[1:42p] brayr:Other PSC members optional/
[1:43p] jasonbirch : 2 daytime meetings a week might be a bit of a burden...
[1:43p] Andy_Morsell : OK.Ê But, part of our decisions are based on the DEV discussions and that would only come during the formal change submittal process?
[1:43p] brayr : yes.
[1:44p] jasonbirch : Yes, we will take guidance from DEV of feasibility, but changes will come through process.
[1:44p] brayr : I agree 2 meetings is a lot, but the PSC one will go away I think.
[1:44p] Andy_Morsell : Thanks for the clarification.Ê In case you hadn't noticed, I'm a bit new to this.
[1:44p] brayr : You are not the only one.
[1:44p] jasonbirch : Yes, at some point PSC IRC as required only.
[1:45p] jasonbirch:Yikes, I think we're on schedule...
[1:45p] brayr : yea, so it is really one meeting. The issue I have with IRC is more around timezones. It's hard to get good world-wide involvement via IRC.
[1:46p] brayr:Let's try a couple of dev meetings and see how they go.
[1:46p] jasonbirch : After we get the roadmap?
[1:46p] brayr : Some of this will be an iterative learning process.
[1:46p] jasonbirch : And maybe some techincal feature requests?
[1:46p] jasonbirch:Need to have something to meet ABOUT
[1:46p] brayr : yea, I don't think starting now makes much sense.
[1:47p] brayr:So does this time work for everyone? For the initial PSC meetings anyway?
[1:47p] pagameba : +1
[1:47p] jasonbirch : +1
[1:47p] bdechant : +1
[1:47p] Andy_Morsell : +1
[1:47p] TomF : +1
[1:48p] brayr : Ok, next topic. Initial PSC size.
[1:48p] jasonbirch : The voting structure doesn't require tie breakers.
[1:48p] brayr : We are at 6, need a seventh. Should we go straight to 9?
[1:48p] jasonbirch : Why seven?
[1:48p] brayr : I like odd numbers, just in case we all vote.
[1:48p] brayr:It is not strictly required.
[1:49p] Andy_Morsell : I like 7
[1:49p] jasonbirch : I think we should see where the project goes and keep it small at first.Ê That allows merit-based expansion.Ê Unless you have someone in mind?
[1:49p] danmo : I would tend to agree with jasonbirch on keeping room for adding people once the project gets going
[1:50p] brayr : I have one nomination in mind. I also would like some non North American input/involvement.
[1:51p] jasonbirch : Good idea.Ê Is +1 enough for now, and a commitment to add two more before leaving incubation?
[1:51p] brayr : I don't even know that we need one or two more before leaving. MapBuilder is seven I think.
[1:51p] brayr:But +1 for now seems right to me.
[1:52p] danmo : pagameba: is there minimum PSC size required by incubation? I personally think that 7 should be enough
[1:52p] pagameba : there is not a minimum required
[1:52p] brayr : Any nominations out there?
[1:52p] pagameba : smaller is better for actually achieving concensus
[1:52p] jasonbirch : I guess what I meant, is 1 enough for your desired global inclusion Bob?
[1:52p] brayr : No0
[1:53p] brayr:But it could be.
[1:53p] pagameba : who do you have in mind, Bob?
[1:53p] brayr : I am fine to stay small ongoing. Like no more than 9.
[1:53p] brayr:Traian.
[1:54p] Andy_Morsell : Any more than 9 and it starts getting unmanagable
[1:54p] danmo : Is Traian with ADSK? And how many ADSK people would that make on the PSC?
[1:54p] brayr : His input, involvement, and code contribution are huge. At ADSK he now longer works on the project, nut has stayed involved.
[1:54p] danmo : (not objecting, just wondering at this point)
[1:54p] brayr : nut = but
[1:55p] Andy_Morsell : Well, get him back on the project! ;)
[1:55p] pagameba : +1
[1:55p] brayr : danmo: You hit one of my concerns on the head.
[1:55p] pagameba : :)
[1:55p] pagameba:what about including an FDO person?
[1:55p] jasonbirch : I personally feel that Traian would be a GREAT addition.Ê There would be 4 ADSK on the committee at that point.
[1:55p] brayr : That would make the PSC ADSK, three external.
[1:55p] pagameba : like Haris?
[1:56p] jasonbirch : Or Mateusz
[1:56p] pagameba : Haris has expressed interest in doing some WebStudio stuff
[1:56p] brayr : Haris would be a good addition. I plan to nominate him for the FDO PSC.
[1:56p] pagameba : :)
[1:56p] pagameba:Perhaps because of the close ties, we should plan for 1 member to be on both ...
[1:56p] brayr : There are a couple others on the mailing list as well that are very active users.
[1:56p] Andy_Morsell : Haris would be good.Ê He's obviously extremely smart.Ê Yes, maybe more suitable for the FDO PSC.
[1:57p] jasonbirch : If he's interested in MapGuide it would be great to haveÊ non ADSK liason between the two as well
[1:57p] brayr : Yes. Right now I am the only liason.
[1:57p] Andy_Morsell : Good point Jason
[1:57p] jasonbirch : Need to be joined at the mind as well as the hip :)
[1:57p] pagameba : So we have Mateusz, Haris and Traian as possibilities, plus potential from the user's list
[1:58p] danmo : I think that with respect to incubation and for the appearance of independance from ADSK, you should not add more ADSK people at this point... that would definitely help prevent any objections when time comes to graduate from incubation
[1:58p] brayr : We are just about out of time. Let's table this and discuss agian next week. We should farm the list for candidates.
[1:58p] pagameba : +1
[1:58p] jasonbirch : +1
[1:58p] brayr : Alright, that excludes Traian
[1:58p] Andy_Morsell : +1
[1:58p] pagameba : unless we go to 9 :)
[1:59p] bdechant : +1
[1:59p] brayr : So bring your list to the table next week. Requirements are non-ADSK, significant contribution as a user on the list.
[1:59p] brayr:I vote to wait on 9 until after we are moving
[1:59p] jasonbirch : Sounds good Bob.
[1:59p] TomF : yes, maybe there's other ways to get Traian involved again
[1:59p] jasonbirch : I would like to see it be a developer though.
[2:00p] brayr : Let's consider re-visiting expansion in one month.
[2:00p] Andy_Morsell : Agreed.Ê
[2:00p] danmo : is non-north-american still a plus?
[2:00p] jasonbirch : Yes,
[2:00p] Andy_Morsell : Yes. A bit of a side-track, but I'm curious where everyone is right now? Geographic distribution and all......
[2:00p] brayr : I think so, that would make Haris a prime candidate.
[2:00p] TomF : Calgary
[2:00p] brayr : All Canada + 1 US
[2:00p] danmo : Chicoutimi, Quebec
[2:00p] brayr : Calgary
[2:01p] bdechant : Calgary
[2:01p] pagameba : Ottawa
[2:01p] danmo : (not on the PSC though... sorry for the noise)
[2:01p] jasonbirch : Beautiful downtown Nanaimo, BC, Canada.Ê I thought you were in Ottawa Bob? :)
[2:01p] brayr : np
[2:01p] Andy_Morsell : Fairbanks, Alaska at a client.Ê 10:00 am right now.
[2:01p] brayr : Well I am at the moment, but normally Calgary.
[2:01p] jasonbirch : OK, we need to go after some canadian government funding :)
[2:02p] brayr : Developers are scarce at the moment. Like I said, bring your nominations next week. Jason you could e-mail me yours.
[2:02p] pagameba : or municipal funding!
[2:02p] jasonbirch : mmm, aren't I working hard enough on that?
[2:02p] pagameba : lol ... of course you are
[2:03p] brayr : That's our time for this week. I'll set up an agenda for next week and post a message when the process doc is updated.
[2:03p] jasonbirch : +1 for adjournment
[2:03p] pagameba : +1
[2:03p] Andy_Morsell : +1 see you next week
[2:03p] brayr : +1
[2:03p] brayr:Thanks everyone.
[2:04p] Andy_Morsell left the chat room. ("Chatzilla 0.9.75
[Firefox 1.5.0.4/2006050817]")
[2:04p] TomF left the chat room. ("Chatzilla 0.9.75
[Firefox 1.5.0.7/2006090918]")
[2:04p] pagameba : Bob ... can you call me?
[2:05p] bdechant left the chat room. ("Chatzilla 0.9.75
[Firefox 1.5.0.7/2006090918]")
[2:05p] brayr : Sure
[2:05p] jasonbirch : ¥ jasonbirch waves goodbye
[2:05p] jasonbirch left the chat room. ("Chatzilla 0.9.73
[Firefox 1.5.0.7/2006090918]")
[2:07p] brayr left the chat room. ("Chatzilla 0.9.70
[Firefox 1.5.0.7/2006090918]")
[2:10p] danmo left the chat room.
-------------- next part --------------
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Fri Oct 20 01:37:12 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] irc transcript
References: <78CCD09F-FED4-4230-84F2-8892E8E3F7C1@dmsolutions.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7A2@starfish.nanaimo.ca>
I posted an edited version of these and what I could discern of the resolutions/actions/carryforwards to the meeting wiki page.
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006
________________________________
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Thu 2006-10-19 11:34 AM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] irc transcript
attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3330 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061019/b33c7b92/attachment.bin
From pspencer at dmsolutions.ca Fri Oct 20 08:45:10 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: road map planning
Message-ID:
All,
I'm keen to lay out the framework for a road map for MGOS. I have a
few suggestions to help us get organised. Primarily I think the road
map should be organised around the planned release schedule and
versions. Central to my proposal is the concept of version
numbering. We do need to have a version numbering discussion, so
I'll lay out my thoughts here.
A MGOS version number consists of 3 numeric fields separated by a
period, X.Y.Z . X is the major version number, Y is the minor
version number and Z is the bugfix release number. Version numbers
can be tagged with a descriptive title as well, for instance BETA or
RELEASE CANDIDATE.
Rules for changing version numbers on release need to be established,
here is my first cut at it (but it will need to be fleshed out some
more):
* Changes to the major version number happen when the software
undergoes substantial architectural changes and/or has a substantial
set of new features.
* Changes to the minor version number happen when the software
undergoes minor architectural changes, improved performance and
stability, some new features, or any changes to the existing
published API.
* Changes to the bugfix release number happen for bug fixes and
trivial changes.
Version numbers can be useful when laying out a road map, if we look
at the road map as a series of releases. The PSC can, at a high
level, agree on a release schedule and slot features etc into the
appropriate slots.
Timing of releases can be planned around the release numbers. I
propose that we adopt the MapServer release strategy, which is as
follows:
1. Release a minor version approximately every 6 months regardless of
what has been done. This has several advantages which I will only
bring up if the group disagrees with this strategy :)
2. Bug fix releases are then done approximately 'whenever' ...
essentially as often as needed, but typically one release within a
month or two of the minor release and then maybe one more before the
next minor release - depends on the stability of the software and the
criticality of the bug fix - sometimes MapServer waits to accumulate
several minor bugfixes and sometimes they release with only one major
bugfix.
3. Major version releases happen irregularly and depend on actual
features implemented. Essentially, enough stuff has to happen to
make it worthwhile.
My suggestion is that the PSC should be planning on major releases
somewhere between the .3 and .6 minor version of the previous major
release ... between 18 months and 3 years essentially, although it
could happen more quickly too.
Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:
MapGuide 1 - Current
MapGuide 1.0.0 - Released ???
MapGuide 1.0.1 - Released ???
MapGuide 1.0.2 - Released Oct 14 2006
MapGuide 1.0.3 - as required
MapGuide 1.1.0 - December 2006
MapGuide 1.2.0 - June 2007
MapGuide 1.3.0 - December 2007
MapGuide 1.4.0 - June 2008
MapGuide 2 - Future
MapGuide 2.0.0 - Unscheduled
We would then start to accumulate wishlist suggestions and
tentatively slot them into minor and major releases. Due to the
nature of open source, we can't actually predict what will end up in
any given release because we need to find volunteers or contributors
to get each piece done.
But if we have a plan of what we would like to see, ADSK, DMSG and
others will be influenced by the road map and hopefully it will have
a greater chance of becoming reality :)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From rbray at robertbray.net Fri Oct 20 08:48:50 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] irc transcript
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7A2@starfish.nanaimo.ca>
References: <78CCD09F-FED4-4230-84F2-8892E8E3F7C1@dmsolutions.ca> <8E468917B01800408B91984428BE03DD0385F7A2@starfish.nanaimo.ca>
Message-ID: <4538C5B2.7070504@robertbray.net>
Thanks Jason, your hired ;-)
Jason Birch wrote:
> I posted an edited version of these and what I could discern of the resolutions/actions/carryforwards to the meeting wiki page.
>
> http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006
>
> ________________________________
>
> From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
> Sent: Thu 2006-10-19 11:34 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] irc transcript
>
>
>
> attached.
>
>
>
From Jason.Birch at nanaimo.ca Fri Oct 20 10:32:05 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] irc transcript
References: <78CCD09F-FED4-4230-84F2-8892E8E3F7C1@dmsolutions.ca> <8E468917B01800408B91984428BE03DD0385F7A2@starfish.nanaimo.ca> <4538C5B2.7070504@robertbray.net>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7AA@starfish.nanaimo.ca>
Hmm. I have to remember that sometimes it's better to just shut up... ;)
________________________________
From: Robert Bray [@robertbray.net]
Sent: Fri 2006-10-20 5:48 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] irc transcript
Thanks Jason, your hired ;-)
Jason Birch wrote:
> I posted an edited version of these and what I could discern of the resolutions/actions/carryforwards to the meeting wiki page.
>
> http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-19-2006
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3526 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061020/f50a2876/attachment.bin
From Jason.Birch at nanaimo.ca Fri Oct 20 12:51:15 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] road map planning
Message-ID: <8E468917B01800408B91984428BE03DD030D561E@starfish.nanaimo.ca>
That layout looks good to me, given Bob's hatred for the even/odd system
;)
I would also suggest that we want a consistent fixed cutoff date for
branching in prep for release. Also, an appeals process more rigorous
than change requests (ie unanimous) for including any additional
functionality after a release cutoff.
As far as version control goes, a policy of creating a branch for each
minor release, but only tags for bugfix releases?
I'm a bit fuzzy on using wish list items for the road map. Obviously if
we're a good OS project we'll be responsive to our users, but to a
certain extent these wish list items will only be implemented through
change requests. I think that perhaps we need a process like userland
wish list -> PSC's concept of "The Road Ahead". All change requests
could be evaluated in light of this TRA document and their own merit and
then slotted into the Road Map. That way users wouldn't be getting all
excited about a road map that contains items that might never get done,
and developers would have a good idea of what's important to the
community?
Sounds like I need to go off and buy an Open Source book or two. Got an
ISBN Tom? :)
Jason
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Friday, October 20, 2006 05:45
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] road map planning
All,
I'm keen to lay out the framework for a road map for MGOS. I have a few
suggestions to help us get organised. Primarily I think the road map
should be organised around the planned release schedule and versions.
Central to my proposal is the concept of version numbering. We do need
to have a version numbering discussion, so I'll lay out my thoughts
here.
A MGOS version number consists of 3 numeric fields separated by a
period, X.Y.Z . X is the major version number, Y is the minor
version number and Z is the bugfix release number. Version numbers can
be tagged with a descriptive title as well, for instance BETA or RELEASE
CANDIDATE.
Rules for changing version numbers on release need to be established,
here is my first cut at it (but it will need to be fleshed out some
more):
* Changes to the major version number happen when the software undergoes
substantial architectural changes and/or has a substantial set of new
features.
* Changes to the minor version number happen when the software undergoes
minor architectural changes, improved performance and stability, some
new features, or any changes to the existing published API.
* Changes to the bugfix release number happen for bug fixes and trivial
changes.
Version numbers can be useful when laying out a road map, if we look at
the road map as a series of releases. The PSC can, at a high level,
agree on a release schedule and slot features etc into the appropriate
slots.
Timing of releases can be planned around the release numbers. I propose
that we adopt the MapServer release strategy, which is as
follows:
1. Release a minor version approximately every 6 months regardless of
what has been done. This has several advantages which I will only bring
up if the group disagrees with this strategy :)
2. Bug fix releases are then done approximately 'whenever' ...
essentially as often as needed, but typically one release within a month
or two of the minor release and then maybe one more before the next
minor release - depends on the stability of the software and the
criticality of the bug fix - sometimes MapServer waits to accumulate
several minor bugfixes and sometimes they release with only one major
bugfix.
3. Major version releases happen irregularly and depend on actual
features implemented. Essentially, enough stuff has to happen to make
it worthwhile.
My suggestion is that the PSC should be planning on major releases
somewhere between the .3 and .6 minor version of the previous major
release ... between 18 months and 3 years essentially, although it could
happen more quickly too.
Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:
MapGuide 1 - Current
MapGuide 1.0.0 - Released ???
MapGuide 1.0.1 - Released ???
MapGuide 1.0.2 - Released Oct 14 2006
MapGuide 1.0.3 - as required
MapGuide 1.1.0 - December 2006
MapGuide 1.2.0 - June 2007
MapGuide 1.3.0 - December 2007
MapGuide 1.4.0 - June 2008
MapGuide 2 - Future
MapGuide 2.0.0 - Unscheduled
We would then start to accumulate wishlist suggestions and tentatively
slot them into minor and major releases. Due to the nature of open
source, we can't actually predict what will end up in any given release
because we need to find volunteers or contributors to get each piece
done.
But if we have a plan of what we would like to see, ADSK, DMSG and
others will be influenced by the road map and hopefully it will have a
greater chance of becoming reality :)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From amorsell at spatialgis.com Fri Oct 20 13:00:38 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] road map planning
In-Reply-To: <8E468917B01800408B91984428BE03DD030D561E@starfish.nanaimo.ca>
Message-ID: <010001c6f469$4717bfc0$46f9fe0a@SPINAJM>
Jason,
Regarding the Open Source book: I saw reference to this one this morning
http://producingoss.com/html-chunk/ from
http://hobu.biz/index_html/open-development
Andy
-----Original Message-----
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Friday, October 20, 2006 9:51 AM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
That layout looks good to me, given Bob's hatred for the even/odd system
;)
I would also suggest that we want a consistent fixed cutoff date for
branching in prep for release. Also, an appeals process more rigorous than
change requests (ie unanimous) for including any additional functionality
after a release cutoff.
As far as version control goes, a policy of creating a branch for each minor
release, but only tags for bugfix releases?
I'm a bit fuzzy on using wish list items for the road map. Obviously if
we're a good OS project we'll be responsive to our users, but to a certain
extent these wish list items will only be implemented through change
requests. I think that perhaps we need a process like userland wish list ->
PSC's concept of "The Road Ahead". All change requests could be evaluated
in light of this TRA document and their own merit and then slotted into the
Road Map. That way users wouldn't be getting all excited about a road map
that contains items that might never get done, and developers would have a
good idea of what's important to the community?
Sounds like I need to go off and buy an Open Source book or two. Got an
ISBN Tom? :)
Jason
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Friday, October 20, 2006 05:45
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] road map planning
All,
I'm keen to lay out the framework for a road map for MGOS. I have a few
suggestions to help us get organised. Primarily I think the road map should
be organised around the planned release schedule and versions.
Central to my proposal is the concept of version numbering. We do need to
have a version numbering discussion, so I'll lay out my thoughts here.
A MGOS version number consists of 3 numeric fields separated by a period,
X.Y.Z . X is the major version number, Y is the minor version number
and Z is the bugfix release number. Version numbers can be tagged with a
descriptive title as well, for instance BETA or RELEASE CANDIDATE.
Rules for changing version numbers on release need to be established, here
is my first cut at it (but it will need to be fleshed out some
more):
* Changes to the major version number happen when the software undergoes
substantial architectural changes and/or has a substantial set of new
features.
* Changes to the minor version number happen when the software undergoes
minor architectural changes, improved performance and stability, some new
features, or any changes to the existing published API.
* Changes to the bugfix release number happen for bug fixes and trivial
changes.
Version numbers can be useful when laying out a road map, if we look at the
road map as a series of releases. The PSC can, at a high level, agree on a
release schedule and slot features etc into the appropriate slots.
Timing of releases can be planned around the release numbers. I propose
that we adopt the MapServer release strategy, which is as
follows:
1. Release a minor version approximately every 6 months regardless of what
has been done. This has several advantages which I will only bring up if
the group disagrees with this strategy :)
2. Bug fix releases are then done approximately 'whenever' ...
essentially as often as needed, but typically one release within a month or
two of the minor release and then maybe one more before the next minor
release - depends on the stability of the software and the criticality of
the bug fix - sometimes MapServer waits to accumulate several minor bugfixes
and sometimes they release with only one major bugfix.
3. Major version releases happen irregularly and depend on actual features
implemented. Essentially, enough stuff has to happen to make it worthwhile.
My suggestion is that the PSC should be planning on major releases somewhere
between the .3 and .6 minor version of the previous major release ...
between 18 months and 3 years essentially, although it could happen more
quickly too.
Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:
MapGuide 1 - Current
MapGuide 1.0.0 - Released ???
MapGuide 1.0.1 - Released ???
MapGuide 1.0.2 - Released Oct 14 2006
MapGuide 1.0.3 - as required
MapGuide 1.1.0 - December 2006
MapGuide 1.2.0 - June 2007
MapGuide 1.3.0 - December 2007
MapGuide 1.4.0 - June 2008
MapGuide 2 - Future
MapGuide 2.0.0 - Unscheduled
We would then start to accumulate wishlist suggestions and tentatively slot
them into minor and major releases. Due to the nature of open source, we
can't actually predict what will end up in any given release because we need
to find volunteers or contributors to get each piece done.
But if we have a plan of what we would like to see, ADSK, DMSG and others
will be influenced by the road map and hopefully it will have a greater
chance of becoming reality :)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Fri Oct 20 13:26:51 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] road map planning
Message-ID: <8E468917B01800408B91984428BE03DD030D5623@starfish.nanaimo.ca>
Awesome, it's "open source". I don't have to beg for another book (I
blew the year's budget in March).
Great book from what I've read so far. Good prose, good advice, etc.
I'll have to get a copy for the shelf in January. :)
Jason
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: Friday, October 20, 2006 10:01
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
Jason,
Regarding the Open Source book: I saw reference to this one this morning
http://producingoss.com/html-chunk/ from
http://hobu.biz/index_html/open-development
Andy
-----Original Message-----
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Friday, October 20, 2006 9:51 AM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
That layout looks good to me, given Bob's hatred for the even/odd system
;)
I would also suggest that we want a consistent fixed cutoff date for
branching in prep for release. Also, an appeals process more rigorous
than change requests (ie unanimous) for including any additional
functionality after a release cutoff.
As far as version control goes, a policy of creating a branch for each
minor release, but only tags for bugfix releases?
I'm a bit fuzzy on using wish list items for the road map. Obviously if
we're a good OS project we'll be responsive to our users, but to a
certain extent these wish list items will only be implemented through
change requests. I think that perhaps we need a process like userland
wish list -> PSC's concept of "The Road Ahead". All change requests
could be evaluated in light of this TRA document and their own merit and
then slotted into the Road Map. That way users wouldn't be getting all
excited about a road map that contains items that might never get done,
and developers would have a good idea of what's important to the
community?
Sounds like I need to go off and buy an Open Source book or two. Got an
ISBN Tom? :)
Jason
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Friday, October 20, 2006 05:45
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] road map planning
All,
I'm keen to lay out the framework for a road map for MGOS. I have a few
suggestions to help us get organised. Primarily I think the road map
should be organised around the planned release schedule and versions.
Central to my proposal is the concept of version numbering. We do need
to have a version numbering discussion, so I'll lay out my thoughts
here.
A MGOS version number consists of 3 numeric fields separated by a
period, X.Y.Z . X is the major version number, Y is the minor
version number and Z is the bugfix release number. Version numbers can
be tagged with a descriptive title as well, for instance BETA or RELEASE
CANDIDATE.
Rules for changing version numbers on release need to be established,
here is my first cut at it (but it will need to be fleshed out some
more):
* Changes to the major version number happen when the software undergoes
substantial architectural changes and/or has a substantial set of new
features.
* Changes to the minor version number happen when the software undergoes
minor architectural changes, improved performance and stability, some
new features, or any changes to the existing published API.
* Changes to the bugfix release number happen for bug fixes and trivial
changes.
Version numbers can be useful when laying out a road map, if we look at
the road map as a series of releases. The PSC can, at a high level,
agree on a release schedule and slot features etc into the appropriate
slots.
Timing of releases can be planned around the release numbers. I propose
that we adopt the MapServer release strategy, which is as
follows:
1. Release a minor version approximately every 6 months regardless of
what has been done. This has several advantages which I will only bring
up if the group disagrees with this strategy :)
2. Bug fix releases are then done approximately 'whenever' ...
essentially as often as needed, but typically one release within a month
or two of the minor release and then maybe one more before the next
minor release - depends on the stability of the software and the
criticality of the bug fix - sometimes MapServer waits to accumulate
several minor bugfixes and sometimes they release with only one major
bugfix.
3. Major version releases happen irregularly and depend on actual
features implemented. Essentially, enough stuff has to happen to make
it worthwhile.
My suggestion is that the PSC should be planning on major releases
somewhere between the .3 and .6 minor version of the previous major
release ...
between 18 months and 3 years essentially, although it could happen more
quickly too.
Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:
MapGuide 1 - Current
MapGuide 1.0.0 - Released ???
MapGuide 1.0.1 - Released ???
MapGuide 1.0.2 - Released Oct 14 2006
MapGuide 1.0.3 - as required
MapGuide 1.1.0 - December 2006
MapGuide 1.2.0 - June 2007
MapGuide 1.3.0 - December 2007
MapGuide 1.4.0 - June 2008
MapGuide 2 - Future
MapGuide 2.0.0 - Unscheduled
We would then start to accumulate wishlist suggestions and tentatively
slot them into minor and major releases. Due to the nature of open
source, we can't actually predict what will end up in any given release
because we need to find volunteers or contributors to get each piece
done.
But if we have a plan of what we would like to see, ADSK, DMSG and
others will be influenced by the road map and hopefully it will have a
greater chance of becoming reality :)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From tom.fukushima at autodesk.com Fri Oct 20 13:32:37 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] road map planning
Message-ID:
Yes, the Karl Fogel book is the one that I'm reading (we got one for all
of the developers here in Calgary).
Yesterday, I mentioned to Jason that I was reading a book and getting
some hints about how to do things from it; and following the suggestions
blindly of course.
Cheers
Tom
-----Original Message-----
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Friday, October 20, 2006 11:27 AM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
Awesome, it's "open source". I don't have to beg for another book (I
blew the year's budget in March).
Great book from what I've read so far. Good prose, good advice, etc.
I'll have to get a copy for the shelf in January. :)
Jason
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: Friday, October 20, 2006 10:01
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
Jason,
Regarding the Open Source book: I saw reference to this one this morning
http://producingoss.com/html-chunk/ from
http://hobu.biz/index_html/open-development
Andy
-----Original Message-----
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Friday, October 20, 2006 9:51 AM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] road map planning
That layout looks good to me, given Bob's hatred for the even/odd system
;)
I would also suggest that we want a consistent fixed cutoff date for
branching in prep for release. Also, an appeals process more rigorous
than change requests (ie unanimous) for including any additional
functionality after a release cutoff.
As far as version control goes, a policy of creating a branch for each
minor release, but only tags for bugfix releases?
I'm a bit fuzzy on using wish list items for the road map. Obviously if
we're a good OS project we'll be responsive to our users, but to a
certain extent these wish list items will only be implemented through
change requests. I think that perhaps we need a process like userland
wish list -> PSC's concept of "The Road Ahead". All change requests
could be evaluated in light of this TRA document and their own merit and
then slotted into the Road Map. That way users wouldn't be getting all
excited about a road map that contains items that might never get done,
and developers would have a good idea of what's important to the
community?
Sounds like I need to go off and buy an Open Source book or two. Got an
ISBN Tom? :)
Jason
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Friday, October 20, 2006 05:45
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] road map planning
All,
I'm keen to lay out the framework for a road map for MGOS. I have a few
suggestions to help us get organised. Primarily I think the road map
should be organised around the planned release schedule and versions.
Central to my proposal is the concept of version numbering. We do need
to have a version numbering discussion, so I'll lay out my thoughts
here.
A MGOS version number consists of 3 numeric fields separated by a
period, X.Y.Z . X is the major version number, Y is the minor
version number and Z is the bugfix release number. Version numbers can
be tagged with a descriptive title as well, for instance BETA or RELEASE
CANDIDATE.
Rules for changing version numbers on release need to be established,
here is my first cut at it (but it will need to be fleshed out some
more):
* Changes to the major version number happen when the software undergoes
substantial architectural changes and/or has a substantial set of new
features.
* Changes to the minor version number happen when the software undergoes
minor architectural changes, improved performance and stability, some
new features, or any changes to the existing published API.
* Changes to the bugfix release number happen for bug fixes and trivial
changes.
Version numbers can be useful when laying out a road map, if we look at
the road map as a series of releases. The PSC can, at a high level,
agree on a release schedule and slot features etc into the appropriate
slots.
Timing of releases can be planned around the release numbers. I propose
that we adopt the MapServer release strategy, which is as
follows:
1. Release a minor version approximately every 6 months regardless of
what has been done. This has several advantages which I will only bring
up if the group disagrees with this strategy :)
2. Bug fix releases are then done approximately 'whenever' ...
essentially as often as needed, but typically one release within a month
or two of the minor release and then maybe one more before the next
minor release - depends on the stability of the software and the
criticality of the bug fix - sometimes MapServer waits to accumulate
several minor bugfixes and sometimes they release with only one major
bugfix.
3. Major version releases happen irregularly and depend on actual
features implemented. Essentially, enough stuff has to happen to make
it worthwhile.
My suggestion is that the PSC should be planning on major releases
somewhere between the .3 and .6 minor version of the previous major
release ...
between 18 months and 3 years essentially, although it could happen more
quickly too.
Given all the preceding is ratified by the PSC (or some reasonable
facsimile), the outline of the road map for MGOS might be:
MapGuide 1 - Current
MapGuide 1.0.0 - Released ???
MapGuide 1.0.1 - Released ???
MapGuide 1.0.2 - Released Oct 14 2006
MapGuide 1.0.3 - as required
MapGuide 1.1.0 - December 2006
MapGuide 1.2.0 - June 2007
MapGuide 1.3.0 - December 2007
MapGuide 1.4.0 - June 2008
MapGuide 2 - Future
MapGuide 2.0.0 - Unscheduled
We would then start to accumulate wishlist suggestions and tentatively
slot them into minor and major releases. Due to the nature of open
source, we can't actually predict what will end up in any given release
because we need to find volunteers or contributors to get each piece
done.
But if we have a plan of what we would like to see, ADSK, DMSG and
others will be influenced by the road map and hopefully it will have a
greater chance of becoming reality :)
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Fri Oct 20 13:43:05 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: Formation of the MapGuide Open Source PSC, and MapGuide Open Source Update
Message-ID: <8E468917B01800408B91984428BE03DD030D5624@starfish.nanaimo.ca>
Hi all,
To keep communication clear and open I thought it would be a good idea
to let y'all know what's going on with MapGuide Open Source.
The MapGuide Open Source Project Steering Committee (PSC) is now in the
boostrapping phase. You can find out more about the PSC on our home
page [1], and if you are interested in following along, our meetings
will all be posted on the OSGeo Wiki [2]. Feel free to lurk on IRC
during the meetings, and join the mailing list [3] as an observer.
After we get the PSC bootstrapped, we will also be setting up regular
developer IRC meetings for anyone interested in contributing to MapGuide
or just wanting to follow along. These developer meetings and the dev
mailing list [4] will be where all technical discussions around the
development of the MapGuide code base takes place, with process items
(such as accepting feature changes and setting the road map) taking
place in the PSC list and IRC meetings. Many other efforts are underway
as part of moving MapGuide Open Source towards a healthy open source
project. Some of these can be seen on the MapGuide Open Source wiki
page [5]
A similar process is taking place for the FDO project.
And, as a personal plug, feel free to read some of my comments on this
process [6].
Jason
[1] PSC home page (currently draft):
https://mapguide.osgeo.org/psc.html
[2] PSC wiki page
http://wiki.osgeo.org/index.php/MapGuide_PSC
[3] PSC mailing List
https://mapguide.osgeo.org/servlets/ProjectMailingListList
[4] DEV mailing list
https://mapguide.osgeo.org/servlets/ProjectMailingListList
[5] MGOS wiki page
http://wiki.osgeo.org/index.php/MapGuide_Open_Source
[6] Jason's blog article
http://www.jasonbirch.com/nodes/2006/10/20/45/insight-foresight-more-sig
ht/
From rbray at robertbray.net Tue Oct 24 16:33:43 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: PSC Guidelines Updated
Message-ID: <453E78A7.8020706@robertbray.net>
All,
I completed my update of the PSC guidelines today. Consider the posted
version the final draft. When looking it over please give careful
consideration to the Process section, which is the most heavily updated.
I tried to clarify everything discussed in the meeting and few other
items that were nagging me as well.
As always it can be found here: https://mapguide.osgeo.org/psc.html.
Thanks,
Bob
From pspencer at dmsolutions.ca Tue Oct 24 19:55:30 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] PSC Guidelines Updated
In-Reply-To: <453E78A7.8020706@robertbray.net>
References: <453E78A7.8020706@robertbray.net>
Message-ID:
Bob,
changes look good to me.
Paul
On 24-Oct-06, at 4:33 PM, Robert Bray wrote:
> All,
>
> I completed my update of the PSC guidelines today. Consider the
> posted version the final draft. When looking it over please give
> careful consideration to the Process section, which is the most
> heavily updated. I tried to clarify everything discussed in the
> meeting and few other items that were nagging me as well.
>
> As always it can be found here: https://mapguide.osgeo.org/psc.html.
>
> Thanks,
> Bob
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Tue Oct 24 20:02:32 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] PSC Guidelines Updated
References: <453E78A7.8020706@robertbray.net>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7D7@starfish.nanaimo.ca>
Me too. +1 :)
________________________________
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tue 2006-10-24 4:55 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] PSC Guidelines Updated
Bob,
changes look good to me.
Paul
On 24-Oct-06, at 4:33 PM, Robert Bray wrote:
> All,
>
> I completed my update of the PSC guidelines today. Consider the
> posted version the final draft. When looking it over please give
> careful consideration to the Process section, which is the most
> heavily updated. I tried to clarify everything discussed in the
> meeting and few other items that were nagging me as well.
>
> As always it can be found here: https://mapguide.osgeo.org/psc.html.
>
> Thanks,
> Bob
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4826 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061024/8e3dfb59/attachment.bin
From rbray at robertbray.net Thu Oct 26 09:10:36 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: Reminder: PSC Meeting Today
Message-ID: <4540B3CC.6060206@robertbray.net>
All,
Just a reminder that there will be a PSC meeting today. The time and
agenda are now posted on the Wiki:
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-26-2006
At this point there are only a couple of agenda items. Feel free to add
more.
Thanks,
Bob
From pspencer at dmsolutions.ca Thu Oct 26 09:23:57 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Reminder: PSC Meeting Today
In-Reply-To: <4540B3CC.6060206@robertbray.net>
References: <4540B3CC.6060206@robertbray.net>
Message-ID: <06AE2D13-EF07-4339-BCFE-CC13F5E66D4D@dmsolutions.ca>
I've added Road Map/Release Schedule Discussion to the list. I would
like to get some feedback on my email suggesting that we plan the
road map around a release schedule based on fixed period minor releases.
Cheers
Paul
On 26-Oct-06, at 9:10 AM, Robert Bray wrote:
> All,
>
> Just a reminder that there will be a PSC meeting today. The time
> and agenda are now posted on the Wiki:
>
> http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-26-2006
>
> At this point there are only a couple of agenda items. Feel free to
> add more.
>
> Thanks,
> Bob
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Thu Oct 26 09:54:39 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] Reminder: PSC Meeting Today
References: <4540B3CC.6060206@robertbray.net> <06AE2D13-EF07-4339-BCFE-CC13F5E66D4D@dmsolutions.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7DD@starfish.nanaimo.ca>
I gave some feedback already. :)
I do see the concept of RC's missing. We'll somehow have to figure out how to package MG more easily than it is currently done.
Jason
________________________________
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Thu 2006-10-26 6:23 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] Reminder: PSC Meeting Today
I've added Road Map/Release Schedule Discussion to the list. I would
like to get some feedback on my email suggesting that we plan the
road map around a release schedule based on fixed period minor releases.
Cheers
Paul
On 26-Oct-06, at 9:10 AM, Robert Bray wrote:
> All,
>
> Just a reminder that there will be a PSC meeting today. The time
> and agenda are now posted on the Wiki:
>
> http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-26-2006
>
> At this point there are only a couple of agenda items. Feel free to
> add more.
>
> Thanks,
> Bob
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5231 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061026/000324b1/attachment.bin
From rbray at robertbray.net Thu Oct 26 15:48:17 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: PSC Meeting Minutes Posted / Welcome Haris
Message-ID: <45411101.2090906@robertbray.net>
All,
The meeting minutes from today's PSC meeting have been posted to:
http://wiki.osgeo.org/index.php/MapGuide_PSC_Meeting_10-26-2006.
I would also like to formally welcome Haris Kurtagic as a member of the
MapGuide PSC. His contribution of an open source Oracle provider is
already a big hit with the MapGuide community.
Thanks,
Bob
From pspencer at dmsolutions.ca Thu Oct 26 16:08:59 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: MapGuide Release Process - proposal
Message-ID:
Based on my email, I've prepared a wiki page documenting my proposal
for a release process for MapGuide. Please feel free to edit and/or
provide feedback via the list.
Please note that it will be hard to perfect this until we actually do
a release or two.
http://wiki.osgeo.org/index.php/MapGuide_Release_Process
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Thu Oct 26 21:11:03 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide Release Process - proposal
References:
Message-ID: <8E468917B01800408B91984428BE03DD0385F7E3@starfish.nanaimo.ca>
I don't know how others feel about this, but I would like an escape valve of being able to ship a minor release with known bugs if they are minor functionality and major effort to fix, and are discovered after a second RC. I don't want to get stuck in the "wait until it's perfect" trap. At some point, you have to shoot the engineer ;)
Jason
________________________________
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Thu 2006-10-26 1:08 PM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] MapGuide Release Process - proposal
Based on my email, I've prepared a wiki page documenting my proposal
for a release process for MapGuide. Please feel free to edit and/or
provide feedback via the list.
Please note that it will be hard to perfect this until we actually do
a release or two.
http://wiki.osgeo.org/index.php/MapGuide_Release_Process
Cheers
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4995 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061026/6cfe2539/attachment.bin
From pspencer at dmsolutions.ca Thu Oct 26 21:34:31 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide Release Process - proposal
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7E3@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD0385F7E3@starfish.nanaimo.ca>
Message-ID:
I think it is acceptable to ship a product with known bugs, as long
as they are minor and they are documented, especially if they have
known work-arounds.
There is always an exception to prove the rule. My recommendation is
that the rule is to not ship with known issues ... the PSC (as a
whole) can override anything - but if we set out good rules, we will
have to really justify it to ourselves to break the rule.
Cheers
Paul
On 26-Oct-06, at 9:11 PM, Jason Birch wrote:
> I don't know how others feel about this, but I would like an escape
> valve of being able to ship a minor release with known bugs if they
> are minor functionality and major effort to fix, and are discovered
> after a second RC. I don't want to get stuck in the "wait until
> it's perfect" trap. At some point, you have to shoot the engineer ;)
>
> Jason
>
> ________________________________
>
> From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
> Sent: Thu 2006-10-26 1:08 PM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide Release Process - proposal
>
>
>
> Based on my email, I've prepared a wiki page documenting my proposal
> for a release process for MapGuide. Please feel free to edit and/or
> provide feedback via the list.
>
> Please note that it will be hard to perfect this until we actually do
> a release or two.
>
> http://wiki.osgeo.org/index.php/MapGuide_Release_Process
>
> Cheers
>
> Paul
>
> +-----------------------------------------------------------------+
> |Paul Spencer pspencer@dmsolutions.ca |
> +-----------------------------------------------------------------+
> |Chief Technology Officer |
> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From dmorissette at mapgears.com Fri Oct 27 11:27:45 2006
From: dmorissette at mapgears.com (Daniel Morissette)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide Release Process - proposal
In-Reply-To:
References:
Message-ID: <45422571.7000501@mapgears.com>
Paul Spencer wrote:
> Based on my email, I've prepared a wiki page documenting my proposal for
> a release process for MapGuide. Please feel free to edit and/or provide
> feedback via the list.
>
> Please note that it will be hard to perfect this until we actually do a
> release or two.
>
> http://wiki.osgeo.org/index.php/MapGuide_Release_Process
>
Nice document. Here are a few comments based on my experience with
MapServer:
1- The current document seems to suggest that functional changes and new
features are allowed up to the first release candidate. I'm not sure
this is a good idea. If you follow that logic, then new features or
functional changes can be added anytime during the beta test period...
very likley to introduce new bugs while others are working hard to
stabilize the software... leading to a never-ending release cycle.
For MapServer, we have a feature freeze date that marks the beginning of
the release cycle. The feature freeze is announced in advance when we
introduce the release plan and no new features or functional changes are
allowed after that date. Beta1 is usually produced in the week that
follows the feature freeze. This means that all betas contain the same
features, just with more bug fixes but hopefully with no new bugs. This
also allows the doc team to start polishing the docs at the beginning of
the release cycle and we hopefully end up with docs in sync with the
software at on the day of the final release (which is the way it should
be, right?)... but more importantly, the feature freeze at the beginning
of the release cycle is to allow the software to really stabilize during
the release cycle and prevent the introduction of new bugs during that
period.
2- Under release type, should we also have a "dev release", "dev
snapshot" or something along those lines that can be produced and
officially labelled anytime during the development cycle to make a much
wanted feature available "as-is" and right away without going through
the full release process? I'm just asking. I proposed that for MapServer
way back when and it was turned down, but I thought I would raise that
possibility with you just in case you see a need for that.
Daniel
--
Daniel Morissette
http://www.mapgears.com/
From pspencer at dmsolutions.ca Fri Oct 27 11:37:12 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide Release Process - proposal
In-Reply-To: <45422571.7000501@mapgears.com>
References: <45422571.7000501@mapgears.com>
Message-ID:
comments inline
On 27-Oct-06, at 11:27 AM, Daniel Morissette wrote:
> Paul Spencer wrote:
>> Based on my email, I've prepared a wiki page documenting my
>> proposal for a release process for MapGuide. Please feel free to
>> edit and/or provide feedback via the list.
>> Please note that it will be hard to perfect this until we actually
>> do a release or two.
>> http://wiki.osgeo.org/index.php/MapGuide_Release_Process
>
> Nice document. Here are a few comments based on my experience with
> MapServer:
>
> 1- The current document seems to suggest that functional changes
> and new features are allowed up to the first release candidate. I'm
> not sure this is a good idea. If you follow that logic, then new
> features or functional changes can be added anytime during the beta
> test period... very likley to introduce new bugs while others are
> working hard to stabilize the software... leading to a never-ending
> release cycle.
>
> For MapServer, we have a feature freeze date that marks the
> beginning of the release cycle. The feature freeze is announced in
> advance when we introduce the release plan and no new features or
> functional changes are allowed after that date. Beta1 is usually
> produced in the week that follows the feature freeze. This means
> that all betas contain the same features, just with more bug fixes
> but hopefully with no new bugs. This also allows the doc team to
> start polishing the docs at the beginning of the release cycle and
> we hopefully end up with docs in sync with the software at on the
> day of the final release (which is the way it should be, right?)...
> but more importantly, the feature freeze at the beginning of the
> release cycle is to allow the software to really stabilize during
> the release cycle and prevent the introduction of new bugs during
> that period.
my intention ... which I didn't get across I guess ... was that it
would be possible to produce a first beta without having all the
planned features in it. It would not be a free-for-all. Only
planned/approved features could be introduced, and it would require
an additional beta cycle and potentially delay the final release, but
it could be a useful tool if the rest of the features are ready for
wider testing and the missing features are relatively minor or have a
low risk of introducing bugs - for instance, missing documentation.
This could also be handled through the dev releases you mention, I
guess.
I'd like to let the process stand as is until I hear from the others
on the PSC. I've already had push-back from Jason on being strict
about not adding features after Release Candidate (but I'm pretty
firm on that one!)
>
> 2- Under release type, should we also have a "dev release", "dev
> snapshot" or something along those lines that can be produced and
> officially labelled anytime during the development cycle to make a
> much wanted feature available "as-is" and right away without going
> through the full release process? I'm just asking. I proposed that
> for MapServer way back when and it was turned down, but I thought I
> would raise that possibility with you just in case you see a need
> for that.
I like this idea. This could also be considered an Alpha release -
known issues and not feature complete, but perhaps useful. PSC, want
to include a Snapshot Release?
>
> Daniel
> --
> Daniel Morissette
> http://www.mapgears.com/
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Fri Oct 27 11:48:19 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide Release Process - proposal
Message-ID: <8E468917B01800408B91984428BE03DD030D569C@starfish.nanaimo.ca>
Heh. OK, I've seen the light and agree with Daniel now. Considering
that we will likely be starting out with not a lot of beta testers,
stabilizing early will reduce the likelihood of bugs creeping in with
new code. I don't see a problem with shipping betas with incomplete
documentation, but I think that if a feature isn't ready for the first
beta it should be slipped to the next release. I don't know about you,
but I work way better under a hard deadline than a soft one.
As far as dev releases go, I'd really prefer to see nightly/weekly
snapshots rather than spending release manager time on an alpha. I'm
not sure what the logistics of creating windows/linux installers against
these snapshots would be though. We're going to have to grow some
experience with installers.
Do numbers need to be sequential, or can we vote to skip from .12 to
.14? (or Word 2.0 to Word 6.0?) :)
Jason
(Daniel's context stripped)
-----Original Message-----
From: Paul Spencer
Sent: Friday, October 27, 2006 08:37
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide Release Process - proposal
my intention ... which I didn't get across I guess ... was that it would
be possible to produce a first beta without having all the planned
features in it. It would not be a free-for-all. Only planned/approved
features could be introduced, and it would require an additional beta
cycle and potentially delay the final release, but it could be a useful
tool if the rest of the features are ready for wider testing and the
missing features are relatively minor or have a low risk of introducing
bugs - for instance, missing documentation.
This could also be handled through the dev releases you mention, I
guess.
I'd like to let the process stand as is until I hear from the others on
the PSC. I've already had push-back from Jason on being strict about
not adding features after Release Candidate (but I'm pretty firm on that
one!)
I like this idea. This could also be considered an Alpha release -
known issues and not feature complete, but perhaps useful. PSC, want to
include a Snapshot Release?
From Jason.Birch at nanaimo.ca Fri Oct 27 16:27:44 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-dev] 1.1.x branch
Message-ID: <8E468917B01800408B91984428BE03DD030D56BC@starfish.nanaimo.ca>
PSC,
When this branch is created, does that mean that we go into feature
freeze (in prep for Beta/RC releases), or is it just to allow 1.2
features to start working their way into the trunk?
Jason
________________________________
From: Tom Fukushima [mailto:tom.fukushima@autodesk.com]
Sent: Friday, October 27, 2006 13:20
To: dev@mapguide.osgeo.org
Subject: [mapguide-dev] 1.1.x branch
Hi,
I would like to target next Monday (or Tuesday) for when we create a
1.1.x branch off of the trunk. This branch will hold all current
submissions to the trunk to date. I will be enumerating the list of
things that are in 1.1.x to date in a subsequent email.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061027/9d26652b/attachment.html
From tom.fukushima at autodesk.com Fri Oct 27 17:24:13 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
Message-ID:
The branch is not intended to mean feature freeze. And I think, any
features that don't get accepted into 1.1 (e.g., it might not be in a
stable state when we want to beta or release the branch) could be put
into Trunk.
Tom
_____
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Friday, October 27, 2006 2:28 PM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
PSC,
When this branch is created, does that mean that we go into feature
freeze (in prep for Beta/RC releases), or is it just to allow 1.2
features to start working their way into the trunk?
Jason
_____
From: Tom Fukushima [mailto:tom.fukushima@autodesk.com]
Sent: Friday, October 27, 2006 13:20
To: dev@mapguide.osgeo.org
Subject: [mapguide-dev] 1.1.x branch
Hi,
I would like to target next Monday (or Tuesday) for when we create a
1.1.x branch off of the trunk. This branch will hold all current
submissions to the trunk to date. I will be enumerating the list of
things that are in 1.1.x to date in a subsequent email.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061027/8365df8d/attachment.html
From pspencer at dmsolutions.ca Fri Oct 27 20:25:39 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
In-Reply-To: <8E468917B01800408B91984428BE03DD030D56BC@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD030D56BC@starfish.nanaimo.ca>
Message-ID:
Jason, my feeling is that is just to allow for 1.2 features. My
experience in most of the projects I've been involved in is that it
is desirable to branch as late as possible to reduce the overhead of
porting bug fixes between branches. MapServer certainly works this way.
Part of the reason for this, though, was the use of cvs (as opposed
to svn), which made it very difficult to branch and merge. Svn is
substantially different in this respect and I expect to see this
aspect of projects change as svn is used more and more.
Cheers
Paul
On 27-Oct-06, at 4:27 PM, Jason Birch wrote:
> PSC,
>
> When this branch is created, does that mean that we go into feature
> freeze (in prep for Beta/RC releases), or is it just to allow 1.2
> features to start working their way into the trunk?
>
> Jason
>
> From: Tom Fukushima [mailto:tom.fukushima@autodesk.com]
> Sent: Friday, October 27, 2006 13:20
> To: dev@mapguide.osgeo.org
> Subject: [mapguide-dev] 1.1.x branch
>
> Hi,
>
> I would like to target next Monday (or Tuesday) for when we create
> a 1.1.x branch off of the trunk. This branch will hold all current
> submissions to the trunk to date. I will be enumerating the list
> of things that are in 1.1.x to date in a subsequent email.
>
> Tom
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Sat Oct 28 01:50:13 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: RFC process...
Message-ID: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca>
http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
Do we really want the RFC process to apply to the web site? Maybe for major overhauls, but personally I think that this kind of thing could be better dealt with informally, perhaps by a web site subcommittee.
Also, I'm a bit scared of an RFC process that appears to expect the presentation of a well-thought-out canned solution, which is then subject to debate on the DEV list. I think that we should be encouraging an informal process where a problem/solution pair (or just the problem) is put forward to the DEV list/channel as a rough WIKI page, and is then debated and polished into a form where it can be submitted as an RFC.
This kind of process gives us better solutions, and ensures that the original submitter only needs to do a limited amount of work before starting the discussion, reducing the emotional attachment to a particular solution.
Jason
From rbray at robertbray.net Sat Oct 28 03:00:32 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca>
Message-ID: <45430010.1060403@robertbray.net>
Jason,
Personally I would like to avoid subcommittees, mainly because of the
pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
for the web site is a different debate, maybe / maybe not. It really
depends on the scope of the change.
To address your core concern though, I expect a mix of RFCs. Some will
start with lots of discussion on the dev list and evolve into a fully
baked RFC. Others may come pre-baked, because the developer has already
thought it through pretty thoroughly (and maybe even has a prototype
running). It really depends highly on the author and what is being
proposed. The key is to welcome active discussion of ideas on the dev
list. Also remember that an RFC is a living document up until the time
it is voted on and approved. It can start with just an idea and no
implementation detail. We should make that clear on the how to create an
RFC page (hmm guess we need one of those).
Does that clarify or confuse the issue more?
Bob
Jason Birch wrote:
> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
>
> Do we really want the RFC process to apply to the web site? Maybe for major overhauls, but personally I think that this kind of thing could be better dealt with informally, perhaps by a web site subcommittee.
>
> Also, I'm a bit scared of an RFC process that appears to expect the presentation of a well-thought-out canned solution, which is then subject to debate on the DEV list. I think that we should be encouraging an informal process where a problem/solution pair (or just the problem) is put forward to the DEV list/channel as a rough WIKI page, and is then debated and polished into a form where it can be submitted as an RFC.
>
> This kind of process gives us better solutions, and ensures that the original submitter only needs to do a limited amount of work before starting the discussion, reducing the emotional attachment to a particular solution.
>
> Jason
>
>
From Jason.Birch at nanaimo.ca Sat Oct 28 13:17:00 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca> <45430010.1060403@robertbray.net>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7F5@starfish.nanaimo.ca>
Does working group sound better? :)
I think that the website, documentation, etc will be an area where non-developers will really be able to contribute, and the split between coding/presentation is clear enough (at least in my fuzzy mind) that splitting the work between coders/documentors would be reasonable. As an aside, I think that these two roles would need to be distinct in LDAP. Anyway, this is a while down the road and will come up again.
I don't buy that a solution a developer has thought through and even coded themselves is necessesarily the best solution for the project. By nature a single individual, or even a single organisation, does not have the breadth of experience or understanding of the problem realm to create a solution that is the best fit for our entire user base. We need to ensure that the project does not turn into a Frankenstein's monster of solutions that have been built in isolation. The problem is that the investment (time and emotion) in fait-accomplis solutions is such that it is difficult to shift their path once they are presented unless there is a severe defect.
I concede that a lot of the existing development will likely come as pre-canned solutions because of where this project is starting from, and that in some cases it will be desirable to accept contributions to the code base that have been developed in isolation, but I really want to stress that by default we should have open development starting at the conceptualisation phase.
Jason
________________________________
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Sat 2006-10-28 12:00 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason,
Personally I would like to avoid subcommittees, mainly because of the
pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
for the web site is a different debate, maybe / maybe not. It really
depends on the scope of the change.
To address your core concern though, I expect a mix of RFCs. Some will
start with lots of discussion on the dev list and evolve into a fully
baked RFC. Others may come pre-baked, because the developer has already
thought it through pretty thoroughly (and maybe even has a prototype
running). It really depends highly on the author and what is being
proposed. The key is to welcome active discussion of ideas on the dev
list. Also remember that an RFC is a living document up until the time
it is voted on and approved. It can start with just an idea and no
implementation detail. We should make that clear on the how to create an
RFC page (hmm guess we need one of those).
Does that clarify or confuse the issue more?
Bob
Jason Birch wrote:
> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
>
> Do we really want the RFC process to apply to the web site? Maybe for major overhauls, but personally I think that this kind of thing could be better dealt with informally, perhaps by a web site subcommittee.
>
> Also, I'm a bit scared of an RFC process that appears to expect the presentation of a well-thought-out canned solution, which is then subject to debate on the DEV list. I think that we should be encouraging an informal process where a problem/solution pair (or just the problem) is put forward to the DEV list/channel as a rough WIKI page, and is then debated and polished into a form where it can be submitted as an RFC.
>
> This kind of process gives us better solutions, and ensures that the original submitter only needs to do a limited amount of work before starting the discussion, reducing the emotional attachment to a particular solution.
>
> Jason
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6318 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/9abc7c86/attachment.bin
From pspencer at dmsolutions.ca Sat Oct 28 13:34:31 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7F5@starfish.nanaimo.ca>
References: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca> <45430010.1060403@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7F5@starfish.nanaimo.ca>
Message-ID: <2144A54B-2FFB-4728-8664-F78DAF939C96@dmsolutions.ca>
Jason, I agree in principle but not in practice. Don't forget that
this is an open source project and we are trying to encourage
participation and contribution through volunteer efforts :)
If someone has thought through and implemented a workable solution,
that's actually a pretty decent start. It may not be the best way to
solve a problem, but as long as the code is sound and architecturally
in line with the project, it is better to have the feature than to
not have it.
People will generally contribute stuff that solves a problem for
them, not for anyone else. There is not a lot of incentive to solve
a problem that doesn't impact them.
We (the PSC) has the power to accept or reject an RFC, or to turn it
back for rewriting with comments. And at the end of the day, it is a
group decision to accept it. I, for one, will be happy to get any
outside contributions and will be generally accepting of those
contributions even if they don't meet all potential needs. You have
to start somewhere.
Anyway, that's my opinion ... :)
Cheers
Paul
On 28-Oct-06, at 1:17 PM, Jason Birch wrote:
> Does working group sound better? :)
>
> I think that the website, documentation, etc will be an area where
> non-developers will really be able to contribute, and the split
> between coding/presentation is clear enough (at least in my fuzzy
> mind) that splitting the work between coders/documentors would be
> reasonable. As an aside, I think that these two roles would need
> to be distinct in LDAP. Anyway, this is a while down the road and
> will come up again.
>
> I don't buy that a solution a developer has thought through and
> even coded themselves is necessesarily the best solution for the
> project. By nature a single individual, or even a single
> organisation, does not have the breadth of experience or
> understanding of the problem realm to create a solution that is the
> best fit for our entire user base. We need to ensure that the
> project does not turn into a Frankenstein's monster of solutions
> that have been built in isolation. The problem is that the
> investment (time and emotion) in fait-accomplis solutions is such
> that it is difficult to shift their path once they are presented
> unless there is a severe defect.
>
> I concede that a lot of the existing development will likely come
> as pre-canned solutions because of where this project is starting
> from, and that in some cases it will be desirable to accept
> contributions to the code base that have been developed in
> isolation, but I really want to stress that by default we should
> have open development starting at the conceptualisation phase.
>
> Jason
>
>
> ________________________________
>
> From: Robert Bray [mailto:rbray@robertbray.net]
> Sent: Sat 2006-10-28 12:00 AM
> To: psc@mapguide.osgeo.org
> Subject: Re: [mapguide-psc] RFC process...
>
>
>
> Jason,
>
> Personally I would like to avoid subcommittees, mainly because of the
> pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
> for the web site is a different debate, maybe / maybe not. It really
> depends on the scope of the change.
>
> To address your core concern though, I expect a mix of RFCs. Some will
> start with lots of discussion on the dev list and evolve into a fully
> baked RFC. Others may come pre-baked, because the developer has
> already
> thought it through pretty thoroughly (and maybe even has a prototype
> running). It really depends highly on the author and what is being
> proposed. The key is to welcome active discussion of ideas on the dev
> list. Also remember that an RFC is a living document up until the time
> it is voted on and approved. It can start with just an idea and no
> implementation detail. We should make that clear on the how to
> create an
> RFC page (hmm guess we need one of those).
>
> Does that clarify or confuse the issue more?
>
> Bob
>
> Jason Birch wrote:
>> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
>>
>> Do we really want the RFC process to apply to the web site? Maybe
>> for major overhauls, but personally I think that this kind of
>> thing could be better dealt with informally, perhaps by a web site
>> subcommittee.
>>
>> Also, I'm a bit scared of an RFC process that appears to expect
>> the presentation of a well-thought-out canned solution, which is
>> then subject to debate on the DEV list. I think that we should be
>> encouraging an informal process where a problem/solution pair (or
>> just the problem) is put forward to the DEV list/channel as a
>> rough WIKI page, and is then debated and polished into a form
>> where it can be submitted as an RFC.
>>
>> This kind of process gives us better solutions, and ensures that
>> the original submitter only needs to do a limited amount of work
>> before starting the discussion, reducing the emotional attachment
>> to a particular solution.
>>
>> Jason
>>
>>
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From haris at sl-king.com Sat Oct 28 13:36:28 2006
From: haris at sl-king.com (Haris Kurtagic)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7F5@starfish.nanaimo.ca>
Message-ID: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com>
This is my first time involvement in open source and don't know much
about RFC's, so I hope I am on topic.
I would like to point that I think that every person comment counts, no
meter if user/developer/..
So, I think this RFC's templates needs to be easy understandable and
that every one can express opinion no metter on skills.
It is not good if they are too techincal and pre-finished so
non-developers got "affraid" to contribute to them.
I suppose this is not new and presumably we all agree on this. Anyhow I
wanted to express my opinion.
Haris
________________________________
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Saturday, October 28, 2006 7:17 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] RFC process...
Does working group sound better? :)
I think that the website, documentation, etc will be an area where
non-developers will really be able to contribute, and the split between
coding/presentation is clear enough (at least in my fuzzy mind) that
splitting the work between coders/documentors would be reasonable. As
an aside, I think that these two roles would need to be distinct in
LDAP. Anyway, this is a while down the road and will come up again.
I don't buy that a solution a developer has thought through and even
coded themselves is necessesarily the best solution for the project. By
nature a single individual, or even a single organisation, does not have
the breadth of experience or understanding of the problem realm to
create a solution that is the best fit for our entire user base. We
need to ensure that the project does not turn into a Frankenstein's
monster of solutions that have been built in isolation. The problem is
that the investment (time and emotion) in fait-accomplis solutions is
such that it is difficult to shift their path once they are presented
unless there is a severe defect.
I concede that a lot of the existing development will likely come as
pre-canned solutions because of where this project is starting from, and
that in some cases it will be desirable to accept contributions to the
code base that have been developed in isolation, but I really want to
stress that by default we should have open development starting at the
conceptualisation phase.
Jason
________________________________
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Sat 2006-10-28 12:00 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason,
Personally I would like to avoid subcommittees, mainly because of the
pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
for the web site is a different debate, maybe / maybe not. It really
depends on the scope of the change.
To address your core concern though, I expect a mix of RFCs. Some will
start with lots of discussion on the dev list and evolve into a fully
baked RFC. Others may come pre-baked, because the developer has already
thought it through pretty thoroughly (and maybe even has a prototype
running). It really depends highly on the author and what is being
proposed. The key is to welcome active discussion of ideas on the dev
list. Also remember that an RFC is a living document up until the time
it is voted on and approved. It can start with just an idea and no
implementation detail. We should make that clear on the how to create an
RFC page (hmm guess we need one of those).
Does that clarify or confuse the issue more?
Bob
Jason Birch wrote:
> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
>
> Do we really want the RFC process to apply to the web site? Maybe for
major overhauls, but personally I think that this kind of thing could be
better dealt with informally, perhaps by a web site subcommittee.
>
> Also, I'm a bit scared of an RFC process that appears to expect the
presentation of a well-thought-out canned solution, which is then
subject to debate on the DEV list. I think that we should be
encouraging an informal process where a problem/solution pair (or just
the problem) is put forward to the DEV list/channel as a rough WIKI
page, and is then debated and polished into a form where it can be
submitted as an RFC.
>
> This kind of process gives us better solutions, and ensures that the
original submitter only needs to do a limited amount of work before
starting the discussion, reducing the emotional attachment to a
particular solution.
>
> Jason
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/552136db/attachment.html
From Jason.Birch at nanaimo.ca Sat Oct 28 13:58:38 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <8E468917B01800408B91984428BE03DD0385F7F4@starfish.nanaimo.ca> <45430010.1060403@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7F5@starfish.nanaimo.ca> <2144A54B-2FFB-4728-8664-F78DAF939C96@dmsolutions.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7F8@starfish.nanaimo.ca>
Paul,
I'm less worried about a feature not meeting all needs, than I am about a feature limiting our ability to solve those other needs in the future.
You said, "it is better to have the feature than to not have it." This is what worries me. Although as a PSC we will have the ability to say No or Try Again, it will be difficult to exercise this negative power when presented with a feature that meets some needs. The developers that are contributing the code will end up driving the direction of the product, rather than the PSC. I think that by encouraging discussion prior to submission or at the starting point of the RFC, we will end up with a bettter product and reduce the amount of times the code has to be refactored to meet some "unforeseen" need.
I'm not saying that we would reject outright contributions (after all, the contributions will not be developed in the absense of user need), but the current RFC template/process seems to encourage private conceptualisation and implementation in advance of submission.
I'm a little worried that I'm in the minority here, as most of the PSC have independantly developed contributions, and because as a non-developer I can be written off as impractical :)
Jason
________________________________
From: Paul Spencer
Sent: Sat 2006-10-28 10:34 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason, I agree in principle but not in practice. Don't forget that
this is an open source project and we are trying to encourage
participation and contribution through volunteer efforts :)
If someone has thought through and implemented a workable solution,
that's actually a pretty decent start. It may not be the best way to
solve a problem, but as long as the code is sound and architecturally
in line with the project, it is better to have the feature than to
not have it.
People will generally contribute stuff that solves a problem for
them, not for anyone else. There is not a lot of incentive to solve
a problem that doesn't impact them.
We (the PSC) has the power to accept or reject an RFC, or to turn it
back for rewriting with comments. And at the end of the day, it is a
group decision to accept it. I, for one, will be happy to get any
outside contributions and will be generally accepting of those
contributions even if they don't meet all potential needs. You have
to start somewhere.
Anyway, that's my opinion ... :)
Cheers
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5346 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/9cf56398/attachment.bin
From Jason.Birch at nanaimo.ca Sat Oct 28 14:00:04 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca>
Hey, I agree. It's an argument in my favour :)
Bob, can I get content developer (or contributor, or whatever is needed for www changes) rights to the MapGuide project? I'd like to update the PSC page to add Haris.
Jason
________________________________
From: Haris Kurtagic
Sent: Sat 2006-10-28 10:36 AM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] RFC process...
This is my first time involvement in open source and don't know much about RFC's, so I hope I am on topic.
I would like to point that I think that every person comment counts, no meter if user/developer/..
So, I think this RFC's templates needs to be easy understandable and that every one can express opinion no metter on skills.
It is not good if they are too techincal and pre-finished so non-developers got "affraid" to contribute to them.
I suppose this is not new and presumably we all agree on this. Anyhow I wanted to express my opinion.
Haris
________________________________
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Saturday, October 28, 2006 7:17 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] RFC process...
Does working group sound better? :)
I think that the website, documentation, etc will be an area where non-developers will really be able to contribute, and the split between coding/presentation is clear enough (at least in my fuzzy mind) that splitting the work between coders/documentors would be reasonable. As an aside, I think that these two roles would need to be distinct in LDAP. Anyway, this is a while down the road and will come up again.
I don't buy that a solution a developer has thought through and even coded themselves is necessesarily the best solution for the project. By nature a single individual, or even a single organisation, does not have the breadth of experience or understanding of the problem realm to create a solution that is the best fit for our entire user base. We need to ensure that the project does not turn into a Frankenstein's monster of solutions that have been built in isolation. The problem is that the investment (time and emotion) in fait-accomplis solutions is such that it is difficult to shift their path once they are presented unless there is a severe defect.
I concede that a lot of the existing development will likely come as pre-canned solutions because of where this project is starting from, and that in some cases it will be desirable to accept contributions to the code base that have been developed in isolation, but I really want to stress that by default we should have open development starting at the conceptualisation phase.
Jason
________________________________
From: Robert Bray [mailto:rbray@robertbray.net]
Sent: Sat 2006-10-28 12:00 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason,
Personally I would like to avoid subcommittees, mainly because of the
pain OSGeo is feeling now due to fragmentation. Whether we need an RFC
for the web site is a different debate, maybe / maybe not. It really
depends on the scope of the change.
To address your core concern though, I expect a mix of RFCs. Some will
start with lots of discussion on the dev list and evolve into a fully
baked RFC. Others may come pre-baked, because the developer has already
thought it through pretty thoroughly (and maybe even has a prototype
running). It really depends highly on the author and what is being
proposed. The key is to welcome active discussion of ideas on the dev
list. Also remember that an RFC is a living document up until the time
it is voted on and approved. It can start with just an idea and no
implementation detail. We should make that clear on the how to create an
RFC page (hmm guess we need one of those).
Does that clarify or confuse the issue more?
Bob
Jason Birch wrote:
> http://wiki.osgeo.org/index.php/MapGuide_RFC_Template
>
> Do we really want the RFC process to apply to the web site? Maybe for major overhauls, but personally I think that this kind of thing could be better dealt with informally, perhaps by a web site subcommittee.
>
> Also, I'm a bit scared of an RFC process that appears to expect the presentation of a well-thought-out canned solution, which is then subject to debate on the DEV list. I think that we should be encouraging an informal process where a problem/solution pair (or just the problem) is put forward to the DEV list/channel as a rough WIKI page, and is then debated and polished into a form where it can be submitted as an RFC.
>
> This kind of process gives us better solutions, and ensures that the original submitter only needs to do a limited amount of work before starting the discussion, reducing the emotional attachment to a particular solution.
>
> Jason
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8614 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/2e3ac1c8/attachment.bin
From rbray at robertbray.net Sat Oct 28 14:25:01 2006
From: rbray at robertbray.net (Robert Bray)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca>
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca>
Message-ID: <4543A07D.509@robertbray.net>
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/90999c58/attachment.html
From Jason.Birch at nanaimo.ca Sat Oct 28 19:02:59 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca> <4543A07D.509@robertbray.net>
Message-ID: <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca>
Discussion, not conflict :)
I actually believe that the template and official process will be applicable regardless. What I would like to do would be to prefix the official RFC process document with something like this:
"
There is nothing stopping you from developing a solution to your problem independantly and presenting it as a version 1.0 RFC. However, this approach has several pitfalls. First, you risk duplication of effort. If you are seeing a limitation in the current code, it's likely that others have too and may be developing a solution independantly. Second, you risk having to expend considerable effort refactoring your code if it meets with valid objections during the RFC process. Third, even if your solution is accepted (we DO like features) you risk having to expend more effort in the future fixing your code to solve an unseen problem that the community could have caught in an open development process.
The preferred way of creating an RFC is to write up a loose business case and proposed solution on the wiki and then ask for informal input on the dev list/channel before formally presenting it to the PSC for review. This will ensure that your solution is the best possible fit for the project's direction, ease your RFC's way through the process, and increase the overall value of the project.
"
Thoughts?
Jason
________________________________
From: Robert Bray
Sent: Sat 2006-10-28 11:25 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason,
I updated the PSC page and also granted you the Documentation Developer role so you can make changes to the website. As for our little conflict, do you think you could maybe outline the process you feel we should use so we can understand it better? Maybe that will allow us to come up with a happy little compromise in the middle.
Thanks,
Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4778 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061028/b35e8738/attachment.bin
From pspencer at dmsolutions.ca Sun Oct 29 14:53:50 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca>
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca> <4543A07D.509@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca>
Message-ID:
Jason,
From mapserver experience, I know that there are some developers
(who are committers even) who prefer not to go through the
bureaucratic nausea of the RFC process to implement something.
I won't argue further against this point, but I really feel that it
is both unnecessary and unnecessarily daunting.
I'm -0 on this :)
Paul
On 28-Oct-06, at 7:02 PM, Jason Birch wrote:
> Discussion, not conflict :)
>
> I actually believe that the template and official process will be
> applicable regardless. What I would like to do would be to prefix
> the official RFC process document with something like this:
>
> "
> There is nothing stopping you from developing a solution to your
> problem independantly and presenting it as a version 1.0 RFC.
> However, this approach has several pitfalls. First, you risk
> duplication of effort. If you are seeing a limitation in the
> current code, it's likely that others have too and may be
> developing a solution independantly. Second, you risk having to
> expend considerable effort refactoring your code if it meets with
> valid objections during the RFC process. Third, even if your
> solution is accepted (we DO like features) you risk having to
> expend more effort in the future fixing your code to solve an
> unseen problem that the community could have caught in an open
> development process.
>
> The preferred way of creating an RFC is to write up a loose
> business case and proposed solution on the wiki and then ask for
> informal input on the dev list/channel before formally presenting
> it to the PSC for review. This will ensure that your solution is
> the best possible fit for the project's direction, ease your RFC's
> way through the process, and increase the overall value of the
> project.
> "
>
> Thoughts?
>
> Jason
>
> ________________________________
>
> From: Robert Bray
> Sent: Sat 2006-10-28 11:25 AM
> To: psc@mapguide.osgeo.org
> Subject: Re: [mapguide-psc] RFC process...
>
>
> Jason,
>
> I updated the PSC page and also granted you the Documentation
> Developer role so you can make changes to the website. As for our
> little conflict, do you think you could maybe outline the process
> you feel we should use so we can understand it better? Maybe that
> will allow us to come up with a happy little compromise in the middle.
>
> Thanks,
> Bob
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Sun Oct 29 16:13:42 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca> <4543A07D.509@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F803@starfish.nanaimo.ca>
Oh no, can't close the discussion that easily; keep arguing :)
Do you think that we should do away with the RFC project, and just let developers commit as they want? I know that there are lots of developers that prefer to just build stuff, and most are smart enough to come up with solutions that are reasonably generic while solving their particular needs. I don't want to discredit this kind of contribution.
I guess my main concern here is that if we design the RFC process as basically an afterthought, the PMC becomes a reactive and negative body rather than a proactive and positive one. In open source development, egos play such a large role that when faced with complete solutions the PMC will likely choose to avoid confrontation unless there is a severe outstanding defect in the implementation. Again, not having community direction and a common vision here will leave us with a Frankenstein's monster. I have an incredible amout of respect for what happenned with the GeoRSS spec, and is now happening with the tiling spec, and would love to see that kind of process around new features in MapGuide.
I wasn't suggesting that the entire RFC process be completed before any code is implemented. I think that once the initial collaborative brainstorming on the problem, general solution, and implications are done on the DEV list/channel (where the PMC participates), it would be safe to just go ahead and implement in a development branch, with the assurance that the feature already has the buy-in of the community. At this point any changes made during the RFC process before commit to trunk would be minor at worst.
This would allow the PMC to take on a more positive role, setting a general vision and communicating any concerns with specific implementations on the DEV list at an early stage of development. Any negative energy could be saved for features that are presented implementation-complete.
This whole discussion is only really relevant for large features/refactorings. Small or obvious features (such as adding a new version of WMS support) will likely just be met with a "looks good" on the dev list, and then breeze through the RFC process.
Another option would be to make the acceptance process more rigourous. Instead of requiring only two positive votes, a feature would require 50% + 1 of the active PMC to accept it. While this might encourage developers to pay close attention to the direction set by the PMC for the product, it also has a considerable downside in required structure and uncertainty of feature adoption.
Jason
________________________________
From: Paul Spencer
Sent: Sun 2006-10-29 11:53 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RFC process...
Jason,
From mapserver experience, I know that there are some developers
(who are committers even) who prefer not to go through the
bureaucratic nausea of the RFC process to implement something.
I won't argue further against this point, but I really feel that it
is both unnecessary and unnecessarily daunting.
I'm -0 on this :)
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5882 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061029/24c86f7d/attachment.bin
From Jason.Birch at nanaimo.ca Sun Oct 29 16:13:55 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca> <4543A07D.509@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca> <8E468917B01800408B91984428BE03DD0385F803@starfish.nanaimo.ca>
Message-ID: <8E468917B01800408B91984428BE03DD0385F804@starfish.nanaimo.ca>
And by the way, feel free to tell me to shut up at any time. I do tend to get caught up in process and over-analyse things. I'm much happier when I've been convinced that I'm wrong though.
________________________________
From: Jason Birch
Sent: Sun 2006-10-29 1:13 PM
Subject: RE: [mapguide-psc] RFC process...
Oh no, can't close the discussion that easily; keep arguing :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3718 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061029/06262bae/attachment.bin
From pspencer at dmsolutions.ca Sun Oct 29 22:18:58 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RFC process...
In-Reply-To: <8E468917B01800408B91984428BE03DD0385F803@starfish.nanaimo.ca>
References: <689794E3063F0544ABB40771AF8BA2290A184A@exchange2.sl-king.com> <8E468917B01800408B91984428BE03DD0385F7F9@starfish.nanaimo.ca> <4543A07D.509@robertbray.net> <8E468917B01800408B91984428BE03DD0385F7FB@starfish.nanaimo.ca> <8E468917B01800408B91984428BE03DD0385F803@starfish.nanaimo.ca>
Message-ID: <57858D29-DE53-4728-BFEA-17CAE65ECCA3@dmsolutions.ca>
Ok, ok ... I'll keep arguing ... ;)
On 29-Oct-06, at 4:13 PM, Jason Birch wrote:
> This whole discussion is only really relevant for large features/
> refactorings. Small or obvious features (such as adding a new
> version of WMS support) will likely just be met with a "looks good"
> on the dev list, and then breeze through the RFC process.
perhaps this meets my concern ... we can include something like the
text you proposed before but I think it needs to be either preceded
by the above or modified to be more in line with the above. What you
wrote before made it sound like if I tried to develop anything for
mapguide without first consulting the PSC, I could be in a world of
hurt :)
This also mostly applies to developers who are not currently
committers, people who want to hack in a new feature relatively
quickly and are willing to contribute it but might not even attempt
after reading your caveats on development. I want to make it as easy
and painless as possible for these folks, quality and usefulness of
the code notwithstanding.
I think we were thinking at different ends of the scale of
contribution. I don't expect non-committers to bring in large
features and refactoring ... the code base is probably too large and
complex for someone to be able to do something large without talking
to the dev list ... so we'll know about it before anyway.
Paul
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From amorsell at spatialgis.com Mon Oct 30 10:23:43 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:17 2006
Subject: PSC added to Nabble
Message-ID: <008801c6fc37$637683b0$6501a8c0@SPINAJM>
For those who use Nabble Forums for viewing archived messages (or as a
regular message reader), I have added MapGuide PSC to the OSGeo group.
Messages started getting picked up on Sunday, October 30, so it is missing
some of the earlier communication. It can be found here:
http://www.nabble.com/MapGuide-PSC-f16492.html
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061030/ab82b2ec/attachment.html
From tom.fukushima at autodesk.com Mon Oct 30 14:03:31 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
Message-ID:
Hi Paul,
Yes, I dislike the merge overhead as well, but it should not be a big
pain as long as there are no more reorgs of the code. I do have some
guys who are working on things that won't fit in the 1.1.x timeline and
so the branch will allow them to continue working. Are you ok with the
branch happening today/tomorrow or would you like some more lead time on
this one.
Thanks
Tom
-----Original Message-----
From: Paul Spencer (External)
Sent: Friday, October 27, 2006 6:26 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
Jason, my feeling is that is just to allow for 1.2 features. My
experience in most of the projects I've been involved in is that it is
desirable to branch as late as possible to reduce the overhead of
porting bug fixes between branches. MapServer certainly works this way.
Part of the reason for this, though, was the use of cvs (as opposed to
svn), which made it very difficult to branch and merge. Svn is
substantially different in this respect and I expect to see this aspect
of projects change as svn is used more and more.
Cheers
Paul
On 27-Oct-06, at 4:27 PM, Jason Birch wrote:
> PSC,
>
> When this branch is created, does that mean that we go into feature
> freeze (in prep for Beta/RC releases), or is it just to allow 1.2
> features to start working their way into the trunk?
>
> Jason
>
> From: Tom Fukushima [mailto:tom.fukushima@autodesk.com]
> Sent: Friday, October 27, 2006 13:20
> To: dev@mapguide.osgeo.org
> Subject: [mapguide-dev] 1.1.x branch
>
> Hi,
>
> I would like to target next Monday (or Tuesday) for when we create a
> 1.1.x branch off of the trunk. This branch will hold all current
> submissions to the trunk to date. I will be enumerating the list of
> things that are in 1.1.x to date in a subsequent email.
>
> Tom
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From pspencer at dmsolutions.ca Mon Oct 30 14:58:00 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
In-Reply-To:
References:
Message-ID:
good by me :)
On 30-Oct-06, at 2:03 PM, Tom Fukushima wrote:
> Hi Paul,
>
> Yes, I dislike the merge overhead as well, but it should not be a big
> pain as long as there are no more reorgs of the code. I do have some
> guys who are working on things that won't fit in the 1.1.x timeline
> and
> so the branch will allow them to continue working. Are you ok with
> the
> branch happening today/tomorrow or would you like some more lead
> time on
> this one.
>
> Thanks
> Tom
>
> -----Original Message-----
> From: Paul Spencer (External)
> Sent: Friday, October 27, 2006 6:26 PM
> To: psc@mapguide.osgeo.org
> Subject: Re: [mapguide-psc] RE: [mapguide-dev] 1.1.x branch
>
> Jason, my feeling is that is just to allow for 1.2 features. My
> experience in most of the projects I've been involved in is that it is
> desirable to branch as late as possible to reduce the overhead of
> porting bug fixes between branches. MapServer certainly works this
> way.
>
> Part of the reason for this, though, was the use of cvs (as opposed to
> svn), which made it very difficult to branch and merge. Svn is
> substantially different in this respect and I expect to see this
> aspect
> of projects change as svn is used more and more.
>
> Cheers
>
> Paul
>
> On 27-Oct-06, at 4:27 PM, Jason Birch wrote:
>
>> PSC,
>>
>> When this branch is created, does that mean that we go into feature
>> freeze (in prep for Beta/RC releases), or is it just to allow 1.2
>> features to start working their way into the trunk?
>>
>> Jason
>>
>> From: Tom Fukushima [mailto:tom.fukushima@autodesk.com]
>> Sent: Friday, October 27, 2006 13:20
>> To: dev@mapguide.osgeo.org
>> Subject: [mapguide-dev] 1.1.x branch
>>
>> Hi,
>>
>> I would like to target next Monday (or Tuesday) for when we create a
>> 1.1.x branch off of the trunk. This branch will hold all current
>> submissions to the trunk to date. I will be enumerating the list of
>> things that are in 1.1.x to date in a subsequent email.
>>
>> Tom
>>
>>
>
> +-----------------------------------------------------------------+
> |Paul Spencer pspencer@dmsolutions.ca |
> +-----------------------------------------------------------------+
> |Chief Technology Officer |
> |DM Solutions Group Inc http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From bruce.dechant at autodesk.com Tue Oct 31 13:20:24 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:17 2006
Subject: MapGuide's 1st RFC!
Message-ID:
Hi All,
I wrote up a simple MapGuide RFC to give our process a trial run.
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
Please have a look and post any feedback.
Thanks,
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/877b1d5a/attachment.html
From warmerdam at pobox.com Tue Oct 31 13:43:17 2006
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Dec 22 16:09:17 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To:
References:
Message-ID: <45479945.3070703@pobox.com>
Bruce Dechant wrote:
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
Bruce,
As an infrequent user of mapguide I'd like to discourage unnecessary backward
incompatible changes. Perhaps /testmode, -testmode, /test and -test could
all work? That is, continue to support the old names, but document the
new shorter versions.
I'm speaking as a long enemy of "churn" who greatly values the few little
bits of knowledge he has collected about mapguide.
PS. Is the plan that mapguide RFCs only be distributed on the psc list? It
seems this is likely to exclude most users and many developers from knowing
an RFC is cooking that might affect them. I'm also not a big fan of seperate
psc lists.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
From bruce.dechant at autodesk.com Tue Oct 31 13:49:29 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
Thanks for the feedback Frank.
I also posted the RFC to the dev list, but used a separate email is all.
Bruce
-----Original Message-----
From: Frank Warmerdam (External)
Sent: October 31, 2006 11:43 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
Bruce Dechant wrote:
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
>
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
Bruce,
As an infrequent user of mapguide I'd like to discourage unnecessary
backward
incompatible changes. Perhaps /testmode, -testmode, /test and -test
could
all work? That is, continue to support the old names, but document the
new shorter versions.
I'm speaking as a long enemy of "churn" who greatly values the few
little
bits of knowledge he has collected about mapguide.
PS. Is the plan that mapguide RFCs only be distributed on the psc list?
It
seems this is likely to exclude most users and many developers from
knowing
an RFC is cooking that might affect them. I'm also not a big fan of
seperate
psc lists.
Best regards,
--
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo,
http://osgeo.org
From warmerdam at pobox.com Tue Oct 31 14:01:38 2006
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To:
References:
Message-ID: <45479D92.4090303@pobox.com>
Bruce Dechant wrote:
> Thanks for the feedback Frank.
>
> I also posted the RFC to the dev list, but used a separate email is all.
Bruce,
Ah, cool.
In fact, I suspect I'm not on the -dev list. I'm on the user list, and
only joined the psc list to get a feel for how stuff is going for
mapguide since it is likely to be a template for the fdo psc.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
From amorsell at spatialgis.com Tue Oct 31 14:08:42 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To:
Message-ID: <01ae01c6fd1f$fb591290$6501a8c0@SPINAJM>
I agree with Frank in that keeping it backwards compatible with the older
command line parameters while in the future only documenting the new ones
would be the best. There are many references, mostly in archived messages
in the mapguide-users mailing list, to the current parameter syntax that new
users are bound to run across (and try to use) when doing research.
Regarding the RFC format, that seems to work very well.
Andy
_____
From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
Sent: Tuesday, October 31, 2006 10:20 AM
To: psc@mapguide.osgeo.org
Subject: [mapguide-psc] MapGuide's 1st RFC!
Hi All,
I wrote up a simple MapGuide RFC to give our process a trial run.
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
Please have a look and post any feedback.
Thanks,
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/b9f94075/attachment.html
From pspencer at dmsolutions.ca Tue Oct 31 14:29:16 2006
From: pspencer at dmsolutions.ca (Paul Spencer)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To: <01ae01c6fd1f$fb591290$6501a8c0@SPINAJM>
References: <01ae01c6fd1f$fb591290$6501a8c0@SPINAJM>
Message-ID: <39B194A5-2669-49CE-9236-2FAB7439EC85@dmsolutions.ca>
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of
adding parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting
> the new ones would be the best. There are many references, mostly
> in archived messages in the mapguide-users mailing list, to the
> current parameter syntax that new users are bound to run across
> (and try to use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From bruce.dechant at autodesk.com Tue Oct 31 14:34:37 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
If you do enter an incorrect commandline parameter you already get the
following response from the MapGuide server to the console: (Windows
version shown below)
Unrecognized option: "/hello".
MapGuide Server
The following is a list of supported command line options:
/? or /help
Displays this information.
/install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
/interactive
Runs the server interactively as an application instead of a
service.
/start
Starts the server service. Note: The service must be installed.
/stop
Stops the server service. Note: The service must be installed.
/testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
/testmode /t /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
/uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Paul Spencer (External)
Sent: October 31, 2006 12:29 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of
adding parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting
> the new ones would be the best. There are many references, mostly
> in archived messages in the mapguide-users mailing list, to the
> current parameter syntax that new users are bound to run across
> (and try to use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From amorsell at spatialgis.com Tue Oct 31 14:42:10 2006
From: amorsell at spatialgis.com (Andy Morsell)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To: <39B194A5-2669-49CE-9236-2FAB7439EC85@dmsolutions.ca>
Message-ID: <01b601c6fd24$a82c18b0$6501a8c0@SPINAJM>
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would be
relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter should
be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really don't
see this as a big issue. Perhaps if the tool just spits out an appropriate
message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From dmorissette at mapgears.com Tue Oct 31 15:04:22 2006
From: dmorissette at mapgears.com (Daniel Morissette)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
In-Reply-To:
References:
Message-ID: <4547AC46.5020405@mapgears.com>
Bruce Dechant wrote:
> Hi All,
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
>
> Please have a look and post any feedback.
>
What about adding a standard header or RFC status section with the
following information that would be useful when we look at it in a few
years:
- Date (proposal date, adoption date, last update date, or all of them?)
- Author
- Status: draft, proposed/pending vote, adopted or rejected
- Implementation status: pending, under development, completed (or is
this too much detail?)
- software version this RFC applies to
- voting history
I realize that Author and Date are there at the bottom as Wiki fields,
but I think making them part of the standard header might be a good idea
in case the doc is migrated away from the wiki.
My 0.02$
Daniel
--
Daniel Morissette
http://www.mapgears.com/
From bruce.dechant at autodesk.com Tue Oct 31 15:08:25 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
I like the idea of the status section.
If there are no objections I'll update the RFC with one.
Bruce
-----Original Message-----
From: Daniel Morissette [mailto:dmorissette@mapgears.com]
Sent: October 31, 2006 1:04 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
Bruce Dechant wrote:
> Hi All,
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
>
> Please have a look and post any feedback.
>
What about adding a standard header or RFC status section with the
following information that would be useful when we look at it in a few
years:
- Date (proposal date, adoption date, last update date, or all of them?)
- Author
- Status: draft, proposed/pending vote, adopted or rejected
- Implementation status: pending, under development, completed (or is
this too much detail?)
- software version this RFC applies to
- voting history
I realize that Author and Date are there at the bottom as Wiki fields,
but I think making them part of the standard header might be a good idea
in case the doc is migrated away from the wiki.
My 0.02$
Daniel
--
Daniel Morissette
http://www.mapgears.com/
From tom.fukushima at autodesk.com Tue Oct 31 15:14:23 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
+1
Bruce, while you're at it, could you also put it into the RFC template?
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 1:08 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I like the idea of the status section.
If there are no objections I'll update the RFC with one.
Bruce
-----Original Message-----
From: Daniel Morissette [mailto:dmorissette@mapgears.com]
Sent: October 31, 2006 1:04 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
Bruce Dechant wrote:
> Hi All,
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
>
> Please have a look and post any feedback.
>
What about adding a standard header or RFC status section with the
following information that would be useful when we look at it in a few
years:
- Date (proposal date, adoption date, last update date, or all of them?)
- Author
- Status: draft, proposed/pending vote, adopted or rejected
- Implementation status: pending, under development, completed (or is
this too much detail?)
- software version this RFC applies to
- voting history
I realize that Author and Date are there at the bottom as Wiki fields,
but I think making them part of the standard header might be a good idea
in case the doc is migrated away from the wiki.
My 0.02$
Daniel
--
Daniel Morissette
http://www.mapgears.com/
From bruce.dechant at autodesk.com Tue Oct 31 15:30:27 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
Sure I can. :)
-----Original Message-----
From: Tom Fukushima
Sent: October 31, 2006 1:14 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
+1
Bruce, while you're at it, could you also put it into the RFC template?
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 1:08 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I like the idea of the status section.
If there are no objections I'll update the RFC with one.
Bruce
-----Original Message-----
From: Daniel Morissette [mailto:dmorissette@mapgears.com]
Sent: October 31, 2006 1:04 PM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
Bruce Dechant wrote:
> Hi All,
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
http://wiki.osgeo.org/index.php/MG_RFC_1_-_Commandline_parameter_changes
>
> Please have a look and post any feedback.
>
What about adding a standard header or RFC status section with the
following information that would be useful when we look at it in a few
years:
- Date (proposal date, adoption date, last update date, or all of them?)
- Author
- Status: draft, proposed/pending vote, adopted or rejected
- Implementation status: pending, under development, completed (or is
this too much detail?)
- software version this RFC applies to
- voting history
I realize that Author and Date are there at the bottom as Wiki fields,
but I think making them part of the standard header might be a good idea
in case the doc is migrated away from the wiki.
My 0.02$
Daniel
--
Daniel Morissette
http://www.mapgears.com/
From bruce.dechant at autodesk.com Tue Oct 31 16:49:09 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be
relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should
be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't
see this as a big issue. Perhaps if the tool just spits out an
appropriate
message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From tom.fukushima at autodesk.com Tue Oct 31 22:22:08 2006
From: tom.fukushima at autodesk.com (Tom Fukushima)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
Message-ID:
Yes, I would like to see both formats ("/" and "-") supported as well.
But when the user gets the command line help by typing "mgserver -?" or
"mgserver --help" (note the double dash), I propose that we only show
the "-" versions of the options. Of course, this is a bit confusing to
those users who want to figure out what /interactive means; Bruce, why
are we changing "interactive" to "run"? Or will "mgserver -interactive"
also work?
So typing "mgserver --help" outputs:
The following is a list of supported command line options:
-? or --help
Displays this information.
-install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
-run
Runs the server interactively as an application instead of a
service.
-start
Starts the server service. Note: The service must be installed.
-stop
Stops the server service. Note: The service must be installed.
-testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
-test /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
-uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 2:49 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
From Jason.Birch at nanaimo.ca Tue Oct 31 22:33:00 2006
From: Jason.Birch at nanaimo.ca (Jason Birch)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
References:
Message-ID: <8E468917B01800408B91984428BE03DD0385F83A@starfish.nanaimo.ca>
Or why not make "interactive" the default behaviour when you run the application, and only have the help show up if you do /help or /? or --help? This would be more in keeping with other apps I'm familiar with.
Can we change the process to require posting the RFC to DEV first for discussion then forward to PSC once any discussion is firmed up? Otherwise we'll be in crosspost hell forever. All of us should be on the dev list anyway.
I'm really looking forward to seeing what the advanced join RFC is about BTW (just to throw in another tla)...
Jason
________________________________
From: Tom Fukushima
Sent: Tue 2006-10-31 7:22 PM
To: psc@mapguide.osgeo.org; dev@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
Yes, I would like to see both formats ("/" and "-") supported as well.
But when the user gets the command line help by typing "mgserver -?" or
"mgserver --help" (note the double dash), I propose that we only show
the "-" versions of the options. Of course, this is a bit confusing to
those users who want to figure out what /interactive means; Bruce, why
are we changing "interactive" to "run"? Or will "mgserver -interactive"
also work?
So typing "mgserver --help" outputs:
The following is a list of supported command line options:
-? or --help
Displays this information.
-install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
-run
Runs the server interactively as an application instead of a
service.
-start
Starts the server service. Note: The service must be installed.
-stop
Stops the server service. Note: The service must be installed.
-testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
-test /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
-uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 2:49 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 9247 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/6d954c32/attachment.bin
From traian.stanev at autodesk.com Tue Oct 31 22:51:20 2006
From: traian.stanev at autodesk.com (Traian Stanev)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-dev] RE: [mapguide-psc] MapGuide's 1st RFC!
References:
Message-ID: <0345418B84C1684C8467DC5A2D7EFF6A01AE8109@msgusaebk01.autodesk.com>
Or, you can drop the - and / altogether and have something like:
mgserver start
mgserver stop
mgserver run
etc.
This would be similar to the apache command line, the subversion command line client, the ifconfig tool on Linux, the net command on Windows, etc., etc.
Traian
-----Original Message-----
From: Tom Fukushima
Sent: Tue 10/31/2006 10:22 PM
To: psc@mapguide.osgeo.org; dev@mapguide.osgeo.org
Cc:
Subject: [mapguide-dev] RE: [mapguide-psc] MapGuide's 1st RFC!
Yes, I would like to see both formats ("/" and "-") supported as well.
But when the user gets the command line help by typing "mgserver -?" or
"mgserver --help" (note the double dash), I propose that we only show
the "-" versions of the options. Of course, this is a bit confusing to
those users who want to figure out what /interactive means; Bruce, why
are we changing "interactive" to "run"? Or will "mgserver -interactive"
also work?
So typing "mgserver --help" outputs:
The following is a list of supported command line options:
-? or --help
Displays this information.
-install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
-run
Runs the server interactively as an application instead of a
service.
-start
Starts the server service. Note: The service must be installed.
-stop
Stops the server service. Note: The service must be installed.
-testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
-test /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
-uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 2:49 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mapguide.osgeo.org
For additional commands, e-mail: dev-help@mapguide.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/a549cdf3/attachment.html
From bruce.dechant at autodesk.com Tue Oct 31 22:58:28 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
References:
Message-ID:
I have changed the RFC to reflect that both "/" and "-" will work, but that the commandline help only shows the "-" options. Also, "interactive" will still be supported, but "run" is the new short version. :)
Bruce
-----Original Message-----
From: Tom Fukushima
Sent: Tue 10/31/2006 8:22 PM
To: psc@mapguide.osgeo.org; dev@mapguide.osgeo.org
Cc:
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
Yes, I would like to see both formats ("/" and "-") supported as well.
But when the user gets the command line help by typing "mgserver -?" or
"mgserver --help" (note the double dash), I propose that we only show
the "-" versions of the options. Of course, this is a bit confusing to
those users who want to figure out what /interactive means; Bruce, why
are we changing "interactive" to "run"? Or will "mgserver -interactive"
also work?
So typing "mgserver --help" outputs:
The following is a list of supported command line options:
-? or --help
Displays this information.
-install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
-run
Runs the server interactively as an application instead of a
service.
-start
Starts the server service. Note: The service must be installed.
-stop
Stops the server service. Note: The service must be installed.
-testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
-test /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
-uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 2:49 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/c246fd1e/attachment.html
From bruce.dechant at autodesk.com Tue Oct 31 23:01:26 2006
From: bruce.dechant at autodesk.com (Bruce Dechant)
Date: Fri Dec 22 16:09:18 2006
Subject: [mapguide-psc] MapGuide's 1st RFC!
References: <8E468917B01800408B91984428BE03DD0385F83A@starfish.nanaimo.ca>
Message-ID:
The default behavior is running the application as a Windows service or a Linux Daemon and not as a standalone application. Running the server interactively is mostly for developers so that they can more easily debug the server.
Bruce
-----Original Message-----
From: Jason Birch [mailto:Jason.Birch@nanaimo.ca]
Sent: Tue 10/31/2006 8:33 PM
To: psc@mapguide.osgeo.org; dev@mapguide.osgeo.org
Cc:
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
Or why not make "interactive" the default behaviour when you run the application, and only have the help show up if you do /help or /? or --help? This would be more in keeping with other apps I'm familiar with.
Can we change the process to require posting the RFC to DEV first for discussion then forward to PSC once any discussion is firmed up? Otherwise we'll be in crosspost hell forever. All of us should be on the dev list anyway.
I'm really looking forward to seeing what the advanced join RFC is about BTW (just to throw in another tla)...
Jason
_____
From: Tom Fukushima
Sent: Tue 2006-10-31 7:22 PM
To: psc@mapguide.osgeo.org; dev@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
Yes, I would like to see both formats ("/" and "-") supported as well.
But when the user gets the command line help by typing "mgserver -?" or
"mgserver --help" (note the double dash), I propose that we only show
the "-" versions of the options. Of course, this is a bit confusing to
those users who want to figure out what /interactive means; Bruce, why
are we changing "interactive" to "run"? Or will "mgserver -interactive"
also work?
So typing "mgserver --help" outputs:
The following is a list of supported command line options:
-? or --help
Displays this information.
-install
Installs the server as a service. Automatically starts the
service.
Default service display name installed:
"MapGuide Server"
You can use a different display name for the service if you
specify an
optional "Name".
-run
Runs the server interactively as an application instead of a
service.
-start
Starts the server service. Note: The service must be installed.
-stop
Stops the server service. Note: The service must be installed.
-testfdo
Runs the FDO unit tests.
Default output of the FDO unit tests will be the console unless
you
specify an optional "Filename". The output to the "Filename" will
be
in XML.
-test /o
Runs the server unit tests.
By default all of the unit tests will be run unless you specify an
optional "Test" to run. If you specify "List" as the test to run
you
will get a list of the available unit tests.
Default output of the unit tests will be the console unless you
specify
an optional "Filename". The output to the "Filename" will be in
XML.
-uninstall
Uninstalls an installed server service. Automatically stops the
service
before uninstalling.
Note: Only 1 command line option can be used at a time.
-----Original Message-----
From: Bruce Dechant
Sent: Tuesday, October 31, 2006 2:49 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I will be easy enough to support both. I'll update the RFC to reflect
this.
Bruce
-----Original Message-----
From: Andy Morsell [mailto:amorsell@spatialgis.com]
Sent: October 31, 2006 12:42 PM
To: psc@mapguide.osgeo.org
Subject: RE: [mapguide-psc] MapGuide's 1st RFC!
I agree, it's probably not a big issue. It depends on how much work it
would be on Bruce's end to support backwards compatibility. If it would
be relatively easy, then may as well do it. If it would require a large
effort, then the current console response to an incorrect parameter
should be sufficient for users to figure it out on their own.
Andy
-----Original Message-----
From: Paul Spencer [mailto:pspencer@dmsolutions.ca]
Sent: Tuesday, October 31, 2006 11:29 AM
To: psc@mapguide.osgeo.org
Subject: Re: [mapguide-psc] MapGuide's 1st RFC!
I am normally a big fan of backwards compatibility too, but I really
don't see this as a big issue. Perhaps if the tool just spits out an
appropriate message if called with incorrect parameters?
Then again, windows users are most likely used to the / style of adding
parameters so perhaps that makes it worthwhile supporting both?
Paul
On 31-Oct-06, at 2:08 PM, Andy Morsell wrote:
> I agree with Frank in that keeping it backwards compatible with the
> older command line parameters while in the future only documenting the
> new ones would be the best. There are many references, mostly in
> archived messages in the mapguide-users mailing list, to the current
> parameter syntax that new users are bound to run across (and try to
> use) when doing research.
>
> Regarding the RFC format, that seems to work very well.
>
> Andy
>
> From: Bruce Dechant [mailto:bruce.dechant@autodesk.com]
> Sent: Tuesday, October 31, 2006 10:20 AM
> To: psc@mapguide.osgeo.org
> Subject: [mapguide-psc] MapGuide's 1st RFC!
>
> Hi All,
>
>
>
> I wrote up a simple MapGuide RFC to give our process a trial run.
>
>
>
> http://wiki.osgeo.org/index.php/MG_RFC_1_-
> _Commandline_parameter_changes
>
>
>
> Please have a look and post any feedback.
>
>
>
> Thanks,
>
> Bruce
>
>
>
>
+-----------------------------------------------------------------+
|Paul Spencer pspencer@dmsolutions.ca |
+-----------------------------------------------------------------+
|Chief Technology Officer |
|DM Solutions Group Inc http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide_psc/attachments/20061031/ec600719/attachment.html