Spec Name or Url: http://ftp.intevation.de/freegis/fedora/4/SPECS/gdal.spec SRPM Name or Url: http://ftp.intevation.de/freegis/fedora/4/SRPMS/gdal-1.3.0-1.src.rpm Description:GDAL is a translator library for raster geospatial data formats. As a library, it presents a single abstract data model to the calling application for all supported formats. The related OGR library (which lives within the GDAL source tree) provides a similar capability for simple features vector data. GDAL supports 40+ popular data formats, including commonly used ones (GeoTIFF, JPEG, PNG and more) as well as the ones used in GIS and remote sensing software packages (ERDAS Imagine, ESRI Arc/Info, ENVI, PCI Geomatics). Also supported many remote sensing and scientific data distribution formats such as HDF, EOS FAST, NOAA L1B, NetCDF, FITS. OGR library supports popular vector formats like ESRI Shapefile, TIGER data, S57, MapInfo File, DGN, GML and more. ------------------------ This is my first package for Fedora 4 so I am seeking a sponsor. Some additional information: ============================ The package is an update of the package discussed about a year ago for fedora 2 (see https://bugzilla.fedora.us/show_bug.cgi?id=1964). I tried to clean all issues but still have a few rpmlint errors resp. warnings: I don't know how to get rid of the following two errors: E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp I couldn't find any hint in the guidelines which documentation should be included at least in a package. Could you please give a pointer so that I can fix this warning? W: gdal-python no-documentation Greetings, Silke
(In reply to comment #0) > I don't know how to get rid of the following two errors: > E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h > E: gdal-debuginfo script-without-shellbang /usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp For some reason these files are marked as executable in the source tarball. Fix the permissions in %prep and this will disappear. > I couldn't find any hint in the guidelines which documentation should be included at least in a package. Could you please give a pointer so that I can fix this warning? > W: gdal-python no-documentation Samples are always a good call.
Not a formal review, just some comments: + A lot of progress since the last iteration The package seems basically OK to me, nevertheless there still are some major gripes, therefore I can avoid: NEEDSWORK - Is there a particular reason for using the internal libtiff? I recommend using the version being shipped with FC, if possible. AFAIS, the version shipped with FC4 seems to be sufficient, I haven't check other versions. - Building the internal libtiff pulls in parts from the private copy of zlib (AFAIS, they compile against the internal headers, but link against the external libz): # grep zlib log /bin/sh ../../../libtool --mode=compile gcc -c -I../../../port -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -I/usr/include/netcdf-3 -I../../../port -DZIP_SUPPORT -DPIXARLOG_SUPPORT -I../../zlib -DJPEG_SUPPORT tif_aux.c -o ../../o/tif_aux.o ... Using the external libtiff seems to avoid this issue. - Something doesn't seem to be correct with mysql-support. If building the package outside of buildroots (with mysql-devel installed), mysql support is being built in, but I can't spot any corresponding "BuildRequires:". => Non deterministic build results I recommend to either switch it off (--with-mysql=no) or to make it mandatory (BuildRequires: mysql-devel/--with-mysql). - Similar consideration on hdf5 (hdf5 is part of FE). If building the package outside of buildroots (with hdf5-devel installed), hdf5 support is picked up. => Non deterministic build results I recommend to either switch it off (--with-hdf5=no) or to make it mandatory (BuildRequires: hdf5-devel/--with-hdf5). - Probably a lot of missing package deps inside of devel package. (c.f. /usr/lib/libgdal.la) Additional remarks: - I recommend not to ship static libs. - Other reviewers probably will gripe on shipping libtool archives, but my opinion differs (This is a different story ;) ).
According to Comments 1 and 2 I prepared a new package now available at http://ftp.intevation.de/freegis/fedora/4/SRPMS/gdal-1.3.0-2.src.rpm The locate for the specfile is the same as before: http://ftp.intevation.de/freegis/fedora/4/SPECS/gdal.spec Please see my additional remarks to both comments in direkt reply.
(In reply to comment #2) > > NEEDSWORK > > - Is there a particular reason for using the internal libtiff? > I recommend using the version being shipped with FC, if possible. AFAIS, the > version shipped with FC4 seems to be sufficient, I haven't check other versions. Yes you are right. Using internal libtiff has historical reasons and I forgot to change it. > - Something doesn't seem to be correct with mysql-support. [...] > > I recommend to either switch it off (--with-mysql=no) or to make it mandatory > (BuildRequires: mysql-devel/--with-mysql). > > > - Similar consideration on hdf5 (hdf5 is part of FE). [...] This is fixed with the new gdal package (See comment #3). > - Probably a lot of missing package deps inside of devel package. > (c.f. /usr/lib/libgdal.la) As far as I can see the dependencies are sufficient. gdal-devel is sufficient to build other packages against gdal. I tried with mapserver after removing all other devel-packages on my system. > > Additional remarks: > - I recommend not to ship static libs. Why? Mostly static libs are not needed but if someone really needs the static lib it is nice to have it available. > > - Other reviewers probably will gripe on shipping libtool archives, but my > opinion differs (This is a different story ;) ). Ack. I can easily remove it. But I think it doesn't hurt to have it available. It is still included in the current package.
(In reply to comment #1) > (In reply to comment #0) > > I don't know how to get rid of the following two errors: > > E: gdal-debuginfo script-without-shellbang > /usr/src/debug/gdal-1.3.0/frmts/jpeg/gdalexif.h > > E: gdal-debuginfo script-without-shellbang > /usr/src/debug/gdal-1.3.0/alg/gdal_tps.cpp > > For some reason these files are marked as executable in the source tarball. Fix > the permissions in %prep and this will disappear. Thanks for this hint. This is fixed in the new package (see Comment #3) > > I couldn't find any hint in the guidelines which documentation should be > included at least in a package. Could you please give a pointer so that I can > fix this warning? > > W: gdal-python no-documentation > > Samples are always a good call. Hm. The samples are already included either as python modules or as python scripts in /usr/bin since they are not only samples but very useful tools. Thus I don't think that including them as samples for documentation is a good idea.
(In reply to comment #4) > (In reply to comment #2) > > > Yes you are right. Using internal libtiff has historical reasons and I forgot > to change it. You still seem to have forgotten it ;) BuildRequires: libtiff-devel >= 3.60 configure ... --with-libtiff ... Without this, building gdal inside of a chroot will build the internal libtiff. > > - Probably a lot of missing package deps inside of devel package. > > (c.f. /usr/lib/libgdal.la) > > As far as I can see the dependencies are sufficient. gdal-devel is sufficient to > build other packages against gdal. I tried with mapserver after removing all > other devel-packages on my system. Hmm, libgal is linked against various libraries. Normally you will not be able to link against libgal unless you have all devel packages corresponding to these libraries installed. AFAIS, this comprises: openssl-devel libjpeg-devel libungif-devel hdf5-devel mysql-devel netcdf-devel unixODBC-devel libpng-devel postgresql-devel sqlite-devel libtiff-devel zlib-devel and probably more (e.g. xorg-x11-libs). > > Additional remarks: > > - I recommend not to ship static libs. > > Why? Mostly static libs are not needed but if someone really needs the > static lib it is nice to have it available. The reasons are: * Maintainability/bugfixing: Unless a library's ABI/API changes, exchanging a shared lib often is sufficient. * Statically linked applications are easy to miss when fixing security issues. * Package bloat * Static linkage is rarely used and even less rarely required. * Avoiding potential licensing issues (static linkage vs. shared linkage makes a substantial difference licensing-wise). All in all, IMO, static libs cause more troublesome than they are useful, but that's just my personal preference. > > - Other reviewers probably will gripe on shipping libtool archives, but my > > opinion differs (This is a different story ;) ). > > Ack. I can easily remove it. But I think it doesn't hurt to have it available. > It is still included in the current package. Fine with me - I consider *.la's to be part of a package's API and removing them to imply breaking the API ;) Note: If you decide to ship *.la's, you can't easily remove them, after a package has been released, because other *.la's depending on them will pickup references to them. I.e. once they are in, you're better off keeping them or you will have to recompile all other libs depending on the *.la.
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #2) > > > > > > Yes you are right. Using internal libtiff has historical reasons and I forgot > > to change it. > You still seem to have forgotten it ;) > > BuildRequires: libtiff-devel >= 3.60 > configure ... --with-libtiff ... > > Without this, building gdal inside of a chroot will build the internal libtiff. Oops, you are of course right. Changed this with an updated version (see usual place on our server). > > > > - Probably a lot of missing package deps inside of devel package. > > > (c.f. /usr/lib/libgdal.la) > > > > As far as I can see the dependencies are sufficient. gdal-devel is sufficient to > > build other packages against gdal. I tried with mapserver after removing all > > other devel-packages on my system. > Hmm, libgal is linked against various libraries. Normally you will not be able > to link against libgal unless you have all devel packages corresponding to these > libraries installed. But I could link an application (in this case UMN MapServer) against gdal with only having gdal-devel (and gd-devel with is necessary for UMN) installed on my system. gdal just creates something like an API to different raster and vector GIS formats. So no information about postgresql, hdf, mysql etc. is needed to have access to gdal. I furthermore checked the header files in /usr/include/gdal to see which header files they include and they just need either other gdal-header files or standards like stdio.h etc. So I am rather sure that the dependencies are sufficient. Have I overseen something? > > > > Additional remarks: > > > - I recommend not to ship static libs. > > > > Why? Mostly static libs are not needed but if someone really needs the > > static lib it is nice to have it available. > The reasons are: > * Maintainability/bugfixing: Unless a library's ABI/API changes, exchanging a > shared lib often is sufficient. > * Statically linked applications are easy to miss when fixing security issues. > * Package bloat > * Static linkage is rarely used and even less rarely required. > * Avoiding potential licensing issues (static linkage vs. shared linkage makes a > substantial difference licensing-wise). Most of these reasons are reasons against static linkage and for shared linkage and I fully agree with you in this issue. Nevertheless if really someone would like to statically link gdal I don't want my package to be the stopper - even if I would probably never need it myself. > > All in all, IMO, static libs cause more troublesome than they are useful, but > that's just my personal preference. > > > > - Other reviewers probably will gripe on shipping libtool archives, but my > > > opinion differs (This is a different story ;) ). > > > > Ack. I can easily remove it. But I think it doesn't hurt to have it available. > > It is still included in the current package. > Fine with me - I consider *.la's to be part of a package's API and removing them > to imply breaking the API ;) > > Note: If you decide to ship *.la's, you can't easily remove them, after a > package has been released, because other *.la's depending on them will pickup > references to them. I.e. once they are in, you're better off keeping them or you > will have to recompile all other libs depending on the *.la. OK. Thanks for this hint. Since I don't have a real preference on having the *.la included or not I think I will wait what the reviewer will say about it.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > (In reply to comment #2) > > > > - Probably a lot of missing package deps inside of devel package. > > > > (c.f. /usr/lib/libgdal.la) > > > > > > As far as I can see the dependencies are sufficient. gdal-devel is sufficient to > > > build other packages against gdal. I tried with mapserver after removing all > > > other devel-packages on my system. > > Hmm, libgal is linked against various libraries. Normally you will not be able > > to link against libgal unless you have all devel packages corresponding to these > > libraries installed. > gdal just creates something like an API to different raster and vector GIS > formats. So no information about postgresql, hdf, mysql etc. is needed to have > access to gdal. I furthermore checked the header files in /usr/include/gdal to > see which header files they include and they just need either other gdal-header > files or standards like stdio.h etc. So I am rather sure that the dependencies > are sufficient. Have I overseen something? Yes, * check the output of nm -sDC libgdal.so.1.8.0 | grep ' U ' libgdal.so.1.8.0 uses other libraries. In your testcase you probably just happen to get away luckily, because your application just seems to happen not to use functions from these other libs. * The gdal headers use headers from other packages: # cd /usr/include/gdal # grep \#include *.h | sed 's,.*[\"\<]\(.*\)[\"\>],\1,' | \ while read a; do if [ ! -f $a ]; then echo "$a"; fi; done sql.h sqlext.h ... > > > > Additional remarks: > > > > - I recommend not to ship static libs. > Most of these reasons are reasons against static linkage and for shared linkage > and I fully agree with you in this issue. Nevertheless if really someone would > like to statically link gdal I don't want my package to be the stopper - even if > I would probably never need it myself. The point is: Probably nobody uses them! The only reason I can imagine for wanting to use static libs is application vendors to ship application binaries, which are supposed to be "distribution independent". From a distribution's view this doesn't make sense, because all dependencies inside of the distribution can resolved inside of the distribution.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #4) > > > > (In reply to comment #2) Sorry for my late answer. I have been busy with some preparation of a fair and ill afterwards. But now I am finally back to packaging GIS software :-) > > > > > > - Probably a lot of missing package deps inside of devel package. > > > > > (c.f. /usr/lib/libgdal.la) > > > > > > > > As far as I can see the dependencies are sufficient. gdal-devel is > sufficient to > > > > build other packages against gdal. I tried with mapserver after removing all > > > > other devel-packages on my system. > > > Hmm, libgal is linked against various libraries. Normally you will not be able > > > to link against libgal unless you have all devel packages corresponding to these > > > libraries installed. > > > gdal just creates something like an API to different raster and vector GIS > > formats. So no information about postgresql, hdf, mysql etc. is needed to have > > access to gdal. I furthermore checked the header files in /usr/include/gdal to > > see which header files they include and they just need either other gdal-header > > files or standards like stdio.h etc. So I am rather sure that the dependencies > > are sufficient. Have I overseen something? > > Yes, You were right. I ran into the problem when I packaged another more complicated software using gdal which is called qgis. I now added all (at least I think so) necessary dependencies. Furthermore I build a new version of the package, since meanwhile gdal 1.3.1 has become available. Please look again at http://ftp.intevation.de/freegis/fedora/4/ Many thanks so far for all your comments. Silke
- Drop static libs and .la files everywhere - Consider including pymod/samples in -python %doc
(In reply to comment #10) > - Drop static libs and .la files everywhere > - Consider including pymod/samples in -python %doc OK. I have changed this. Furthermore I have recompiled gdal fro FC 5. The new specfile and SRPMS are available at http://ftp.intevation.de/freegis/fedora/5 The output of rpmlint is: W: gdal unstripped-binary-or-object /usr/lib/libgdal.so.1.9.0 W: gdal-bin unstripped-binary-or-object /usr/bin/gdal_contour W: gdal-bin unstripped-binary-or-object /usr/bin/gdaltindex W: gdal-bin unstripped-binary-or-object /usr/bin/gdal_translate W: gdal-bin unstripped-binary-or-object /usr/bin/ogr2ogr W: gdal-bin unstripped-binary-or-object /usr/bin/ogrtindex W: gdal-bin unstripped-binary-or-object /usr/bin/gdaladdo W: gdal-bin unstripped-binary-or-object /usr/bin/gdalwarp W: gdal-bin unstripped-binary-or-object /usr/bin/ogrinfo W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo Should I strip the binaries and libraries manually or can I ignore these warnings?
(In reply to comment #11) > W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo > > Should I strip the binaries and libraries manually or can I ignore these warnings? Neither. RPM is supposed to strip binaries in /usr/bin automatically. I.e. this indicates a serious problem elsewhere, which needs to be investigated.
(In reply to comment #12) > (In reply to comment #11) > > > W: gdal-bin unstripped-binary-or-object /usr/bin/gdalinfo > > > > Should I strip the binaries and libraries manually or can I ignore these warnings? > > Neither. RPM is supposed to strip binaries in /usr/bin automatically. > > I.e. this indicates a serious problem elsewhere, which needs to be investigated. > I checked this again. For debugging purposes I added 'set -x' to /usr/lib/rpm/brp-strip and found out that at least all binaries are stripped with -g option: strip -g /var/tmp/gdal-1.3.1-2-root-silke/usr/bin/gdaltindex Any ideas how I can proceed to debug the problem?
2 issues: * Package doesn't acknowledge $RPM_OPT_FLAGS. The cause is the -fPIC hack inside of the spec file is overriding CFLAGS and CXXFLAGS, instead of combining -fPIC and $RPM_OPT_FLAGS. You probably want CFLAGS="-fPIC $RPM_OPT_FLAGS" \ CXXFLAGS="-fPIC $RPM_OPT_FLAGS" \ %configure ... or similar. * These two manpages from *-bin: /usr/share/man/man1/pct2rgb.py.1.gz /usr/share/man/man1/rgb2pct.py.1.gz should be moved to *-python, because the executables they refer to are in *-python.
> /usr/lib/rpm/brp-strip You should have /usr/lib/rpm/redhat/brp-strip which is part of the "redhat-rpm-config" package which in turn is available if "fedora-rpmdevtools" are installed.
Ping?
(In reply to comment #16) > Ping? I think, this PR has been lingering around long enough and should be closed to give others who might be more interested into this package that the OP an opportunity to take over.
if anyone is interested i got a patch around that makes dynamically building vs hdf4 possible. just lemme know.
Ignacio, are you still reviewing this review request? I think this PR has exceeded all reasonable limits and should be closed now.
#19 where can i read up about the time limit policy for review requests? if something like that doesent exist theres no time limits at all in my eyes.
(In reply to comment #20) > #19 where can i read up about the time limit policy for review requests? Nowhere. IMO, Silke is simply AWOL and has left this Review request behind. > if something like that doesent exist theres no time limits at all in my eyes. Jerks "stopping by and dropping a Review bomb" don't help anybody. They should be sanctioned. If Fedora doesn't have a policy on this, it should be implemented.
(In reply to comment #21) > (In reply to comment #20) > > #19 where can i read up about the time limit policy for review requests? > Nowhere. IMO, Silke is simply AWOL and has left this Review request behind. > > > if something like that doesent exist theres no time limits at all in my eyes. > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should > be sanctioned. > > If Fedora doesn't have a policy on this, it should be implemented. > #21 well then instead of posting in tons of review requests id suggest to work on getting a policy out that doesent hurt progress. you see everything from a rather negative side. i dont see it as review bomb. more as work in progress. maybe at some point circumstances dont allow the initial poster to continue. closing the bug though will only make the time invested by anyone involved "wasted time" why not deal with it rather in a manner as with orphaned packages -> orphaned review request. someone else can take over and can continue to work on the existing base. i want progress not wheel reinvention by having someone else starting from scratch and having all the stuff repeated over and over. gdal is an important key component for various interesting things. well its a bit offtopic to discuss that here but "blackmailing" review requests is just not the right approach in my eyes... instead wheres the rfe for enhanced review rules? also e.g. in the case of initng ... if you want software that fits well into fedora, fedora people have to have an organized way to work through the stuff. the more replys the more interest into a package -> the more progress and progress and final output is all that really counts in my eyes. everything else is just a waste of all our time. hope you dont take the response as offensive.. its not meant to be. just my opinion on the case.
(In reply to comment #22) > why not deal with it rather in a manner as with orphaned packages -> orphaned > review request. someone else can take over and can continue to work on the > existing base. FWIW, something similar happened with milter-regex. I was reviewing it and found it sufficiently interesting that I started using the package myself. For whatever reason, the original poster lost interest in it and after a few unanswered requests, I resubmitted the package myself and closed the original review request as a duplicate of my new one. Somebody else then reviewed "my" package, and it's now in Extras.
In reply to comment #22) > > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should > > be sanctioned. > > > > If Fedora doesn't have a policy on this, it should be implemented. > > > #21 > well then instead of posting in tons of review requests id suggest to work on > getting a policy out that doesent hurt progress. > i dont see it as review bomb. I do. Just have a look at the timeline of Silke's responses. There are many months inbetween any response of hers. Have a look at how many times she had been asked to respond, ... nothing much since ... Finally, this is not the first incident of this type with Silke - IIRC, the same has happened in Fedora.US. - So, I am not negative, I am drawing conclusions based on former contacts with her. As it seems to me, her opinion is, she can "stop by", "drop her spec" and let others polish it - She should learn she's in error. > why not deal with it rather in a manner as with orphaned packages -> orphaned > review request. someone else can take over and can continue to work on the > existing base. I am opposed to doing this, because this would encourage people to perform "drive-by review request bombs". Instead, people should to understand that if they submit a package for review, it's their baby they are dropping and they'll be expected to take care about it in future. If that's not acceptable to them, they 'd better stay away from FE. > i want progress not wheel reinvention by having someone else starting from > scratch and having all the stuff repeated over and over. Well, I am not opposed in somebody else adopting Silke's package. But it won't be me - I am not her coding-monkey. > gdal is an important key component for various interesting things. Exactly, that's why I want to see this "damn thing" nailed down. Actually, I want * Silke to wake up and start cooperating or * some volunteer to take over her package or * somebody closing this RR, giving others the liberty of resubmitting a new one. > also e.g. in the case of initng ... initng and my other very friend elektra are completely different cases. IMO, these packages are a million miles away off from being ready for public use. In case of gdal the situation different: This simply is a case of a submitter being non-responsive for reasons I can only speculate on. > hope you dont take the response as offensive.. its not meant to be. Understood.
Regarding gdal, I'd be happy to finish this one off if there are no other volunteers. It's a bit of a beast due to the dependencies and testing whether the package is working right is also time consuming. But, as Rudolf noted, this package is key to getting the open-source GIS packages into Fedora (QGIS, Grass, etc) and until its approved, Fedora won't have any GIS applications in the extras repository. I had a package ready last fall but then saw that this submission was already in progress. I exchanged emails with Silke back in January to see if she wanted any help getting this finished off, but haven't pushed to get closure. My vote is to declare this an orphan package and let someone else take it over and finish it off (either by starting fresh or fixing up what exists).
(In reply to comment #25) > Regarding gdal, I'd be happy to finish this one off if there are no other > volunteers. It's a bit of a beast due to the dependencies and testing whether > the package is working right is also time consuming. But, as Rudolf noted, this > package is key to getting the open-source GIS packages into Fedora (QGIS, Grass, This and the key to next generation game development. i just finished off doing basic packaging of delta3d and all its dependencies... some require a ton of selfwritten patches. i am just about to get stuff upstream and polish everything. i have a full blown gdal package btw... builds on fc5 with all deps dynamically that are important and free. i might put up the yet in extras missing stuff into a special repository on newrpms. some things require more work. and i wont be able to maintain it all. i am just interested in delta3d itsself. if you take over the package we could get in further contact and id be happy to pass you my current work so you can merge stuff you want in. id be also willing to help you with all issues i can help with. > etc) and until its approved, Fedora won't have any GIS applications in the > extras repository. > > I had a package ready last fall but then saw that this submission was already in > progress. I exchanged emails with Silke back in January to see if she wanted any > help getting this finished off, but haven't pushed to get closure. > > My vote is to declare this an orphan package and let someone else take it over > and finish it off (either by starting fresh or fixing up what exists). >
(In reply to comment #24) > In reply to comment #22) > > > > Jerks "stopping by and dropping a Review bomb" don't help anybody. They should > > > be sanctioned. > > > > > > If Fedora doesn't have a policy on this, it should be implemented. > > > > > #21 > > well then instead of posting in tons of review requests id suggest to work on > > getting a policy out that doesent hurt progress. > > > i dont see it as review bomb. > I do. Just have a look at the timeline of Silke's responses. There are many > months inbetween any response of hers. Have a look at how many times she had > been asked to respond, ... nothing much since ... > Finally, this is not the first incident of this type with Silke - IIRC, the same > has happened in Fedora.US. - So, I am not negative, I am drawing conclusions > based on former contacts with her. Yes i can see that. i can also see your point of view. but in the end the really important stuff is to change things in general. so there must be a good solution about this. > > As it seems to me, her opinion is, she can "stop by", "drop her spec" and let > others polish it - She should learn she's in error. > > > why not deal with it rather in a manner as with orphaned packages -> orphaned > > review request. someone else can take over and can continue to work on the > > existing base. > I am opposed to doing this, because this would encourage people to perform > "drive-by review request bombs". Instead, people should to understand that if > they submit a package for review, it's their baby they are dropping and they'll > be expected to take care about it in future. > > If that's not acceptable to them, they 'd better stay away from FE. > > > i want progress not wheel reinvention by having someone else starting from > > scratch and having all the stuff repeated over and over. > Well, I am not opposed in somebody else adopting Silke's package. But it won't > be me - I am not her coding-monkey. no one wants to push you into the role of the maintainer. seriously wasnt my intention. > > > gdal is an important key component for various interesting things. > Exactly, that's why I want to see this "damn thing" nailed down. same here. > > Actually, I want > * Silke to wake up and start cooperating > or > * some volunteer to take over her package > or > * somebody closing this RR, giving others the liberty of resubmitting a new one. like above id still say that there should be some rules nailed down. > > > also e.g. in the case of initng ... > initng and my other very friend elektra are completely different cases. IMO, > these packages are a million miles away off from being ready for public use. but theres fedora specific work to be done. the initng daemon is ready in the next release probably because all buildwarnings been fixed and it also works on x86_64 pretty well already. the scripts have to be tweaked in a fedora special way at times so theres a good point to start off the work. i can see your point of view that this is development work... but thats life... with a project like replacing the init system you cant just go there alone and fix it up in a day. i think that the bugzilla thread helped alot in getting a dedicated place to get the right things together to fix all open issues that arise or are brought up in this and future release to block it from inclusion into extras. thats the point of a review. i use initng on 2 fedora boxes personally. a thinkpad r51 and a x86_64 desktop box. having the thread really fired up lots of work that might not have happened without it. i wouldnt have looked at it either and also submitted a few small patches upstream already. > > In case of gdal the situation different: This simply is a case of a submitter > being non-responsive for reasons I can only speculate on. yeah but in both cases my conclusion is the same. there needs to be a pinned down rules what is supposed to happen and not. e.g. in this case asking for someone to takeover i think is a better thing. like on the mailinglist. elektra is again completly different because initng offers undoubtfully features certain interest groups are missing yet and theres no comparable other stab at it currently. elektra though is something that requires changes in alot other packages to be useful.... unless... someone goes and makes bindings to all scripting languages with swig. then people could just use it for some projects if they fill its nice. its there anyways. some people are interested in it enough to maintain a package. I am also not yet sure though if it would be my taste > > > hope you dont take the response as offensive.. its not meant to be. > Understood. > >
Closing, due to https://www.redhat.com/archives/fedora-extras-list/2006-June/msg00275.html Shaun, Rudolf or whoever feels addressed, feel encouraged to submit a new versions of gdal for review.
Make that review block FE-DEADREVIEW
(In reply to comment #29) > Make that review block FE-DEADREVIEW I fail to see the usefulness of FE-DEADREVIEW. All it does is to add further bureaucracy.
If I understand well it is not something mandatory, it may help contributors who want to submit a package, as in case it has allready been submitted but abandonned they can see it by looking at the FE-DEADREVIEW tree. If it was mandatory sure it would add more bureaucracy.
New review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205955
Marking this as duplicate as new request appeared. *** This bug has been marked as a duplicate of 205955 ***