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=509158 Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: |Review Request: |gnat-project-common – files |fedora-gnat-project-common |shared by Ada libraries |– files shared by Ada | |libraries --- Comment #6 from Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> 2009-07-03 12:17:25 EDT --- New version: http://www.rombobjörn.se/packages/fedora-gnat-project-common.spec http://www.rombobjörn.se/packages/fedora-gnat-project-common-1.1-2.fc11.src.rpm (In reply to comment #4) > It's a good style to distribute the verbatin text of the license. Of corse this > may be a small file on your case, but in common it's a good idea, because the > user will get the version of the license text which was valid at the time of > publisching of your software. The license text inside the actual project file is also the one that was valid at the time of publishing. Anyway, I've added a license file now. It should at least make it clearer that the license covers all four files. > first, because it's your first release, I have to assume, that this package is > not widely tested and may contains bug. So it's a good idea to beginn the > versioning with a version nummer less the 1.0. That version numbers would contain any information about the quality of the software is an illusion. The amount of bugs depends on how meticulous the programmer is and what measures he takes to avoid bugs, not on the version number. I've seen high-quality software with low version numbers, and garbage with high version numbers. Version numbers should be ordinal numbers – first, second, third and so on. There is no such ordinal number as "zeroth". I'll call it the zeroth version if I must to get the package approved, not otherwise. > Second, If you have a major and a minor version number you can disting between > greater changes which may introduced new feature or have a API breakage and > minor changes which only fixed bugs. Now that I think about it I can see situations where a minor version number would be useful, so this is the first major version, and the first minor version of that major version, that is version 1.1. (In reply to comment #5) > for the buildroot stuff please keep in mind, that there are the EL-4 and EL5 > branches which based on RHEL 4 and RHEL 5. this releases contains older > releases of rpm because this distributions are designed for a very long > lifecycle in enterprises. When I started making my packages on Fedora 9 I had to hack around all sorts of problems – broken debuginfo packages, bogus dependencies, bad symlinks and whatnot. Then I found that several of my workarounds were unnecessary on Fedora 10, so I removed them. One more is unnecessary on Fedora 11. To build the packages for EPEL I'd have to insert the workarounds again, and probably run into even more problems. I'll take one step at a time. When the time comes for RHEL 6, maybe I'll be ready to build my packages for EPEL 6 – which will hopefully not need any more workarounds than Fedora 11 (nor buildroot tags) – but for now Fedora 10 and 11 is enough. -- 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review