Ugh, what a mess.. Quoting Andrea Musuruane (2013-10-20 23:37:54) > Hi all, > last April the following bug report was opened: > https://bugzilla.redhat.com/show_bug.cgi?id=947457 > > As I stated on bugzilla, metadata-extractor was just needed by JOSM. > Updating metadata-extractor would break JOSM. Anyway I suggested to > patch JOSM to use a newer version of metadata-extractor if he really > needed it. I had no response at all. > > BTW, I am metadata-extractor maintainer, and not JOSM maintainer. Sorry but it is your responsibility as maintainer to keep the package up to date as much as possible. If JOSM required older version you should work with JOSM maintainer and upstream to update it to latest (providing patches/testing etc.) Why are you even maintaining metadata-extractor if you have no use for it? It only makese sense for JOSM maintainer to maintain metadata-extractor in the first place since he's the only user of the library > This evening the submitter emailed me privately and I discovered that > meanwhile, a new review request for a newer version of > metadata-extractor was approved and now it is part of Fedora: > https://bugzilla.redhat.com/show_bug.cgi?id=1004563 I don't like the naming of the package, both are metadata-extractor 2.x. If anything new package should have been metadata-extractor26. Technically the review was OK, the packages do not conflict in any way, but they are helluva confusing. All in all, even if JOSM couldn't be ported it would have been better to package metadata-extractor-compat solely for JOSM and then just update extractor to latest upstream. > As I understand now, newer metadata-extractor is required by Apache > Sorl and Apache Tika, which are not yet part of Fedora. Already are as was mentioned > He asked me to "exchange our repository" "to simplify some build with > maven". And with that I presume that he would like to have his package > called metadata-extractor because he has troubles to build sorl and > tika. Frankly...I'd rather ask for clarification. I have trouble understanding some people > I think all this have been handled very badly. He could have told why > he needed a more recent version of metadata-extractor in the first > place, the reviewer of #1004563 could have checked if the package > followed the naming guidelines and/or have checked if the package was > already in Fedora. The review was technically OK, there was one question from reviewer missing: Why cannot you use version already in Fedora and what have you done to fix that? Other than that the packages don't really conflict or cause any issues to each other AFAIK. > I still think that my original plan (i.e. patching JOSM). was more sensible. Agreed > What to do now? What do you think? Ideally? I'd say: 1. Update metadata-extractor to latest upstream, add maven metadata, shell script in /usr/bin/ etc. Basically overwrite metadata-extractor with current metadata-extractor2 2. Sort out JSOM breakage afterwards. Either package metadata-extractor-compat, or patch JSOM (ideally going to upstream with the patch afterwards) 3. Obsolete/deprecate metadata-extractor2 4. Wham someone with a cluestick > If it helps, if it makes things easier, I can release the ownership of > metadata-extractor and someone else can have good care. I just > packaged it because, as an openstreetmap mapper, I longed to have JOSM > in Fedora Libraries should be generally maintained by people who are actually using them in some application. But it's up to you after all said and done if you want to keep maintaining it. -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
