4:09 a.m.
Hi,
At the risk of fragmenting the upstream discussion: what would be the
consequences for RDO of the proposal to no longer provide stable
point releases?
From our consumer perspective, the RPMs following these stable point
releases have always allowed us to plan our upgrades in a
straightforward way:
- We ignore the initial release :)
- The first point release is the basis for our upgrade campaign,
where we upgrade component-by-component over a period of a
few months.
- The deployment of the subsequent point releases is a (usually)
trivial matter.
I would imagine that other deployers follow similar scenarios.
I think it would be good if RPMs would continue to be produced on
a regular basis, to allow consumers to benefit from the upstream
bug fixes. But I guess we would need to find a balance between
consumer needs and the available packaging effort.
Thoughts?
thanks, cheers, Jan
5:38 a.m.
- We ignore the initial release :)
That's why first RHEL was 2.1 :)
I would imagine that other deployers follow similar scenarios.
Me too, thanks for confirmation for the field.
I think it would be good if RPMs would continue to be produced on
a regular basis, to allow consumers to benefit from the upstream
bug fixes. But I guess we would need to find a balance between
consumer needs and the available packaging effort.
Yes, in upstream discussion I was at first going to propose to keep
strictly time-based point release tags but then I liked upstream
"stands behind" each commit idea. So every stable commit would be
micro-versioned (TBD how and where to provide tarballs) so that RDO
and other distros could take any of them, based on their own schedules
and still have common reference point(s).
I'd propose to do RDO rebases on monthly basis with an option to do
on-demand rebases for CVE or critical issues.
Package updates are always up to the package maintainers so this would
be a recommendation.
If needed, in case of unresponsive maintainers for example,
super-packagers would do the rebases but that should an exception,
package maintainership must be distributed otherwise we failed!
Cheers,
Alan
2:11 p.m.
Hi Alan, all,
> I think it would be good if RPMs would continue to be produced
on
> a regular basis, to allow consumers to benefit from the upstream
> bug fixes. But I guess we would need to find a balance between
> consumer needs and the available packaging effort.
Yes, in upstream discussion I was at first going to propose to keep
strictly time-based point release tags but then I liked upstream
"stands behind" each commit idea.
Yes, I also like that idea.
So every stable commit would be
micro-versioned (TBD how and where to provide tarballs) so that RDO
and other distros could take any of them, based on their own schedules
and still have common reference point(s).
I'd propose to do RDO rebases on monthly basis with an option to do
on-demand rebases for CVE or critical issues.
I'd support that strongly, as this would mean even more bug fix releases
than today. It would be incentive to work more closely
with upstream on getting patches committed and tagged "stable",
which I believe is good for all.
Package updates are always up to the package maintainers so this
would
be a recommendation.
If needed, in case of unresponsive maintainers for example,
super-packagers would do the rebases but that should an exception,
package maintainership must be distributed otherwise we failed!
Agreed.
Do you know when the creation of point releases would stop? Assuming the
proposal is accepted, would this start with Liberty, or would it also
affect Kilo and Juno?
thanks, cheers, Jan
5:58 a.m.
-----Original Message-----
From: rdo-list-bounces(a)redhat.com [mailto:rdo-list-bounces@redhat.com] On
Behalf Of Alan Pevec
Sent: 03 June 2015 12:39
To: Jan Van Eldik
Cc: Rdo-list(a)redhat.com
Subject: Re: [Rdo-list] Consequences for RDO of the proposal "no longer doing
stable point releases"
> - We ignore the initial release :)
That's why first RHEL was 2.1 :)
To be complete, CERN does participate in the RDO test days using the initial releases so I
would not propose to not build anything until month 3. I'd hope to find an CentOS/RHEL
system or specific packaging issues at this stage in particular. Given that the Trunk CI
is Ubuntu based, it is important to catch these sort of problems early since they can lead
to negative user experiences.
I'm fine with the overall approach though.
Tim
> I would imagine that other deployers follow similar scenarios.
Me too, thanks for confirmation for the field.
> I think it would be good if RPMs would continue to be produced on a
> regular basis, to allow consumers to benefit from the upstream bug
> fixes. But I guess we would need to find a balance between consumer
> needs and the available packaging effort.
Yes, in upstream discussion I was at first going to propose to keep strictly time-
based point release tags but then I liked upstream "stands behind" each commit
idea. So every stable commit would be micro-versioned (TBD how and where to
provide tarballs) so that RDO and other distros could take any of them, based on
their own schedules and still have common reference point(s).
I'd propose to do RDO rebases on monthly basis with an option to do on-
demand rebases for CVE or critical issues.
Package updates are always up to the package maintainers so this would be a
recommendation.
If needed, in case of unresponsive maintainers for example, super-packagers
would do the rebases but that should an exception, package maintainership
must be distributed otherwise we failed!
Cheers,
Alan
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
4:49 p.m.
Do you know when the creation of point releases would stop? Assuming
the
proposal is accepted, would this start with Liberty, or would it also affect Kilo and
Juno?
Summit session was for the work during Liberty cycle i.e. it affects
all current stable branches.
But discussion is on-going[1] and spec is still to be written to work
out details.
The only point release currently planned is Icehouse 2014.1.5 which
will be also tagged icehouse-eol and stable/icehouse branches
deleted[2]
Cheers,
Alan
[1] thread [openstack-dev] [all] [stable] No longer doing stable point releases
[2] thread [openstack-dev] Targeting icehouse-eol?
3266
days inactive
3268
days old
4 comments
3 participants
participants (3)
-
Alan Pevec -
Jan van Eldik -
Tim Bell