Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=817268 --- Comment #10 from Alec Leamas <leamas.alec@xxxxxxxxx> 2012-05-09 04:22:09 EDT --- (In reply to comment #9) > Issues: > [!]: MUST Requires correct, justified where necessary. > Not requiring pygtk2. Good catch! Agreed. > [!]: The 'git' macro is defined but not used Agreed > [!]: I suggest the srpm be named 'faces-pm', and split into four rpms: > - faces-pm "A project management tool based on Python" (the executable, > and desktop entry file if you can provide) > - python-faces "Python modules of Faces project management tool" > - python-metapie "An application framework based on wxpython" (quoted from > metapie/__init__.py) > - python-faces-timescale "Timescale module for python-faces for Faces > project management tool" Agreed: split out python-metapie. As for application faces-pm, see below. > [!] There is a special homepage for this project: http://faces.homeip.net/ Agreed. There is more about that, faces have been and is hosted at many sites. Still I think sourceforge is the place for the most recent activities. The submitter of bug #693425 made some work here, and the overall conclusion at that point was to proceed like this. Since then, no more actual source has been released, so the situation is the same. Agreed: URL:http://faces.homeip.net/ > [!] The urls for Patch0 and Patch3 are the same. Agreed (patch0 is wrong). > [!] Patch0 is too heavy, actually cuts and relicenses the original file. I > think the job can be done within OpenERP instead of patching faces/__init__.py. Agreed: to patch the license is unacceptable. This is published under GPLv2+, and a patch can't change this. Also a good catch! That said, is there a rule saying how heavy a patch can be? Given that current code doesn't even pass setup.py? And that upstream doesn't respond when submitting patches? > Since Faces-pm seems dead, it may be acceptable that OpenERP adopts some useful > source files from Faces directly. This would be to bundle. That's something to avoid IMHO. > [!]: MUST Changelog in prescribed format. > Every time of change should bump release number, even still under review. No. http://fedoraproject.org/wiki/Packaging:Guidelines#Multiple_Changelog_Entries_per_Release > An empty is required between two changelog entries I could certainly put a blank between the entries. Is there such a requirement in the guidelines? > [!]: SHOULD Package functions as described. > I may not approve this package if the application doesn't run. Simply removing > the executable is not responsible. This is the core issue. We have here a package which is not maintained since many years, and thus partly doesn't work with recent python. There is no recent upstream activities I'm aware of about this. I have actually looked into patching it, and my conclusion is that it would *not* be responsible of me to try to fix it. It's simply beyond what I can do, it would end up in something which doesn't work. OTOH, openerp is doing exactly that for the libraries. It's just that they have no interest in the application. The project is dead, definitely. The openerp patch represents among other things what need to be done just to build it. This patch is sent upstream without any response at all. Note that the last commits (2010) are indeed openerp contributions i. e., openerp is nowadays the part which (partly) keeps faces up to recent python standards, something the upstream project don't. Open issues: - If you can't approve removing the application. - If you can't accept patch0 (revised for licensing) because being to heavy. I suggest that we consult the mailing list in case these cannot be resolved here. With these issues open, I don't publish new links ATM. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review