subject:"Re\: Responsibility for rebuilding dependent components, was\: F\-16 Branched report\: 20110920 changes"

On 09/20/2011 03:01 PM, Nils Philippsen wrote:
 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.

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.

 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.

Ralf

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

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

2011-09-20 Thread Sven Lankes

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: s...@lankes.net
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

2011-09-20 Thread Bruno Wolff III

On Tue, Sep 20, 2011 at 15:01:06 +0200,
  Nils Philippsen n...@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

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

2011-09-20 Thread Adam Jackson

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

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

2011-09-20 Thread Nicolas Chauvet

2011/9/20 Nils Philippsen n...@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

Re: 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 Philippsenn...@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

Re: 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 | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

2011-09-20 Thread Matthias Clasen

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

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

2011-09-20 Thread Adam Jackson

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

Re: 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

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

On Tue, Sep 20, 2011 at 10:21:52AM -0400, Matthias Clasen wrote:

 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.

That does seem like pretty fair criticism. We should probably discuss 
this for the F17 timeframe.

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

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

On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:

 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).

What the maintainers could have done is not upload a package that breaks 
binary compatibility into a distribution that's attempting to stabalise 
for release. Really. Don't do that.

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

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

On 09/20/2011 04:37 PM, Matthew Garrett wrote:
 On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:

 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).

 What the maintainers could have done is not upload a package that breaks
 binary compatibility into a distribution that's attempting to stabalise
 for release.

