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-21-2011, 03:33 PM
Till Maas
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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 to perform a rebuild to fix the
dependency:
https://fedoraproject.org/wiki/Fedora_Engineering_Services

Probably any member of the provenpackager group can help you here.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-21-2011, 04:32 PM
Ralf Corsepius
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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

Agreed - If so, these need to be addressed. IMO, if packagers and/or
proven packagers are not able to fix these in "reasonable time", I'd
consider it to be QA's job to take care about these.

As experience as a proven packager, who did try to address such cases in
the past tells, such cases typically originate from
a) packagers not being sufficently skilled to fix such breakages and
them not asking for assitance.
b) packagers having gone AWOL or being unreachable
c) packages being sufficiently incompatible to an upgrade that they
better should be removed/retired.

Wrt. a) experience tells, some packagers are hesitant to ask for
assitance and prefer to "sit out the issue", until some proven packager
or upstream takes action.

Wrt. the packages I had stepped in, case b) was fairly common. IMO the
cause is Fedora lacking a spirit of "teaming up".

Wrt. c), here the issue seems to be packagers being hesitant to "draw a
cut" and to retire a package. Surprisingly, when directly contacting
maintainers of such packages, they often agree to such retirement.

>>> 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.
Well, what am I supposed to say?

Anybody would be grateful for less bugs and breakage, but ... on rawhide
breakage is simply inevitable.

> 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.
That's one view.

From a packager's view, whenever something changes incompatibly, no
matter how careful and speedy the packager tries to be, there always be
situations when something breaks.

Typical case are: The packager who is pushing an incompatible upgrade
misses a "to be rebuild package", the packager doesn't have sufficient
privileges to rebuild a package in need of a rebuilt or the upgrade
renders a package unbuildable ...

IMO, the last on this list is the critical case, which is causing
rawhide users to complain.

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

> It would certainly help here if buildroots could be created for Rawhide
> so that breakage can be resolved in isolation there.

I am using local mock environments which inherit from "upstream" (==
Fedora), as a band-aid to identify potential breakage and to keep impact
of incompatible upgrades low. This often works, but not always.

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

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 07:15 AM
Marcela Mašláňová
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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.
>
> If you notice this, ask FESCo to ask FES to perform a rebuild to fix the
> dependency:
> https://fedoraproject.org/wiki/Fedora_Engineering_Services
>
> Probably any member of the provenpackager group can help you here.
>
> Regards
> Till
>
>
>
I hope you don't suggest for every rebuild of few dependent packages one
FESCo ticket.

--
Marcela Mašláňová
BaseOS team Brno
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 09:41 AM
Matthias Runge
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/09/11 09:15, Marcela Mašláňová wrote:
> 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.
>>
>> If you notice this, ask FESCo to ask FES to perform a rebuild to
>> fix the dependency:
>> https://fedoraproject.org/wiki/Fedora_Engineering_Services
>>
>> Probably any member of the provenpackager group can help you
>> here.
>>
>> Regards Till
>>
>>
>>
> I hope you don't suggest for every rebuild of few dependent
> packages one FESCo ticket.
>
Thinking some time about this:

Would it help to have a person (per branch), responsible for
rebuilding packages with broken deps? The person may rebuild himself
or try to force package maintainers to rebuild, retire packages, when
they stay in broken state since .. days/releases/...?

Cheers,
Matthias

- --
Matthias Runge <mrunge@matthias-runge.de>
<mrunge@fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOewLRAAoJEOnz8qQwcaIW/IkH/A4BNpTcqwH8+x9FXdHGWeNv
pw1FoeT1SZx+UtLdVbSmXiDKAsIvZ9InGD8+9hXF1Af6QRz0+E CJXhJ6Vn16FEO4
zmLtZ7SX/gZGtcafxw4ua7W0QjW/96EY+E5sAzIJ34DqSaDmklt/rOTuqf37oRuQ
pf1wim9KYcbeLTJhV2iJ3OWEAXW2lmyH2JQSg+sfZv7QQTSjGl 6VmD+asV7Ktn/3
aiYmquIRtwIdxLkJtfEvVq4yUUqVvsAg3GWgH2HQXG3QHvzFTT 0hpWgQ00h5M0n+
a0YVLpBqleiVRP9x1/evh5qdywxtdWZ2uucQCE6rQu/zZXEPXhkhZg1BSXF7uv4=
=1iuC
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 03:58 PM
Till Maas
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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 ticket to
get dependent packages rebuild than to open several Bugzilla tickets for
each dependent package. If the respective maintainer can perform the
rebuilds all by himself, then there is off course no need to ask for
help from FES.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 04:06 PM
Ralf Corsepius
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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 efficient to open one FESCo and one FES ticket to
> get dependent packages rebuild than to open several Bugzilla tickets for
> each dependent package. If the respective maintainer can perform the
> rebuilds all by himself, then there is off course no need to ask for
> help from FES.

Does the word "bureaucracy" ring a bell to you?

You to me sound like a the proverbial German "Finanzbeamter" (tax
officer), who wonders why people are sick of filling out forms.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 09:18 PM
Stephen John Smoogen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

On Fri, Sep 23, 2011 at 14:31, Doug Ledford <dledford@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 continue.
>
> Am I right in saying that AutoQA is basically mired in the muck and going nowhere at the moment?
>

Doug,

= If Autoqa is currently slow it is mainly because what developers who
are working on it are also tasked with doing other things. How long
did it take for autoqa to show up inside of RH? I know it was started
in part by Wanger in 97-98 and reimplemented multiple times never
getting very far because who ever was writing it would be told that
qa'ing what is out there now was the high priority task. If you have
extra time because kernel.org is down, here are some places to look at
what is going on, where you can help.

There is a list here which shows what autoqa is doing per day:
https://fedorahosted.org/pipermail/autoqa-results/

Development is here
https://fedorahosted.org/mailman/listinfo/autoqa-devel

Here is the main webpage on autoqa
http://fedoraproject.org/wiki/AutoQA


--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2011, 04:07 PM
Adam Williamson
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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 right in saying that AutoQA is basically mired in the muck and going nowhere at the moment?

"at the moment", yes, but that's with a very narrow scope of "at the
moment" - i.e. for the last few weeks. I don't want Kamil's email to
give the impression that AutoQA has been going nowhere for months,
because that certainly isn't the case. Work has slowed down in the last
few weeks because Fedora 16 Beta testing was extremely problematic and
sucked up most of the AutoQA manpower, and QA is anyway undermanned
(from a Red Hat paid staff viewpoint) ATM. It should speed up again to a
lesser degree now, and to a greater degree when Final is done and we
have a couple more bodies in place.

I think adding some more rpmdiff-type tests to current AutoQA wouldn't
actually be a huge stretch, but I'd bow to Tim or Kamil on the detail
front there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net


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

Thread Tools




All times are GMT. The time now is 04:36 PM.

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