sync'ing mg21 branch in fusion to trunk
|
|
Paul Spencer-2
|
Its been several months since we've done any work on Fusion and
pushing it closer to a release ... no excuses, it just didn't happen : ( But I would like to start planning some work on Fusion to get it more stable and address some of the many issues logged in fusion trac, especially the ones that people have been kind enough to do the leg work on and propose fixes. Right now, I think MapGuide 2.1 is pulling fusion from a branch called fusion2-mg21. There are a few differences between this branch and the fusion-2.0 branch, and some of the mapguide-issues logged in mapguide and fusion trac could perhaps be addressed simply by switching to the 2.0 branch. Also, the other problem is that we have let the 2.0 branch languish and it is no longer quite relevant. I am going to propose to the Fusion community that we more-or-less abandon the existing 2.0 beta release and sync with the current trunk version and try again. This will mean more substantial changes and additions to 2.0 than would otherwise be acceptable once a beta version had been released ... but I think it is worth it for a couple of reasons: * we obviously have limited attention from developers contributing to fusion and trying to make time to release an out-of-date package seems like a poor use of their time. * there are some important changes in trunk like switching the client- side vector code over to use OpenLayers vectors that will further minimize the amount of maintenance we need to do while increasing functionality. * I think trunk is more stable than the 2.0 branch right now :) Question: Will MapGuide 2.1 include the 'official' 2.0 branch of Fusion if we restart the release process for 2.0 from the current state of fusion trunk? Feedback is welcome, of course. Cheers Paul __________________________________________ Paul Spencer Chief Technology Officer DM Solutions Group Inc http://research.dmsolutions.ca/ _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Jason Birch
|
Paul,
In general, I would be in favour of this approach. I haven't seen anything committed to Fusion trunk that would destabilize our existing functionality (correct me if I'm wrong), and we may benefit from additional fixes and from developers spending time fixing bugs instead of managing merges. And, as users have pointed out in the -users list, Fusion really needs a bit of work before it's usable with the current templates, and it hurts to release 2.1 with another "broken" version of Fusion. I could use a confirmation that the 2.0 Sheboygan samples are good with the 2.1 templates; I keep wondering if some of the bugs are because of problems using the 2.0 application definitions with the 2.1 templates. As a point of clarification, MG 2.1 beta is pulling from this branch: http://svn.osgeo.org/fusion/branches/fusion-2.0 I believe the other branch may have been used by Autodesk? Jason -----Original Message----- From: Paul Spencer Sent: Friday, July 03, 2009 5:29 AM To: MapGuide Internals Mail List Subject: [mapguide-internals] sync'ing mg21 branch in fusion to trunk Its been several months since we've done any work on Fusion and pushing it closer to a release ... no excuses, it just didn't happen : ( But I would like to start planning some work on Fusion to get it more stable and address some of the many issues logged in fusion trac, especially the ones that people have been kind enough to do the leg work on and propose fixes. Right now, I think MapGuide 2.1 is pulling fusion from a branch called fusion2-mg21. There are a few differences between this branch and the fusion-2.0 branch, and some of the mapguide-issues logged in mapguide and fusion trac could perhaps be addressed simply by switching to the 2.0 branch. Also, the other problem is that we have let the 2.0 branch languish and it is no longer quite relevant. I am going to propose to the Fusion community that we more-or-less abandon the existing 2.0 beta release and sync with the current trunk version and try again. This will mean more substantial changes and additions to 2.0 than would otherwise be acceptable once a beta version had been released ... but I think it is worth it for a couple of reasons: * we obviously have limited attention from developers contributing to fusion and trying to make time to release an out-of-date package seems like a poor use of their time. * there are some important changes in trunk like switching the client- side vector code over to use OpenLayers vectors that will further minimize the amount of maintenance we need to do while increasing functionality. * I think trunk is more stable than the 2.0 branch right now :) Question: Will MapGuide 2.1 include the 'official' 2.0 branch of Fusion if we restart the release process for 2.0 from the current state of fusion trunk? Feedback is welcome, of course. Cheers Paul _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
Walt Welton-Lair
|
Hi Paul / Jason,
I plan to prepare some fusion patches for MapGuide search-related defects (fusion tickets 236, 237, 268). I want to prepare these for all current versions of MapGuide: trunk, MGOS 2.1 beta, and the sandbox version used by Autodesk: * the sandbox version is based on fusion2-mg21 and I don't expect that to change, so I will prepare one set of patches against that stream * I'll prepare another set of patches against the trunk stream The one I'm wondering about is MGOS 2.1 which currently uses the fusion-2.0 stream. Has a decision been made as to what version of fusion it will use? I'll hold off preparing the patches for MGOS 2.1 until we know for sure. Thanks, Walt -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch Sent: Friday, July 03, 2009 4:18 PM To: MapGuide Internals Mail List Subject: RE: [mapguide-internals] sync'ing mg21 branch in fusion to trunk Paul, In general, I would be in favour of this approach. I haven't seen anything committed to Fusion trunk that would destabilize our existing functionality (correct me if I'm wrong), and we may benefit from additional fixes and from developers spending time fixing bugs instead of managing merges. And, as users have pointed out in the -users list, Fusion really needs a bit of work before it's usable with the current templates, and it hurts to release 2.1 with another "broken" version of Fusion. I could use a confirmation that the 2.0 Sheboygan samples are good with the 2.1 templates; I keep wondering if some of the bugs are because of problems using the 2.0 application definitions with the 2.1 templates. As a point of clarification, MG 2.1 beta is pulling from this branch: http://svn.osgeo.org/fusion/branches/fusion-2.0 I believe the other branch may have been used by Autodesk? Jason -----Original Message----- From: Paul Spencer Sent: Friday, July 03, 2009 5:29 AM To: MapGuide Internals Mail List Subject: [mapguide-internals] sync'ing mg21 branch in fusion to trunk Its been several months since we've done any work on Fusion and pushing it closer to a release ... no excuses, it just didn't happen : ( But I would like to start planning some work on Fusion to get it more stable and address some of the many issues logged in fusion trac, especially the ones that people have been kind enough to do the leg work on and propose fixes. Right now, I think MapGuide 2.1 is pulling fusion from a branch called fusion2-mg21. There are a few differences between this branch and the fusion-2.0 branch, and some of the mapguide-issues logged in mapguide and fusion trac could perhaps be addressed simply by switching to the 2.0 branch. Also, the other problem is that we have let the 2.0 branch languish and it is no longer quite relevant. I am going to propose to the Fusion community that we more-or-less abandon the existing 2.0 beta release and sync with the current trunk version and try again. This will mean more substantial changes and additions to 2.0 than would otherwise be acceptable once a beta version had been released ... but I think it is worth it for a couple of reasons: * we obviously have limited attention from developers contributing to fusion and trying to make time to release an out-of-date package seems like a poor use of their time. * there are some important changes in trunk like switching the client- side vector code over to use OpenLayers vectors that will further minimize the amount of maintenance we need to do while increasing functionality. * I think trunk is more stable than the 2.0 branch right now :) Question: Will MapGuide 2.1 include the 'official' 2.0 branch of Fusion if we restart the release process for 2.0 from the current state of fusion trunk? Feedback is welcome, of course. Cheers Paul _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
|
Paul Spencer-2
|
No decision has been posted but based on the feedback so far, I will
be announcing that we will 'abandon' the 2.0 release and start over again with a new beta by merging the current state of trunk into the branch. I suggest that you provide patches for trunk only to minimize wasted effort. Thank you for fixing things! Paul On 8-Jul-09, at 5:59 PM, Walt Welton-Lair wrote: > Hi Paul / Jason, > > I plan to prepare some fusion patches for MapGuide search-related > defects (fusion tickets 236, 237, 268). I want to prepare these for > all current versions of MapGuide: trunk, MGOS 2.1 beta, and the > sandbox version used by Autodesk: > * the sandbox version is based on fusion2-mg21 and I don't expect > that to change, so I will prepare one set of patches against that > stream > * I'll prepare another set of patches against the trunk stream > > The one I'm wondering about is MGOS 2.1 which currently uses the > fusion-2.0 stream. Has a decision been made as to what version of > fusion it will use? I'll hold off preparing the patches for MGOS > 2.1 until we know for sure. > > Thanks, > Walt > > -----Original Message----- > From: [hidden email] [mailto:[hidden email] > ] On Behalf Of Jason Birch > Sent: Friday, July 03, 2009 4:18 PM > To: MapGuide Internals Mail List > Subject: RE: [mapguide-internals] sync'ing mg21 branch in fusion to > trunk > > Paul, > > In general, I would be in favour of this approach. I haven't seen > anything committed to Fusion trunk that would destabilize our > existing functionality (correct me if I'm wrong), and we may benefit > from additional fixes and from developers spending time fixing bugs > instead of managing merges. And, as users have pointed out in the - > users list, Fusion really needs a bit of work before it's usable > with the current templates, and it hurts to release 2.1 with another > "broken" version of Fusion. > > I could use a confirmation that the 2.0 Sheboygan samples are good > with the 2.1 templates; I keep wondering if some of the bugs are > because of problems using the 2.0 application definitions with the > 2.1 templates. > > As a point of clarification, MG 2.1 beta is pulling from this branch: > > http://svn.osgeo.org/fusion/branches/fusion-2.0 > > I believe the other branch may have been used by Autodesk? > > Jason > > -----Original Message----- > From: Paul Spencer > Sent: Friday, July 03, 2009 5:29 AM > To: MapGuide Internals Mail List > Subject: [mapguide-internals] sync'ing mg21 branch in fusion to trunk > > Its been several months since we've done any work on Fusion and > pushing it closer to a release ... no excuses, it just didn't happen : > ( But I would like to start planning some work on Fusion to get it > more stable and address some of the many issues logged in fusion trac, > especially the ones that people have been kind enough to do the leg > work on and propose fixes. > > Right now, I think MapGuide 2.1 is pulling fusion from a branch called > fusion2-mg21. There are a few differences between this branch and the > fusion-2.0 branch, and some of the mapguide-issues logged in mapguide > and fusion trac could perhaps be addressed simply by switching to the > 2.0 branch. > > Also, the other problem is that we have let the 2.0 branch languish > and it is no longer quite relevant. I am going to propose to the > Fusion community that we more-or-less abandon the existing 2.0 beta > release and sync with the current trunk version and try again. This > will mean more substantial changes and additions to 2.0 than would > otherwise be acceptable once a beta version had been released ... but > I think it is worth it for a couple of reasons: > > * we obviously have limited attention from developers contributing to > fusion and trying to make time to release an out-of-date package seems > like a poor use of their time. > > * there are some important changes in trunk like switching the client- > side vector code over to use OpenLayers vectors that will further > minimize the amount of maintenance we need to do while increasing > functionality. > > * I think trunk is more stable than the 2.0 branch right now :) > > Question: Will MapGuide 2.1 include the 'official' 2.0 branch of > Fusion if we restart the release process for 2.0 from the current > state of fusion trunk? > > Feedback is welcome, of course. > > Cheers > > Paul > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals > _______________________________________________ > mapguide-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/mapguide-internals __________________________________________ Paul Spencer Chief Technology Officer DM Solutions Group Inc http://research.dmsolutions.ca/ _______________________________________________ mapguide-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