That's a way too simplistic view - It's simply that other processes 
(upstream release cycles, upstream release processes, package 
maintainer's time slots, etc.) are not in sync with Fedora's cycles and 
that Fedora's wanna-be QA's delay slots are severely adding to the 
already existing problems.

 Really. Don't do that.

Really, your vision is impractical and non-applicable.

Ralf



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

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

On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
 On 09/20/2011 04:37 PM, Matthew Garrett wrote:
 What the maintainers could have done is not upload a package that breaks
 binary compatibility into a distribution that's attempting to stabalise
 for release.
 
 That's a way too simplistic view - It's simply that other processes
 (upstream release cycles, upstream release processes, package
 maintainer's time slots, etc.) are not in sync with Fedora's cycles
 and that Fedora's wanna-be QA's delay slots are severely adding to
 the already existing problems.

You're not obliged to upload the latest upstream. It's very practical to 
simply not do so.

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

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

2011-09-20 Thread Miloslav Trmač

On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
 On 09/20/2011 04:37 PM, Matthew Garrett wrote:
 What the maintainers could have done is not upload a package that breaks
 binary compatibility into a distribution that's attempting to stabalise
 for release.

 That's a way too simplistic view - It's simply that other processes
 (upstream release cycles, upstream release processes, package
 maintainer's time slots, etc.) are not in sync with Fedora's cycles
 and that Fedora's wanna-be QA's delay slots are severely adding to
 the already existing problems.

 You're not obliged to upload the latest upstream. It's very practical to
 simply not do so.

So when _is_ a good time to do binary-incompatible changes to libraries?

* It's not after beta freeze, because they are unwanted at that time

* It's not 14 days before beta freeze, because they won't get out of
updates-testing in time

* It's not 14 days + 3 (4?) weeks before beta freeze - even if the
library gets out of updates-testing in time, its users may not be
rebuilt because the maintainer is on vacation.

* What if there are two layers of users that need to be rebuilt?

The delays just pile one upon another...
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

On Tue, 2011-09-20 at 16:06 +0200, Nicolas Chauvet wrote:
 2011/9/20 Nils Philippsen n...@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.

I wasn't picking on you, or anyone for what it's worth. It's just a
situation I've seen often enough so that I think it deserves some kind
of a solution, at least for the majority of cases where this shouldn't
be too much of a hassle.

With responsible I didn't mean that this person needs to do all of the
work either. Ordinary (non-proven-)packagers need to be part of the
picture.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

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

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

- Original Message -
 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.

One rationale is that if we don't get it *before* the release when everyone is 
actively testing, then it ends up going in post release, likely with far less 
testing, and risks destabilizing the already released product.  Unless we want 
to change the Fedora update policy that updates such as this are not allowed 
after the product goes GA, then there is an argument to be made that before GA 
when people are testing is better than after GA when testing isn't so 
widespread (the counter argument being that we need to stabilize what we have, 
and then deal with destabilizing changes in later updates because if we don't 
pick some line in the sand to call a stabilization point, then destabilizing 
changes will never end).

However, if a group were to take this approach, then the entire CRITPATH and 
normal update process for an early branched release is totally backwards from 
what it should be.  If we were to say that we want the stuff in early instead 
of post-GA, then on an early branched process things should go direct to stable 
without hitting testing at all on the theory that getting it in the most hands 
as quickly as possible maximizes testing prior to the product going GA.  Yes, 
it might destabilize the early branched release momentarily, but without 
anything blocking a fix from being pushed right on out, the iterative push, 
test, report breakage, fix, push, test cycle goes much faster.

Note: I'm not putting my $.02 in towards either side, just playing devil's 
advocate.

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

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

On Tue, 2011-09-20 at 16:07 +0200, Ralf Corsepius wrote:
 On 09/20/2011 03:47 PM, Bruno Wolff III wrote:
  On Tue, Sep 20, 2011 at 15:01:06 +0200,
 Nils Philippsenn...@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.

Well, easy build overrides are helping getting the technical side done
without involving rel-eng. Several maintainers being involved and
non-trivial technical difficulties are exactly the topics that need to
be sorted out, but they don't have a thing to do with who sets up the
build overrides.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

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

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

On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
 Of course, the accounts system _still_ doesn't have groups, five years 
 later, so provenpackager is the big hammer we have.  We could get groups 
 any day now, that'd be just fine.

Do you mean groups of groups, like in provenpackager-kde,
provenpackager-gnome, and provenpackager means all of these?

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

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

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

- Original Message -
 So when _is_ a good time to do binary-incompatible changes to
 libraries?
 
 * It's not after beta freeze, because they are unwanted at that time
 
 * It's not 14 days before beta freeze, because they won't get out of
 updates-testing in time
 
 * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
 library gets out of updates-testing in time, its users may not be
 rebuilt because the maintainer is on vacation.
 
 * What if there are two layers of users that need to be rebuilt?
 
 The delays just pile one upon another...
Mirek

I'd like to expand on my previous email (the one where I played devil's 
advocate) and pick up where Mirek left off here.

I'm fine with our new early branched methodology, to a point.  I think it's a 
good idea that we do an early branch and separate our upcoming release from 
rawhide.  However, I think the process we use to get packages from 
updates-testing into the actual GA candidate tree is the problem.

I think we are gating package updates on the wrong thing: testing.  I say this 
because the *real* testing happens with the alpha/beta/rc candidate install 
images, not with individual testers pulling packages from updates-testing.  And 
when trying to stabilize a product for GA, you want *everyone* testing the 
updates, not just a few.

Instead, I think we ought to revamp the process like this:

Maintainer A builds new package B
Maintainer A files a bodhi ticket for package B
In that ticket, the maintainer is responsible for list each item of change from 
the previous package already in the compose tree.  For example, did the 
upstream source get bumped, did any new patches get applied, did any old 
patches stop being applied, are the changes verified bug fixes as tested in 
rawhide, are the changes isolated or are there feature additions as well, will 
this update create dependency problems from things such as an soname bump, will 
other packages need to be rebuilt.
Finally, the bodhi update should be reviewed by people from release 
engineering, and if the ticket meets the requirements of a reasonable change at 
this late stage of the game, the ticket should be approved and the package 
pushed to stable.

The point of this process is that when stabilizing the product for GA, we want 
to minimize unnecessary or risky churn, and that doesn't need testing, that 
needs a human to make a judgement call.  Then, once the judgement call is made, 
we need as much testing as possible to make the release as good as possible.  
Holding things up in updates-testing and then releasing them later throws away 
untold instances of testing, wasting those resources on a package that may 
never be on the final product.  We need to make that judgement call, put the 
package in if we are going to, test the hell out of it, and fix any breakage we 
find.  We need this iterative test, report breakage, fix, retest process to 
be as fast as possible, and our current process moves at the speed of a salt 
coated slug.

That's my proposed process for our early branched release.  Thoughts?

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

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

On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote:
 On 09/20/2011 03:01 PM, Nils Philippsen wrote:
  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.
 
 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.

I didn't want to (re)start that particular discussion ;-).

We need some guidelines who should drive rebuilds in such a situation,
regardless of whether it happens in Rawhide or Branched or wherever.
Otherwise we'll end up with nobody doing the driving.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

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

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

On Tue, 2011-09-20 at 11:45 -0400, Doug Ledford wrote:
 - Original Message -
  So when _is_ a good time to do binary-incompatible changes to
  libraries?
  
  * It's not after beta freeze, because they are unwanted at that time
  
  * It's not 14 days before beta freeze, because they won't get out of
  updates-testing in time
  
  * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
  library gets out of updates-testing in time, its users may not be
  rebuilt because the maintainer is on vacation.
  
  * What if there are two layers of users that need to be rebuilt?
  
  The delays just pile one upon another...
 Mirek
 
 I'd like to expand on my previous email (the one where I played
 devil's advocate) and pick up where Mirek left off here.
 
 I'm fine with our new early branched methodology, to a point.  I think
 it's a good idea that we do an early branch and separate our upcoming
 release from rawhide.  However, I think the process we use to get
 packages from updates-testing into the actual GA candidate tree is the
 problem.
 
 I think we are gating package updates on the wrong thing: testing.  I
 say this because the *real* testing happens with the alpha/beta/rc
 candidate install images, not with individual testers pulling packages
 from updates-testing.  And when trying to stabilize a product for GA,
 you want *everyone* testing the updates, not just a few.
 
 Instead, I think we ought to revamp the process like this:
 
 Maintainer A builds new package B
 Maintainer A files a bodhi ticket for package B
 In that ticket, the maintainer is responsible for list each item of
 change from the previous package already in the compose tree.  For
 example, did the upstream source get bumped, did any new patches get

I'd like to mention that an upstream source getting bumped doesn't mean
anything per se, so we should rather have criteria agnostic of arbitrary
parameters like this. For instance, it shouldn't make a shred of
difference whether I apply a patch in the spec file, or upstream, all
other things being the same (i.e. if tarball-1.0 + patch == tarball-1.1
+ changes we want to have anyway like updated translations).

  applied, did any old patches stop being applied, are the changes
 verified bug fixes as tested in rawhide, are the changes isolated or
 are there feature additions as well, will this update create
 dependency problems from things such as an soname bump, will other
 packages need to be rebuilt.

^^ This.

 Finally, the bodhi update should be reviewed by people from release
 engineering, and if the ticket meets the requirements of a reasonable
 change at this late stage of the game, the ticket should be approved
 and the package pushed to stable.
 
 The point of this process is that when stabilizing the product for GA,
 we want to minimize unnecessary or risky churn, and that doesn't need
 testing, that needs a human to make a judgement call.  Then, once the
 judgement call is made, we need as much testing as possible to make
 the release as good as possible.  Holding things up in updates-testing
 and then releasing them later throws away untold instances of testing,
 wasting those resources on a package that may never be on the final
 product.  We need to make that judgement call, put the package in if
 we are going to, test the hell out of it, and fix any breakage we
 find.  We need this iterative test, report breakage, fix, retest
 process to be as fast as possible, and our current process moves at
 the speed of a salt coated slug.
 
 That's my proposed process for our early branched release.  Thoughts?

Looks like it would get things done.

Nils
-- 
Nils Philippsen  Those who would give up Essential Liberty to purchase 
Red Hat   a little Temporary Safety, deserve neither Liberty
n...@redhat.com   nor Safety.  --  Benjamin Franklin, 1759
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

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

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

2011-09-20 Thread Adam Jackson

On 9/20/11 11:43 AM, Nils Philippsen wrote:
 On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
 Of course, the accounts system _still_ doesn't have groups, five years
 later, so provenpackager is the big hammer we have.  We could get groups
 any day now, that'd be just fine.

 Do you mean groups of groups, like in provenpackager-kde,
 provenpackager-gnome, and provenpackager means all of these?

I don't see any real reason to do that instead of just unix-style 
groups, but either one would be an improvement.

- ajax

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

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

- Original Message -
 I'd like to mention that an upstream source getting bumped doesn't
 mean
 anything per se, so we should rather have criteria agnostic of
 arbitrary
 parameters like this. For instance, it shouldn't make a shred of
 difference whether I apply a patch in the spec file, or upstream, all
 other things being the same (i.e. if tarball-1.0 + patch ==
 tarball-1.1
 + changes we want to have anyway like updated translations).

I agree.  Each source update would have to be justified.  I know I've done a 
source tarball update when it was just a roll up bug fix release.  A source 
update that implements new features is another issue.  The maintainer is in the 
best position to know this and can note the distinction in the bodhi ticket.

 Looks like it would get things done.

That's what I thought ;-)

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

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

2011-09-20 Thread Nicolas Mailhot

Le mardi 20 septembre 2011 à 17:10 +0200, Miloslav Trmač a écrit :

 So when _is_ a good time to do binary-incompatible changes to libraries?

The answer is obvious - in rawhide, before branching point. Anything
after branching will interact with various groups schedules and crash
into the barriers put in place to try to bring some order to the
release.

Now of course that supposes rawhide is kept in dogfoodable state and
people don't let problems fester there because 'it eats babies, so who
cares'


-- 
Nicolas Mailhot

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

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

2011-09-20 Thread tim.laurid...@gmail.com

 * What if there are two layers of users that need to be rebuilt?

 The delays just pile one upon another...

 You can update rawhide at any time and accomplish that work without
 delays.  Then it shows up in the next Fedora version.


Yes, but then we have align the schedules, so have a new gnome release
in good time before a new fedora release tree is forked and when a new
Fedora GA is released, it will be close to the next Gnome release and
Fedora will not be the latest and greatest.
As an example i was hit by the latest gnome 3.2 pre-release in Rawhide
and F16 in awn-extras-applets, there contains a lot of applets to awn
written in C, Python  Vala with a lot of different requirements to
all kind of different gnome stuff (fx. gnome-menu 2.0) this was bumped
to 3.0 and some python binding disappeared. It will take me 2-3 weeks
before figure out how to work around the issues, remove stuff there
can't be fixed and get into updates-testing and to stable. Lucky for
me, nothing depends on awn-extras-applets, but users will have
problems updating to the new gnome packages without removing the
awn-extras-applets package.
This is not ideal between alpha and beta, but it the way things goes,
if we want to have the latest gnome close to the fedora release.

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

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

2011-09-20 Thread Christoph Wickert

Am Dienstag, den 20.09.2011, 15:39 +0200 schrieb Sven Lankes:

 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?

I think we should. Please file a bug against bodhi because it should be
at 3 days for F16 already.

Regards,
Christoph

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

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

2011-09-20 Thread Christoph Wickert

Am Dienstag, den 20.09.2011, 16:06 +0200 schrieb Nicolas Chauvet:
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.

IHMO the proper way to deal with this is:
1. Mail fedora-devel and owners of dependent packages (at least)
one week in advance. This is a requirement and written down in
our wiki [1]. repoquery and the foo-owner aliases should help
here.
2. Ask maintainers if they are ok with the update and willing/able
to do a rebuild in time. Offer to rebuild packages if people are
not able to do it. Request the necessary commit access in
packagedb.
3. Once you have sufficient feedback, update opencv.
4. Submit a buildroot overwrite for opencv but do not push it to
stable or testing.
5. Mail owners again and tell them they can now rebuild their
packages
6. Wait for feedback before you create an update. If you have
commit access, you can include dependent packages in the update.
Proven packager will not work.
7. Mail owners again when you push the update from one tag to
another.

Regards,
Christoph

[1]
http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages

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

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

2011-09-20 Thread Panu Matilainen

On 09/20/2011 08:19 PM, Nicolas Mailhot wrote:
 Le mardi 20 septembre 2011 à 17:10 +0200, Miloslav Trmač a écrit :

 So when _is_ a good time to do binary-incompatible changes to libraries?

 The answer is obvious - in rawhide, before branching point. Anything
 after branching will interact with various groups schedules and crash
 into the barriers put in place to try to bring some order to the
 release.

 Now of course that supposes rawhide is kept in dogfoodable state and
 people don't let problems fester there because 'it eats babies, so who
 cares'

Also related to rawhide dogfoodability is this recent trend where after 
a branch point, all work appears switch to the branched distro, 
resulting in branches having newer packages than rawhide and such. This 
was very visible at least after F15 branching, this time around I 
haven't paid enough attention to comment whether its the same now.

The effect of this is that the active rawhide window *seems* awfully 
short these days, because rawhide is relatively quiet for large number 
of packages during branced state. That's not how the branching procedure 
intends this to work, but that's how it seems to go in practise to a 
large extent.

My personal pet-peeve with the current branching policy is that the 
mass-branching happens way way too early for packages where there are no 
significant new development to be introduced in rawhide during branched 
state. So for every single tiny fix that needs to go in, it needs to be 
built into rawhide and also branched. Minor annoyance maybe but annoying 
things tend to get negletted - perhaps this is one of the reasons for 
rawhide lagging behind branched.

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

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

On Sep 20, 2011, at 8:45 AM, Doug Ledford wrote:
 
 Instead, I think we ought to revamp the process like this:
 
 Maintainer A builds new package B
 Maintainer A files a bodhi ticket for package B
 In that ticket, the maintainer is responsible for list each item of change 
 from the previous package already in the compose tree.  For example, did the 
 upstream source get bumped, did any new patches get applied, did any old 
 patches stop being applied, are the changes verified bug fixes as tested in 
 rawhide, are the changes isolated or are there feature additions as well, 
 will this update create dependency problems from things such as an soname 
 bump, will other packages need to be rebuilt.
 Finally, the bodhi update should be reviewed by people from release 
 engineering, and if the ticket meets the requirements of a reasonable change 
 at this late stage of the game, the ticket should be approved and the package 
 pushed to stable.
 
 The point of this process is that when stabilizing the product for GA, we 
 want to minimize unnecessary or risky churn, and that doesn't need testing, 
 that needs a human to make a judgement call.  Then, once the judgement call 
 is made, we need as much testing as possible to make the release as good as 
 possible.  Holding things up in updates-testing and then releasing them later 
 throws away untold instances of testing, wasting those resources on a package 
 that may never be on the final product.  We need to make that judgement call, 
 put the package in if we are going to, test the hell out of it, and fix any 
 breakage we find.  We need this iterative test, report breakage, fix, 
 retest process to be as fast as possible, and our current process moves at 
 the speed of a salt coated slug.
 
 That's my proposed process for our early branched release.  Thoughts?

This is essentially what we had a while ago, only with trac tickets instead of 
bodhi requests.  There were a couple of problems with this.

1) Nowhere near enough releng folks to properly review all the tickets.
2) 9 times out of 10 there was very little data put into the ticket.
3) releng folks were often not the best people to decide whether a change was 
too risky
4) There was no easy way to get at the package and assess its stability.

