FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-20-2011, 08:25 PM
Ralf Corsepius
 
Default 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
 
Old 09-20-2011, 08:43 PM
Ralf Corsepius
 
Default 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
 
Old 09-20-2011, 08:59 PM
Kevin Fenzi
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford <dledford@redhat.com> wrote:

...snip...

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

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 see what changed in
them...
>
> > 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.

So, I run it on xfwm4 updates:

rpmdiff xfwm4-4.8.1-2.fc15.x86_64.rpm xfwm4-4.8.1-3.fc16.x86_64.rpm

removed REQUIRES libpng12.so.0()(64bit)
removed PROVIDES xfwm4(x86-64) = 4.8.1-2.fc15
added PROVIDES xfwm4(x86-64) = 4.8.1-3.fc16
S.5.......T /usr/bin/xfwm4
S.5.......T /usr/bin/xfwm4-settings
S.5.......T /usr/bin/xfwm4-tweaks-settings
S.5.......T /usr/bin/xfwm4-workspace-settings
..........T /usr/lib64/xfce4/xfwm4
S.5.......T /usr/lib64/xfce4/xfwm4/helper-dialog
...all the doc files have different timestamp...

What does that help me with?

> > 4) There was no easy way to get at the package and assess its
> > stability.
>
> Using bodhi instead of trac solves this, no?

well, not bodhi, but a repo like updates-testing, yeah.

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

I'd love to see something more detailed from rpmdiff.

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-20-2011, 09:44 PM
Bruno Wolff III
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

On Tue, Sep 20, 2011 at 11:18:18 -0700,
Jesse Keating <jkeating@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 for the better. I've noticed f17 is not picking
up fixes from f16 for a long time as stuff sits in updates-testing.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-20-2011, 10:03 PM
Christoph Wickert
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-20-2011, 10:56 PM
Nicolas Chauvet
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

2011/9/20 Jesse Keating <jkeating@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 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 been improved?

I think the situation improved with bodhi buildroot overrides over trac tickets.
But I've hit several issues with the opencv case:

- Buildroot overrides disappear on bodhi ticket submission:
When an override is scheduled for a period of time, it is discarded
when a bodhi updates is submitted. In my case, some dependencies
wasn't rebuilt yet, but was also FTBFS for other reason. Pushing an
update didn't invalidate the need to rebuilt this update with the new
ABI. That could have been done later and would still allows to test
the actual override.

- Buildroot overrides should be included in the dependency checks report.
That cannot replace an announcement to know if such ABI change is
legitimate. But that would help maintainers to keep in mind that their
action is needed and for which branch. Specially if they have missed
the announcement for any reason.

- About Bodhi and ACLs,
Tickets integrity shouldn't be affected by the ACL mismatch of each
single package by the submitter.
As I'm submitting an override, then I should inherit "some rights" to
push an update with consistency from testing to stable.
Probably bodhi should be aware that buildroot overrides are a premise
to an update and suggest to add the packages rebuilt with the new
version, and allow an ACL on it for the ticket.

I can understand that there is too much rights involved with the bodhi
buildroot override for non provenpackager. So it become a
provenpackager duty to drive an ABI change. That wasn't the case with
trac tickets because that has involved also some ACLs override to
rebuild a list of packages. And that was conduced in a single process.

Nicolas (kwizart)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-21-2011, 11:09 AM
Nils Philippsen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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

Hmm, it seems I don't quite get what you mean with "the accounts system
_still_ doesn't have groups" -- while provenpackager among others is a
group. Would you please elaborate?

TIA,
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@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
 
Old 09-21-2011, 11:25 AM
Nils Philippsen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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

Uhm, no. A library SONAME bump can happen in Rawhide as well as in
branches and if dependent packages don't get built with the new version,
things are broken. Waiting for dependent components to be built at their
maintainers leisure or whenever a mass rebuild comes around isn't a
solution, not if we want to have a "more stable Rawhide".

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@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
 
Old 09-21-2011, 01:51 PM
Ralf Corsepius
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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 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.
>
> Uhm, no. A library SONAME bump can happen in Rawhide as well as in
> branches and if dependent packages don't get built with the new version,
> things are broken.
Right. They break in rawhide, where issues are inevitable and can be
addressed within short terms because maintainers are not being forced to
play "10 days per package update" "you wait for me/I wait for you" delay
ping-pong.

Or am I misunderstanding? Are you referring to points in time when
"stable fedoras" are being sync'ed and inherit "broken deps" during this
fork? If this happens, something would be very defective with Fedora's
rel-eng's procedures.

The situation currently to be found in f16 is "longer dep chains" being
in inconsistent build-state (showing as broken deps), because fixed
packages in *-testing did not make it into "stable" in time because of
these QA delays and because Fedora policies _forbit_ fixing these at
this point in time.

> Waiting for dependent components to be built at their
> maintainers leisure or whenever a mass rebuild comes around isn't a
> solution, not if we want to have a "more stable Rawhide".

To we want this? I don't. To me, rawhide is the "big package dumping
ground" for the bleading edge". Certainly, it should be as little broken
as possible, but "its brokenness" is part of its working principle and
inevitable to me. That said, I find a stable "rawhide" to be
nonrealisting and inapplicable.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-21-2011, 02:43 PM
Nils Philippsen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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, 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.
> >
> > Uhm, no. A library SONAME bump can happen in Rawhide as well as in
> > branches and if dependent packages don't get built with the new version,
> > things are broken.
> Right. They break in rawhide, where issues are inevitable and can be
> addressed within short terms because maintainers are not being forced to
> play "10 days per package update" "you wait for me/I wait for you" delay
> ping-pong.

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.

> Or am I misunderstanding? Are you referring to points in time when
> "stable fedoras" are being sync'ed and inherit "broken deps" during this
> fork? If this happens, something would be very defective with Fedora's
> rel-eng's procedures.

I'm not talking about branched Fedora vs. Rawhide at all. I thought I
made myself clear on that.

> > Waiting for dependent components to be built at their
> > maintainers leisure or whenever a mass rebuild comes around isn't a
> > solution, not if we want to have a "more stable Rawhide".
>
> To we want this? I don't. To me, rawhide is the "big package dumping
> ground" for the bleading edge". Certainly, it should be as little broken
> as possible, but "its brokenness" is part of its working principle and
> inevitable to me. That said, I find a stable "rawhide" to be
> nonrealisting and inapplicable.

You're twisting my words a bit. I wasn't opting for a stable, but a more
stable release. If somebody wants to test something in Rawhide they
shouldn't have to debug other parts of the distribution. This means that
changes should be done with enough circumspection that breakage is
reduced to a minimum. People who actually run Rawhide (and I know their
number is low) would thank us for that.

Right now this is not the case: a substantial number of components is
broken due to unsatisfied dependencies alone, meaning that everybody who
wants to test Rawhide in conjunction with anything on that list is
simply out of luck right now. I admit that the impact of being broken is
not the same for every component in the distribution: some stuff more on
the fringe is sufficiently isolated that it will only affect few testers
if it doesn't work (ideally the ones fixing the breakage), so it won't
hurt many if these are broken for a longer time, but other components
are central enough that they can't afford that luxury.

It would certainly help here if buildroots could be created for Rawhide
so that breakage can be resolved in isolation there. In this case they'd
need to be created before the first package is built however, so it
doesn't break unrelated builds. This is because we don't file Bodhi
updates for Rawhide packages (nobody in their right mind would want
that).

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@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
 

Thread Tools




All times are GMT. The time now is 01:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org