[Bug 436704] Review Request: mapnik - a Free toolkit for developing mapping applications

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: mapnik - a Free toolkit for developing mapping applications


https://bugzilla.redhat.com/show_bug.cgi?id=436704





------- Additional Comments From rezso at rdsor.ro  2008-07-29 21:42 EST -------
> The work that you have done so far is great and I'm both grateful and relieved
> that someone else took up the challenge. However please send your patches
> upstream - you have still yet to make any comments on the development mailing
> list for this project - they can then be merged into the stable branch as
> suggested. I have found them to be extremely receptive and responsive to what I
> have sent. Sending patches upstream is one of the core principles of packaging
> for Fedora:
> 
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> 
> I would urge you to convert the sed processing and other code-munging present in
> the .spec file into a patch and post it to the relevant list.
> 
> Regards
> Chris
> 

Chirs,

  I wish too to be so magical to fix evrything in this minute, but I
am afraid its not possible. First trac ticket #103 render all shiped
demo unusable for our mapnik, its annoying for this package to not have those
nice demos, second i still don't worked out a working patch so lets see upstream
 what have to say too for this issue, third I have to carry sed/grep 
workarounds since they are higly visible in the .spec but I olso want to get rid
of them ASAP by colaborate upsteam. I dislike patches for build infra (Makfiles,
scons, automagic stuff), but _totaly_ agree and follow tham only for source code
(c++/c/.py) for same reason as spot article says it, olso I always behave to
submitt relevant functional source code patch upstream. 
  With build infrastructure patch, I carry tham as sed/grep hacks as i explained.

  Its not the first one package which carry workarounds like this way,
please look at grass package, its simply terrifying one due to many arches and
OS supported upstream, upstream folk are pretty complex and its extremly hard
booth for tham and me to merge tham ATM, olso understood from tham that they
not focus only for particular distro e.g. fedora but for global functionality.
  Or, e.g lets take ogdi (another GIS) wich I maintain even upstream, simply
cannot get the time to rewrote a nice autoconf/automake to get rid of ugly hacks
due to fact that I have to issue a MS-VS project file wich i cannot deal,
and be aware of multiple unixes than, olso spent lot of time to clean license
and rewrote chunks, so for upstream could be hard too, not only for fedora
packager which can easily say "this/that I dont like".

 Chirs i agree, but its hard, and yes I am all to willing.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.