I think there were more issues, but those come to mind first.  We decided it 
was best instead to make a repository out of proposed changes, and let your 
packaging peers decide whether or not the update was safe enough to go into the 
release, thus we have bodhi and updates-testing as a gateway to get into the 
release.

- jlk

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

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

On Sep 20, 2011, at 11:11 AM, Panu Matilainen wrote:
 
 My personal pet-peeve with the current branching policy is that the 
 mass-branching happens way way too early for packages where there are no 
 significant new development to be introduced in rawhide during branched 
 state. So for every single tiny fix that needs to go in, it needs to be 
 built into rawhide and also branched. Minor annoyance maybe but annoying 
 things tend to get negletted - perhaps this is one of the reasons for 
 rawhide lagging behind branched.

This isn't quite correct.  If you haven't built anything explicitly for Rawhide 
since the branch point, the stable packages from the branched repo will be 
inherited into rawhide.

You still should merge your changes from the branch up to master (for rawhide) 
but there is no reason to do a build.  Let the build system inheritance take 
care of that.

One change to make this better might be to move the inheritance point to 
updates-testing so that things built from the fresh branch are immediately 
inherited into rawhide.

- jlk

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

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

- Original Message -
 This is essentially what we had a while ago, only with trac tickets
 instead of bodhi requests.

