Re: More proposed release schedule changes

2020-02-19 Thread Iain Lane
Hey,

Thanks for the mail. I'll reply as one(!) Ubuntu voice.

On Thu, Feb 13, 2020 at 04:45:56PM -0600, Michael Catanzaro wrote:
> Quality issues with our new stable releases are longstanding problems,
> but for 3.34 we had a particularly rough time. I don't have a record
> of how many serious quality issue we had, but it was a lot; it took
> until 3.34.2 to resolve the most serious of the issues. Now of course
> we have more problems here than just the release schedule, but the
> release schedule is a contributing factor.  Thing is, most testing of
> the new GNOME doesn't begin until Fedora branches from rawhide. Well,
> that happened earlier this week, so most testing is only just now
> beginning for the earliest of early adopters. Serious testing really
> heats up around the Fedora beta release. But 3.36.0 is going to be
> released a week *before* F32 beta, so we're releasing before testing
> enters its most important phase!

Also no data to offer, but I feel like when we update in Ubuntu &
Debian, we start getting people finding a reasonable number of issues
and we're not too bad at forwarding and working on those upstream.

Due to everyone on the Ubuntu team having too much to do, in recent
cycles we've not been as early in pushing out the development releases
of GNOME as I'd have liked (we are just starting to release 3.35 to
Focal at the minute - ideally this would have happened some weeks prior
to now). I'd like us to fix that but can't promise any change just yet.

> Now, Ubuntu's schedule isn't posted yet, but I guess October 15 seems
> like the likely final release date for 20.10 (third Thursday of
> October), and my guess is beta freeze will be September 28 (last
> Monday of September). That seems a bit tight, but our final tarball
> deadline for 3.38.0 would be September 19, so it would leave one full
> week to get 3.38.0 in before the 28th. Since we normally have three
> weeks between our .0 and our .1, that means Ubuntu wouldn't be able to
> ship our .1 regardless. The main difference should be an extra two
> weeks of bugfixing for the .0 release that does ship, so I'm thinking
> that should only improve quality. Ubuntu folks, please confirm if this
> should work OK for you.

In recent Ubuntu releases, given the issues you've mentioned in this
mail, we have really appreciated being able to ship the stable .1 GNOME
release. They usually contain fixes for quite egregious bugs and
shipping with .0 would kind of suck. I get that's the point of what
you're trying to address here, so I'm not opposed to this shift if the
.0 releases start to achieve the same quality that we eventually manage
to reach with .1 (or in some cases .2) - i.e. the thing that we ship
should be something we're proud of and confident enough in to give to
stable users whatever the version number.

I think I'd like to hear from maintainers what their perspective on this
issue is before being fully convinced that shifting the cycle to
accommodate Fedora's beta will automatically result in the quality
improvements being sought: any thoughts on why we might have quality
issues with .0 releases or is it really mostly about the schedule?

(are there bigger wins to be had than implementing this change alone?)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


Re: For projects switching to Meson *only*

2017-04-27 Thread Iain Lane
Hiya,

Apologies for any ignorance about the scope and intent of the build API.

On Thu, Apr 27, 2017 at 09:45:04AM +0100, Emmanuele Bassi wrote:
> Hi everyone;
> A simple script is available here[2], and it has nice properties, like
> being able to work with a simple:
> 
>   ./configure
>   make
>   sudo make install
> 
> which makes distributors and integrators happy.
> […]
> [2]: https://github.com/ebassi/graphene/blob/master/configure

As it happens I interacted with this script (in gnome-software)
yesterday. I hadn't got a new enough jhbuild - the one I had was trying
to call ./configure instead of meson directly.

The script AFAICS ignores unknown arguments. In particular, I was
interested in passing some --enable/--disable flags to select features
but I didn't find out how to do that short of explicitly extending it
with those particular options. If you expect distributors to be using
this, or if this is interesting for users of the build API, is having
some support for ./configure <-> meson_options integration a reasonable
request?

Otherwise, and this is what happens now that I upgraded jhbuild, using
meson directly works fine. But if a goal of this is to smooth the
transition path and avoid a requirement for tooling to be updated, maybe
it would be useful.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list