Difference between revisions of "MapGuide PSC Meeting 02-01-2007"
Jump to navigation
Jump to search
Line 20: | Line 20: | ||
== Transcript == | == Transcript == | ||
− | <rbray> Ok, lets get started. Not sure where Jason and Tom are but I am sure they will join shortly. | + | <rbray> Ok, lets get started. Not sure where Jason and Tom are but I am sure they will join shortly. |
− | <rbray> First topic is CLA collection. We need to get everyone with commit rights to sign and send in a CLA. | + | <rbray> First topic is CLA collection. We need to get everyone with commit rights to sign and send in a CLA. |
− | <rbray> Hey Jason. | + | <rbray> Hey Jason. |
− | <pagameba> sorry, stepped out for a sec | + | <pagameba> sorry, stepped out for a sec |
− | <jasonbirch> Howdy howdy (just to make you feel at home :) | + | <jasonbirch> Howdy howdy (just to make you feel at home :) |
− | <rbray> I thought I would just post a mail to every commiter and have them fax them in. | + | <rbray> I thought I would just post a mail to every commiter and have them fax them in. |
− | <rbray> Do we need to set a timeframe for that? | + | <rbray> Do we need to set a timeframe for that? |
− | <jasonbirch> Yes. | + | <jasonbirch> Yes. |
− | <rbray> What do you think a week? | + | <rbray> What do you think a week? |
− | <rbray> Else they lose commit rights... | + | <rbray> Else they lose commit rights... |
− | <jasonbirch> Is everyone currently available (not off on holiday? | + | <jasonbirch> Is everyone currently available (not off on holiday? |
− | <pagameba> danmo: http://mapguide.osgeo.org/trac/ | + | <pagameba> danmo: http://mapguide.osgeo.org/trac/ |
− | <sigq> Title: Available Projects (at mapguide.osgeo.org) | + | <sigq> Title: Available Projects (at mapguide.osgeo.org) |
− | <jasonbirch> I guess reinstating isn't that hard? | + | <jasonbirch> I guess reinstating isn't that hard? |
− | <jasonbirch> trac.osgeo.org/trac/mapguide should be the URL we're using | + | <jasonbirch> trac.osgeo.org/trac/mapguide should be the URL we're using |
− | <rbray> Yes I think everyone is around. If not it is easy to remove and re-instate. | + | <rbray> Yes I think everyone is around. If not it is easy to remove and re-instate. |
− | <jasonbirch> SAC decided on serv-ce-based URLs, not project-based | + | <jasonbirch> SAC decided on serv-ce-based URLs, not project-based |
− | <rbray> That is correct. | + | <rbray> That is correct. |
− | <rbray> The trac is not fully configured however. | + | <rbray> The trac is not fully configured however. |
− | <rbray> Every evening that I have had spare cycles the SVN instance is down | + | <rbray> Every evening that I have had spare cycles the SVN instance is down |
− | <rbray> and trac with it. | + | <rbray> and trac with it. |
− | <jasonbirch> Do you think that SVN might be getting hammered by spiders? | + | <jasonbirch> Do you think that SVN might be getting hammered by spiders? |
− | <rbray> Although I am almost there. | + | <rbray> Although I am almost there. |
− | <rbray> No idea. I need to get SAC to look into it more closely. The upgrade was supposed to fix it, but it was | + | <rbray> No idea. I need to get SAC to look into it more closely. The upgrade was supposed to fix it, but it was down again last night., |
− | <bdechant> It seems to go more often then the old system | + | <bdechant> It seems to go more often then the old system |
− | <bdechant> *go down | + | <bdechant> *go down |
− | <jasonbirch> I wish I knew more about SVN. Perhaps there is a log that would allow us to trace what's happening. | + | <jasonbirch> I wish I knew more about SVN. Perhaps there is a log that would allow us to trace what's happening. |
− | <rbray> Yes it does, not good. | + | <rbray> Yes it does, not good. |
− | <rbray> Me too, but SAC is on it. | + | <rbray> Me too, but SAC is on it. |
− | <rbray> Anyway, back on topic. Is everyone ok with an e-mail and one week deadline for submitting a CLA? | + | <rbray> Anyway, back on topic. Is everyone ok with an e-mail and one week deadline for submitting a CLA? |
− | <jasonbirch> Seconded, +1 :) | + | <jasonbirch> Seconded, +1 :) |
− | <bdechant> +1 | + | <bdechant> +1 |
− | <pagameba> +1 | + | <pagameba> +1 |
− | <Haris_> +1 | + | <Haris_> +1 |
− | <Andy_Morsell> +1 | + | <Andy_Morsell> +1 |
− | <rbray> Ok, one down. I'll send that out later today. | + | <rbray> Ok, one down. I'll send that out later today. |
− | <rbray> Next topic: Incubation Status. | + | <rbray> Next topic: Incubation Status. |
− | <rbray> danmo: are you with us at the moment? | + | <rbray> danmo: are you with us at the moment? |
− | <danmo> yup | + | <danmo> yup |
− | <danmo> I have started reviewing everything | + | <danmo> I have started reviewing everything |
− | <danmo> A few questions came up, the first one was whether we had an active bug tracker... hence my question about trac before the meeting | + | <danmo> A few questions came up, the first one was whether we had an active bug tracker... hence my question about trac before the meeting |
− | <rbray> That will be in place by the end of this week. | + | <rbray> That will be in place by the end of this week. |
− | <danmo> Will trac be linked from a easy to find user-accessible location when the setup is completed? | + | <danmo> Will trac be linked from a easy to find user-accessible location when the setup is completed? |
− | <rbray> Just need to | + | <rbray> Just need to finish the Wiki pages |
− | <rbray> Yep, right off the home page. | + | <rbray> Yep, right off the home page. |
− | <danmo> Cool | + | <danmo> Cool |
− | <rbray> With anonymous access for ticket submission. | + | <rbray> With anonymous access for ticket submission. |
− | <jasonbirch> We'll be restructuring the menu to be more developer-accessible. | + | <jasonbirch> We'll be restructuring the menu to be more developer-accessible. |
− | <jasonbirch> (Links to SVN, Trac, etc) | + | <jasonbirch> (Links to SVN, Trac, etc) |
− | <rbray> The initial rework of the left nav will be done this week too. | + | <rbray> The initial rework of the left nav will be done this week too. |
− | <rbray> I am really just waiting to flip the switch on Trac. | + | <rbray> I am really just waiting to flip the switch on Trac. |
− | <rbray> Any other incubation concerns so far? | + | <rbray> Any other incubation concerns so far? |
− | <danmo> I think I saw that the old bugs from the CN system won't be ported to Trac? That's too bad | + | <danmo> I think I saw that the old bugs from the CN system won't be ported to Trac? That's too bad |
− | <jasonbirch> Yes, it's unfortunate. It would be nice even to pull them into a web page as "historical". | + | <jasonbirch> Yes, it's unfortunate. It would be nice even to pull them into a web page as "historical". |
− | <rbray> That is the plan. Just need time to put together a XSLT for the XML. | + | <rbray> That is the plan. Just need time to put together a XSLT for the XML. |
− | <rbray> There was about 300 defects/enhancements/tasks in the CN system. | + | <rbray> There was about 300 defects/enhancements/tasks in the CN system. |
− | <danmo> I think we're in very good shape for incubation. Based on the MapGuide Incubation Status page we'd be all set, but I need to check with IncCom for a complete checklist to pass before graduation. pagameba, did you have such a checklist fro previous projects or was it enough to have addressed everything from the status page? | + | <danmo> I think we're in very good shape for incubation. Based on the MapGuide Incubation Status page we'd be all set, but I need to check with IncCom for a complete checklist to pass before graduation. pagameba, did you have such a checklist fro previous projects or was it enough to have addressed everything from the status page? |
− | <pagameba> thinking ... | + | <pagameba> thinking ... |
− | <pagameba> I thought there was a graduation checklist | + | <pagameba> I thought there was a graduation checklist |
− | <pagameba> but I haven't looked in a while | + | <pagameba> but I haven't looked in a while |
− | <pagameba> checking | + | <pagameba> checking |
− | <danmo> I was hoping there would be one but could not find it this morning... | + | <danmo> I was hoping there would be one but could not find it this morning... |
− | <danmo> There is http://www.osgeo.org/incubator/process/evaluation.html | + | <danmo> There is http://www.osgeo.org/incubator/process/evaluation.html |
− | <sigq> Title: Project Evaluation Criteria | OSGeo.org (at www.osgeo.org) | + | <sigq> Title: Project Evaluation Criteria | OSGeo.org (at www.osgeo.org) |
− | <FrankW> There is no incubation checklist per se. | + | <FrankW> There is no incubation checklist per se. |
− | <rbray> That is acceptance into incubation. | + | <rbray> That is acceptance into incubation. |
− | <danmo> yeah, I know | + | <danmo> yeah, I know |
− | <rbray> Sounds like a next step for the Incubation Committee. A checklist would be helpful... | + | <rbray> Sounds like a next step for the Incubation Committee. A checklist would be helpful... |
− | <rbray> And provide some consistency. | + | <rbray> And provide some consistency. |
− | + | <FrankW> encourages rbray to prepare and submit one for discussion... | |
− | <rbray> At any rate, danmo if you come across any issues please send them to the mailing list. | + | <rbray> At any rate, danmo if you come across any issues please send them to the mailing list. |
− | <FrankW> I believe in the past it was felt to be redundant, duplicating much of the other material. | + | <FrankW> I believe in the past it was felt to be redundant, duplicating much of the other material. |
− | <rbray> FrankW: Maybe I'll take on a mentor role and do that. | + | <rbray> FrankW: Maybe I'll take on a mentor role and do that. |
− | <rbray> Any other incubation related questions or comments? | + | <rbray> Any other incubation related questions or comments? |
− | <jasonbirch> The current process just points to the template: http://wiki.osgeo.org/index.php/Project_Graduation_Process | + | <jasonbirch> The current process just points to the template: http://wiki.osgeo.org/index.php/Project_Graduation_Process |
− | <sigq> Title: Project Graduation Process - OSGEO (at wiki.osgeo.org) | + | <sigq> Title: Project Graduation Process - OSGEO (at wiki.osgeo.org) |
− | <rbray> There is this: http://wiki.osgeo.org/index.php/Project_Graduation_Checklist | + | <rbray> There is this: http://wiki.osgeo.org/index.php/Project_Graduation_Checklist |
− | <sigq> Title: Project Graduation Checklist - OSGEO (at wiki.osgeo.org) | + | <sigq> Title: Project Graduation Checklist - OSGEO (at wiki.osgeo.org) |
− | <danmo> Perhaps the status page is the checklist, but then the template should be edited to include things like "does the project have a bug tracker?" I remember this was brought up as an issue with other projects | + | <danmo> Perhaps the status page is the checklist, but then the template should be edited to include things like "does the project have a bug tracker?" I remember this was brought up as an issue with other projects |
− | <pagameba> yep, that seems to be all there is | + | <pagameba> yep, that seems to be all there is |
− | <jasonbirch> Just saw that link :) | + | <jasonbirch> Just saw that link :) |
− | <jasonbirch> We're missing steps 9 and 10, but I don't think that OSGeo supports those directly? Or is MapGuide running under BuildBot already? | + | <jasonbirch> We're missing steps 9 and 10, but I don't think that OSGeo supports those directly? Or is MapGuide running under BuildBot already? |
− | <jasonbirch> Oops, sorry, not 10. | + | <jasonbirch> Oops, sorry, not 10. |
− | <rbray> 10 is more or less in place. | + | <rbray> 10 is more or less in place. |
− | <rbray> There is a full unit test suite. We are also working on a scalability/performance suite. | + | <rbray> There is a full unit test suite. We are also working on a scalability/performance suite. |
− | <danmo> I think I'd make 9 optional | + | <danmo> I think I'd make 9 optional |
− | <rbray> 9 is internal at the moment. | + | <rbray> 9 is internal at the moment. |
− | <jasonbirch> I prefer "not public" to internal :) | + | <jasonbirch> I prefer "not public" to internal :) |
− | <rbray> It would be nice to move that to BuildBot | + | <rbray> It would be nice to move that to BuildBot |
− | <rbray> Yea, I agree. But these things take time away from fun stuff. | + | <rbray> Yea, I agree. But these things take time away from fun stuff. |
− | <rbray> Like feature development :) | + | <rbray> Like feature development :) |
− | <jasonbirch> Once GeoTec is out of the way, I wouldn't mind getting involved in trying to figure out building and packaging automatically. | + | <jasonbirch> Once GeoTec is out of the way, I wouldn't mind getting involved in trying to figure out building and packaging automatically. |
− | <danmo> FrankW: Do the issues listed in the code provenance review need to have all been resolved before graduation? | + | <danmo> FrankW: Do the issues listed in the code provenance review need to have all been resolved before graduation? |
− | <rbray> Excellent a volunteer! | + | <rbray> Excellent a volunteer! |
− | <pagameba> danmo, I believe we decided that they did need to be resolved | + | <pagameba> danmo, I believe we decided that they did need to be resolved |
− | <jasonbirch> Since I'm not too helpful with the fun stuff (other than making my wishes clear) :) | + | <jasonbirch> Since I'm not too helpful with the fun stuff (other than making my wishes clear) :) |
− | <pagameba> what are the issues? | + | <pagameba> what are the issues? |
− | <danmo> They seem simple on the surface. For instance, FoundationTest.cpp missing header in http://wiki.osgeo.org/index.php/MapGuide_Provenance_Review | + | <danmo> They seem simple on the surface. For instance, FoundationTest.cpp missing header in http://wiki.osgeo.org/index.php/MapGuide_Provenance_Review |
− | <sigq> Title: MapGuide Provenance Review - OSGEO (at wiki.osgeo.org) | + | <sigq> Title: MapGuide Provenance Review - OSGEO (at wiki.osgeo.org) |
− | <rbray> Looks like mostly missing LGPL license headers. | + | <rbray> Looks like mostly missing LGPL license headers. |
− | <rbray> A lot of them in javascript files where we dont want them. | + | <rbray> A lot of them in javascript files where we dont want them. |
− | <rbray> or html. | + | <rbray> or html. |
− | <TomFukushima> Yes, most of them were HTML and Javascript files | + | <TomFukushima> Yes, most of them were HTML and Javascript files |
− | <jasonbirch> Are individual license headers required, or even desirable? | + | <jasonbirch> Are individual license headers required, or even desirable? |
− | <danmo> In the FDO code provenance review, there are a couple of mentioned of copyrighted files without mention of the license, e.g. ConvertUTF.cpp/.h and a couple of .xsd | + | <danmo> In the FDO code provenance review, there are a couple of mentioned of copyrighted files without mention of the license, e.g. ConvertUTF.cpp/.h and a couple of .xsd |
− | <pagameba> no, they are not required | + | <pagameba> no, they are not required |
− | <pagameba> in small js files, for instance, we decided that it was acceptable to explicitly decide not to include them | + | <pagameba> in small js files, for instance, we decided that it was acceptable to explicitly decide not to include them |
− | <rbray> FDO will be seperate. So that is excluded from MapGuide Incubation. | + | <rbray> FDO will be seperate. So that is excluded from MapGuide Incubation. |
− | <rbray> It will come formally into incubator once I get MG out. | + | <rbray> It will come formally into incubator once I get MG out. |
− | <danmo> But the incubation status doc refers to it ;) | + | <danmo> But the incubation status doc refers to it ;) |
− | <pagameba> so for everything in that list that says 'no', we need to either fix it or say we won't fix it because it isn't required | + | <pagameba> so for everything in that list that says 'no', we need to either fix it or say we won't fix it because it isn't required |
− | <rbray> Sorry, that was when I was trying to be slick and push it through with MG. | + | <rbray> Sorry, that was when I was trying to be slick and push it through with MG. |
− | <TomFukushima> pagameba: but they should be in large .js files then? | + | <TomFukushima> pagameba: but they should be in large .js files then? |
− | <pagameba> its a judgement call ... but I think yes personally | + | <pagameba> its a judgement call ... but I think yes personally |
− | <jasonbirch> I think that a "Body of work" license should be all that is required, with headers only where there are exceptions. | + | <jasonbirch> I think that a "Body of work" license should be all that is required, with headers only where there are exceptions. |
− | <rbray> We could just drop a license file into the directory of html/javascript. That would be easy and not burden the code. | + | <rbray> We could just drop a license file into the directory of html/javascript. That would be easy and not burden the code. |
− | <pagameba> that works for me | + | <pagameba> that works for me |
− | <rbray> danmo: I'll remove the FDO references from the MG incubation status page. | + | <rbray> danmo: I'll remove the FDO references from the MG incubation status page. |
− | <danmo> dropping a single license file in the html/js dirs seems to make sense to me too | + | <danmo> dropping a single license file in the html/js dirs seems to make sense to me too |
− | <TomFukushima> What's a "Body of work" license. Anyone have any examples they could send me? | + | <TomFukushima> What's a "Body of work" license. Anyone have any examples they could send me? |
− | <rbray> Frank did not answer, but if my memory is correct all the issues in provence do not need resolution. As long as there are no copyright violations. | + | <rbray> Frank did not answer, but if my memory is correct all the issues in provence do not need resolution. As long as there are no copyright violations. |
− | <FrankW> Well, "outstanding issues" will be reviewed by inccom before approval. | + | <FrankW> Well, "outstanding issues" will be reviewed by inccom before approval. |
− | <FrankW> The key is to be sure that stuff is well understood and documented. | + | <FrankW> The key is to be sure that stuff is well understood and documented. |
− | <rbray> I think that was brought up on the incubator mail list at one point. | + | <rbray> I think that was brought up on the incubator mail list at one point. |
− | <jasonbirch> It just means that we are asserting the license and copyright on the entire body of work (in a license.txt file) rather than in individual files. | + | <jasonbirch> It just means that we are asserting the license and copyright on the entire body of work (in a license.txt file) rather than in individual files. |
− | <jasonbirch> Unless the individual files contain differing licences/copyrights. | + | <jasonbirch> Unless the individual files contain differing licences/copyrights. |
− | <rbray> Ok, we could drop one of those in the tree. | + | <rbray> Ok, we could drop one of those in the tree. |
− | <rbray> danmo: Let us know how your review progresses. I'll keep this item on the agenda until we graduate. | + | <rbray> danmo: Let us know how your review progresses. I'll keep this item on the agenda until we graduate. |
− | <danmo> license.txt as a replacement for license on every individual file or in addition to? | + | <danmo> license.txt as a replacement for license on every individual file or in addition to? |
− | <FrankW> Hopefully in addition to, but making up for the lack of it in some files (like javascript). | + | <FrankW> Hopefully in addition to, but making up for the lack of it in some files (like javascript). |
− | <rbray> I would use it as a catch all. No way we are removing all those. | + | <rbray> I would use it as a catch all. No way we are removing all those. |
− | <jasonbirch> lol | + | <jasonbirch> lol |
− | <danmo> I remember reading in one of the incubation docs that a copyright and license ref was required in every file. I was surprised to see this requirement but it seems to have been agreed to by IncCom | + | <danmo> I remember reading in one of the incubation docs that a copyright and license ref was required in every file. I was surprised to see this requirement but it seems to have been agreed to by IncCom |
− | <rbray> I was one heck of a perl script that put them all in. | + | <rbray> I was one heck of a perl script that put them all in. |
− | <rbray> I = it | + | <rbray> I = it |
− | <ChrisGo> any recommendations on a linux distro im not moving very fast on debian ;) | + | <ChrisGo> any recommendations on a linux distro im not moving very fast on debian ;) |
− | <jasonbirch> Bob is a perl script. | + | <jasonbirch> Bob is a perl script. |
− | <rbray> ChrisGo: Fedora works well. | + | <rbray> ChrisGo: Fedora works well. |
− | <jasonbirch> CentOS will be closest to RH | + | <jasonbirch> CentOS will be closest to RH |
− | <rbray> We'll have an FGS installer for Linux in a couple months that should make install on any distro much easier. | + | <rbray> We'll have an FGS installer for Linux in a couple months that should make install on any distro much easier. |
− | <ChrisGo> i was going to give that another try but the yum package thing was gona be a learning curve | + | <ChrisGo> i was going to give that another try but the yum package thing was gona be a learning curve |
− | <FrankW> Sweet! | + | <FrankW> Sweet! |
− | <rbray> Oh yea, it works great on CentOS too. | + | <rbray> Oh yea, it works great on CentOS too. |
− | + | <FrankW> flees... | |
− | <rbray> Shall we move on to the next topic, or do we have more incubation topics? | + | <rbray> Shall we move on to the next topic, or do we have more incubation topics? |
− | <danmo> Here is the doc that requires the copyright in every .cpp and .h file: FAQ #1 at http://wiki.osgeo.org/index.php/Code_Provenance_Review | + | <danmo> Here is the doc that requires the copyright in every .cpp and .h file: FAQ #1 at http://wiki.osgeo.org/index.php/Code_Provenance_Review |
− | <sigq> Title: Code Provenance Review - OSGEO (at wiki.osgeo.org) | + | <sigq> Title: Code Provenance Review - OSGEO (at wiki.osgeo.org) |
− | <ChrisGo> the biggest issue i was having was getting java sdk installed being its "non free" | + | <ChrisGo> the biggest issue i was having was getting java sdk installed being its "non free" |
− | <ChrisGo> maybe i wil wiat a month or so and get the new installer and be clueless how it works but happy it works... yeah | + | <ChrisGo> maybe i wil wiat a month or so and get the new installer and be clueless how it works but happy it works... yeah |
− | <rbray> ChrisGo: You are not the only one, I think we will create an opt out for Java. E.g. a PHP only build. | + | <rbray> ChrisGo: You are not the only one, I think we will create an opt out for Java. E.g. a PHP only build. |
− | <danmo> No more incubation topics from me | + | <danmo> No more incubation topics from me |
− | <rbray> Ok, lets move on to Trac. | + | <rbray> Ok, lets move on to Trac. |
− | <rbray> Which is really, really cool software BTW. | + | <rbray> Which is really, really cool software BTW. |
− | <jasonbirch> Change in tune from last meeting ;) | + | <jasonbirch> Change in tune from last meeting ;) |
− | <rbray> Yea | + | <rbray> Yea |
− | <rbray> I debated having RFCs simply be enhancement tickets, but... | + | <rbray> I debated having RFCs simply be enhancement tickets, but... |
− | <rbray> You can't edit the description after submitting it. So it would not allow for refinement. | + | <rbray> You can't edit the description after submitting it. So it would not allow for refinement. |
− | <rbray> Instead I think we will need to link Enhancements to RFCs and vice versa. | + | <rbray> Instead I think we will need to link Enhancements to RFCs and vice versa. |
− | <rbray> Make sense? | + | <rbray> Make sense? |
− | <jasonbirch> I think they need to be a separate status (or WIKI page) that reference appropriate enhancement tickets. | + | <jasonbirch> I think they need to be a separate status (or WIKI page) that reference appropriate enhancement tickets. |
− | <rbray> Right | + | <rbray> Right |
− | <jasonbirch> Or, in other words, yes. | + | <jasonbirch> Or, in other words, yes. |
− | <rbray> We could use the Enhancment ticket to discuss the RFC, but that feels wrong. The mail list is the right place for that. | + | <rbray> We could use the Enhancment ticket to discuss the RFC, but that feels wrong. The mail list is the right place for that. |
− | <jasonbirch> Agreed. The RFC should be modified based on discussions in the mailing list. Right tool for the job. | + | <jasonbirch> Agreed. The RFC should be modified based on discussions in the mailing list. Right tool for the job. |
− | <pagameba> I vote for a wiki page for the actual RFC followed by an enhancement ticket when the RFC is approved | + | <pagameba> I vote for a wiki page for the actual RFC followed by an enhancement ticket when the RFC is approved |
− | <jasonbirch> Especially since we're not opening up Wiki rights outside of the PSC/Developer ++ community | + | <jasonbirch> Especially since we're not opening up Wiki rights outside of the PSC/Developer ++ community |
− | <pagameba> and discussions on the mailing list | + | <pagameba> and discussions on the mailing list |
− | <rbray> Could happen the other way. | + | <rbray> Could happen the other way. |
− | <rbray> If a user requests an enhanment via a ticket, that then turns into an RFC. | + | <rbray> If a user requests an enhanment via a ticket, that then turns into an RFC. |
− | <rbray> For example. | + | <rbray> For example. |
− | <jasonbirch> enhancement-> Wiki RFC -> Task | + | <jasonbirch> enhancement-> Wiki RFC -> Task |
− | <rbray> Don't need the task really do you? | + | <rbray> Don't need the task really do you? |
− | <jasonbirch> Yes, need it to track SVN commits for the RFC against. | + | <jasonbirch> Yes, need it to track SVN commits for the RFC against. |
− | <rbray> Why not use the Enhancement? | + | <rbray> Why not use the Enhancement? |
− | <jasonbirch> Might be many-> one between enhancements and RFC | + | <jasonbirch> Might be many-> one between enhancements and RFC |
− | <rbray> I can buy that, just more tickets to manage though. | + | <rbray> I can buy that, just more tickets to manage though. |
− | <jasonbirch> Yes, but easier to track back from commits to RFC | + | <jasonbirch> Yes, but easier to track back from commits to RFC |
− | <rbray> Any objections to this approach? | + | <rbray> Any objections to this approach? |
− | <rbray> If not then I'll document it on the Trac Wiki. | + | <rbray> If not then I'll document it on the Trac Wiki. |
− | <jasonbirch> Enhancement tickets should be closed as soon as fully integrated into RFC. | + | <jasonbirch> Enhancement tickets should be closed as soon as fully integrated into RFC. |
− | <rbray> BTW: you can see trac in its current state at: http://www.osgeo.org/trac/mapguide | + | <rbray> BTW: you can see trac in its current state at: http://www.osgeo.org/trac/mapguide |
− | <sigq> Title: MapGuide Open Source - Trac (at www.osgeo.org) | + | <sigq> Title: MapGuide Open Source - Trac (at www.osgeo.org) |
− | <jasonbirch> RFC status (and associated task) are closed when code is complete | + | <jasonbirch> RFC status (and associated task) are closed when code is complete |
− | <rbray> And all related enhancements... | + | <rbray> And all related enhancements... |
− | <TomFukushima> we should only close Enhancement when the RFC has been completed; RFC could always be withdrawn at some point | + | <TomFukushima> we should only close Enhancement when the RFC has been completed; RFC could always be withdrawn at some point |
− | <jasonbirch> No, I think enhancements should be closed as soon as RFC is adopted. | + | <jasonbirch> No, I think enhancements should be closed as soon as RFC is adopted. |
− | <ChrisGo> rbray: you should do a web cast on linux ;-) | + | <ChrisGo> rbray: you should do a web cast on linux ;-) |
− | <jasonbirch> Oh. | + | <jasonbirch> Oh. |
− | <ChrisGo> I will even donate a few cases of your choice beer. | + | <ChrisGo> I will even donate a few cases of your choice beer. |
− | <rbray> Excellent. | + | <rbray> Excellent. |
− | <jasonbirch> ChrisGo: Individually shipped to the participants? | + | <jasonbirch> ChrisGo: Individually shipped to the participants? |
− | <TomFukushima> I guess we could reopen the enhancement if the RFC is withdrawn | + | <TomFukushima> I guess we could reopen the enhancement if the RFC is withdrawn |
− | <jasonbirch> I'd prefer that... | + | <jasonbirch> I'd prefer that... |
− | <ChrisGo> I'be installed NetBSD, Fedora and Debian and once I get to the install package something always goes wrong ;X | + | <ChrisGo> I'be installed NetBSD, Fedora and Debian and once I get to the install package something always goes wrong ;X |
− | <rbray> How often do you think we would withdraw an RFC? | + | <rbray> How often do you think we would withdraw an RFC? |
− | <jasonbirch> I don't think that we even account for that in the process once it's adopted. | + | <jasonbirch> I don't think that we even account for that in the process once it's adopted. |
− | <rbray> We dont at the moment. | + | <rbray> We dont at the moment. |
− | <rbray> ChrisGo: What version of Fedora? | + | <rbray> ChrisGo: What version of Fedora? |
− | <jasonbirch> Let's hope it's a rare event. The process is supposed to confirm "rightness" and "commitment" | + | <jasonbirch> Let's hope it's a rare event. The process is supposed to confirm "rightness" and "commitment" |
− | <rbray> I agree. So lets go forth with enhancements are closed when the RFC is adopted. | + | <rbray> I agree. So lets go forth with enhancements are closed when the RFC is adopted. |
− | <rbray> Should probably be final RFC. Might take more than one for some enahancement requests. | + | <rbray> Should probably be final RFC. Might take more than one for some enahancement requests. |
− | <rbray> Like the ones you ask for Jason :) | + | <rbray> Like the ones you ask for Jason :) |
− | <jasonbirch> Yes, don't close them unless they are fully implemented in the RFC. Add a note to the enhancement saying "partially implemented in RFC# / task# | + | <jasonbirch> Yes, don't close them unless they are fully implemented in the RFC. Add a note to the enhancement saying "partially implemented in RFC# / task# |
− | <rbray> Ok, I'll document that stuff on the new Wiki. Give me a day or so. | + | <rbray> Ok, I'll document that stuff on the new Wiki. Give me a day or so. |
− | <jasonbirch> Heh... | + | <jasonbirch> Heh... |
− | <jasonbirch> ok. I have a meeting in 4 mins... :) | + | <jasonbirch> ok. I have a meeting in 4 mins... :) |
− | <rbray> Last item on Trac, any suggestions for extra fields? | + | <rbray> Last item on Trac, any suggestions for extra fields? |
− | <rbray> Not really sure we need any, although I did bring back Severity and Priority. | + | <rbray> Not really sure we need any, although I did bring back Severity and Priority. |
− | <jasonbirch> Can we carry that over to email once have had time to look at current setup? | + | <jasonbirch> Can we carry that over to email once have had time to look at current setup? |
− | <rbray> Of course. | + | <rbray> Of course. |
− | <rbray> I only added one field, External ID. Gee wonder what that is for... | + | <rbray> I only added one field, External ID. Gee wonder what that is for... |
− | <jasonbirch> I don't want to know... | + | <jasonbirch> I don't want to know... |
− | <jasonbirch> Mailing list: can we please turn off HTML email on the lists, and restrict attachments to text, jpg, png, gif? | + | <jasonbirch> Mailing list: can we please turn off HTML email on the lists, and restrict attachments to text, jpg, png, gif? |
− | <rbray> Yes, I'll try that again. | + | <rbray> Yes, I'll try that again. |
− | <rbray> Did not work so well last time. Maybe I'll enlist Shawns help./ | + | <rbray> Did not work so well last time. Maybe I'll enlist Shawns help./ |
− | <jasonbirch> It's working on the WebCom list. Let me know if you want me to take over list admin. | + | <jasonbirch> It's working on the WebCom list. Let me know if you want me to take over list admin. |
− | <rbray> Sure. I'll send you the password by e-mail. | + | <rbray> Sure. I'll send you the password by e-mail. |
− | <jasonbirch> I gotta go... good meeting. see you next week and in email. | + | <jasonbirch> I gotta go... good meeting. see you next week and in email. |
− | <ChrisGo> its really nice to see so many leads in irc | + | <ChrisGo> its really nice to see so many leads in irc |
− | <rbray> Ok, we are out of time. All remaining topics go to the next meeting agenda. | + | <rbray> Ok, we are out of time. All remaining topics go to the next meeting agenda. |
− | <rbray> Thanks everyone... | + | <rbray> Thanks everyone... |
− | <TomFukushima> bye | + | <TomFukushima> bye |
− | <jasonbirch> Someone gonna grab the logs? | + | <jasonbirch> Someone gonna grab the logs? |
Latest revision as of 00:05, 2 February 2007
MapGuide PSC - Home
Meeting Info
The fifth meeting of the MapGuide PSC will take place Thursday February 1st at 18:00 UTC (1:00 PM EST / 11:00 AM MST / 10:00 AM PST).
Meeting Chair: Bob Bray Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=02&day=01&year=2007&hour=18&min=0&sec=0&p1=0 Location: The meeting will be held on IRC at #mapguide
Agenda
- CLA Collection
- Incubation Status
- Trac Setup, Process, Etc.
- Tweaking Mail List Behavior
- Process to put a minor modification into an already approved RFC. (Tom)
Actions
Transcript
<rbray> Ok, lets get started. Not sure where Jason and Tom are but I am sure they will join shortly. <rbray> First topic is CLA collection. We need to get everyone with commit rights to sign and send in a CLA. <rbray> Hey Jason. <pagameba> sorry, stepped out for a sec <jasonbirch> Howdy howdy (just to make you feel at home :) <rbray> I thought I would just post a mail to every commiter and have them fax them in. <rbray> Do we need to set a timeframe for that? <jasonbirch> Yes. <rbray> What do you think a week? <rbray> Else they lose commit rights... <jasonbirch> Is everyone currently available (not off on holiday? <pagameba> danmo: http://mapguide.osgeo.org/trac/ <sigq> Title: Available Projects (at mapguide.osgeo.org) <jasonbirch> I guess reinstating isn't that hard? <jasonbirch> trac.osgeo.org/trac/mapguide should be the URL we're using <rbray> Yes I think everyone is around. If not it is easy to remove and re-instate. <jasonbirch> SAC decided on serv-ce-based URLs, not project-based <rbray> That is correct. <rbray> The trac is not fully configured however. <rbray> Every evening that I have had spare cycles the SVN instance is down <rbray> and trac with it. <jasonbirch> Do you think that SVN might be getting hammered by spiders? <rbray> Although I am almost there. <rbray> No idea. I need to get SAC to look into it more closely. The upgrade was supposed to fix it, but it was down again last night., <bdechant> It seems to go more often then the old system <bdechant> *go down <jasonbirch> I wish I knew more about SVN. Perhaps there is a log that would allow us to trace what's happening. <rbray> Yes it does, not good. <rbray> Me too, but SAC is on it. <rbray> Anyway, back on topic. Is everyone ok with an e-mail and one week deadline for submitting a CLA? <jasonbirch> Seconded, +1 :) <bdechant> +1 <pagameba> +1 <Haris_> +1 <Andy_Morsell> +1 <rbray> Ok, one down. I'll send that out later today. <rbray> Next topic: Incubation Status. <rbray> danmo: are you with us at the moment? <danmo> yup <danmo> I have started reviewing everything <danmo> A few questions came up, the first one was whether we had an active bug tracker... hence my question about trac before the meeting <rbray> That will be in place by the end of this week. <danmo> Will trac be linked from a easy to find user-accessible location when the setup is completed? <rbray> Just need to finish the Wiki pages <rbray> Yep, right off the home page. <danmo> Cool <rbray> With anonymous access for ticket submission. <jasonbirch> We'll be restructuring the menu to be more developer-accessible. <jasonbirch> (Links to SVN, Trac, etc) <rbray> The initial rework of the left nav will be done this week too. <rbray> I am really just waiting to flip the switch on Trac. <rbray> Any other incubation concerns so far? <danmo> I think I saw that the old bugs from the CN system won't be ported to Trac? That's too bad <jasonbirch> Yes, it's unfortunate. It would be nice even to pull them into a web page as "historical". <rbray> That is the plan. Just need time to put together a XSLT for the XML. <rbray> There was about 300 defects/enhancements/tasks in the CN system. <danmo> I think we're in very good shape for incubation. Based on the MapGuide Incubation Status page we'd be all set, but I need to check with IncCom for a complete checklist to pass before graduation. pagameba, did you have such a checklist fro previous projects or was it enough to have addressed everything from the status page? <pagameba> thinking ... <pagameba> I thought there was a graduation checklist <pagameba> but I haven't looked in a while <pagameba> checking <danmo> I was hoping there would be one but could not find it this morning... <danmo> There is http://www.osgeo.org/incubator/process/evaluation.html <sigq> Title: Project Evaluation Criteria | OSGeo.org (at www.osgeo.org) <FrankW> There is no incubation checklist per se. <rbray> That is acceptance into incubation. <danmo> yeah, I know <rbray> Sounds like a next step for the Incubation Committee. A checklist would be helpful... <rbray> And provide some consistency. <FrankW> encourages rbray to prepare and submit one for discussion... <rbray> At any rate, danmo if you come across any issues please send them to the mailing list. <FrankW> I believe in the past it was felt to be redundant, duplicating much of the other material. <rbray> FrankW: Maybe I'll take on a mentor role and do that. <rbray> Any other incubation related questions or comments? <jasonbirch> The current process just points to the template: http://wiki.osgeo.org/index.php/Project_Graduation_Process <sigq> Title: Project Graduation Process - OSGEO (at wiki.osgeo.org) <rbray> There is this: http://wiki.osgeo.org/index.php/Project_Graduation_Checklist <sigq> Title: Project Graduation Checklist - OSGEO (at wiki.osgeo.org) <danmo> Perhaps the status page is the checklist, but then the template should be edited to include things like "does the project have a bug tracker?" I remember this was brought up as an issue with other projects <pagameba> yep, that seems to be all there is <jasonbirch> Just saw that link :) <jasonbirch> We're missing steps 9 and 10, but I don't think that OSGeo supports those directly? Or is MapGuide running under BuildBot already? <jasonbirch> Oops, sorry, not 10. <rbray> 10 is more or less in place. <rbray> There is a full unit test suite. We are also working on a scalability/performance suite. <danmo> I think I'd make 9 optional <rbray> 9 is internal at the moment. <jasonbirch> I prefer "not public" to internal :) <rbray> It would be nice to move that to BuildBot <rbray> Yea, I agree. But these things take time away from fun stuff. <rbray> Like feature development :) <jasonbirch> Once GeoTec is out of the way, I wouldn't mind getting involved in trying to figure out building and packaging automatically. <danmo> FrankW: Do the issues listed in the code provenance review need to have all been resolved before graduation? <rbray> Excellent a volunteer! <pagameba> danmo, I believe we decided that they did need to be resolved <jasonbirch> Since I'm not too helpful with the fun stuff (other than making my wishes clear) :) <pagameba> what are the issues? <danmo> They seem simple on the surface. For instance, FoundationTest.cpp missing header in http://wiki.osgeo.org/index.php/MapGuide_Provenance_Review <sigq> Title: MapGuide Provenance Review - OSGEO (at wiki.osgeo.org) <rbray> Looks like mostly missing LGPL license headers. <rbray> A lot of them in javascript files where we dont want them. <rbray> or html. <TomFukushima> Yes, most of them were HTML and Javascript files <jasonbirch> Are individual license headers required, or even desirable? <danmo> In the FDO code provenance review, there are a couple of mentioned of copyrighted files without mention of the license, e.g. ConvertUTF.cpp/.h and a couple of .xsd <pagameba> no, they are not required <pagameba> in small js files, for instance, we decided that it was acceptable to explicitly decide not to include them <rbray> FDO will be seperate. So that is excluded from MapGuide Incubation. <rbray> It will come formally into incubator once I get MG out. <danmo> But the incubation status doc refers to it ;) <pagameba> so for everything in that list that says 'no', we need to either fix it or say we won't fix it because it isn't required <rbray> Sorry, that was when I was trying to be slick and push it through with MG. <TomFukushima> pagameba: but they should be in large .js files then? <pagameba> its a judgement call ... but I think yes personally <jasonbirch> I think that a "Body of work" license should be all that is required, with headers only where there are exceptions. <rbray> We could just drop a license file into the directory of html/javascript. That would be easy and not burden the code. <pagameba> that works for me <rbray> danmo: I'll remove the FDO references from the MG incubation status page. <danmo> dropping a single license file in the html/js dirs seems to make sense to me too <TomFukushima> What's a "Body of work" license. Anyone have any examples they could send me? <rbray> Frank did not answer, but if my memory is correct all the issues in provence do not need resolution. As long as there are no copyright violations. <FrankW> Well, "outstanding issues" will be reviewed by inccom before approval. <FrankW> The key is to be sure that stuff is well understood and documented. <rbray> I think that was brought up on the incubator mail list at one point. <jasonbirch> It just means that we are asserting the license and copyright on the entire body of work (in a license.txt file) rather than in individual files. <jasonbirch> Unless the individual files contain differing licences/copyrights. <rbray> Ok, we could drop one of those in the tree. <rbray> danmo: Let us know how your review progresses. I'll keep this item on the agenda until we graduate. <danmo> license.txt as a replacement for license on every individual file or in addition to? <FrankW> Hopefully in addition to, but making up for the lack of it in some files (like javascript). <rbray> I would use it as a catch all. No way we are removing all those. <jasonbirch> lol <danmo> I remember reading in one of the incubation docs that a copyright and license ref was required in every file. I was surprised to see this requirement but it seems to have been agreed to by IncCom <rbray> I was one heck of a perl script that put them all in. <rbray> I = it <ChrisGo> any recommendations on a linux distro im not moving very fast on debian ;) <jasonbirch> Bob is a perl script. <rbray> ChrisGo: Fedora works well. <jasonbirch> CentOS will be closest to RH <rbray> We'll have an FGS installer for Linux in a couple months that should make install on any distro much easier. <ChrisGo> i was going to give that another try but the yum package thing was gona be a learning curve <FrankW> Sweet! <rbray> Oh yea, it works great on CentOS too. <FrankW> flees... <rbray> Shall we move on to the next topic, or do we have more incubation topics? <danmo> Here is the doc that requires the copyright in every .cpp and .h file: FAQ #1 at http://wiki.osgeo.org/index.php/Code_Provenance_Review <sigq> Title: Code Provenance Review - OSGEO (at wiki.osgeo.org) <ChrisGo> the biggest issue i was having was getting java sdk installed being its "non free" <ChrisGo> maybe i wil wiat a month or so and get the new installer and be clueless how it works but happy it works... yeah <rbray> ChrisGo: You are not the only one, I think we will create an opt out for Java. E.g. a PHP only build. <danmo> No more incubation topics from me <rbray> Ok, lets move on to Trac. <rbray> Which is really, really cool software BTW. <jasonbirch> Change in tune from last meeting ;) <rbray> Yea <rbray> I debated having RFCs simply be enhancement tickets, but... <rbray> You can't edit the description after submitting it. So it would not allow for refinement. <rbray> Instead I think we will need to link Enhancements to RFCs and vice versa. <rbray> Make sense? <jasonbirch> I think they need to be a separate status (or WIKI page) that reference appropriate enhancement tickets. <rbray> Right <jasonbirch> Or, in other words, yes. <rbray> We could use the Enhancment ticket to discuss the RFC, but that feels wrong. The mail list is the right place for that. <jasonbirch> Agreed. The RFC should be modified based on discussions in the mailing list. Right tool for the job. <pagameba> I vote for a wiki page for the actual RFC followed by an enhancement ticket when the RFC is approved <jasonbirch> Especially since we're not opening up Wiki rights outside of the PSC/Developer ++ community <pagameba> and discussions on the mailing list <rbray> Could happen the other way. <rbray> If a user requests an enhanment via a ticket, that then turns into an RFC. <rbray> For example. <jasonbirch> enhancement-> Wiki RFC -> Task <rbray> Don't need the task really do you? <jasonbirch> Yes, need it to track SVN commits for the RFC against. <rbray> Why not use the Enhancement? <jasonbirch> Might be many-> one between enhancements and RFC <rbray> I can buy that, just more tickets to manage though. <jasonbirch> Yes, but easier to track back from commits to RFC <rbray> Any objections to this approach? <rbray> If not then I'll document it on the Trac Wiki. <jasonbirch> Enhancement tickets should be closed as soon as fully integrated into RFC. <rbray> BTW: you can see trac in its current state at: http://www.osgeo.org/trac/mapguide <sigq> Title: MapGuide Open Source - Trac (at www.osgeo.org) <jasonbirch> RFC status (and associated task) are closed when code is complete <rbray> And all related enhancements... <TomFukushima> we should only close Enhancement when the RFC has been completed; RFC could always be withdrawn at some point <jasonbirch> No, I think enhancements should be closed as soon as RFC is adopted. <ChrisGo> rbray: you should do a web cast on linux ;-) <jasonbirch> Oh. <ChrisGo> I will even donate a few cases of your choice beer. <rbray> Excellent. <jasonbirch> ChrisGo: Individually shipped to the participants? <TomFukushima> I guess we could reopen the enhancement if the RFC is withdrawn <jasonbirch> I'd prefer that... <ChrisGo> I'be installed NetBSD, Fedora and Debian and once I get to the install package something always goes wrong ;X <rbray> How often do you think we would withdraw an RFC? <jasonbirch> I don't think that we even account for that in the process once it's adopted. <rbray> We dont at the moment. <rbray> ChrisGo: What version of Fedora? <jasonbirch> Let's hope it's a rare event. The process is supposed to confirm "rightness" and "commitment" <rbray> I agree. So lets go forth with enhancements are closed when the RFC is adopted. <rbray> Should probably be final RFC. Might take more than one for some enahancement requests. <rbray> Like the ones you ask for Jason :) <jasonbirch> Yes, don't close them unless they are fully implemented in the RFC. Add a note to the enhancement saying "partially implemented in RFC# / task# <rbray> Ok, I'll document that stuff on the new Wiki. Give me a day or so. <jasonbirch> Heh... <jasonbirch> ok. I have a meeting in 4 mins... :) <rbray> Last item on Trac, any suggestions for extra fields? <rbray> Not really sure we need any, although I did bring back Severity and Priority. <jasonbirch> Can we carry that over to email once have had time to look at current setup? <rbray> Of course. <rbray> I only added one field, External ID. Gee wonder what that is for... <jasonbirch> I don't want to know... <jasonbirch> Mailing list: can we please turn off HTML email on the lists, and restrict attachments to text, jpg, png, gif? <rbray> Yes, I'll try that again. <rbray> Did not work so well last time. Maybe I'll enlist Shawns help./ <jasonbirch> It's working on the WebCom list. Let me know if you want me to take over list admin. <rbray> Sure. I'll send you the password by e-mail. <jasonbirch> I gotta go... good meeting. see you next week and in email. <ChrisGo> its really nice to see so many leads in irc <rbray> Ok, we are out of time. All remaining topics go to the next meeting agenda. <rbray> Thanks everyone... <TomFukushima> bye <jasonbirch> Someone gonna grab the logs?