Re: Re-evaluating Ubuntu's Milestones

[Dustin Krysak]

I follow suit with Steve here with regards to the automated testing (the
referenced gate). If there are toolsets that already exist - even better!
And from the sounds of it, the process has already been vetted.

Dustin

On Mon, Apr 9, 2018, 16:13 Steve Langasek, 
wrote:

> On Mon, Apr 09, 2018 at 02:31:31PM -0500, Simon Quigley wrote:
> > On 2018-04-09 03:30, Oliver Grawert wrote:
> > > well, apart from actual installer fixes, your users should get all
> > > these fixes through package updates anyway ...
>
> > Right, which is another point for getting rid of these extra milestones,
> in
> > my opinion.
>
> > > One thing that the other pro/con responses did not cover yet but that
> > > should not be underestimated is the promotional aspect of milestones
> > > ...
>
> > > You typically get press coverage for such pre-releases and will likely
> > > attract more testers.
>
> > Not really, actually. In my experience, testers are present when there
> is an
> > occasion to test them, regardless of putting a name to it or releasing an
> > ISO. I could see your point if my proposal was to get rid of the
> milestones
> > entirely with no replacements, but in this case, having the testing week
> > once a month would attract press coverage as well.
>
> > Why? Because milestones in all reality are just a fancy name to slap on
> an
> > ISO that will most likely be stale the next day. You then get people
> > installing from these ISOs and potentially even reporting old bugs. The
> > unfortunate reality of this press coverage is that you could pick an ISO
> any
> > day of the month and call it "beta," and just because it has that name
> on it
> > means that people will install it because of the appeal of the name.
> Despite
> > the positive press that comes from the associated announcements (that can
> > always be made regardless, which is what Lubuntu has started doing[1]),
> in a
> > technical sense, I would even consider it *bad* for people to install
> using
> > these ISOs.
>
> > The coordinated testing weeks would allow for there still to be positive
> > press coverage (and maybe announcements resulting from cross-team
> > collaboration during these times) while not having the downsides of a
> > blessed image when the archive isn't in a decently stable state.
>
> I agree (as you know).
>
> The one other value milestone images provide is to give a "known good"
> image
> to install the development release from.  We have solved this for Ubuntu
> Desktop and Server by having automated tests that gate the promotion of an
> image build to "current".  I would strongly encourage flavors to
> collaborate
> around this automation, instead of continuing to rely on a heavy-weight
> manual test process that leaves the "known good" image stale for weeks at a
> time.
>
> Code for this automation lives here:
>
>
> https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/desktop
>
> If there is interest from flavors in having this image gate, I would be
> willing to argue for Canonical hosting of the test infrastructure, as
> necessary.
>
> And if there *isn't* interest from flavors in doing this, well, I also
> don't
> think that should block on that as a reason to carry on with the existing
> milestone process, which I think is a very inefficient use of everyone's
> time.
>
> So to summarize, I think the right path forward is:
>
>  - discontinue all opt-in milestones for 18.10 and beyond
>- implicitly discontinuing the matching milestone freezes
>  - coordinate a cadence of "testing weeks", organized by the flavor leads
>(i.e.: requires no involvement from ubuntu-cdimage or ubuntu-release in
>order to drive to success)
>  - at the flavor teams' discretion, implement automated QA gating of daily
>image promotions
>
> --
> 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 Developerhttp://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> --
> Ubuntu-release mailing list
> Ubuntu-release@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
>
-- 
Dustin Krysak
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Tracking removals of reverse-dependencies from devel-proposed

[Steve Langasek]

Matthias and I had a conversation on IRC today about how to handle packages
that are stuck indefinitely in devel-proposed until some dependent package
is fixed.  Up to now we have largely been leaving them in -proposed; this
now makes them one of the largest groupings of unreleasable packages in
-proposed, including most of the packages that have been waiting longest.

Leaving non-actionable packages in devel-proposed for long periods of time
(these packages are non-actionable because they are not broken but depend on
some other package that is) makes developers less productive when trying to
identify packages in update_excuses to work on.  But because these packages
are themselves also not buggy, removing them means they disappear from
Ubuntu and don't come back when the underlying issue is fixed.

To square this circle, Matthias and I agreed that if such packages are
removed, we should document them somewhere so that we can (periodically,
perhaps semi-automatically) review that list and re-add packages as
appropriate.

This list now lives in the sync-blacklist branch:

  
https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/extra-removals.txt

Archive admins should feel free to make use of it.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release