Bodhi is definitely a better place to track this stuff, regardless of how 
decisions are made.

  There were a couple of problems with
 this.
 
 1) Nowhere near enough releng folks to properly review all the
 tickets.

Fair enough.

 2) 9 times out of 10 there was very little data put into the ticket.

Multiple options here.  Kick back incomplete tickets, or the better option 
IMNSHO, run rpmdiff runs between the package currently in the compose and the 
one in testing to check for various failures and require the developer to 
justify failures.

 3) releng folks were often not the best people to decide whether a
 change was too risky

The rpmdiff option above would help with this.

 4) There was no easy way to get at the package and assess its
 stability.

Using bodhi instead of trac solves this, no?

 I think there were more issues, but those come to mind first.  We
 decided it was best instead to make a repository out of proposed
 changes,

But in practice that's not really what updates-testing on the early branched 
release really is.  It's a repo all right, but not of proposed changes, it's a 
repo of packages, and getting to the actual changes versus the final package 
would require installing the current source rpm, the new source rpm, then doing 
a manual inspection for changes.  An automated rpmdiff run would be a *far* 
superior means of presenting the proposed changes to the community.

 and let your packaging peers decide whether or not the
 update was safe enough to go into the release,

But they can't, not really.  For instance, a proventester may install my mdadm 
package, but if they don't have a raid array, they can't decide anything.  
Where as if they had access to the code diffs and could tell that all I did was 
change a typo in the udev rules file, and verify for themselves via code 
inspection that the code as it stands in the repo can't work and the fix should 
work, then they could make an educated contribution.  Because the testing repo 
doesn't really present changes, but only a final product, there is no 
possibility for my peers to look at my changes and say Yeah, that's should be 
a safe change, let it in, and if it breaks then we'll fix it.  So the 
judgement call that I mentioned in my previous email is taken entirely out of 
the loop, and there is no ability for my peers to make any contribution to 
whether or not a package should be allowed in *except* unit testing, there is 
no ability for them to easily do an actual analysis of the changes and ma
 ke an engineering decision versus a QA decision.

 thus we have bodhi
 and updates-testing as a gateway to get into the release.

