Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   Fedora 13 has been branched!! (http://www.linux-archive.org/fedora-development/327325-fedora-13-has-been-branched.html)

Jesse Keating 02-17-2010 03:10 AM

Fedora 13 has been branched!!
 
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
that we wrote about:
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases

The real take away here is explained at
https://fedoraproject.org/wiki/Branch_Freeze_Policy

The upshot is that if you want to get a build into Fedora 13, you gotta
build from F-13/ and you gotta put it in bodhi. The good news is that
if your package isn't critical path, it's just like any other update in
bodhi, you decide when it goes stable. If it's critical path, releng or
QA will have to give it karma, but that means somebody will look at it!
(We're working on ways to make it more visible to the user that your
package is critical path).

There are new paths on the mirrors too:

pub/fedora/linux/development/rawhide <-- this is the new home of
rawhide. Builds from devel/ go here. This is now the F-14 development
ground.

pub/fedora/linux/development/13 <-- this is the branched Fedora 13.
Builds from F-13/ that make it through bodhi as stable show up here.
This is what we'll use to make the Alpha, Beta, Final release and all
the snapshots in between and the nightly attempt at instllable images.

pub/fedora/linux/updates/testing/13 <-- this is where the testing
updates go for the branched 13. Test 'em here before they go to stable.

For a better picture, see
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Tree.2FRepo_Overvi ew

I have disabled the rsync part of the rawhide compose process so that I
can do things by hand tomorrow and ensure we don't screw up the mirrors,
so you'll see a delay in things. We'll also do the branched tree
compose by hand as well and then sync the output at the same time to
preserve hardlinks. It'll be a fun day! Hop by #fedora-devel if you've
got questions and somebody will try to help you.

Welcome to the world of No Frozen Rawhide!!!

--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Mamoru Tasaka 02-17-2010 03:27 AM

Fedora 13 has been branched!!
 
Jesse Keating wrote, at 02/17/2010 01:10 PM +9:00:
> That's right folks, we are now branched for Fedora 13. What does this
> mean to you? Well that depends on who "you" are, here are some "you"s
> that we wrote about:
> https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases

>From me currently two questions.

A. How does this affect http://koji.fedoraproject.org/static-repos/ ?
B. As other person already asked, will daily "rawhide changes" report
(containing broken deps) be reported also for F-13 to devel list,
or just changes for F-14 only will be reported (i.e. daily broken
deps report will no longer be available for F-13)?

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

Jesse Keating 02-17-2010 03:31 AM

Fedora 13 has been branched!!
 
On Wed, 2010-02-17 at 13:27 +0900, Mamoru Tasaka wrote:
>
> A. How does this affect http://koji.fedoraproject.org/static-repos/ ?

static-repos will act as it normally does for a released Fedora. The
repo seen is what is in the buildroot, which is what is tagged for
release, and anything we've tagged "override" to make it available in
the buildroot for further builds.

There is one small wrinkle. I've "broken" the dist-rawhide static repo,
because I've made dist-rawhide a real build target to be used by builds
from devel/. I'll be making a symlink soon that will keep
"dist-rawhide" static repos pointed to the right location.

> B. As other person already asked, will daily "rawhide changes" report
> (containing broken deps) be reported also for F-13 to devel list,
> or just changes for F-14 only will be reported (i.e. daily broken
> deps report will no longer be available for F-13)?
>

There will be a Rawhide Report and a Branched Report. Rawhide will be
F-14 now, Branched is F-13. There will also be Fedora 13 Updates
Testing announcements over on the test list.


--
Jesse Keating
Fedora -- Freedomē is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Ralf Corsepius 02-17-2010 03:45 AM

Fedora 13 has been branched!!
 
On 02/17/2010 05:10 AM, Jesse Keating wrote:
> That's right folks, we are now branched for Fedora 13. What does this
> mean to you? Well that depends on who "you" are, here are some "you"s
> that we wrote about:
> https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
>
> The real take away here is explained at
> https://fedoraproject.org/wiki/Branch_Freeze_Policy
>
> The upshot is that if you want to get a build into Fedora 13, you gotta
> build from F-13/ and you gotta put it in bodhi. The good news is that
> if your package isn't critical path, it's just like any other update in
> bodhi, you decide when it goes stable. If it's critical path, releng or
> QA will have to give it karma, but that means somebody will look at it!
> (We're working on ways to make it more visible to the user that your
> package is critical path).
>
> There are new paths on the mirrors too:
>
> pub/fedora/linux/development/rawhide<-- this is the new home of
> rawhide. Builds from devel/ go here. This is now the F-14 development
> ground.
>
> pub/fedora/linux/development/13<-- this is the branched Fedora 13.
> Builds from F-13/ that make it through bodhi as stable show up here.
> This is what we'll use to make the Alpha, Beta, Final release and all
> the snapshots in between and the nightly attempt at instllable images.
>
> pub/fedora/linux/updates/testing/13<-- this is where the testing
> updates go for the branched 13. Test 'em here before they go to stable.
>
> For a better picture, see
> https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Tree.2FRepo_Overvi ew
>
> I have disabled the rsync part of the rawhide compose process so that I
> can do things by hand tomorrow and ensure we don't screw up the mirrors,
> so you'll see a delay in things. We'll also do the branched tree
> compose by hand as well and then sync the output at the same time to
> preserve hardlinks. It'll be a fun day! Hop by #fedora-devel if you've
> got questions and somebody will try to help you.
>
> Welcome to the world of No Frozen Rawhide!!!

Am I correct in assuming, wcorresponding mock setups for and yum
mirrorlists reflecting this new setup will be in place in time when
these repos go on-line?

Ralf

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

Frank Murphy 02-17-2010 07:26 AM

Fedora 13 has been branched!!
 
On 17/02/10 04:31, Jesse Keating wrote:
--snipped--
>>
>
> There will be a Rawhide Report and a Branched Report. Rawhide will be
> F-14 now, Branched is F-13. There will also be Fedora 13 Updates
> Testing announcements over on the test list.
>
>
>

When will there be a "branched.repo" config for testers.
So they won't be getting "rawhide.repo".
It that's what they want
eed.


--
Regards,

Frank Murphy
UTF_8 Encoded
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Christoph Wickert 02-17-2010 08:04 AM

Fedora 13 has been branched!!
 
Am Dienstag, den 16.02.2010, 20:31 -0800 schrieb Jesse Keating:
>
> static-repos will act as it normally does for a released Fedora. The
> repo seen is what is in the buildroot, which is what is tagged for
> release, and anything we've tagged "override" to make it available in
> the buildroot for further builds.

This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g. we only have 8 days to build one of the
pre-releases.

When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
everything due to the long dependency chain that required a lot of
overrides from rel-eng [2].

This means that large updates like Gnome, KDE or Xfce will get massively
delayed after alpha. They might not make it into one of the prereleases,
which means they get less testing. A lot of features will no longer be
possible in their current state.

How do we address this issue?

Regards,
Christoph

[1] https://fedoraproject.org/wiki/Features/Xfce48#Detailed_Description
[2] https://fedorahosted.org/rel-eng/ticket/1429


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

Michal Schmidt 02-17-2010 08:34 AM

Fedora 13 has been branched!!
 
On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
> This means that chainbuilds are no longer possible and this slows
> development down dramatically. Think of a feature like Xfce 4.8 with
> it's tight schedule [1]. E.g. we only have 8 days to build one of the
> pre-releases.
>
> When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
> everything due to the long dependency chain that required a lot of
> overrides from rel-eng [2].
>
> This means that large updates like Gnome, KDE or Xfce will get
> massively delayed after alpha. They might not make it into one of the
> prereleases, which means they get less testing. A lot of features
> will no longer be possible in their current state.
>
> How do we address this issue?

Would it help to use a special Koji tag for this?
Let's say you'd get a tag 'dist-f13-xfce48' where all packages built
there would be immediately available for building dependend packages.
And then when you're done, you'd ask rel-eng to tag them all at once
into 'dist-f13-updates-candidate'.

Jesse, does it make sense?

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

Christoph Wickert 02-17-2010 08:44 AM

Fedora 13 has been branched!!
 
Am Mittwoch, den 17.02.2010, 10:34 +0100 schrieb Michal Schmidt:
> On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
> > This means that chainbuilds are no longer possible and this slows
> > development down dramatically. Think of a feature like Xfce 4.8 with
> > it's tight schedule [1]. E.g. we only have 8 days to build one of the
> > pre-releases.
> >
> > When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
> > everything due to the long dependency chain that required a lot of
> > overrides from rel-eng [2].
> >
> > This means that large updates like Gnome, KDE or Xfce will get
> > massively delayed after alpha. They might not make it into one of the
> > prereleases, which means they get less testing. A lot of features
> > will no longer be possible in their current state.
> >
> > How do we address this issue?
>
> Would it help to use a special Koji tag for this?

We were planning to do this with a custom tag anyway, but I'm not sure
if this also affects whether they go straight into the repos or not.

And what about the updates that don't have a custom tag?

Regards,
Christoph

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

Till Maas 02-17-2010 10:18 AM

Fedora 13 has been branched!!
 
On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:

> And what about the updates that don't have a custom tag?

If the update is big enough, that a lot of packages require a rebuild,
using a custom tag seems to be the best approach, so if there is none,
ask of it. If there is no need for one, then the buildroot overwrite
approach seems to be good enough. Or what is the specific problem you
are seeing?

The advantage of using a custom tag is also, that it does not touch the
buildroots of all packages and therefore makes it possible to still push
updates for the affected dependent packages, if they are required to fix
a bug. Afaik currently kde does not use a custom tag, and therefore if
one wants to update a kde/qt dependent package, it would be build with
a incompatible kde/qt version and therefore cannot be pushed to stable.

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

Christoph Wickert 02-17-2010 12:23 PM

Fedora 13 has been branched!!
 
Am Mittwoch, den 17.02.2010, 12:18 +0100 schrieb Till Maas:
> On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:
>
> > And what about the updates that don't have a custom tag?
>
> If the update is big enough, that a lot of packages require a rebuild,
> using a custom tag seems to be the best approach, so if there is none,
> ask of it. If there is no need for one, then the buildroot overwrite
> approach seems to be good enough. Or what is the specific problem you
> are seeing?

Both approaches have their ups and downs, but both slow down
development:
* Asking rel-eng for overwrites takes time.
* Asking rel-eng for a tag takes some time too. And I'm afraid
that with an inflationary number of tags things get unclear for
other maintainers. They don't know what to build their packages
against or when to use which tag. It requires a lot of
coordination between the different parties.

> The advantage of using a custom tag is also, that it does not touch the
> buildroots of all packages and therefore makes it possible to still push
> updates for the affected dependent packages, if they are required to fix
> a bug.

The major advantage of a custom tag for me is that we have a consistency
plan. If something goes wrong, we can just throw away all these builds
and turn back to a previous state without downgrading packages and
introducing epochs.

So we both agree about the advantages of custom tags, but we are talking
about the development versions here and not about stable releases. In
the branches that are under development we would not do a bugfix against
the "stable" tag. Instead, all updates are supposed to target
development. If we really needed a bugfix in a development branch, this
could easily be done with early branching.

> Afaik currently kde does not use a custom tag, and therefore if
> one wants to update a kde/qt dependent package, it would be build with
> a incompatible kde/qt version and therefore cannot be pushed to stable.

Again, we are not talking about stable releases. But if someone does
large updates in the stable releases, I agree they should use a custom
tag.

> Regards
> Till

Regards,
Christoph

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


All times are GMT. The time now is 03:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.