New Official Flavor Process Issues (Was Re: Ubuntu Cinnamon Remix packages)

Fri Jul 29 15:58:22 UTC 2022

Hi Steve,

On Fri, 2022-07-29 at 06:34 -0700, Steve Langasek wrote:
> Hi Erich,
> 
> [Dropping ubuntu-release from Cc: as this isn't relevant for that
> list]
> 
> On Wed, Jul 27, 2022 at 06:21:56PM -0700,
> eeickmeyer at ubuntu.com wrote:
> > On Sun, 2022-07-24 at 22:54 -0700, Steve Langasek wrote:
> > > - The source package points to github for its seed.  This needs
> > > to be
> > >   hosted on Launchpad, and owned by a team of which ~ubuntu-core-
> > > dev is
> > >   a member.
> 
> > There is no documentation anywhere that I know of in this context
> > for
> > the requirement of the involvement of a member of the ~ubuntu-core-
> > dev
> > team, so now I'm emploring the technical board to get this sorted,
> > preferably on some kind of documentation, but not necessarily on
> > <https://wiki.ubuntu.com/RecognizedFlavors> as I'm not happy with
> > that
> > wiki entry from a community standpoint. More on this later in this
> > email.
> 
> There seems to be a misunderstanding here.  I did not say that
> members of
> ubuntu-core-dev needed to be involved; I said that the team which
> owns the
> seed branches needs to have ubuntu-core-dev as a member.
> 
> See any of https://launchpad.net/~lubuntu-dev/+members,
> https://launchpad.net/~ubuntustudio-dev/+members,
> https://launchpad.net/~xubuntu-dev/+members by way of example.
> 
> This follows directly from the fact that ubuntu-core-dev is entrusted
> with
> the ability to upload all packages in the archive as necessary; and
> unlike
> some packages where a maintaining team might have a package with a
> Vcs-Git
> pointing to a repository that only they can commit to, but that they
> can
> merge changes back from the archive if someone needs to upload the
> package,
> for a flavor metapackage the VCS branch *is* the real source.  A core
> dev
> cannot make (maintainable) changes to these metapackages unless they
> can
> commit to the VCS; so rather than leaving them with the only option
> to fork
> the official seed branches for the flavor under ~ubuntu-core-dev (or
> ~ubuntu-motu) and make it impossible for the /flavor maintainers/ to
> update
> the branch pointed to by the source package, we should simply head
> this off
> up front by making sure ubuntu-core-dev is a member of the team
> owning the
> branches.
> 
> Concretely, the Release Team needs to be able to create new branches
> for
> each flavor when a new series opens.  So the above is not a
> hypothetical.
> 
> This is not documented as a requirement on the wiki page simply
> because when
> that page was being prepared no one thought to include it given that
> this is
> meant to be simply clerical rather than a requirement that the flavor
> team
> needs to overcome with effort in order to be considered by the TB.  I
> have
> no objections to it being documented on the wiki.  Regardless, in
> practice
> this is simply:
> 
>  - create a -dev team for the flavor in launchpad
>  - invite ubuntu-core-dev to the team
>  - push your branches to git under the new -dev team
>  - point your meta package at that git repository

Excellent. I would consider these sub-tasks under a larger task.
However, people shouldn't have to hunt for these steps, and never
assume that people are going to know this. I would definitely consider
this relevant information.

> 
> > Your reply brings up a larger discussion which involves not only
> > the
> > technical board, but also the community council since there are
> > community implications that need to be addressed as the wiki entry
> > you
> > referred to is not at all community friendly.
> 
> What, concretely, is the Community Council asking be changed on this
> wiki
> page?  Does this just concern the above omission, or are you asking
> for
> something else?  I'm not clear what "community friendly" means here.

"Community friendly", in this context, means something that the average
developer, wishing to create a new flavor of Ubuntu, or bring in an
unofficial flavor, and make an official flavor, and read and
immediately understand without having to hunt for information or make
assumptions based on the pre-conceived notion that they "should"
already understand the information that they are reading. In other
words, it should spell-out each and every requirement in order in which
it should be obtained.

Basically, human-readable without prior education.

