11:36 p.m.
Formatted text and full IRC log here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-apr-16
Please make edits to the wiki if I've mis-characterized an issue or left
something out.
John
== Executive Summary ==
1. Freezing for Test4 tomorrow (17-APR-07)
* f13 to create tag and start signing packages on 17-APR-07
* start of continuous freeze until Fedora 7 goes GOLD
* potential checkins for F8 starting in June (assuming all goes well)
* any builds will have to be brought to rel-eng(a)fedoraproject.org
before it'll get included in:
a. Rawhide
a. the final release.
* Eventually need documentation surrounding the freeze and distro
build process
1. Merge of extras and core
* will not delay F7
* will most likely not be completed until after F7
* held up because of equipment needed in the colo
* post-merge some packages will need to be rebuilt to pick up deps
that used to be in Extras
1. In the future we should consider a mass rebuild of all packages
around, but no later than test2
1. Still working on increasing build capacity
1. Discussion of Features
* incomplete features at this stage of the release will be dropped
* incomplete features will not block the release
* poelcat will go ping feature owners and update the wiki
* Unclear whether codecbuddy is in or out: controversy over whether
it should block the release or not
* Known feature which are OUT: boot/shutdown, customdistro (as
written) fix wakeups, newinit, syslogng, texlive
* Known feature which are IN: fast-user-switching, fds, everything,
kde, prime, targeted spins, firewire, libata, livecd, nouveau, rpm/yum,
wireless, tickless, pungi, firmware, smolt
1. wwoods reported on the state of the trees + discussion of important
areas needing testing
* looking pretty solid
* most concerned about the pata/libata changeover
* concerns about iwlwifi and e1000 changes
* upgrade testing from FC6 and FC5
* automated testing is being conducted using KATE
* SNAKE scheduled for release around May 3
* Friday is a kernel bug triaging day
* bad mkinitrd bug which hoses scsi *BZ 220470
1. wwoods will write the test4 announcement which will include known
problems, newly added features, and upgrade issues
1. Blocker bugs
* Blocker bugs are best effort; not *all* blocker bugs must be
fixed to go GA
* Blocker bug criteria:
http://fedoraproject.org/wiki/QA/ReleaseCriteria
* F7 blocker bug
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=150226 is
the big blocker for FC7
* F7T4 blocker bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=F7Test4
1. Potential schedule slips
* none known at this time
1. Open discussion
* cdrkit
* need to decide what to do with it
* Extras vs. Core and when to merge
* wwoods "I got confirmation from the bluez maintainer that the
firmware is freely redistributable (although non-modifiable), just like
the intel firmware"
1. Next Release Engineering Meeting
* Thursday 19-APR-07 at 18:00 UTC (14:00 EDT)
* Coordination of sub-groups
* Test4 status
* When should we branch for F8?
11:58 p.m.
1. In the future we should consider a mass rebuild of all packages
around, but no later than test2
Hmmm, this was discussed in depth at the end of this thread:
https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html
Some people would like to see a mass rebuild, some others are against it.
I'm one of those against it. Reasons:
- Seems we have quite some users in country were internet bandwidth is
unreliable and costly. If we mass-rebuild everything each time those
users have to download a lot of new stuff where nothing changed besides
the release. that makes Fedora harder to use for them.
- the update process gets much longer for each and everyone of us if
each package has to be downloaded and updated.
- the packages out in the wild are tested and known to work. Rebuild
packages have to proof again that everything is fine (which should be
the case most of the time, but in rare cases isn't)
IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth
the trouble we create for our users. I think a mass rebuild now and then
when the toolchain (things like gcc or other crucial stuff like rpm,
python,...) changed massively (round about probably every second or
third release cycle) is more then enough.
CU
thl
12:48 a.m.
On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
> 1. In the future we should consider a mass rebuild of all
packages
> around, but no later than test2
Hmmm, this was discussed in depth at the end of this thread:
https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html
Some people would like to see a mass rebuild, some others are against it.
I'm one of those against it. Reasons:
- Seems we have quite some users in country were internet bandwidth is
unreliable and costly. If we mass-rebuild everything each time those
users have to download a lot of new stuff where nothing changed besides
the release. that makes Fedora harder to use for them.
And these users are running rawhide ?
- the update process gets much longer for each and everyone of us if
each package has to be downloaded and updated.
- the packages out in the wild are tested and known to work. Rebuild
packages have to proof again that everything is fine (which should be
the case most of the time, but in rare cases isn't)
IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth
the trouble we create for our users. I think a mass rebuild now and then
when the toolchain (things like gcc or other crucial stuff like rpm,
python,...) changed massively (round about probably every second or
third release cycle) is more then enough.
Yeah, I'll agree with that.
Off the top of my head, I can come up with three scenarios where
rebuilds make sense.
- Considerable bugfixes which fix up bad code generation.
- new/enhanced features (such as more FORTIFY_SOURCE improvements)
- new optimisations
(We could even narrow the scope on this one to rebuild just
packages that would show a notable difference. Ie, don't
bother rebuilding fileutils, but do rebuild say, bzip2).
Taking a look at the packages in my f7 mirror, I spot 52 packages
that still have a .fc6 tag, none of which look particularly
"omg, we have to rebuild this". There are also 713 with no %{dist} tag
which include some which we definitly have rebuilt, so it's harder
to figure out which of those got updated and which didn't.
Dave
--
http://www.codemonkey.org.uk
1:22 a.m.
On 17.04.2007 07:48, Dave Jones wrote:
On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
> > 1. In the future we should consider a mass rebuild of all packages
> > around, but no later than test2
> Hmmm, this was discussed in depth at the end of this thread:
> https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html
> Some people would like to see a mass rebuild, some others are against it.
>
> I'm one of those against it. Reasons:
> - Seems we have quite some users in country were internet bandwidth is
> unreliable and costly. If we mass-rebuild everything each time those
> users have to download a lot of new stuff where nothing changed besides
> the release. that makes Fedora harder to use for them.
And these users are running rawhide ?
Probably not, but they will have to download and install the new
packages that got build during the mass-rebuild when they do the Fedora
(x) -> Fedora (x+1 or x+2) update. Currently packages where nothing
changed in between simply stay installed and no action is needed.
> - the update process gets much longer for each and everyone of
us if
> each package has to be downloaded and updated.
> - the packages out in the wild are tested and known to work. Rebuild
> packages have to proof again that everything is fine (which should be
> the case most of the time, but in rare cases isn't)
>
> IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth
> the trouble we create for our users. I think a mass rebuild now and then
> when the toolchain (things like gcc or other crucial stuff like rpm,
> python,...) changed massively (round about probably every second or
> third release cycle) is more then enough.
Yeah, I'll agree with that.
Off the top of my head, I can come up with three scenarios where
rebuilds make sense.
- Considerable bugfixes which fix up bad code generation.
- new/enhanced features (such as more FORTIFY_SOURCE improvements)
- new optimisations
(We could even narrow the scope on this one to rebuild just
packages that would show a notable difference. Ie, don't
bother rebuilding fileutils, but do rebuild say, bzip2).
+1
Taking a look at the packages in my f7 mirror, I spot 52 packages
that still have a .fc6 tag, none of which look particularly
"omg, we have to rebuild this". There are also 713 with no %{dist} tag
which include some which we definitly have rebuilt, so it's harder
to figure out which of those got updated and which didn't.
Some numbers:
$ fc6release=$(date -d "24 Oct 2006" +%s); sudo repoquery
--repoid=development-source --repoid=extras-development-source
--archlist="src" -qa --qf '%{buildtime} %{name}' | sort | while read
date name; do [[ ${date} < ${fc6release} ]] && echo ${date} ${name} ||
break ; done | wc -l
1206
$ sudo repoquery --repoid=development-source
--repoid=extras-development-source --archlist="src" -qa --qf
'%{buildtime} %{name}' | wc -l
4073
$ echo $((4073-1206))
2867
IOW: 1206 out of 4073 source packages were not rebuild in devel (both
core and extras) between release of FC6 and now.
CU
thl
2:42 a.m.
On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote:
On 17.04.2007 07:48, Dave Jones wrote:
>On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
> > > 1. In the future we should consider a mass rebuild of all packages
> > > around, but no later than test2
>Taking a look at the packages in my f7 mirror, I spot 52
packages
>that still have a .fc6 tag, none of which look particularly
>"omg, we have to rebuild this". There are also 713 with no %{dist} tag
>which include some which we definitly have rebuilt, so it's harder
>to figure out which of those got updated and which didn't.
Some numbers:
$ echo $((4073-1206))
2867
IOW: 1206 out of 4073 source packages were not rebuild in devel (both
core and extras) between release of FC6 and now.
But that's by choice and now what the usual Fedora policy was until
now. Here is the historical data, that shows that we've been doing
effectively full rebuilds ever until now.
On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote:
Here are the numbers of the amount of Core packages rebuilt per
release. FC1 gets 100% because I don't have the RHL9 packages handy,
but anyway (for > 99% I added as many digits as neccessary to show
what wasn't rebuilt):
1 100%
2 99.7%
3 100%
4 96.6%
5 99.991%
6 95%
7 80%
So as you see, up to F7 Core had really been effectively rebuilt on
each release with FC4 and FC5 being the most "sloppy" ones leaving
3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80%
rebuild
rate. This *is* a new release model.
--
Axel.Thimm at ATrpms.net
3:14 a.m.
On 17.04.2007 09:42, Axel Thimm wrote:
On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote:
> On 17.04.2007 07:48, Dave Jones wrote:
>> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
>>>> 1. In the future we should consider a mass rebuild of all packages
>>>> around, but no later than test2
>> Taking a look at the packages in my f7 mirror, I spot 52 packages
>> that still have a .fc6 tag, none of which look particularly
>> "omg, we have to rebuild this". There are also 713 with no %{dist}
tag
>> which include some which we definitly have rebuilt, so it's harder
>> to figure out which of those got updated and which didn't.
> Some numbers:
> $ echo $((4073-1206))
> 2867
> IOW: 1206 out of 4073 source packages were not rebuild in devel (both
> core and extras) between release of FC6 and now.
But that's by choice and now what the usual Fedora policy was until
now.
There is no "policy" afaik. The maintainer simply decided what to do if
no mass-rebuild was announced. There were for example mass rebuilds
performed in FC6 and FE6.
Here is the historical data, that shows that we've been doing
effectively full rebuilds ever until now. [...]
Just a heads up for the readers (as it's not obvious in the first
sight): The data from Axel is for Core only afaics, my data included Extras.
CU
thl
3:35 a.m.
On Tue, Apr 17, 2007 at 10:14:15AM +0200, Thorsten Leemhuis wrote:
On 17.04.2007 09:42, Axel Thimm wrote:
>On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote:
>>On 17.04.2007 07:48, Dave Jones wrote:
>>>On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
>>>>> 1. In the future we should consider a mass rebuild of all packages
>>>>>around, but no later than test2
>>>Taking a look at the packages in my f7 mirror, I spot 52 packages
>>>that still have a .fc6 tag, none of which look particularly
>>>"omg, we have to rebuild this". There are also 713 with no %{dist}
tag
>>>which include some which we definitly have rebuilt, so it's harder
>>>to figure out which of those got updated and which didn't.
>>Some numbers:
>>$ echo $((4073-1206))
>>2867
>>IOW: 1206 out of 4073 source packages were not rebuild in devel (both
>>core and extras) between release of FC6 and now.
>
>But that's by choice and now what the usual Fedora policy was until
>now.
There is no "policy" afaik. The maintainer simply decided what to do if
no mass-rebuild was announced. There were for example mass rebuilds
performed in FC6 and FE6.
Well, let's not play with wording, the numbers speak for themselves:
In the history of Fedora until F7 both FC and FE did effectively full
rebuilds.
>Here is the historical data, that shows that we've been
doing
>effectively full rebuilds ever until now.
On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote:
> Here are the numbers of the amount of Core packages rebuilt per
> release. FC1 gets 100% because I don't have the RHL9 packages handy,
> but anyway (for > 99% I added as many digits as neccessary to show
> what wasn't rebuilt):
>
> 1 100%
> 2 99.7%
> 3 100%
> 4 96.6%
> 5 99.991%
> 6 95%
> 7 80%
>
> So as you see, up to F7 Core had really been effectively rebuilt on
> each release with FC4 and FC5 being the most "sloppy" ones leaving
> 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80%
> rebuild
> rate. This *is* a new release model.
Just a heads up for the readers (as it's not obvious in the first
sight): The data from Axel is for Core only afaics, my data included Extras.
Well, I can include Extras, too, the data above was from a mail to
Jesse when it was about Core. For Extras the numbers are far more
striking, here is a common table including the FC data:
FC FE
1 100% -
2 99.7% -
3 100% 100%
4 96.6% 99.4%
5 99.991% 99.0%
6 95% 99.4%
7 80% 62%
So Extras was even closer to a complete rebuilds, leaving out 0.6% to
1% of packages at most until FC6 inclusive.
Since FE has more packages the merged full repo will look more like
FE's rebuild rates. But since the CD/DVD spins are made mostly out of
former Core bits the actual rate of bugs found due to non-rebuilds
will be closer to FC's. That's a bit comforting, since FC has seen
some more rebuilds.
We are on new territory with F7, both on the FC and FE side. Let's
prey for the best.
--
Axel.Thimm at ATrpms.net
4:10 a.m.
On 17.04.2007 10:35, Axel Thimm wrote:
[...]
Well, I can include Extras, too, the data above was from a mail to
Jesse when it was about Core. For Extras the numbers are far more
striking, here is a common table including the FC data [...]
Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6]
were released? Otherwise your numbers are IMHO totally misleading, as
they show what got rebuild between release of FC[3-6] and *today*.
CU
thl
4:32 a.m.
On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote:
On 17.04.2007 10:35, Axel Thimm wrote:
>[...]
>Well, I can include Extras, too, the data above was from a mail to
>Jesse when it was about Core. For Extras the numbers are far more
>striking, here is a common table including the FC data [...]
Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6]
were released?
No, do you?
Otherwise your numbers are IMHO totally misleading, as they show
what got rebuild between release of FC[3-6] and *today*.
No, they compare the latest state of FE<N> and the latest state of
FE<N+1>. For FE5 and FE6 for example it compares the latest state as
of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and
today. So there is no time discrepancy as you assume.
And it comes as no suprise since as we all should know FE was always
doing mass rebuilds until including FC6. I wonder how the 0.6% and 1%
were forgotten in the process. Perhaps someone did a rebuild with the
same EVR - we didn't catch these in the old days.
--
Axel.Thimm at ATrpms.net
5:19 a.m.
On 17.04.2007 11:32, Axel Thimm wrote:
On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote:
> On 17.04.2007 10:35, Axel Thimm wrote:
>> [...]
>> Well, I can include Extras, too, the data above was from a mail to
>> Jesse when it was about Core. For Extras the numbers are far more
>> striking, here is a common table including the FC data [...]
> Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6]
> were released?
No, do you?
No, sorry, I don't have any local Extras trees at all.
> Otherwise your numbers are IMHO totally misleading, as they show
> what got rebuild between release of FC[3-6] and *today*.
No, they compare the latest state of FE<N> and the latest state of
FE<N+1>. For FE5 and FE6 for example it compares the latest state as
of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and
today. So there is no time discrepancy as you assume.
Assume package foo-1.0-1.noarch was in FE5 and devel. The FE6 got
branched, so foo was not rebuild during that devel cycle (this is thus a
example of a package we are up to: one that didn't get rebuild during a
devel cycle). Some weeks later foo got a update to foo-1.1-1.noarch; it
got build in both FE5, FE6 and FE-devel. Got a bugfix with
foo-1.1-2.noarch; the old one foo-1.0-1.noarch gets deleted from the
tree then, as we only ship the two latest versions.
So how can your scripts detect now that foo-1.0-1.noarch wasn't rebuild
during the devel-period FE5->FE6 by looking at todays repos?
And it comes as no suprise since as we all should know FE was always
doing mass rebuilds until including FC6. I wonder how the 0.6% and 1%
were forgotten in the process. Perhaps someone did a rebuild with the
same EVR - we didn't catch these in the old days.
We never did full rebuilds. Data-packages never had to be rebuild.
Noarch packages (python, perl) did not have to be rebuild during those
mass rebuilds either iirc (but we adviced to do it when preparing FE6 iirc).
CU
thl
6:05 a.m.
On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote:
>And it comes as no suprise since as we all should know FE was
always
>doing mass rebuilds until including FC6. I wonder how the 0.6% and 1%
>were forgotten in the process. Perhaps someone did a rebuild with the
>same EVR - we didn't catch these in the old days.
We never did full rebuilds. Data-packages never had to be rebuild.
OK, that accounts for the 0.6-1% then. As you know I'm not advocating
rebuilding stuff like firmware that are known to be content-invariant
over time.
--
Axel.Thimm at ATrpms.net
6:31 a.m.
On 17.04.2007 13:05, Axel Thimm wrote:
On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote:
>> And it comes as no suprise since as we all should know FE was always
>> doing mass rebuilds until including FC6. I wonder how the 0.6% and 1%
>> were forgotten in the process. Perhaps someone did a rebuild with the
>> same EVR - we didn't catch these in the old days.
> We never did full rebuilds. Data-packages never had to be rebuild.
OK, that accounts for the 0.6-1% then. [...]
Well, you carefully didn't reply to the part where I explained that you
can't get to a proper number "how many packages weren't rebuild in the
devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are
FUD in my eyes.
I don't have hard numbers either -- but from memory I'd say we didn't
rebuild round about 1/3 of the packages in the FE mass rebuild for FC6.
Some of those not rebuild received updates earlier or later in the devel
cycle. So if I should guess I'd say the number of packages that didn't
get rebuild between FE5 and FE6 was somewhere between 7.5 and 25
percent. Maybe Ville has more data, he did a lot of work back then for
the mass rebuild.
CU
thl
/me will try to resist from this thread now, this doesn't lead to anything
7:10 a.m.
On Tue, Apr 17, 2007 at 01:31:49PM +0200, Thorsten Leemhuis wrote:
On 17.04.2007 13:05, Axel Thimm wrote:
>On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote:
>>>And it comes as no suprise since as we all should know FE was always
>>>doing mass rebuilds until including FC6. I wonder how the 0.6% and 1%
>>>were forgotten in the process. Perhaps someone did a rebuild with the
>>>same EVR - we didn't catch these in the old days.
>>We never did full rebuilds. Data-packages never had to be rebuild.
>OK, that accounts for the 0.6-1% then. [...]
Well, you carefully didn't reply to the part where I explained that you
can't get to a proper number "how many packages weren't rebuild in the
devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are
FUD in my eyes.
Please be careful with using the word FUD. Not everything that doesn't
suit your needs is FUD.
I don't have hard numbers either -- but from memory I'd say
we didn't
rebuild round about 1/3 of the packages in the FE mass rebuild for FC6.
Your memory doesn't serve you well. You even asked for two mass
rebuilds for FC6, one for new rpm signing/sped up dynamic linking/new
minimal buildroots and another "semi-mass rebuild" for fixing the
gdb-backtrace bug for packages build in September. In fact all (but
1%) packages in FE6 got rebuilt at least once.
On Sun, Jan 15, 2006 at 07:59:20PM +0100, Thorsten Leemhuis wrote:
We probably will have to do a rebuild of all (most?) packages in
Fedora Extras before FC5 is released. Why? Some reasons:
On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote:
Now it makes four good reasons to build all Extras packages in devel
before FC6.
On Sat, Dec 09, 2006 at 07:13:16PM +0100, Thorsten Leemhuis wrote:
Yes, we did a lot of mass-rebuilds in for the last releases,
--
Axel.Thimm at ATrpms.net
3:13 a.m.
On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote:
> 1. In the future we should consider a mass rebuild of all packages
>around, but no later than test2
Hmmm, this was discussed in depth at the end of this thread:
https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html
Some people would like to see a mass rebuild, some others are against it.
I'm one of those against it. Reasons:
I'm one of those for it.
- Seems we have quite some users in country were internet bandwidth
is
unreliable and costly. If we mass-rebuild everything each time those
users have to download a lot of new stuff where nothing changed besides
the release. that makes Fedora harder to use for them.
The big players that are always on the user's choicelist are being
rebuilt almost by definition. The savings are therefore marginal at
best.
- the update process gets much longer for each and everyone of us if
each package has to be downloaded and updated.
- the packages out in the wild are tested and known to work. Rebuild
packages have to proof again that everything is fine (which should be
the case most of the time, but in rare cases isn't)
That's a contradiction: Either the packages are stable and will
survive a rebuild, or they are fragile enough to break apart if they
are rebuilt in the current environment. Furthermore the testing these
packages have received was on another release offering a different
build and run-time environment, so they may not be as stable or tested
as you think they are.
The dangers of letting packages go to seed are the following:
o non deterministic package rebuilds: It is not guaranteed that some
package will rebuild and function the same for the current release
(we may have automated rebuild facilities, but no one tests runtime
behaviour), a simple rebuild may unearth that the package needs
further attention (in fact that is Thorsten's argument to not
rebuild, but the attention will be needed, the question is when to
spend the time on it, see below)
o slow security responses: A one-line fix may result to a package
breaking due to the above. This means that security issues may start
shipping broken packages out, or may require more time in QA to
ensure that an ancient-not-rebuilt package really properly works.
o The choice of what to rebuild or not requires more developer time
than fixing broken rebuilds: Currently some heuristics were uses to
cherry-pick what to rebuild. This requires a careful examination
that if doen properly consumes as much or more developer time than
to fix any broken rebuilds. If not done careful, then some
dependencies will be missed. For example the current upgrade sees
the following changes in the buildtools
FC6 F7
gcc 4.1.1-30 4.1.2-8
glibc 2.5-3 2.5.90-20
binutils 2.17.50.0.3-6 2.17.50.0.12-3
Perhaps the gcc or binutils changes are not that big, but the glibc
ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking
the API (the glibc-headers) gives:
41 files changed, 297 insertions(+), 220 deletions(-)
Other examples are packages (like bridge-utils) being built against
kernel-headers. F7 is now shipping a bridge-utils that was built
agains 2.6.18 kernel headers at the very beginning of the FC6
cycle. The questions that come up are: Did anyone check whether the
bridging interface of the kernel changed between 2.6.18-21? Were any
interfaces deprecated? Will bridge-utils work on F7, if not will a
rebuild suffice?
I've picked bridge-utils as an example as it was the first package
that looked suspicious when I looked at an alphabetical list, that
doesn't mean that bridge-utils is now broken. Still the questions
raised are valid for any package depending on kernel-headers.
o Moving bugs from development cycle to maintenance cycle: Effectively
the argument for not rebuilding during development time and breaking
N fragile packages means that once these N broken packages are
spotted after the release they will need the developer's attention
just the same. We are only moving the bugs from the devlopment cycle
to mainenance. Do we really want that? From a technical and
*marketing* POV we don't. It is better to ship a good release from
the start, than to stumble over rebuild bugs over and over
again, and that includes both deelopers and now users. And from a
*business* POV the resources that are spent are the same, someone
must fix the packages. So let's do it during the development cycle
instead of during maintenance where the users will feel like guinea
pigs.
In a nutshell: There are no significant savings in user downloads, and
there are no savings in developer resources when not rebuilding
packages to match the upcoming release environment. But there is bad
publicity if packages will break after the release and this could had
been prevented with a simple mass rebuild during devlopment time
instead of outsourcing this to the maintenance cycle.
--
Axel.Thimm at ATrpms.net
6 a.m.
On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote:
o The choice of what to rebuild or not requires more developer time
than fixing broken rebuilds: Currently some heuristics were uses to
cherry-pick what to rebuild. This requires a careful examination
that if doen properly consumes as much or more developer time than
to fix any broken rebuilds. If not done careful, then some
dependencies will be missed. For example the current upgrade sees
the following changes in the buildtools
FC6 F7
gcc 4.1.1-30 4.1.2-8
glibc 2.5-3 2.5.90-20
binutils 2.17.50.0.3-6 2.17.50.0.12-3
Perhaps the gcc or binutils changes are not that big, but the glibc
ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking
the API (the glibc-headers) gives:
41 files changed, 297 insertions(+), 220 deletions(-)
Even the glibc changes in F7 are mostly glibc internal changes, bugfixes
and addition of a few new symbols (epoll_wait, sync_file_range,
strerror_l, __sched_cpucount) and only on PPC a new version for existing
symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc
changes necessitate a mass rebuild (and I'm not aware of any huge changes
in redhat-rpm-config either) at this time and that's why F7 rebuild status
is so low. GCC 4.2 has been stagnating for 6 months now and we have
several important things backported anyway in GCC 4.1.x-RH (OpenMP,
visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
...). If gcc, binutils or glibc changes substantially in say F8, we'll
of course need to do a mass rebuild.
I'd note that sometimes it makes sense to rebuild all packages, including
noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config
etc. changes that affect all packages.
Jakub
6:46 a.m.
On Tuesday 17 April 2007 07:00:39 Jakub Jelinek wrote:
Even the glibc changes in F7 are mostly glibc internal changes,
bugfixes
and addition of a few new symbols (epoll_wait, sync_file_range,
strerror_l, __sched_cpucount) and only on PPC a new version for existing
symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc
changes necessitate a mass rebuild (and I'm not aware of any huge changes
in redhat-rpm-config either) at this time and that's why F7 rebuild status
is so low. GCC 4.2 has been stagnating for 6 months now and we have
several important things backported anyway in GCC 4.1.x-RH (OpenMP,
visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
...). If gcc, binutils or glibc changes substantially in say F8, we'll
of course need to do a mass rebuild.
I'd note that sometimes it makes sense to rebuild all packages, including
noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config
etc. changes that affect all packages.
Thanks Jakub. This is exactly why we didn't rebuild this session. We weren't
guessing that there wasn't any changes, we talked to the right people to
CONFIRM there wasn't any changes. Let me repeat, I'm all for rebuilding for
technical reasons. I'm not for rebuilding when we _think_ there _might_ be a
reason.
--
Jesse Keating
Release Engineer: Fedora
6:56 a.m.
On Tue, Apr 17, 2007 at 07:00:39AM -0400, Jakub Jelinek wrote:
On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote:
> o The choice of what to rebuild or not requires more developer time
> than fixing broken rebuilds: Currently some heuristics were uses to
> cherry-pick what to rebuild. This requires a careful examination
> that if doen properly consumes as much or more developer time than
> to fix any broken rebuilds. If not done careful, then some
> dependencies will be missed. For example the current upgrade sees
> the following changes in the buildtools
>
> FC6 F7
> gcc 4.1.1-30 4.1.2-8
> glibc 2.5-3 2.5.90-20
> binutils 2.17.50.0.3-6 2.17.50.0.12-3
>
> Perhaps the gcc or binutils changes are not that big, but the glibc
> ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking
> the API (the glibc-headers) gives:
>
> 41 files changed, 297 insertions(+), 220 deletions(-)
Even the glibc changes in F7 are mostly glibc internal changes, bugfixes
and addition of a few new symbols (epoll_wait, sync_file_range,
strerror_l, __sched_cpucount) and only on PPC a new version for existing
symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc
changes necessitate a mass rebuild (and I'm not aware of any huge changes
in redhat-rpm-config either) at this time and that's why F7 rebuild status
is so low. GCC 4.2 has been stagnating for 6 months now and we have
several important things backported anyway in GCC 4.1.x-RH (OpenMP,
visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
...).
When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier?
If gcc, binutils or glibc changes substantially in say F8, we'll
of course need to do a mass rebuild.
gcc should finally have made it to 4.2 by then.
I'd note that sometimes it makes sense to rebuild all packages,
including
noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config
etc. changes that affect all packages.
--
Axel.Thimm at ATrpms.net
7:34 a.m.
On Tue, Apr 17, 2007 at 01:56:51PM +0200, Axel Thimm wrote:
> Even the glibc changes in F7 are mostly glibc internal changes,
bugfixes
> and addition of a few new symbols (epoll_wait, sync_file_range,
> strerror_l, __sched_cpucount) and only on PPC a new version for existing
> symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc
> changes necessitate a mass rebuild (and I'm not aware of any huge changes
> in redhat-rpm-config either) at this time and that's why F7 rebuild status
> is so low. GCC 4.2 has been stagnating for 6 months now and we have
> several important things backported anyway in GCC 4.1.x-RH (OpenMP,
> visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
> ...).
When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier?
Java stack rebase is in F7+ only, OpenMP/visibility stuff/most of Fortran
improvements were already in FC6. Bug fixes are obviously continuously
coming, be it from upstream gcc-4_1-branch or backports of fixes from GCC
trunk or gcc-4_2-branch.
> If gcc, binutils or glibc changes substantially in say F8,
we'll
> of course need to do a mass rebuild.
gcc should finally have made it to 4.2 by then.
Except it is unclear whether 4.2 is a win, while it has some advantages,
it has also pretty significant drop in performance of compiled code (due to
quick aliasing fixes), which is really fixed without performance degradation
only in 4.3+. While this is not so severe for upstream 4.2 which compares
to vanilla 4.1, as redhat/gcc-4_1-branch contains e.g. the i?86/x86_64 CPU
tuning improvements (-mtune=generic, -m{arch,tune}={core2,amdfam10,geode}),
when comparing redhat/gcc-4_1-branch to gcc-4_2-branch this is more visible.
4.3 has a lot of other goodies we are looking for, but we can't predict ATM
how long will it take till 4.3 release, if it will stagnate the same way as
4.2 is or not. 4.2 actual development stages weren't terribly long, but
after branching it has been 6 months with little activity, bugfixing where
significant portion of the bugfixes went also to gcc-4_1-branch.
Jakub
3 a.m.
On Mon, Apr 16, 2007 at 09:36:50PM -0700, John Poelstra wrote:
* Known feature which are IN: fast-user-switching,
1. wwoods reported on the state of the trees + discussion of important
areas needing testing
Other display managers than gdm don't set the 'authentication' needed
for consolekit, thus hal is unusable in those cases. It is problematic
for wdm, although I guess the user base is not that big, but it is
very annoying for xdm and kdm. The relevant bugs block FC7 Blocker
Tracker. I don't clearly know what is the right thing to do, but a
decision should be explicitely made and documented at least in the
release notes.
--
Pat
6268
days inactive
6268
days old
18 comments
7 participants
participants (7)
-
Axel Thimm -
Dave Jones -
Jakub Jelinek -
Jesse Keating -
John Poelstra -
Patrice Dumas -
Thorsten Leemhuis