On Tue, 2011-10-04 at 09:07 -0700, Adam Williamson wrote:
On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote:
- Original Message -
The setup inside Red Hat cannot be (directly) copied outside at this
time. Instead the autoQA project was started to re-create it as an
open
On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote:
- Original Message -
The setup inside Red Hat cannot be (directly) copied outside at this
time. Instead the autoQA project was started to re-create it as an
open source project. That's where effort should continue.
Am I
- Original Message -
The setup inside Red Hat cannot be (directly) copied outside at this
time. Instead the autoQA project was started to re-create it as an
open source project. That's where effort should continue.
Am I right in saying that AutoQA is basically mired in the muck and
On Fri, Sep 23, 2011 at 14:31, Doug Ledford dledf...@redhat.com wrote:
- Original Message -
The setup inside Red Hat cannot be (directly) copied outside at this
time. Instead the autoQA project was started to re-create it as an
open source project. That's where effort should
Am I right in saying that AutoQA is basically mired in the muck and
going nowhere at the moment?
--
Doug Ledford dledf...@redhat.com
Our progress is very slow at the moment, correct. We will happily welcome some
help. We don't have many tasks that you could do in a free afternoon, however.
- Original Message -
Doug,
= If Autoqa is currently slow it is mainly because what developers
who
are working on it are also tasked with doing other things.
I made no reference or allusion to it being slow because people were slacking.
I myself have more to do than I have time in
On 09/21/2011 05:33 PM, Till Maas wrote:
On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote:
And that's always fine and dandy if these issues are resolved in a
reasonable amount of time. Right now Rawhide has packages with
dependencies broken since pre-F15. This isn't acceptable.
On Thu, Sep 22, 2011 at 09:15:38AM +0200, Marcela Mašláňová wrote:
I hope you don't suggest for every rebuild of few dependent packages one
FESCo ticket.
This is what is currently required to ask FES for help. It is certainly
a lot better and more efficient to open one FESCo and one FES
On 09/22/2011 05:58 PM, Till Maas wrote:
On Thu, Sep 22, 2011 at 09:15:38AM +0200, Marcela Mašláňová wrote:
I hope you don't suggest for every rebuild of few dependent packages one
FESCo ticket.
This is what is currently required to ask FES for help. It is certainly
a lot better and more
- Original Message -
On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford dledf...@redhat.com wrote:
...snip...
Which rpmdiff are we talking about here?
The free/included in fedora one is not that great... it gives you
files
and deps that changed, but that doesn't help you
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
On Sep 22, 2011, at 11:27 AM, Doug Ledford wrote:
- Original Message -
On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford dledf...@redhat.com wrote:
...snip...
Which rpmdiff are we talking about here?
The free/included in fedora one is not that great... it gives you
files
On Tue, 2011-09-20 at 12:21 -0400, Adam Jackson wrote:
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
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
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.
On 09/21/2011 01:25 PM, Nils Philippsen wrote:
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
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
On Wed, Sep 21, 2011 at 04:43:38PM +0200, Nils Philippsen wrote:
And that's always fine and dandy if these issues are resolved in a
reasonable amount of time. Right now Rawhide has packages with
dependencies broken since pre-F15. This isn't acceptable.
If you notice this, ask FESCo to ask FES
On 09/21/2011 04:43 PM, Nils Philippsen wrote:
On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote:
On 09/21/2011 01:25 PM, Nils Philippsen wrote:
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote:
On 09/20/2011 05:52 PM, Nils Philippsen wrote:
On Tue, 2011-09-20 at 15:19 +0200,
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.
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
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.
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
- 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
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
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,
- 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
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
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
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
- 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,
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
* 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
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
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
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
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
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
- 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
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 ;-).
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
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
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
On Sep 20, 2011, at 1:35 PM, Ralf Corsepius wrote:
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
On Tue, Sep 20, 2011 at 11:18:18 -0700,
Jesse Keating jkeat...@j2solutions.net wrote:
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.
I think this would be a change
Am Dienstag, den 20.09.2011, 22:25 +0200 schrieb Ralf Corsepius:
In a nutshell: Fedora's QA process is cause of many of these broken
deps complaints.
Please make a proposal to improve the situation and submit it to FESCo.
TIA,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
2011/9/20 Jesse Keating jkeat...@j2solutions.net:
...
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
58 matches
Mail list logo
