[Bug 509158] Review Request: fedora-gnat-project-common – files shared by Ada libraries

[bugzilla at redhat.com]

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 at xn--rombobjrn-67a.se> 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 at xn--rombobjrn-67a.se>  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.