XFree86 @devel vs @updates

[ByteEnable]

On Fri, 2004-02-13 at 22:29, Mike A. Harris wrote:
> On Fri, 13 Feb 2004, Luciano Miguel Ferreira Rocha wrote:
> 
> >Date: Fri, 13 Feb 2004 22:07:46 +0000
> >From: Luciano Miguel Ferreira Rocha <strange at nsk.no-ip.org>
> >To: fedora-devel-list at redhat.com
> >Content-Type: text/plain; charset=us-ascii
> >List-Id: Development discussions related to Fedora Core
> >    <fedora-devel-list.redhat.com>
> >Subject: XFree86 @devel vs @updates
> >
> >
> >Hello,
> >
> >I've been tracking fedora-devel for some weeks, but I also track FC1 updates &
> >updates-testing.
> >
> >Today I updated my fedora-devel mirror and I see XFree86-4.3.0-45.0.2
> >packages, but on FC1 updates-testing there are XFree86-4.3.0-50, that rpm
> >and yum consider above the development version.
> >
> >So which should I use? Which one is the more up to date?
> 
> The XFree86 4.3.0 src.rpm is 100% shared between:
> 
> - Red Hat Linux 9 
> - Red Hat Enterprise Linux 3 
> - Fedora Core 1 
> - Fedora development 
> - Red Hat Linux 8.0 (It can be built 'unofficially' for RHL 8.0
>   with the addition of some RHL 9 packages to the system.)
> 
> Packages built for RHL 8.0, I set the release tag to "1.80.n", 
> packages for RHL 9, the release tag is set to "1.90.n", and 
> packages for RHEL, the release tag is set to "n.EL", where Fedora 
> Core 1 erratum, as well as Fedora development, I set the release 
> simply to "n".
> 
> So, for release '55', which is the absolute latest one, which was 
> just released as erratum across the board, the release number for 
> each product is:
> 
> RHL8.0	- 1.80.55 (my personal unofficial builds [1])
> RHL9	- 2.90.55
> RHEL3	- 55.EL
> FC1	- 55
> devel	- whatever random number of the day/week/month I decide 
>           to use in order to confuse people.  It might even go 
>           backwards, or use irrational numbers.
> 
> 
> The value of 'n' is what determines which is the 'latest' for the 
> given release.  The binary packages for each of the above OS 
> releases are not all build 100% identically.  Inside the spec 
> file, there are 5 rpm macros to determine what OS release the 
> package should be configured to build for.  Depending on which of 
> the 5 macros is set to "1", the build is reconfigured to build 
> especially for that particular OS release.
> 
> The macros are:
> 
> %if ! %{build_autodetect_mode}
> # Set *one* of the following build targets to 1 as appropriate
> # Fedora Core development builds a.k.a. "rawhide"
> %define build_rawhide           0
> # Fedora Core 1
> %define build_yarrow            1
> # Red Hat Enterprise Linux version 3 (AS/WS/ES/PW)
> %define build_taroon            0
> # Red Hat Linux 9 (Shrike)
> %define build_shrike            0
> # Red Hat Linux 8.0 (Psyche)
> %define build_psyche            0
> 
> 
> >From the above, my current spec file is configured to build 
> Fedora Core 1 (Yarrow) packages.
> 
> The next question which might be on people's minds is "What are
> the differences between each of the above build targets Mike?"
> 
> Each OS release, new enhancements are made, some of which are 
> experimental and need some time in rawhide testing, etc. before I 
> can deem them worthy of being included in future erratum for 
> older OS releases.  I wrap those changes in %if %{build_rawhide} 
> checks in the spec file.  Over time, I may consider such a change 
> stable enough to be considered ok for some or all of the other 
> releases, and will change the conditionalizaton appropriately.
> 
> Other changes and improvements made, sometimes require features 
> only present in a particular OS release or releases, and so I 
> have to conditionalize the inclusion of those features to just 
> the releases it will work on.  An example of this is our libGL 
> optimization patch:
> 
> # Only apply this to Cambridge and Taroon builds
> %define with_libGL_opt_patch    %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' -o '%{build_taroon}' -eq '1' ] && echo 1 || echo 0)
> 
> The above support wont work on older OS releases due to requiring 
> new gcc and/or glibc and/or kernel support for example.
> 
> 
> # Only apply to Cambridge until well tested, then apply to Taroon also.
> %define with_libGL_exec_shield_fixes    %([ '%{build_yarrow}' -eq '1' -o '%{build_rawhide}' -eq '1' ] && echo 1 || echo 0)
> 
> This is an example of testing out exec-shield on Fedora Core
> guinea pigs.  ;o)  The intent here being to test this
> functionality well before applying the patches to other OS
> releases.  The recent XFree86 security exploits which we just
> released erratum for, were just tested with exec-shield enabled
> and the X server was found not vulnerable to the exploit while
> exec-shield was enabled.  So those running Fedora Core 1 or 
> rawhide, who have exec-shield enabled, don't need to bother 
> updating to fix the security issue that was just released.  I'll 
> probably enable the above check on other OS releases once 
> confirming we have exec-shield support on them.  ;o)
> 
> Anyhow...  It's Friday and I was a bit bored.  Having read 
> through the subject lines of fedora-devel-list I found myself 
> craving some actual development related content, kindof like a 
> chocolate bar, and so I figured I'd post the above tidbits in 
> case someone found them useful/informative, etc.
> 
> Perhaps I can even sucker some people into testing rawhide 
> XFree86 out on previous OS releases now, and get even more test 
> coverage.  ;o)
> 
> Anyhow, hope this is useful to someone... time to go read now..
> 
> TTYL
> 
> -- 
> Mike A. Harris     ftp://people.redhat.com/mharris
> OS Systems Engineer - XFree86 maintainer - Red Hat
> 

You sound like you make releases on a whim and whenever you get around
to it.  There is no sign off or test plan that you follow?  I surely
hope that you are jesting.

Byte