GNOME 3.19.92 megaupdate

[Kalev Lember]

Hi all,

It's GNOME 3.19.92 release this week. As we are deep in the Alpha freeze
in Fedora, this will stay in updates-testing for a while until the
freeze is lifted and floodgates open a again.

We have koji side tag to collect all the builds before submitting them
to Bodhi. If you are helping with builds, please use f24-gnome build target:

$ fedpkg build --target f24-gnome

I'll take care of submitting them all in a single bodhi update ticket
later this week.

Thanks,
Kalev

[Vít Ondruch]

Dne 14.3.2016 v 08:34 Kalev Lember napsal(a):
>  Hi all,
>
>  It's GNOME 3.19.92 release this week. As we are deep in the Alpha freeze
>  in Fedora, this will stay in updates-testing for a while until the
>  freeze is lifted and floodgates open a again.
>
>  We have koji side tag to collect all the builds before submitting them
>  to Bodhi. If you are helping with builds, please use f24-gnome build target:
>
>  $ fedpkg build --target f24-gnome 
Interesting ... you are building F24 package in side tag, where there is
used Bodhi for gating, so it can't make harm, but are you going to use
side tag for Rawhide as well? Looking at gtk3 build, it does not look
like that. So will it be 3rd time in 3 months you are going to broke my
Rawhide?

Vít

>  I'll take care of submitting them all in a single bodhi update ticket
>  later this week.
>
>  Thanks,
>  Kalev
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]

[Richard Hughes]

On 15 March 2016 at 08:04, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  So will it be 3rd time in 3 months you are going to broke my
>  Rawhide? 
I think using the F25 packages when F24 alpha hasn't even been
released is probably asking for trouble. Are we supposed to be
maintaining F22, F23, F24, *and* F25 at this point?

Richard.

[Peter Robinson]

On Tue, Mar 15, 2016 at 8:34 AM, Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>  On 15 March 2016 at 08:04, Vít Ondruch <vondruch(a)redhat.com&gt;
> wrote:
> > So will it be 3rd time in 3 months you are going to broke my
> > Rawhide?
>
>  I think using the F25 packages when F24 alpha hasn't even been
>  released is probably asking for trouble. Are we supposed to be
>  maintaining F22, F23, F24, *and* F25 at this point? 
In a word, yes. There is an expectation that rawhide continues to be
usable for those people that wish to use it for development. It's when
large functional changes need to be made and people need to be able to
develop them on a working OS. Release engineering are happy to, and
regularly do, make side tags for rawhide builds, the GNOME teams have
scripts to build in those tags, like you do for f24, so it would be
little extra effort for you to do that same for f25/rawhide.

Peter

[Richard Hughes]

On 15 March 2016 at 08:53, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  so it would be little extra effort for you to do that same for
> f25/rawhide. 
I'm a bit confused where the problem is, at least my workflow is:

* build latest release for rawhide
* if gnome-3.19.*, cherry-pick to f24
* if we're using bohdi, build for f24-gnome, else build for f24

I'm somewhat confused where the problem is.

Richard

[Tom Hughes]

On 15/03/16 09:03, Richard Hughes wrote:

>  I'm a bit confused where the problem is, at least my workflow
> is:
>
>  * build latest release for rawhide
>  * if gnome-3.19.*, cherry-pick to f24
>  * if we're using bohdi, build for f24-gnome, else build for f24 
That last step is backwards surely?

If bodhi is in use then you can bundle all the builds into one bodhi 
update to ensure that nobody gets a broken tree.

It's when bodhi isn't in use that you might want to use f24-gnome so 
that you can get everything built before merging it and making it 
visible to people.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Richard Hughes]

On 15 March 2016 at 09:06, Tom Hughes <tom(a)compton.nu&gt; wrote:
>  If bodhi is in use then you can bundle all the builds into one bodhi
> update
>  to ensure that nobody gets a broken tree. 
Why would people get a broken tree if there are no soname bumps? If
there is a soname bump mclazy won't touch it with a bargepole and I
leave the maintainer to do all the required rebuilds.

Richard

[Tom Hughes]

On 15/03/16 09:13, Richard Hughes wrote:

>  On 15 March 2016 at 09:06, Tom Hughes <tom(a)compton.nu&gt; wrote:
> > If bodhi is in use then you can bundle all the builds into one bodhi update
> > to ensure that nobody gets a broken tree.
>
>  Why would people get a broken tree if there are no soname bumps? If
>  there is a soname bump mclazy won't touch it with a bargepole and I
>  leave the maintainer to do all the required rebuilds. 
Sorry, I thought that's what this whole discussion was about.

If you're not concerned about people getting a partial update then a 
side tag isn't necessary anyway?

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Vít Ondruch]

Dne 15.3.2016 v 10:13 Richard Hughes napsal(a):
>  On 15 March 2016 at 09:06, Tom Hughes <tom(a)compton.nu&gt; wrote:
> > If bodhi is in use then you can bundle all the builds into one bodhi update
> > to ensure that nobody gets a broken tree.
>  Why would people get a broken tree if there are no soname bumps?  
Because of issues such as:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

IOW some of Gnome developers don't care about sonames, "because it is
just development version".


Vít

[Debarshi Ray]

On Tue, Mar 15, 2016 at 10:20:51AM +0100, V?t Ondruch wrote:
>  IOW some of Gnome developers don't care about sonames,
> "because it is
>  just development version". 
I find your repeated use of phrases like "don't care" to be insulting.

Cheers,
Rishi

[Vít Ondruch]

Dne 15.3.2016 v 16:17 Debarshi Ray napsal(a):
>  On Tue, Mar 15, 2016 at 10:20:51AM +0100, V?t Ondruch wrote:
> > IOW some of Gnome developers don't care about sonames, "because it is
> > just development version".
>  I find your repeated use of phrases like "don't care" to be insulting.
Sorry, I didn't mean to offend you or anybody else and I would
appreciate if you can keep the discussion on technical level.

Thank you.


Vít

[Vít Ondruch]

Dne 15.3.2016 v 10:03 Richard Hughes napsal(a):
>  On 15 March 2016 at 08:53, Peter Robinson
> <pbrobinson(a)gmail.com&gt; wrote:
> > so it would be little extra effort for you to do that same for f25/rawhide.
>  I'm a bit confused where the problem is, at least my workflow is:
>
>  * build latest release for rawhide 
This should be "build latest release for rawhide in f25-gnome side tag".

>  * if gnome-3.19.*, cherry-pick to f24
>  * if we're using bohdi, build for f24-gnome, else build for f24
>
>  I'm somewhat confused where the problem is. 
This is the problem:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

https://lists.fedoraproject.org/archives/list/[e-mail].o...

https://lists.fedoraproject.org/archives/list/[e-mail].o...

IOW you are keep changing API/ABI without proper .so name bumps and at
the same time, you refuse to use side tag (which would limit the impact)
for Rawhide builds.


Vít

[Richard Hughes]

On 15 March 2016 at 09:17, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
> > I'm somewhat confused where the problem is.
>  This is the problem:
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
This isn't anything to do with the gnome-shell version being different
to the other components.

> https://lists.fedoraproject.org/archives/list/[e-mail].o...
That wouldn't have been prevented using a side-tag either. Bugs happen
in development software, holding the push for an extra week wouldn't
have magically fixed that bug.

>  IOW you are keep changing API/ABI without proper .so name bumps and
> at
>  the same time, you refuse to use side tag (which would limit the impact)
>  for Rawhide builds. 
Okay, so the obvious solution is "don't put ABI-unstable development
GNOME packages into rawhide". We'd then be using a xdg-app enhanced
atomic image for all development, and then rawhide would rot.

Richard

[Vít Ondruch]

Dne 15.3.2016 v 10:24 Richard Hughes napsal(a):
>  On 15 March 2016 at 09:17, Vít Ondruch <vondruch(a)redhat.com&gt;
> wrote:
> >> I'm somewhat confused where the problem is.
> > This is the problem:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  This isn't anything to do with the gnome-shell version being different
>  to the other components.
>
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  That wouldn't have been prevented using a side-tag either. Bugs happen
>  in development software, holding the push for an extra week wouldn't
>  have magically fixed that bug.
>
> > IOW you are keep changing API/ABI without proper .so name bumps and at
> > the same time, you refuse to use side tag (which would limit the impact)
> > for Rawhide builds.
>  Okay, so the obvious solution is "don't put ABI-unstable development
>  GNOME packages into rawhide". We'd then be using a xdg-app enhanced
>  atomic image for all development, and then rawhide would rot.
>
>  Richard 
My assumption is, that whatever you put into Rawhide, the components are
compatible, e.g. you release gnome 3.19.91, you tested all the
components together and they work together.

So lets say I am using Gnome 3.19.90. The 3.19.91 is released and you
start build, which takes some time (12h? 24h? 2 days? Have no idea). In
the middle of the build, the compose is done and it is pushed to the
repositories. Now I do update of my computer and I get half of the
packages of 3.19.91 but the second half is still at 3.19.90. They were
never tested together and never expected to work together. There is
probably hidden some ABI breakage. While the build continues and there
are eventually build all 3.19.91 packages and everything will get into
order, there is certainly substantial time during Gnome update when
Rawhide is possibly broken (unfortunately this happened during every
Gnome update in recent months).

To minimize impact of the possible ABI incompatibilities, I can see
several solutions:

1) Minimalist solution is to announce that you are building new version
of Gnome and breakage can be expected. I would happily wait for the
announcement of rebuild done to be sure that I get the whole Gnome
update at once.
2) Use side tag for Rawhide builds
3) Specify more precisely the dependencies between Gnome project, e.g.
gnome-terminal-3.19.91-1.fc25.x86_64 has to work only with
vte291-0.43.91-1.fc25.x86_64 and nothing else, because this is how they
were tested

I hope you can make your choice, where the (2) is my favorite of course.



Vít

[Richard Hughes]

On 15 March 2016 at 10:00, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  So lets say I am using Gnome 3.19.90. The 3.19.91 is released and
> you
>  start build, which takes some time (12h? 24h? 2 days? Have no idea). 
Building all the components in mclazy takes a couple of hours. The
issue is that not all GNOME modules release on the same day,
especially when we're early in the development cycle.

>  1) Minimalist solution is to announce that you are building new
> version
>  of Gnome and breakage can be expected. I would happily wait for the
>  announcement of rebuild done to be sure that I get the whole Gnome
>  update at once. 
We'd never know when we're waiting for new tarballs, projects don't
actually have to release a tarball on release day. Some are always
late, some never come at all... Delaying the automated building by a
week would be one solution, but late in the dev cycle where .91 -> .92
is two weeks this doesn't work so well.

>  2) Use side tag for Rawhide builds 
I think that would be even more confusing for projects that are not
quite core GNOME, e.g. NetworkManager needing a new glib. We'd have to
get any project depending on the core GNOME stuff to also build in the
side tag for the duration of the delayed push, which we don't even
know how long would be for. If you want to manage this that's fine,
but for me I'd just stop building for rawhide as it's just too much
hassle. It's already a chore, and with the advent of xdg-app and the
coming push of the atomic image, rawhide isn't something GNOME
developers actually need. I'm not trying to be facetious, I'm just
saying that you can't solve a social problem with guidelines, and if
you make something that's already a chore a logistical and technical
nightmare (with people that shout at you when you get it wrong) then
nobody is going to bother.

>  3) Specify more precisely the dependencies between Gnome project,
> e.g.
>  gnome-terminal-3.19.91-1.fc25.x86_64 has to work only with
>  vte291-0.43.91-1.fc25.x86_64 and nothing else, because this is how they
>  were tested 
I'd hope upstream projects update the deps on things like
gsettings-desktop-schemas when new versions are required. It's
certainly what I do.

Richard.

[Vít Ondruch]

So do you see any solution/improvement for this issue? I repeatedly
reported the breakages, I made some proposals (as simple as "send an
email"), which IMO should improve the situation, but it seems that you
prefer to keep status quo.


Vít



Dne 15.3.2016 v 11:18 Richard Hughes napsal(a):
>  On 15 March 2016 at 10:00, Vít Ondruch <vondruch(a)redhat.com&gt;
> wrote:
> > So lets say I am using Gnome 3.19.90. The 3.19.91 is released and you
> > start build, which takes some time (12h? 24h? 2 days? Have no idea).
>  Building all the components in mclazy takes a couple of hours. The
>  issue is that not all GNOME modules release on the same day,
>  especially when we're early in the development cycle.
>
> > 1) Minimalist solution is to announce that you are building new version
> > of Gnome and breakage can be expected. I would happily wait for the
> > announcement of rebuild done to be sure that I get the whole Gnome
> > update at once.
>  We'd never know when we're waiting for new tarballs, projects don't
>  actually have to release a tarball on release day. Some are always
>  late, some never come at all... Delaying the automated building by a
>  week would be one solution, but late in the dev cycle where .91 -> .92
>  is two weeks this doesn't work so well.
>
> > 2) Use side tag for Rawhide builds
>  I think that would be even more confusing for projects that are not
>  quite core GNOME, e.g. NetworkManager needing a new glib. We'd have to
>  get any project depending on the core GNOME stuff to also build in the
>  side tag for the duration of the delayed push, which we don't even
>  know how long would be for. If you want to manage this that's fine,
>  but for me I'd just stop building for rawhide as it's just too much
>  hassle. It's already a chore, and with the advent of xdg-app and the
>  coming push of the atomic image, rawhide isn't something GNOME
>  developers actually need. I'm not trying to be facetious, I'm just
>  saying that you can't solve a social problem with guidelines, and if
>  you make something that's already a chore a logistical and technical
>  nightmare (with people that shout at you when you get it wrong) then
>  nobody is going to bother.
>
> > 3) Specify more precisely the dependencies between Gnome project, e.g.
> > gnome-terminal-3.19.91-1.fc25.x86_64 has to work only with
> > vte291-0.43.91-1.fc25.x86_64 and nothing else, because this is how they
> > were tested
>  I'd hope upstream projects update the deps on things like
>  gsettings-desktop-schemas when new versions are required. It's
>  certainly what I do.
>
>  Richard.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]

[Matthias Clasen]

On Tue, 2016-03-15 at 13:06 +0100, Vít Ondruch wrote:
>  So do you see any solution/improvement for this issue? I repeatedly
>  reported the breakages, I made some proposals (as simple as "send an
>  email"), which IMO should improve the situation, but it seems that
>  you
>  prefer to keep status quo. 
A solution would be to have rawhide gated by some form of minimal auto-
qa that keeps such breakage out of composes.

Asking the people who already do a _ton of work+ to get all these
builds done in multiple streams to do even more work, and asking in an
accusatory tone, is probably not going to lead to a solution.

[Peter Robinson]

On Tue, Mar 15, 2016 at 4:46 PM, Matthias Clasen <mclasen(a)redhat.com&gt; wrote:
>  On Tue, 2016-03-15 at 13:06 +0100, Vít Ondruch wrote:
> > So do you see any solution/improvement for this issue? I repeatedly
> > reported the breakages, I made some proposals (as simple as "send an
> > email"), which IMO should improve the situation, but it seems that
> > you
> > prefer to keep status quo.
>
>  A solution would be to have rawhide gated by some form of minimal auto-
>  qa that keeps such breakage out of composes. 
That is already being worked upon.

>  Asking the people who already do a _ton of work+ to get all these
>  builds done in multiple streams to do even more work, and asking in an 
I don't see this as any more work that what goes into the f24-gnome
branch building, and as the pushing of builds is scripted through
mclazy is it actually much more work, given mclazy must already
support building in this manner, to ensure that it's usable for
everyone that is using it?

[Jared K. Smith]

On Tue, Mar 15, 2016 at 6:18 AM, Richard Hughes <hughsient(a)gmail.com&gt; wrote:

>  I think that would be even more confusing for projects that are not
>  quite core GNOME, e.g. NetworkManager needing a new glib. We'd have to
>  get any project depending on the core GNOME stuff to also build in the
>  side tag for the duration of the delayed push, which we don't even
>  know how long would be for. If you want to manage this that's fine,
>  but for me I'd just stop building for rawhide as it's just too much
>  hassle.
>  

I'm confused by your reluctance to use a side-tag here -- it's really not a
hassle at all to use, and it would really help those of us who regularly
use Rawhide.  Would you be willing to at least try it for a couple of
iterations and see how it goes?

--
Jared Smith

[Richard Hughes]

On 15 March 2016 at 15:09, Jared K. Smith <jsmith(a)fedoraproject.org&gt; wrote:
>   Would you be willing to at least try it for a couple of iterations
>  and see how it goes? 
Three questions:

* Which packages should use this side tag?
* When *exactly* would we do the push from the side-tag to rawhide?
* Who would test rawhide+side-tag?

Richard

[Peter Robinson]

On Tue, Mar 15, 2016 at 3:29 PM, Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>  On 15 March 2016 at 15:09, Jared K. Smith
> <jsmith(a)fedoraproject.org&gt; wrote:
> >  Would you be willing to at least try it for a couple of iterations
> > and see how it goes?
>
>  Three questions:
>
>  * Which packages should use this side tag?
>  * When *exactly* would we do the push from the side-tag to rawhide? 
The same packaging and process as is being used for the 3.19.92 mega
update in the f24-gnome side tag.

>  * Who would test rawhide+side-tag? 
From my PoV it would be more
about ensuring everything that needs to
be rebuilt due to an API/ABI bump is done so in that side tag, just
like the aforementioned f24-gnome tag, so that when it lands in
rawhide it's a clean upgrade for users. That to me would be a great
start.

Peter

[Richard Hughes]

On 15 March 2016 at 16:59, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  The same packaging and process as is being used for the 3.19.92 mega
>  update in the f24-gnome side tag. 
We only use side tags for the later updates (.90, .91, .92, and .0)
which are supposed to be API stable.

Richard

[Michael Catanzaro]

Using a side tag seems like a great idea. When folks are brave enough
to test rawhide for us, we should try to avoid breaking their
computers. :)

A few arbitrary answers:

On Tue, 2016-03-15 at 15:29 +0000, Richard Hughes wrote:
>  * Which packages should use this side tag? 
Let's start by including all the packages currently tracked by mclazy.

>  * When *exactly* would we do the push from the side-tag to rawhide?
How about sometime on Thursday during the week of a GNOME release.

>  * Who would test rawhide+side-tag? 
I think nobody needs to test it tbh. The packages will get testing once
they're merged into rawhide.

Michael

[Vít Ondruch]

Thas a great plan Michael. Thank you.


Vít



Dne 15.3.2016 v 18:47 Michael Catanzaro napsal(a):
>  Using a side tag seems like a great idea. When folks are brave
> enough
>  to test rawhide for us, we should try to avoid breaking their
>  computers. :)
>
>  A few arbitrary answers:
>
>  On Tue, 2016-03-15 at 15:29 +0000, Richard Hughes wrote:
> > * Which packages should use this side tag?
>  Let's start by including all the packages currently tracked by mclazy.
>
> > * When *exactly* would we do the push from the side-tag to rawhide?
>  How about sometime on Thursday during the week of a GNOME release.
>
> > * Who would test rawhide+side-tag?
>  I think nobody needs to test it tbh. The packages will get testing once
>  they're merged into rawhide.
>
>  Michael
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]

[Peter Robinson]

On Tue, Mar 15, 2016 at 9:24 AM, Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>  On 15 March 2016 at 09:17, Vít Ondruch <vondruch(a)redhat.com&gt;
> wrote:
> >> I'm somewhat confused where the problem is.
> > This is the problem:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  This isn't anything to do with the gnome-shell version being different
>  to the other components.
>
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  That wouldn't have been prevented using a side-tag either. Bugs happen
>  in development software, holding the push for an extra week wouldn't
>  have magically fixed that bug. 
It does in the case where things need to be rebuilt to fix the problem
because you can rebuild everything in a side tag and tag them in all
at once in a single transaction ensuring when the daily update goes
out either everything or nothing is there.

In the case of bugs in software development I thought that most of
them should be picked up as part of gnome-continous, sure bugs happen
but CI helps stop them from getting to end users.

> > IOW you are keep changing API/ABI without proper .so name bumps
> and at
> > the same time, you refuse to use side tag (which would limit the impact)
> > for Rawhide builds.
>
>  Okay, so the obvious solution is "don't put ABI-unstable development
>  GNOME packages into rawhide". We'd then be using a xdg-app enhanced
>  atomic image for all development, and then rawhide would rot. 
I think you're going a bit far here. I think what Vit is trying to say
is that rawhide isn't just meant to be a dumping ground and that while
there will be breakage it would be nice if things were co-ordinated as
much as possible to minimise that. Doing mass bumps in a rawhide side
tag would help with that.

Peter