> > > On Sat, Jul 23, 2022 at 09:26:16AM -0700, Erich Eickmeyer wrote:
> > > > On Sat, 2022-07-23 at 07:46 -0700, Erich Eickmeyer wrote:
> > > > > There is also an ubuntucinnamon-meta package which Joshua has
> > > > > been
> > > > > creating manually, but I suspect this should be uploaded
> > > > > later after
> > > > > a germinate seed has been created.
> 
> > > > I stand corrected, he's using germinate to create the meta. 
> > > > It'll be
> > > > easy to transition to a proper seed once the flavor is
> > > > official.
> 
> > > This needs to happen *before* the flavor is recognized as
> > > official.
> 
> > If there is a step-by-step process that is undocumented, then this
> > brings up a point that I'll address below.
> 
> Again, I'm happy to document this in whatever detail the CC thinks is
> appropriate, but I also don't think this should be surprising to
> anyone
> involved in Ubuntu development.  The Archive Admins don't approve NEW
> packages before they're uploaded; the SRU team doesn't pre-approve
> SRUs but
> reviews them based on what is actually uploaded to the archive (and
> requires
> SRU test cases for the actual binary packages built as part of the
> SRU, not
> just pre-upload testing); likewise, the TB is going to need to assess
> a
> candidate flavor based on what is actually in the archive, not what
> is
> proposed.

This is understandable, but the point is to get from point A (not in
the archive, no seed, no .iso image being built, nothing) to point B
(everything ready for official application).

> 
> You mention that Joshua has been working towards official flavor
> status
> following <https://wiki.ubuntu.com/RecognizedFlavors>, but that page
> has had
> the requirement of Tech Board approval for much longer than 3 years;
> so why
> is the first outreach to the Tech Board only happening after 3 years,
> only
> after a redirect on my part from ubuntu-release, and at a point where
> any
> sort of pushback apparently results in significant frustration?

Joshua posted on Discourse 3 years ago
(https://discourse.ubuntu.com/t/ubuntu-cinnamon-remix-plans/10573) and
was brought into IRC chat which directed him into that (woefully
inadequate) document, therefore this is nothing new. This is where he
got lost and has been the source of his frustration as he didn't want
to go to the TB prior to his first official application as he felt
intimidated as he'd be rejected outright without a chance to reapply
(despite my assurances). So, some of the pushback has been perceived,
yes, but most of it is he just feels lost. And, quite frankly, I'm
having trouble following that document too, which means there are
pieces missing. It needs to be better. This is why I raised it with the
CC as I felt it was a community issue, and I want to be clear here:

*****************************************************************
THIS WAS NOT MEANT TO BE A POINT OF ESCALATION I APOLOGIZE TO THE
TECHNICAL BOARD IF THAT IS HOW IT APPEARS. THIS WAS MEANT TO BE A
COOPERATION BETWEEN "COMMUNITY" AND "TECHNICAL".
*****************************************************************

> 
> > Therefore, on behalf of the Community Council, I charge the
> > technical
> > board to come up with such a document, posted in an easy-to-find
> > location, so that unofficial flavors (two currently on my radar
> > include
> > Ubuntu Cinnamon and Ubuntu Unity) can have a streamlined shot at
> > becoming official flavors if they so desire. Remember, this is
> > about
> > putting the community first, and a growing community is a healthy
> > community, which means allowing and helping new flavors rather than
> > discouraging them.
> 
> The https://wiki.ubuntu.com/RecognizedFlavors page, already linked
> from
> <https://wiki.ubuntu.com/Flavors>, should be this one place.  We
> should not
> have separate documentation for the Tech Board and the flavor
> maintainers. 
> It also appears to clear the bar for being easy-to-find (as much as
> anything
> ever is) since you and Joshua were both already aware of it.
> 
> However, aside from adding more details like the above around seeds,
> and
> clearly documenting that becoming a daily is a prerequisite for
> becoming a
> released flavor, I'm not clear what you are asking for that isn't
> already
> there.  So please, clarify.

To clarify, what we are asking for is a step-by-step document (I guess,
perhaps even added to the existing checklist might be sufficient)
explaining, for anyone that can read it, what it takes for an
unofficial flavor that wishes to become an official flavor to become
one. Robie and I already worked on a preliminary outline yesterday
which would delegate the Release Team to help out with this and appoint
an official liason to become a "guide", if you will, for that potential
flavor:

1) Maintain packages in the archive for a while, ie. become an uploader
for the packages important to your flavor
2) (any other general prerequisites)
3) Have an uploader nominated to drive the process from your end, and
then have them email ubuntu-release at lists.ubuntu.com to request to
being the process to get official flavor status
4) The release team will nominate someone to coordinate with you.
5) That person will look at the situation with you and create a list of
what is outstanding from your end
6) Do those things
7) Done

Obviously, this list isn't complete and requires some major revison,
but it's a start. Like I said earlier, I'm happy to help with this
process, and Jose also mentioned he'd be happy to help.

-- 
Erich Eickmeyer
Member, Ubuntu Community Council
Project Leader, Ubuntu Studio
Ubuntu MOTU