[rhelv6-list] Update (Point) Releases and Pre-announcements -- WAS: 6.4 anyone?

Thu Feb 21 17:03:59 UTC 2013

[ My last post on the matter.  100% of my comments are 100% based on
long-standing experience, including with integrators and partners,
with Red Hat distribution and release since Red Hat Linux 4.2 ('90s),
as well as every Advanced Server / Enterprise product release.  I make
them as a peer professional and no other assumptions should be made. ]

On Thu, Feb 21, 2013 at 11:27 AM, Red Hat Enterprise Linux 6
(Santiago) discussion mailing-list <rhelv6-list at redhat.com> wrote:
> I fully agree with not rushing a release to meet a deadline set a weeks
> ahead of time. However unless there are any serious security releases in the
> point release, which should likely not be put off until the rest of the
> point release packages are ready anyways,

Understand there are a many considerations in an Update (Point)
Release.  These include (my apologies if you are already quite
familiar):
- RHEA (Enhancements):  Rarely ever released as mid-Update errata,
usually saved for an Update (especially if anything is going to be
rebased)
- RHBA (Bugfixes):  More sparingly released as mid-Update errata
- RHSA (Security):  Regularly released as mid-Update errata

As you noted, most RHSA are released as required, as mid-Update
errata, and are not held-up.  But understand some Bugfix and most
Enhancements must be not just unit and integration tested, but
regression, integrator and other partner tested.  That's a lot of
moving parts, and with entities other than just Red Hat involved,
there are always a lot of considerations.

With that said, _if_ you would like to have an official response from
Red Hat, consider filing a GSS Case.  That way you could get an
explanation or response from Engineering or Product Management.  This
list is _hardly_ the place to make such requests.  Alternatively,
contact your individual Red Hat representative(s).

> could you not give a buffer of a day or two between when the point release is announced
> (because it is ready to go) and when it is released?

And what happens if there is an issue in distribution outside of Red
Hat's control?

Again, as someone who has done a _lot_ of deployment, management and
update of _all_ sorts of platforms (I get dragged into a lot of
Solaris and Windows too), I'd rather have a discrete, atomic and fully
available changeset when something is announced.  In fact, wouldn't it
be a real issue if you set all of your updates for a specific time and
then some distribution snafu hit that prevented it from being such?

Red Hat has never, ever, officially pre-announced products as policy
(there are exceptions, such as a Summit and other, strategic
announcements), and it makes total sense to me why Red Hat does not.

> That way administrators could plan their maintenance schedules with a little more
> notice.

Your individual Red Hat representatives is who you should be asking
this of, not publicly in a Red Hat list (which will never get an
answer).  Many sales, solutions architects, consultants, TAMs and
other individuals in Red Hat want to be ensure your continued
deployment and integration success.  So they will help you plan and
coordinate, although remember that no date is ever set-in-stone, and
don't throw them under-the-bus if they give you a "target timeframe"
and it falls outside of it.

> I must admit that I have not had alot of experience with the beta releases,
> as I have limited time and money for test servers, so I have not paid alot
> of attention to when they are released, so it is my fault that releases
> sneak up on me without notice.

Red Hat extremely values those customers that take the time, effort
and expense to coordinate with Beta releases and their testing.  To
this end, Red Hat tries to meet and exceed the expectations of
customers who do take the time to do so, including providing resources
that are directly available.  Again, please contact your individual
Red Hat representatives to find out what those options and resources
might be for your organization.

> This is not a serious issue to me or I would look into the other entitlements mentioned,

Remember, every software distribution and release entity has its own
method -- and definitely tools -- for addressing asynchronous,
Internet-based distribution.  E.g., RHN Satellite Server would not
exist if customers didn't ask for it.  Same goes for the Extended
Update Support (EUS) entitlement.  Red Hat(R) has always been
customer-driven, with the utmost consideration for community as well
(beyond just Fedora(TM) and others).  There are several Entitlement
solutions, Enterprise tools, as well as even "free beer" community
tools, and use of at least one solution is highly recommended.

> however I do find the release procedure a little clunky and since someone brought
> up the topic I thought I would just express some options. I hope I have not wasted
> too much of everyone's time.

It's never a matter of "time waste," but more of a matter of different
people asking the same questions over time, and they are answered or
at least mitigated, only for more people to come along and make the
same set of requests or related questions.  As professionals, we must
ensure we mitigate risks to our organizations or customer
organizations, and everything I've seen from Red Hat over the last
eighteen (18) years suggest they have tried to mitigate issues in
their release model.

For me, almost entirely working in the western hemisphere (although
with some notable development/integration successes worldwide in my
time), the release model is easy to schedule.  But when I've had _any_
concern, or needed a "timeframe" for internal or customer
considerations, I've found my individual Red Hat representatives
invaluable in assisting.  Just don't go to making their timeframe
suggestions into specific, hard dates (which too many customers always
do).

-- bjs