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@xxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review