6:27 a.m.
Hello
I would like to hear some more opinions on the subject described in
the thread started by
https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is
expressed in comment #9 and I am quite sure that any future update of
the rawhide version might introduce the exact same problem again. I
could, of course, keep using always the same release tag as in the
corresponding rawhide version, but it looks a bit odd to me. Are there
any guidelines on the subject of the correspondence of release numbers
between epel and rawhide ?
--
Manuel
7:33 a.m.
On Tue, Feb 03, 2009 at 02:27:18PM +0200, Manuel Wolfshant wrote:
Hello
I would like to hear some more opinions on the subject described in
the thread started by
https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is
expressed in comment #9 and I am quite sure that any future update of
the rawhide version might introduce the exact same problem again. I
could, of course, keep using always the same release tag as in the
corresponding rawhide version, but it looks a bit odd to me. Are there
any guidelines on the subject of the correspondence of release numbers
between epel and rawhide ?
First, I think that the exact same guidelines should apply to fedora
rawhide versus fedora releases.
Then I think that it is better to sync releases when this really
corresponds with the same package (same version, same functionality),
and helps versionned requires. However, I don't think that bumps and
builds should be done only for that. In the case at hand, the build
should still be in epel testing, so a bump and a rebuild would
do no harm and help requires, so I think it is fine to do it -- at
least when there is a known case where it helps requires.
In the end I don't think that this should be a guideline, more something
that is left to the packager. So if you think that it is pointless to
try to sync with the rawhide releases, you shouldn't do the bump and
rebuild.
--
Pat
7:41 a.m.
On 03.02.2009 13:27, Manuel Wolfshant wrote:
I would like to hear some more opinions on the subject described
in
the thread started by
https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is
expressed in comment #9 and I am quite sure that any future update of
the rawhide version might introduce the exact same problem again.
I'd tend to agree with some of what the reported outlines, but I'd say
it's not important enough to justify a rebuild.
I
could, of course, keep using always the same release tag as in the
corresponding rawhide version, but it looks a bit odd to me.
For me it's not odd; I'd even say it's the natural thing to do.
Rawhide is the main "devel branch" for the spec file itself -- the
version-release of the spec file for me is like a verison number of a
regular software. Version numbers don't go backwards; thus if I'd (kind
of) fork a spec file by picking it from rawhide and using it for another
branch (EPEL in this case) then I'd normally leave the version-release
as it is as long as %dist gets used in %release.
But if maintainers in Rawhide and EPEL are different then I'd want to be
on the safe site and would add a ".1" to %release and "rebuild for
EPEL"
to the changelog -- then it's obvious where this spec file exactly comes
from and how they relate to each other -- that might be important to
know for users and packagers.
CU
knurd
8:09 a.m.
Thorsten Leemhuis wrote:
On 03.02.2009 13:27, Manuel Wolfshant wrote:
> I would like to hear some more opinions on the subject described
> in the thread started by
> https://bugzilla.redhat.com/show_bug.cgi?id=481601#c6. My opinion is
> expressed in comment #9 and I am quite sure that any future update of
> the rawhide version might introduce the exact same problem again.
I'd tend to agree with some of what the reported outlines, but I'd say
it's not important enough to justify a rebuild.
> I could, of course, keep using always the same release tag as in the
> corresponding rawhide version, but it looks a bit odd to me.
For me it's not odd; I'd even say it's the natural thing to do.
Rawhide is the main "devel branch" for the spec file itself -- the
version-release of the spec file for me is like a verison number of a
regular software. Version numbers don't go backwards; thus if I'd
(kind of) fork a spec file by picking it from rawhide and using it for
another branch (EPEL in this case) then I'd normally leave the
version-release as it is as long as %dist gets used in %release.
But if maintainers in Rawhide and EPEL are different then I'd want to
be on the safe site and would add a ".1" to %release and "rebuild for
EPEL" to the changelog -- then it's obvious where this spec file
exactly comes from and how they relate to each other -- that might be
important to know for users and packagers.
Maintainers are different in EPEL and rawhide. I try to sync with Ville
before rebuilding in EPEL, but I am not going to keep his pace. My
intention is to do as few rebuilds as sensible, integrating the
differences accumulated over time. Current bump to 0.85 was mainly
triggered by the release of RHEL 5.3 and integrated a few changes which
were commited by Ville to CVS, were not yet included in any version
built in koji but about which he told me in a private mail that might be
good to include. Changes which were properly documented by me in the
changelog.
8:31 a.m.
On 03.02.2009 15:09, Manuel Wolfshant wrote:
Thorsten Leemhuis wrote:
> On 03.02.2009 13:27, Manuel Wolfshant wrote:
Maintainers are different in EPEL and rawhide. I try to sync with Ville
before rebuilding in EPEL, but I am not going to keep his pace.
Wasn't likely obvious from my mail, as I didn't go much into that part
of the discussion.
But I agree with this -- the EPEL branch should just sync now and then.
But nevertheless I'd say the version-release should indicate where from
which rawhide spec file the spec in EPEL comes from.
CU
knurd
2:17 p.m.
On Tuesday 03 February 2009, Manuel Wolfshant wrote:
Current bump to 0.85 was mainly
triggered by the release of RHEL 5.3 and integrated a few changes which
were commited by Ville to CVS, were not yet included in any version
built in koji but about which he told me in a private mail that might be
good to include.
No strong opinions here, but in this particular case I would have personally
put it to EPEL as 0.85-3%{?dist}.1. "3" for the reasons outlined by others,
and .1 appended because it's actually a bit ahead of Fedora's 3%{?dist}.
5:32 a.m.
Ville Skyttä wrote:
On Tuesday 03 February 2009, Manuel Wolfshant wrote:
> Current bump to 0.85 was mainly
> triggered by the release of RHEL 5.3 and integrated a few changes which
> were commited by Ville to CVS, were not yet included in any version
> built in koji but about which he told me in a private mail that might be
> good to include.
>
No strong opinions here, but in this particular case I would have personally
put it to EPEL as 0.85-3%{?dist}.1. "3" for the reasons outlined by others,
and .1 appended because it's actually a bit ahead of Fedora's 3%{?dist}.
Thank you all for your advices. I have followed Knurd's/Ville's
suggestions and bumped released to 3.1
manuel
5552
days inactive
5554
days old
epel-devel@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Manuel Wolfshant -
Patrice Dumas -
Thorsten Leemhuis -
Ville Skyttä