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, 03:52 PM
Nils Philippsen
 
Default 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
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-20-2011, 04:00 PM
Nils Philippsen
 
Default 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
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-20-2011, 04:21 PM
Adam Jackson
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
 
Old 09-20-2011, 05:19 PM
Nicolas Mailhot
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
 
Old 09-20-2011, 05:19 PM
Christoph Wickert
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
 
Old 09-20-2011, 05:20 PM
"tim.lauridsen@gmail.com"
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

>> * 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
 
Old 09-20-2011, 05:29 PM
Christoph Wickert
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
 
Old 09-20-2011, 06:11 PM
Panu Matilainen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

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
 
Old 09-20-2011, 06:41 PM
Panu Matilainen
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

On 09/20/2011 09:18 PM, Jesse Keating wrote:
> 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
> forRawhide 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
> (forrawhide) but there is no reason to do a build. Let the build system
> inheritance take care of that.

Oh, I certainly wasn't aware of that. And I would've expected this to
work the other way around (because doing new work in a branch instead of
rawhide just feels wrong to me, but there's obviously a point to doing
it this way), but good to know, thanks.

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

As long as it's rawhide inheriting from branched, that sounds like a
winner to me. Who knows, might even get those test-updates a bit of
additional testing.

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-20-2011, 07:28 PM
Nicolas Chauvet
 
Default Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

2011/9/20 Christoph Wickert <christoph.wickert@googlemail.com>:
> 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.
You missed the point, this process was started 3 weeks away from now
with the help of rdieter since then.

The problem is about this legitimate update that was truncated by some
bodhi ACL weirdness I didn't expected.
https://admin.fedoraproject.org/updates/FEDORA-2011-12320

In others words, I've pushed this ticket to stable but only packages I
actually own was pushed to dist-16, others packages in this tickets
went back to limbo. This unexpected behavior evidently broke
dependencies.
While submitting this update to stable I was even informed that
packages I didn't own was tagged as dist-16. This didn't take into.

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

Thread Tools




All times are GMT. The time now is 09:24 PM.

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