It's a gateway, I just don't think it serves as useful a purpose as it was 
intended to.

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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

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

On 09/20/2011 05:52 PM, Nils Philippsen wrote:
 On Tue, 2011-09-20 at 15:19 +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.

 I didn't want to (re)start that particular discussion ;-).
 
 We need some guidelines who should drive rebuilds in such a situation,
 regardless of whether it happens in Rawhide or Branched or wherever.
a) These situation can only happen in release branches.

b) To me, Fedora is like coping with German Tax Laws.
We don't need more regulations/guidelines, we need a fundamental
change of the tax system.

 Otherwise we'll end up with nobody doing the driving.
Well, packagers are driving ... it's the QA process which is causing 
their measures to show effect.

In a nutshell: Fedora's QA process is cause of many of these broken 
deps complaints.

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

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

On 09/20/2011 05:30 PM, Doug Ledford wrote:
 - Original Message -
 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.

 One rationale is that if we don't get it *before* the release when everyone 
 is actively testing, then it ends up going in post release,
Agreed, but what currently is happening, is packagers not being able to 
submit package chains _in time_ because of the delays.

Reality is, when the root of a dependency chain changes incompatibly, 
there are situations, it takes weeks until the whole chain has been 
rebuilt. And when a freeze closes down update submissions, the repos 
end up in inconsistent and broken state.

 likely with far less testing, and risks destabilizing the already released 
 product.

