Hi All,<div><br></div><div>With regards to osgeo4w I think we might consider various things to make the approach more reliable. Not sure I have a strong opinion about the exact direction, but at least the followings should be reconsidered.</div>
<div><br></div><div>1. Packages coming from various sources being made by hand in a non-regular fashion may cause the overall system fragile, incompatibilities between versions dependencies may likely happen. The overall build process is out of the control, it's quite difficult to reproduce at least the same build without requiring the package providers to participate. We are reusing  the same dependencies among various projects which is not necessarily be the only way to follow.</div>
<div>In my opinion if we continue to go with this multi-package concept, we could probably make it more reliable if we don't let the users to create their packages by hand. We should provide a build environment (a dedicated server) to provide the builds and the users should just author their build scripts which would check out the sources and compile it regularly or the build would be triggered by someone who is authorized to do it.</div>
<div><br></div><div>2. The current cygwin based installer is not necessarily be convenient for most Windows users.  I consider on Windows the users would rather require pre-bundled msi installers which would make things up and running instead of dealing versions and sub-package dependencies in mind. Users would not want to be in familiar with which version of zlib or curl is installed for MapServer or QGIS to run correctly. Installers may however contain feature selection options and further customizations according to the requirement of the project specifically. </div>
<div>For example QGIS and MapServer may have similar dependencies (like GDAL) but it not necessarily be the same version. Project may be installed into different target directories with different versions of the same dependencies side by side. This would let the projects provide more consistent builds without being affected by versions of external dependencies. Some of the projects may require further actions which could also be included in the installers as custom actions. For example we may probably install MapServer  with IIS registration, or bundled with a Web server like Apache or both. </div>
<div>We could however aim to use the same version of GDAL between multiple projects, but it would be essential to build the complete system in a centralized fashion and making sure about the correct build order according to the project hierarchies. Packages from a single project should also be build in a single process. I doubt it is a good solution for example to build GDAL core and the plugins or the bindings different times.</div>
<div><br></div><div><br></div><div>Since #1 is mostly about a build concept we could probably start with authoring the buildsystem and then build several installer on the top and the cygwin or the msi based packages could exist side by side.</div>
<div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Tamas</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">2013/3/2 Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>Il 02/03/2013 01:16, Frank Warmerdam ha scritto:<br>
<div class="im"><br>
> I must admit I'm not absolutely certain what the best way is<br>
> to move OSGeo4W forward.  Given the right person interested<br>
> in working on the project full time (or a substantial part time)<br>
> at a "scrappy" price, I'd push for funding but I'm not sure that<br>
> such a person exists.<br>
<br>
</div>Well, I think it depends a lot on what do you mean with "scrappy": can you work out a<br>
potential budget? I'm sure we can find support from our huge Windows power users base.<br>
<div class="im"><br>
> There are also some technical direction issues with<br>
> OSGeo4W that remain open.<br>
>  - Should we stay focused on just 32bit or add/switch to 64bit?<br>
<br>
</div>IMHO adding 64bit is important.<br>
<div class="im"><br>
>  - Should we do "complete refreshes" every could of<br>
>    years instead of the package by package updating<br>
>    that works well at the high level but not so well down<br>
>    in the low level packages (like GDAL).<br>
<br>
</div>IMHO a continuous refresh (à la Debian unstable) is the way to go.<br>
<div class="im"><br>
> Anyways, I don't want to dive into great detail on the board<br>
> list, but I do think OSGeo4W is worthy of OSGeo funding<br>
> if the project had a clear plan how such funding would<br>
> work.<br>
<br>
</div>Agreed fully - thanks for your thoughts.<br>
All the best.<br>
<br>
- --<br>
Paolo Cavallini - Faunalia<br>
<a href="http://www.faunalia.eu" target="_blank">www.faunalia.eu</a><br>
Full contact details at <a href="http://www.faunalia.eu/pc" target="_blank">www.faunalia.eu/pc</a><br>
Nuovi corsi QGIS e PostGIS: <a href="http://www.faunalia.it/calendario" target="_blank">http://www.faunalia.it/calendario</a><br>
<div class="im">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
</div>iEYEARECAAYFAlExwksACgkQ/NedwLUzIr4XuwCdHc+9aULI5WZG5sU/V2YgblFp<br>
KNUAoJ/9ApsahbIz0leTmdH6pvhSQIbw<br>
=x+wc<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>