Hi Erich,
On Mon, Mar 30, 2020 at 04:18:07PM -0700, Erich Eickmeyer wrote:
> I have a package (carla) for which I have PPU upload rights for that I
> have been working with the upstream for getting a release today. Despite
> this, the upstream developer could not meet this deadline for their
> release, which is really not their problem as the application isn't
> necessarily developed for Ubuntu specifically (the world doesn't revolve
> around Ubuntu). This is a bugfix release being prepared (carla-2.1-rc2,
> with carla-2.1-rc1 already in the archives) in preparation for a final
> release mid-April prior to Final Freeze.
> Unfortunately, beta freeze came without any discussion as to if the
> flavors were ready for this freeze, and now flavors must rely on a small
> group of developers (the Release Team) to approve any last-minute,
> intended-for-beta uploads. With carla being a release candidate, it is
> perfect for beta testing in preparation of that final release, not only
> for carla, but for Ubuntu.
> Additionally, carla is a seeded package in Ubuntu Studio.
> [Proposal 1]
>
> I believe that the release team needs to check with the flavor leads
> prior to enacting the beta freeze, just to make sure there are no
> last-minute intended-for-beta already-seeded packages preparing for
> upload. A good way would be checking with the flavor leads either in
> #ubuntu-flavors or on #ubuntu-release (which many, if not most, are
> monitoring). I think this is important especially for packages in the
> archive that are in beta or release candidate status that have an
> imminent bugfix or final release from an upstream.
Speaking with my Release Team hat: we do time-based releases, and the dates
are known well in advance. The manual process of the Release Team approving
exceptions to the milestone freeze exists because we know not all seeded
packages, across all flavors, are going to be ready for beta at the start of
the freeze. Nevertheless, a freeze is necessary to impose control over the
set of changes going into the milestone preparation.
In this case, you want the carla package to be included in the beta. But
you probably wouldn't appreciate it if some other Ubuntu developer uploaded
5 other packages for unrelated reasons, that happened to be included on the
Ubuntu Studio images, without talking to the Ubuntu Studio team, and
possibly introducing bugs at the last minute before the beta.
Delaying the freeze would, in aggregate, also mean delaying the beta,
because of the risk that some flavor image or another would be impacted by
such a regression that results in a respin. Consulting flavors about
readiness prior to freezing only serves a purpose if we are willing to give
flavors a veto over the timing of the milestone release itself - which we
are not, as this would adversely impact all other flavors who are otherwise
ready to freeze at the scheduled time.
In the case of carla, this package has now been accepted.
> [Proposal 2]
> I believe the release team does not currently represent every flavor
> equally, and that they do not take into account the needs of all of the
> flavors. Therefore, I believe that the release team needs to also
> consist of a representative of each flavor, whether that be the flavor
> lead or another delegate from the flavor teams. It seems as though all
> flavors are not treated equally, and that some flavors are seen as
> burdens and ignored while other flavors are given more of a voice.
> Including more people for the release team would reduce the burden on
> the existing release team, and remember, it should never be about "control".
The Release Team is always open to involving new members. However, the role
of the Release Team is one of coordinating milestones, managing
proposed-migration, and reviewing freeze exceptions and the contents of the
unapproved queue during the freeze. There is a high skill barrier for being
part of the team due to the technical judgement that is required to be
exercised, and if one's goal is to improve Release Team responsiveness for a
particular flavor, joining the Release Team is an inefficient way to go
about it.
We have a longstanding practice of delegating to representatives of the
flavors the authority to approve feature freeze exceptions for packages
seeded only by those flavors. I see no reason why we wouldn't consider this
for Ubuntu Studio.
> Even if neither of these proposals are accepted, I think we the
> discussion should at least be opened for some sort of solution, and the
> situation should not be disregarded. I'd love to hear some thoughts on
> this. Let's be pragmatic and learn how to trust a little more. :)
> Warmest regards from cold Seattle,
> Erich
>
> ----
> Erich Eickmeyer
> Project Leader
> Ubuntu Studio
> ubuntustudio.org
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