The way things currently are, these packages will land as part of day 
one mass updates.

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

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

On 09/20/2011 04:33 PM, Adam Jackson wrote:

 Of course, you had the option of not pulling the new OpenSceneGraph back
 to F16, or simply not doing so yet.

Correct. I could have opted to ship the distro which embraces novelty 
with outdated, upstream unmaintained and upstream dead packages, no user 
is interested in using in anymore.

  Particularly during a phase where
 people are trying to keep change to a minimum so we know what we're
 working with.
The change had affected 5 packages ... You are right insofar as I 
underestimated the harmful impact of Fedora's wanna-be QA bureaucracy.

 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.
Please understand, I can not take you seriously anymore.



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

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

On Sep 20, 2011, at 12:19 PM, Doug Ledford wrote:
 - Original Message -
 This is essentially what we had a while ago, only with trac tickets
 instead of bodhi requests.
 
 Bodhi is definitely a better place to track this stuff, regardless of how 
 decisions are made.
 
 There were a couple of problems with
 this.
 
 1) Nowhere near enough releng folks to properly review all the
 tickets.
 
 Fair enough.
 
 2) 9 times out of 10 there was very little data put into the ticket.
 
 Multiple options here.  Kick back incomplete tickets, or the better option 
 IMNSHO, run rpmdiff runs between the package currently in the compose and the 
 one in testing to check for various failures and require the developer to 
 justify failures.

There was supposed to be AutoQA filling this role here, catching obvious 
issues, sanity checking, and letting things through that looked OK.  We're 
still waiting for autoQA.  There certainly wasn't enough releng man 
power/volunteers to manually look through this for every potential update.

 
 3) releng folks were often not the best people to decide whether a
 change was too risky
 
 The rpmdiff option above would help with this.
 
 4) There was no easy way to get at the package and assess its
 stability.
 
 Using bodhi instead of trac solves this, no?

No, what was missing was a repository with yum metadata to get at the package 
and any sibling packages that needed to come with it for a comprehensive 
picture of what was going on.

 
 I think there were more issues, but those come to mind first.  We
 decided it was best instead to make a repository out of proposed
 changes,
 
 But in practice that's not really what updates-testing on the early branched 
 release really is.  It's a repo all right, but not of proposed changes, it's 
 a repo of packages, and getting to the actual changes versus the final 
 package would require installing the current source rpm, the new source rpm, 
 then doing a manual inspection for changes.  An automated rpmdiff run would 
 be a *far* superior means of presenting the proposed changes to the community.

It depends on what you're after.  If you just want a list of changes, sure, but 
if you want some idea as to whether or not those changes introduce instability 
then you need to look more comprehensively.  It is rather difficult to look at 
a small list of changes and gauge how well/ill it will effect the stability of 
the distribution going forward.  Either you're too liberal and we have rampant 
instability, or you're too draconian and we have very strict barriers to entry, 
which are suddenly removed once a product goes GA.  Using the same criteria 
prior to and post GA to assess the validity of an update makes sense to me.

 
 and let your packaging peers decide whether or not the
 update was safe enough to go into the release,
 
 But they can't, not really.  For instance, a proventester may install my 
 mdadm package, but if they don't have a raid array, they can't decide 
 anything.  Where as if they had access to the code diffs and could tell that 
 all I did was change a typo in the udev rules file, and verify for themselves 
 via code inspection that the code as it stands in the repo can't work and the 
 fix should work, then they could make an educated contribution.

Sadly we have far far too few real developers who could do that comparison.

  Because the testing repo doesn't really present changes, but only a final 
 product, there is no possibility for my peers to look at my changes and say 
 Yeah, that's should be a safe change, let it in, and if it breaks then we'll 
 fix it.  So the judgement call that I mentioned in my previous email is 
 taken entirely out of the loop, and there is no ability for my peers to make 
 any contribution to whether or not a package should be allowed in *except* 
 unit testing, there is no ability for them to easily do an actual analysis of 
 the changes and ma
 ke an engineering decision versus a QA decision.

I think that's largely because we don't have a community of engineers.  We have 
a community of /packagers/ who are able to cause packages to be built, and are 
able to do some measure of QA to see if those builds work, but do not have the 
skill set to look at a code diff and give a honest opinion as to whether or not 
the change is safe.

If the makeup of our community were different, then you would have a case for 
your proposal.  I just don't believe we have the community it would take to 
accomplish it on a large scale.

 
 thus we have bodhi
 and updates-testing as a gateway to get into the release.
 
 It's a gateway, I just don't think it serves as useful a purpose as it was 
 intended to.


The question though really is whether or not it is more useful than a few (like 
4) release engineers looking at trac tickets and making best guesses depending 
on whatever the ticket reporter put in the ticket about the change.  We were 
trying to improve the workflow, not perfect it.  Has it

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