Hi all, We missed hackfest again :( But we were busy working on several things, that might be of interest, we:
1. fixed qgis2google, working again ;) 2. created a win-build with OTB plugins based on r14713m 3. modified all three measurement tools to work with unprojected data in lat-long and automagically give numbers in meters etc (angles are spherical), calculations are using QgsDistanceArea and WGS84 based. Handy for those who have rasters in latlong, but still want to get measurements in meters/km2 All three things are available for testing as a package, details on installation can be found here: http://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fgis-lab.info%2Fblog%2F2010-11%2Fotb-plugin-qgis%2F New measurements patch is in trac, can please someone have a look and commit or just review, Alex can commit. http://trac.osgeo.org/qgis/ticket/3240 Thanks to stopa85 and alexbruy for awesome work, Maxim Вы писали 19 ноября 2010 г., 19:24:46: AM> On 11/19/2010 04:43 PM, Martin Dobias wrote: >> Hi Alex >> >> On Sat, Nov 20, 2010 at 12:44 AM, Alex Mandel >> <tech_...@wildintellect.com> wrote: >>> >>> I feel that a central option would help new plugin authors and authors >>> who want collaborate on plugins. I've created a sourceforge site for my >>> plugins in the past and attracted zero developers and only had a handful >>> of bugs put into my trac. Aside from that, a central place lets us >>> easily adopt abandoned plugins, and to give 1 place for reporting bugs >>> which in theory would improve the reporting and tracking of fixes. >>> >>> I don't think we have to host it, but if we don't I would like to see us >>> pick one of the 3rd party hosting services and create a collaborative >>> collective under which people list their plugins(a qgis group). >> >> Picking a 3rd party hosting service seems like an option. Anyway there >> were such motions before, but did not really succeed: >> http://sourceforge.net/projects/qgiscommunitypl/ >> AM> The biggest con is that we can't use osgeo logins if it's 3rd party. AM> This to me is a big barrier to getting people using it. So picking a AM> place a bunch of us already use would be good. We could speculate more AM> about why that one didn't pan out (had forgotten about it) but I think AM> the important parts are that there needs to be some buy-in (which I feel AM> we have now that we've discussed the options), some ability for qgis AM> core devs to admin over it (for rescue purposes), and more visibility AM> like obvious linkage from qgis.org and in this case the new plugin site AM> that's being built. AM> My guess is a survey amongst current plugin and core devs would have AM> them pick github 1st and maybe googlecode next with AM> bitbucket/launchpad/sourceforge on the least favorite end. AM> I also think Paolo is really excited about a central place to report and AM> track issues. His team seems to do most of it right now and I see how AM> other users searching the internet could really benefit from knowing AM> where to look/getting them in search results. Then it just becomes a AM> cultural thing to convince devs to pay attention to it. >> >>> A large number of plugins right now aren't even under version control >>> and even fewer of them have public tickets systems. So when I go to hack >>> on a plugin(that isn't mine) I never know if I have the latest code or >>> if it's been fixed and I don't expect an update to the release for every >>> little fix. I also have no idea if it's still under development, or >>> abandoned in favor of something else, merged into another plugin, etc. >> >> I just have the impression that the plugin developers mostly will not >> use that service. As you say, lots of plugins don't have any >> versioning system (or just a private one) and maybe that's because the >> authors do not need it for their work - more than 90% of the plugins >> are one-man shows. >> AM> I actually see this as a potential issue going forward as more and more AM> people rely on plugins to get stuff done and there is potential to AM> incorporate some plugins that offer central functionality into the core. AM> A Bus number of 1 is kinda scary and while they may be one man shows AM> that might be because it too much effort to solicit help (I've heard AM> this from some developers out there over the years, 'I didn't open up AM> the code or ask for collaboration because it was too much extra work'). AM> Lack of version control is a little frightening too (Carson lost all his AM> original work on ftools at one point because he wasn't using version AM> control, I think he recovered from the already released code). My goal AM> is to better enable collaboration and encourage good open source AM> programming practices. >> In the new plugin repository we would like to keep track of plugin >> updates - so determining whether the plugin is dead should be simple. >> >> Regards >> Martin AM> Example, someone files a ticket with a patch to fix a major bug(feature) AM> in a plugin. Said plugin appears to be dead. So someone else grabs the AM> patch, forks the code, applies the patch and releases the plugin update. AM> I'm open to trying github right now before we go and install stuff if we AM> can figure out how to group stuff. I get the feeling the issue tracking AM> won't be super central but it's really easy to try it 1st before we AM> start installing stuff on the servers. AM> Thanks, AM> Alex AM> _______________________________________________ AM> Qgis-developer mailing list AM> Qgis-developer@lists.osgeo.org AM> http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer