Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On Tue, Sep 20, 2011 at 03:19:17PM +0200, Ralf Corsepius wrote:

> When you have a closer look, you'll notice that such "mass rebuilts"
> were being delayed by QA's "delay queue" and now are stuck.

Yeah. I rebuilt maatkit on the 1st of September and it still hasn't made
it to the -stable repository. It's a mix of "it needs to stay in
-testing for a week" and "no update pushes during Alpha/Beta
preparation".

Didn't we have the time an update had to stay in -testing changed to
three days during the F15 stabilization phase? Could we implement this
again for F16 to mitigate the issue?

--
sven === jabber/xmpp: sven@lankes.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On Tue, Sep 20, 2011 at 15:01:06 +0200,
Nils Philippsen <nils@redhat.com> wrote:
>
> I'd like to see a discussion about how we can ensure -- within
> reasonable limits -- that e.g. bumping a library's SONAME is followed by
> dependent components being rebuilt and included with the providing
> component in one update.

This should be easier to do now with the (relatively) new way to set up
build overrides.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On 9/20/11 9:19 AM, Ralf Corsepius wrote:

>> Currently
>> I only see mails of maintainers who plan updating the library, but the
>> rest of it pretty much depends on the maintainers of the depending
>> components rebuilding them quickly enough, and the original maintainer
>> to include them in the F-16 branched update.
>>
>> I'd like to see a discussion about how we can ensure -- within
>> reasonable limits -- that e.g. bumping a library's SONAME is followed by
>> dependent components being rebuilt and included with the providing
>> component in one update.
>
> I'd like to see a discussion on the proceedures currently being applied
> by QA, esp. "during freezes". IMO, they are unsuitable and harmful.

I'd like to see a rationale for jamming a soname-changing update into
the OS so close to a release. In the absence of a very good motivation,
that's not good engineering practice, and it's not consistent with the
feature process.

Perhaps you're not clear on what the word "freeze" means.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

2011/9/20 Nils Philippsen <nils@redhat.com>:
> On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
>> What's wrong with all that broken deps? Is this just a missing rebuild
>> against opencv and other libs or what's the reason for all this
>> "mess". I mean the release of F16 is not that far away and the amount
>> of broken deps is quite big imho.
>> I would be glad helping out if this is due to some orphaned packages.
>
> Some of these seem to be a case of "new library version was built and
> pushed as an update without the rebuilds of dependent components". It
> seems to be unclear who is responsible for the dependents to be rebuilt
> and included in the same update as the library being updated. Currently
> I only see mails of maintainers who plan updating the library, but the
> rest of it pretty much depends on the maintainers of the depending
> components rebuilding them quickly enough, and the original maintainer
> to include them in the F-16 branched update.
I'm the maintainer of opencv here.

quick answear: I have no right to submit a bodhi update for packages I
do not own. Given that I'm no in the provenpackager group.
So as I cannot expect every single maintainers to respond in time, the
consequence is that I depend on a provenpackager to do the whole task
of "administrative rebuilt of dependent packages".
Unfortunately it became a way more complicated task with the collapse
of two bodhi tickets and others unexpected behaviour.

Nicolas (kwizart)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On 09/20/2011 03:47 PM, Bruno Wolff III wrote:
> On Tue, Sep 20, 2011 at 15:01:06 +0200,
> Nils Philippsen<nils@redhat.com> wrote:
>>
>> I'd like to see a discussion about how we can ensure -- within
>> reasonable limits -- that e.g. bumping a library's SONAME is followed by
>> dependent components being rebuilt and included with the providing
>> component in one update.
>
> This should be easier to do now with the (relatively) new way to set up
> build overrides.

These are hardly applicable, if several maintainers are involved or if
non-trivial technical difficulties arise.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On 09/20/2011 04:03 PM, Adam Jackson wrote:
> On 9/20/11 9:19 AM, Ralf Corsepius wrote:
>
>>> Currently
>>> I only see mails of maintainers who plan updating the library, but the
>>> rest of it pretty much depends on the maintainers of the depending
>>> components rebuilding them quickly enough, and the original maintainer
>>> to include them in the F-16 branched update.
>>>
>>> I'd like to see a discussion about how we can ensure -- within
>>> reasonable limits -- that e.g. bumping a library's SONAME is followed by
>>> dependent components being rebuilt and included with the providing
>>> component in one update.
>>
>> I'd like to see a discussion on the proceedures currently being applied
>> by QA, esp. "during freezes". IMO, they are unsuitable and harmful.
>
> I'd like to see a rationale for jamming a soname-changing update into
> the OS so close to a release.
Maintainers on vacation, non-trivial changes?

