Changes between Version 2 and Version 3 of PscMeeting12-06-2007


Ignore:
Timestamp:
Mar 18, 2008, 9:57:48 PM (16 years ago)
Author:
robertbray
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PscMeeting12-06-2007

    v2 v3  
    1818 * Other Business?
    1919
    20 == Actions ==
    21 
    2220
    2321== Transcript ==
     22<rbray> Ok, sorry about that. I am ready to start.
     23<rbray> Tom can you give us an update on the Beta.
     24<tomf1> Yes
     25<tomf1> We are upgrading the MGOS isntalls to the latest FDO beta posted on osgeo.org
     26<tomf1> We should have new installs available for next week. It will also have GDAL 1.4.4 compliant FDO provider
     27<tomf1> so ECW and MrSID support will be back
     28<tomf1> So beta 2 early next week
     29<tomf1> That's it.
     30<rbray> Where are we with bugs.
     31<tomf1> Oh, some more of the documentation should come back online too, as I get around to that.
     32<rbray> Will it also include a new fusion drop, with some bug fixes / enhancements?
     33<tomf1> It will include bug fixes in all aspects of the product.
     34<tomf1> I'll try to set up a trac query that has the list of fixed tickets between the two builds. I don't have that right now
     35<rbray> Anyone have any concerns? Any specific items that need to be addressed for Beta 2 beyond what Tom mentioned?
     36<geojason>      There were some installer issues...
     37<geojason>      like adding the json mime type properly, and...
     38<geojason>      Not allowing an install on the same machine as 1.2
     39<geojason>      Any chance these can be remedied?
     40<geojason>      the json thing was just for IIS6/Win2k3
     41<tomf1> We are working on the mime type issue
     42<tomf1> There is nothing being done about side-by-side install capabilities of MGOS
     43<geojason>      Even if the installer completed and the user had to change the ports, it would be better than seeing it as "same product" and halting the install.
     44<tomf1> That's good to know
     45<rbray> Yea I agree with that.
     46<rbray> They will run side by side fine with some tweaking. Let them tweak.
     47<geojason>      The user has to be savvy enough to pass an alternate install path to the installer in the first place :)
     48<tomf1> I'll talk to Tim about that. No guarantees though
     49<geojason>      k :)
     50<rbray> Other issues or concerns going into Beta2?
     51<rbray> OK.
     52<tomf1> One sec
     53<rbray> holding
     54<tomf1> Were there plans before about doing builds on a OSGeo server?
     55<tomf1> What happened with that?
     56<rbray> Dunno. I think that is still waiting for some brave soul to adopt it.
     57<geojason>      We can still do it...
     58<geojason>      Just have to get some time from Mat :)
     59<rbray> I do not want to hold up Beta or RCs for that though.
     60<geojason>      Oh, and some commandline build scripts would help.
     61<geojason>      No, no kidding.
     62<tomf1> OK, just thinking that that might be a way we could get stuff that we want into the installer as well.
     63<tomf1> Done
     64<rbray> OK
     65<geojason>      Yes, I have plans to look at NSIS when I have a second. or three-hundred. It looks easy. :)
     66<rbray> Beta Test Servers.
     67<geojason>      Really hard to get it to do everything the InstallShield installer does, but maybe good enough.
     68<rbray> We have the infrastructrue to host these, but probably not the bandwidth to keep them running.
     69<rbray> Any volunteers willing to help?
     70<rbray> Wow, don't everyone jump at once.
     71<geojason>      bandwidth?
     72<Andy_Morsell>  I can probably help, but am somewhat bandwidth challenged lately myself.
     73<rbray> People time.
     74<geojason>      oh, sorry. I'm hardware-centric today.
     75<geojason>      What does that entail? Rolling back the VMWare image once in a while? :)
     76<rbray> I think all we need is a small group to each pitch in a little here and there. Not a big commitment.
     77<geojason>      I'm game...
     78<geojason>      Are these Linux or Windows?
     79<rbray> I'd like one more.
     80<geojason>      And.. are they VM?
     81<rbray> They are VM's and Windows.
     82<geojason>      Will we have access to the root vm console to roll back if necessary?
     83<HarisK>        I am not sure what it means but I am willing to be in
     84<geojason>      Hey, HarisK ! welcome, I didn't see you there.
     85<rbray> HarisK: Thanks. Just monitoring, restarting them, stuff like that.
     86<HarisK>        Hi :)
     87<geojason>      We can probably set up some kind of automated monitoring that restarts the services if they're dead...
     88<HarisK>        ok I am in
     89<rbray> Yes we can. OK Tom and I will have Trevor get in touch with you directly. He will be setting this up.
     90<rbray> At this point, I suggest we tackle this for Beta 2.
     91<HarisK>        ok
     92<geojason>      What kind of access are we going to allow?
     93<rbray> FTP to upload data and php code.
     94<rbray> Studio access for authoring.
     95<rbray> They can basically use it like a hosted MG server.
     96<geojason>      The PHP code thing scares the shit out of me...
     97<geojason>      Good way to own the server.
     98<rbray> But only for a limited tme, and no up time guarantees.
     99<rbray> Yea
     100<rbray> We could pull that part.
     101<rbray> Up to you, Trevor, and Haris.
     102<geojason>      What's the alternative... only giving that level of access to "trusted" users?
     103<geojason>      Setting up new sites for users (not really interested in that...)
     104<rbray> Well that is all we'll be giving. They will have to ask to use it and we will grant them access user by user.
     105<rbray> We cannot open it to the world. That would be asking for trouble.
     106<bdechant>      yup - trusted users only :)
     107<geojason>      works for me... though it will be a lower level of "trust" than I usually apply for server access :)
     108<rbray> Yes. It is really just a testbed. We do not want to get carried away or it will become a management nightmare.
     109<rbray> I personally think it will be really cool. I do not know of another open geospatial project that does this.
     110<rbray> OK next topic
     111<rbray> Anyone object to enabling SVN post commit hooks?
     112<tomf1> Not me
     113<bdechant>      nope
     114<rbray> They allow for putting in something like fixed: #123
     115<mapguidetrac>  Ticket #123: Cannot find overload for MgMappingService::GeneratePlot(), http://trac.osgeo.org/mapguide/ticket/123
     116<rbray> And that bug is automatically marked as fixed.
     117<tomf1> I would also like to get it enforced that all submissions much be associated with a ticket
     118<rbray> That would requrie the pre-commit hook.
     119<geojason>      As long as people stop putting things like RFC #23 :)
     120<mapguidetrac>  Ticket #23: Add icon on toolbar to show that map is reloading, http://trac.osgeo.org/mapguide/ticket/23
     121<geojason>      Will it add comments to the ticket as the submissions are made?
     122-->|    wekeltr (n=chatzill@adeskout.autodesk.com) has joined #MapGuide
     123<rbray> Yes.
     124<geojason>      That's useful.
     125<rbray> Yea the comments from the submission get logged in trac.
     126<rbray> It's just another level of integration.
     127<geojason>      Yes, I've found a few times where I wanted to look at what was fixed, and had to root through.
     128<rbray> What do folks think about pre-commit hook. Requirenig a ticket to submit?
     129<bdechant>      Not sure I like that as some times the commit might be to fix a simple typo or source comment
     130<tomf1> If we don't geojason is still going to have to "root through"
     131<rbray> You can always refer to the original ticket.
     132<bdechant>      Lots of times there is no root ticket to reference
     133<rbray> in the subsequent fixing submission.
     134<rbray> Then there should have been.
     135<bdechant>      I can see a "catch all" ticket being created and commiters using that
     136<rbray> Yuch
     137<geojason>      Those would get pretty big...
     138<rbray> That would be bad
     139<tomf1> I don't think that will be bad
     140<tomf1> if the ticket says "typo and code comment updates"
     141<geojason>      One per release?
     142<tomf1> It would be bad if the ticket summary was "stuff"
     143<bdechant>      or "Tab fixes" :)
     144<geojason>      heh
     145<rbray> right, my concern is the general catchall. Hey ma, look I just submitted 2000 lines of code under tab fixes.
     146<rbray> And its all new
     147<rbray> Then we are wasting our tme
     148<bdechant>      hehe - I don't want to see that either
     149<rbray> I personally support the idea, but it has to be properly used.
     150<tomf1> I think we need the pre commit hook to make sure that submission/ticket associations are good, otherwise it's very easy to forget to reference the ticket in a submission
     151<geojason>      Wow, this is a cool bug: http://www.nabble.com/Problem-in-the-GenerateFilter%28%29-method-of-the-MgSelection-class-tf4937455.html#a14132755
     152=-=     wekeltr is now known as trevorw
     153<rbray> Nice one. Even gave code to re-produce.
     154<rbray> So let's vote here.
     155<rbray> First Motion: Enable Post Commit Hooks
     156<rbray> I am +1
     157<geojason>      +1
     158<HarisK>        +1
     159<tomf1> +1Any other dissenters to the
     160<Andy_Morsell>  +1
     161<tomf1> oops, half typed message
     162<bdechant>      +1
     163<tomf1> ignore it please
     164<geojason>      dissenters will be shot :)
     165<rbray> Good enough for me, passed.
     166<rbray> Second Motion: Enable Pre-Commit Hooks implying all submissions require a ticket.
     167<tomf1> 1
     168<tomf1> +1
     169<rbray> I am also +1, but Tom will need to document some process :)
     170<geojason>      +1
     171<bdechant>      +1 (as long as we have a process)
     172<HarisK>        +1
     173<tomf1> Whatever we used when we were with collabnet was fine
     174<tomf1> Where's the documentation for that?
     175<rbray> Yes that is one that that worked well in the collabnet environment.
     176<tomf1> Saves me from having to write it again :-)
     177<rbray> There was none.
     178<geojason>      lol
     179<rbray> OK. That is also good enough for me.
     180<rbray> passed
     181<rbray> I will send out the meeting minutes and as long as our absent member does not complain I'll ask SAC to enable them.
     182<rbray> Any other business for today.
     183<rbray> Apparently the website is a bit of a mess, but Jason is working on it.
     184<rbray> :)
     185<geojason>      I'm just pushing... don't hav eserver access.
     186<geojason>      Hey, bob, you should be in there fixing it :)
     187<rbray> Yea, well....I am a little pre-occupied today. I can do it this evening though.
     188<tomf1> I found a broken link just a second ago for the official PSC page
     189<tomf1> do we still have one, the one that was pointed to was http://mapguide.osgeo.org/psc.html
     190<rbray> Send me stuff you see broken and I will try to fix.
     191<geojason>      All of the old URLs, especially if hardcoded, will break for now.
     192<tomf1> ...from out wiki page http://wiki.osgeo.org/index.php/MapGuide_Open_Source
     193<rbray> I know about those
     194<geojason>      Don't "fix" to point to ?q= pages...
     195<rbray> No I wont
     196<rbray> Any other business?
     197<geojason>      Updating the roadmap?
     198<geojason>      A few folks have asked.
     199<geojason>      And the one in Trac is out of date.
     200<rbray> Tom and I can take a stab at that, and then ask the PSC for input. Does that seem like a reasonable approach.
     201<rbray> We'll do it by updating Trac.
     202<trevorw>       Hi everyone, Tom asked me to join but I didn't have an IRC client installed. Haris, should I contact you at your sl-king email address?
     203<HarisK>        yes, please
     204<geojason>      Works for me rbray
     205<rbray> OK, Tom let's see if we can find an hour for that tomorrow.
     206|<--    CIA-17 has left irc.freenode.net (Client Quit)
     207<HarisK>        for this support do I need to be the one, or it can also be Simon from my company ?
     208<trevorw>       Ok. Thanks. Jason, should I use your nanaimo address?
     209<rbray> Other agenda items or concerns?
     210<rbray> Simon is fine.
     211<geojason>      Sure...
     212<rbray> Just give his e-mail to Trevor.
     213<HarisK>        yes
     214<geojason>      Though after-hours probably better to use my home address: jason at jasonbirch.com
     215<rbray> Asking again since we were side-tracked - Other agenda items or concerns?
     216<geojason>      The list of tickets is pretty long...
     217<geojason>      And assignment in Trac doesn't seem to be getting used much.
     218<geojason>      Is your internal system primary?
     219<rbray> Yes. One of those things we are having a hard time reconciling.
     220<rbray> Our internal system is all conected to product support and such.
     221<geojason>      Almost need some kind of gateway... but there would be a lot of risk there.
     222<rbray> Yes and they are so completely incompatible it is not funny.
     223<rbray> Tons of work to try and link
     224<geojason>      If I understood the internals better (ie, was a developer) I wouldn't mind managing the public tickets
     225<geojason>      But as it stands I end up way out of my depth real fast.
     226<rbray> Tom and I will add this our list for tomorrow. Not sure how to resolve this just yet, but we basically need a bug manager.
     227<tomf1> What are we looking for with this?
     228<rbray> And of course both of us are swamped.
     229<rbray> Someone to watch trac, assign defects, make sure the target fix version is set, etc.
     230<rbray> Oh, and don't forget they first need to go back through and cleanup the tickets we have.
     231<geojason>      I have a feeling that we have a number of bugs that have either been fixed in 2.0, or are impossible to reproduce without more detail and should be closed.
     232<geojason>      Hard to deal with though.
     233<rbray> Yea, it is a massive time sync.
     234<rbray> I'll table that as another action for Tom and I to think about.
     235<rbray> anything else? We are out of time.
     236<tomf1> yes, I've asked for more details in some tickets, but there have not been updates, so I'll close those now
     237<tomf1> ...a few months to provide more details should be enough I would think
     238<rbray> Yea
     239<rbray> OK, lets adjourn. Thanks everyone.
     240<geojason>      Bye!
     241<bdechant>      bye
     242<HarisK> bye