In my case, a major change was introduced into rawhide many weeks ago,
which had caused breakage in rawhide. One maintainer being involved was
in vacation, another one was non-responsive.

Ca. 4 weeks later the issues were resolved in rawhide and we started to
propagate these changes to f16 and where caught by the delay queues.

> In the absence of a very good motivation,
> that's not good engineering practice, and it's not consistent with the
> feature process.
>
> Perhaps you're not clear on what the word "freeze" means.

Perhaps you're not clear on what the word defective procedures means?

This socalled QA now is testing non-installable rsp. obsolete packages.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On Tue, Sep 20, 2011 at 04:13:27PM +0200, Ralf Corsepius wrote:
> On 09/20/2011 04:03 PM, Adam Jackson wrote:
> > I'd like to see a rationale for jamming a soname-changing update into
> > the OS so close to a release.
> Maintainers on vacation, non-trivial changes?
>
> In my case, a major change was introduced into rawhide many weeks ago,
> which had caused breakage in rawhide. One maintainer being involved was
> in vacation, another one was non-responsive.
>
> Ca. 4 weeks later the issues were resolved in rawhide and we started to
> propagate these changes to f16 and where caught by the delay queues.

We're in the freeze for beta. It's not reasonable to push new sonames
into the distribution at this point.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On Tue, 2011-09-20 at 10:03 -0400, Adam Jackson wrote:

> I'd like to see a rationale for jamming a soname-changing update into
> the OS so close to a release. In the absence of a very good motivation,
> that's not good engineering practice, and it's not consistent with the
> feature process.
>
> Perhaps you're not clear on what the word "freeze" means.

It may be worth pointing out that our release cycle has undergone
significant changes with the early branching that we've introduced in
F15.

We align our releases closes to things like the GNOME release. That used
to be fine in the old days, but now we have added early branching and
made it considerably harder to push large sets of updates post-alpha,
which makes it quite onerous to get e.g. GNOME updates into a branched
Fedora release.

We've set our freezes as if we expect all major development to be done
at that point, but we've aligned our schedules in a way that guarantees
that (at least for GNOME) major development is still happening at the
time of branching.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On 9/20/11 10:13 AM, Ralf Corsepius wrote:
> On 09/20/2011 04:03 PM, Adam Jackson wrote:
>> I'd like to see a rationale for jamming a soname-changing update into
>> the OS so close to a release.
> Maintainers on vacation, non-trivial changes?
>
> In my case, a major change was introduced into rawhide many weeks ago,
> which had caused breakage in rawhide. One maintainer being involved was
> in vacation, another one was non-responsive.

That sounds like the kind of upheaval I'd want to keep out of a release
that's in its stabilization phase.

> Ca. 4 weeks later the issues were resolved in rawhide and we started to
> propagate these changes to f16 and where caught by the delay queues.

Of course, you had the option of not pulling the new OpenSceneGraph back
to F16, or simply not doing so yet. Particularly during a phase where
people are trying to keep change to a minimum so we know what we're
working with.

I'm sorry that you don't understand release engineering, but since you
insist on not understanding it I don't really have any sympathy for your
packages being so visibly at fault for breakages.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
 

On 09/20/2011 04:16 PM, Matthew Garrett wrote:
> On Tue, Sep 20, 2011 at 04:13:27PM +0200, Ralf Corsepius wrote:
>> On 09/20/2011 04:03 PM, Adam Jackson wrote:
>>> I'd like to see a rationale for jamming a soname-changing update into
>>> the OS so close to a release.
>> Maintainers on vacation, non-trivial changes?
>>
>> In my case, a major change was introduced into rawhide many weeks ago,
>> which had caused breakage in rawhide. One maintainer being involved was
>> in vacation, another one was non-responsive.
>>
>> Ca. 4 weeks later the issues were resolved in rawhide and we started to
>> propagate these changes to f16 and where caught by the delay queues.
>
> We're in the freeze for beta. It's not reasonable to push new sonames
> into the distribution at this point.

I disagree. A reasonable QA would strive to resolve the issues and apply
the solution candidates others already have contributed.

That said, a reasonable QA would cherry-pick such "solution candidates"
from *-testing and integrate them. Simply flooding maintainers "with
complaint mails" about broken deps, maintainers believe to already have
fixed doesn't help anybody. Neither the testers (who can't test because
of these broken deps), nor the maintainers (who believe to have done
everything possible), nor the users (who will end up with low-quality
distros).

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel