10:30 a.m.
An update has been submitted for systemd today:
https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21
with a fairly short description. I wanted to flag up that, in fact,
systemd-216-9 is a major change from systemd-216-8 and is not really
systemd 216 at all.
systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less
identical to upstream systemd-stable 216:
http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable .
systemd "216-9" is not built from 216 at all, it is in fact systemd-217
with some particular changes (presumably intended to be the most
disruptive ones) reverted. When I dropped build-related files and
directories and documentation from the trees, did a context-free
recursive diff, and filtered out the metadata from the diff, it still
worked out at >7,000 lines worth of additions and removals between the
underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a lot of
change to land between Beta and Final.
Testers, please take care to test the update thoroughly, despite the
small bump and small description it is a major change to the package.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:37 a.m.
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
systemd "216-9" is not built from 216 at all, it is in fact
systemd-217
Why the misleading version number?
--
Tomasz Torcz "Never underestimate the bandwidth of a station
xmpp: zdzichubg(a)chrome.pl wagon filled with backup tapes." -- Jim Gray
10:41 a.m.
Hi
On Tue, Nov 4, 2014 at 11:37 AM, Tomasz Torcz wrote:
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> systemd "216-9" is not built from 216 at all, it is in fact systemd-217
Why the misleading version number?
More importantly, why is this pushed so late in the release cycle?
Rahul
10:56 a.m.
On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote:
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> systemd "216-9" is not built from 216 at all, it is in fact systemd-217
Why the misleading version number?
There is a comment in the spec:
# This is really closer to 217 than to 216, and it is easier to revert a few
# patches then to carry all the other patches after 216.
and a changelog note:
- Pull more changes from upstream, including post-217 bugfixes. This
is now a bastard mix of systemd-216 and systemd-217, with some of
the important changes in systemd 217 still reverted:
readahead removal, timedatectl change, fq_codel as default,
job timeouts for init and poweroff, multi-seat-x removal,
coredumps from watchdog timeouts.
For the record, systemd-216-8 had ~588 patches.
I think the intent is that 216-8 and 216-9 be more or less the same
codebase but arrived at in different ways, but in practice there seems
to be a noticeable difference.
The diff I came up with is:
https://www.happyassassin.net/temp/systemd-2168-2169.diff
if anyone wants to check it (that version has context left in).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:20 p.m.
On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote:
On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote:
> On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> > systemd "216-9" is not built from 216 at all, it is in fact
systemd-217
>
> Why the misleading version number?
There is a comment in the spec:
# This is really closer to 217 than to 216, and it is easier to revert a few
# patches then to carry all the other patches after 216.
and a changelog note:
- Pull more changes from upstream, including post-217 bugfixes. This
is now a bastard mix of systemd-216 and systemd-217, with some of
the important changes in systemd 217 still reverted:
readahead removal, timedatectl change, fq_codel as default,
job timeouts for init and poweroff, multi-seat-x removal,
coredumps from watchdog timeouts.
For the record, systemd-216-8 had ~588 patches.
I think the intent is that 216-8 and 216-9 be more or less the same
codebase but arrived at in different ways, but in practice there seems
to be a noticeable difference.
The diff I came up with is:
https://www.happyassassin.net/temp/systemd-2168-2169.diff
This diffs autogenerated
content.
It also contains a rename of functions to add mac_ prefixes to
selinux functions. And a rename to hashmap functions in preparation
of for implementation changes which were done post 217 (and are
not part of this update). It is also done without -M, so catches
some renames as significant changes.
I'm frankly puzzled about the point of this exercise.
Zbyszek
2:48 p.m.
On Tue, 2014-11-04 at 21:20 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote:
> On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote:
> > On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> > > systemd "216-9" is not built from 216 at all, it is in fact
systemd-217
> >
> > Why the misleading version number?
>
> There is a comment in the spec:
>
> # This is really closer to 217 than to 216, and it is easier to revert a few
> # patches then to carry all the other patches after 216.
>
> and a changelog note:
>
> - Pull more changes from upstream, including post-217 bugfixes. This
> is now a bastard mix of systemd-216 and systemd-217, with some of
> the important changes in systemd 217 still reverted:
> readahead removal, timedatectl change, fq_codel as default,
> job timeouts for init and poweroff, multi-seat-x removal,
> coredumps from watchdog timeouts.
>
> For the record, systemd-216-8 had ~588 patches.
>
> I think the intent is that 216-8 and 216-9 be more or less the same
> codebase but arrived at in different ways, but in practice there seems
> to be a noticeable difference.
>
> The diff I came up with is:
>
> https://www.happyassassin.net/temp/systemd-2168-2169.diff
This diffs autogenerated content.
There's a bit of stuff at the top that could have been trimmed out,
sure, but I didn't want to spend *too* much time on it. It's not that
much.
It also contains a rename of functions to add mac_ prefixes to
selinux functions. And a rename to hashmap functions in preparation
of for implementation changes which were done post 217 (and are
not part of this update).
None of which was communicated in the package changelog, or the update
description. And remember, what you just wrote is gobbledegook to most
of the people testing updates, they are not necessarily coders and do
not necessarily know anything about systemd internals. They are folks
volunteering to provide feedback on pre-release updates; even those who
are also Fedora packagers are not necessarily coders, and those who are
coders don't necessarily know systemd's design.
It is also done without -M, so catches
some renames as significant changes.
I'm frankly puzzled about the point of this exercise.
Well, remember, I'm not a specialist. I'm just the QA monkey. I don't
know the detailed ins and outs of every codebase in the distro, QA
doesn't in general, we just try to test the bits. The more information
is available about what those changes actually *are*, communicated in a
style appropriate to the knowledge level of the folks doing the testing,
the better that job is going to get done. I didn't inspect the diff in a
huge degree of detail, I just was interested in how much difference
there actually is between '216 stable plus 500+ patches' (216-5 / 216-8)
and '217 minus some reversions (216-6 / 216-9), so I bashed at the trees
for fifteen minutes trying to figure it out, and it looked like rather
more difference than the update description and package changelog
suggested, so I thought it would be a good idea to communicate that.
Again, one thing that could prevent us having to have this kind of
discussion would be for systemd to have more
sophisticated/heavier/whatever stable release management. The
systemd-stable repo is a definite improvement on the previous approach,
but it's still missing actual *release management*, when you say 'OK,
we're going to release an actual thing that will be called systemd 216.1
and we're going to put all these bits in it and we're going to write
down what those are'.
Right now if someone asks what systemd is in Fedora 21, what do we say?
Well, we can say 'systemd-216 stable' and point to
http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable ,
but then they ask 'what's that?', and what do we say? Where is its
existence described? It's not systemd-216. It's not systemd-217. It
doesn't have a version, it doesn't have a tarball, it doesn't have a
readme, it doesn't have a changelog. The NEWS file says "CHANGES WITH
217:", so it seems dangerous to assume that it accurately describes all
the changes on the 216-stable branch and *only* those changes.
You only really have a hope of understanding what it *is* by reading the
commit log, somehow grokking that it used to be produced by backporting
a ton of changes onto 216 but is now produced by reverting/excluding a
bunch of stuff from 217, and understanding what the things that were
reverted actually *are* and what the implications of their
reversion/exclusion are. And then to answer the original question, you
have to figure out somehow whether there are any downstream-specific
changes in the Fedora package vs. the 216-stable tree and what they are,
when the current maintenance approach means that when we update to a new
checkout of the 216-stable tree we bump the package release but when we
add a downstream specific change we...bump the package release.
One simple change that might help a bit right now is to follow the
Fedora package versioning convention for when your package is built from
SCM snapshots:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
So the systemd package should not just be 'systemd-216-8', or whatever,
but something like:
systemd-216-8.20141104gitaf59039bc
(checkout id entirely invented). That would at least give us an
indicator right in the package version / changelog of when the upstream
checkout got changed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:39 p.m.
On Tue, Nov 04, 2014 at 12:48:36PM -0800, Adam Williamson wrote:
On Tue, 2014-11-04 at 21:20 +0100, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote:
> > On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote:
> > > On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> > > > systemd "216-9" is not built from 216 at all, it is in fact
systemd-217
> > >
> > > Why the misleading version number?
> >
> > There is a comment in the spec:
> >
> > # This is really closer to 217 than to 216, and it is easier to revert a few
> > # patches then to carry all the other patches after 216.
> >
> > and a changelog note:
> >
> > - Pull more changes from upstream, including post-217 bugfixes. This
> > is now a bastard mix of systemd-216 and systemd-217, with some of
> > the important changes in systemd 217 still reverted:
> > readahead removal, timedatectl change, fq_codel as default,
> > job timeouts for init and poweroff, multi-seat-x removal,
> > coredumps from watchdog timeouts.
> >
> > For the record, systemd-216-8 had ~588 patches.
> >
> > I think the intent is that 216-8 and 216-9 be more or less the same
> > codebase but arrived at in different ways, but in practice there seems
> > to be a noticeable difference.
> >
> > The diff I came up with is:
> >
> > https://www.happyassassin.net/temp/systemd-2168-2169.diff
> This diffs autogenerated content.
There's a bit of stuff at the top that could have been trimmed out,
sure, but I didn't want to spend *too* much time on it. It's not that
much.
> It also contains a rename of functions to add mac_ prefixes to
> selinux functions. And a rename to hashmap functions in preparation
> of for implementation changes which were done post 217 (and are
> not part of this update).
None of which was communicated in the package changelog, or the update
description. And remember, what you just wrote is gobbledegook to most
of the people testing updates
Well, it is gobbledegook to everyone, it is a
completely meaningless
internal change. It was done with a sed script, and if the tree still
compiles afterwards, then its OK. It blows up the diff. It also makes it
annoying to backport later patches because of trivial conflicts, which
is why I include it in the update.
, they are not necessarily coders and do
not necessarily know anything about systemd internals. They are folks
volunteering to provide feedback on pre-release updates; even those who
are also Fedora packagers are not necessarily coders, and those who are
coders don't necessarily know systemd's design.
> It is also done without -M, so catches
> some renames as significant changes.
>
> I'm frankly puzzled about the point of this exercise.
Well, remember, I'm not a specialist. I'm just the QA monkey. I don't
know the detailed ins and outs of every codebase in the distro, QA
doesn't in general, we just try to test the bits. The more information
is available about what those changes actually *are*, communicated in a
style appropriate to the knowledge level of the folks doing the testing,
the better that job is going to get done. I didn't inspect the diff in a
huge degree of detail, I just was interested in how much difference
there actually is between '216 stable plus 500+ patches' (216-5 / 216-8)
and '217 minus some reversions (216-6 / 216-9), so I bashed at the trees
for fifteen minutes trying to figure it out, and it looked like rather
more difference than the update description and package changelog
suggested, so I thought it would be a good idea to communicate that.
OK, let's
not dwell on this. I don't think this is a useful measure
in any way.
Again, one thing that could prevent us having to have this kind of
discussion would be for systemd to have more
sophisticated/heavier/whatever stable release management.
If you want me (or
someone else) to provide better changelogs or
whatever, than I'm happy to discuss it, but a thread about a specific
update on test@ is hardly the place.
The
systemd-stable repo is a definite improvement on the previous approach,
but it's still missing actual *release management*, when you say 'OK,
we're going to release an actual thing that will be called systemd 216.1
and we're going to put all these bits in it and we're going to write
down what those are'.
If you look the diff you made, it NEWS file is accurate
and lists
user-visible changes. I guess it should not say '217'. This *is* a
good suggestion, in the future I'll make sure that the NEWS file says
that it pertains to the release.
Right now if someone asks what systemd is in Fedora 21, what do we
say?
Well, we can say 'systemd-216 stable' and point to
http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable ,
but then they ask 'what's that?', and what do we say? Where is its
existence described? It's not systemd-216. It's not systemd-217. It
doesn't have a version, it doesn't have a tarball, it doesn't have a
readme, it doesn't have a changelog. The NEWS file says "CHANGES WITH
217:", so it seems dangerous to assume that it accurately describes all
the changes on the 216-stable branch and *only* those changes.
You have the git
tree. I'm pretty certain that this is superior to a
tarball. You can trivially generate a tarball if you want to.
If you looks at the NEWS file, although it says 'CHANGES WITH 217' it
also says '[reverted in this update]' in a few places, which I think
suggests that it pertains to this update. I'll make sure to fix the
header in the future.
I understand that systemd git is not easy to follow, but I don't think
this differes that much from other fast-changing projects. If you take
a random kernel release, it's not like there's a nice lwn-style description
somewhere.
[snip]
checkout of the 216-stable tree we bump the package release but when
we
add a downstream specific change we...bump the package release.
Well, there's
really very little difference between upstream and downstream
here. stable/v216-stable is updated when I add patches to the Fedora package.
If they were both versioned, the version numbers would be pretty much the same
anyway.
One simple change that might help a bit right now is to follow the
Fedora package versioning convention for when your package is built from
SCM snapshots:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
So the systemd package should not just be 'systemd-216-8', or whatever,
but something like:
systemd-216-8.20141104gitaf59039bc
Yes, this makes sense when building from
upstream git, where the date
and the number correspond to something tangible. Here the list of
patches is somewhat arbitrary: patches are backported if they are easy,
or when they fix know problems. They often end up not in the same
order as upstream, for example where a cleanup patch is much later
cherry-picked to avoid diff conflicts in an actual patch that fixes
something. So the upstream git hash (or date) would be very misleading.
What I can do, and what should be useful, is to add tags to the stable
branches where fedora releases are built from. This was available
by looking at the last patch in the srpm, but not convenient to look up.
Zbyszek
4:06 p.m.
On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote:
I understand that systemd git is not easy to follow, but I don't
think
this differes that much from other fast-changing projects. If you take
a random kernel release, it's not like there's a nice lwn-style description
somewhere.
But there are actual releases. There's a kernel 3.17.1, and a kernel
3.17.2. They are artifacts with some sort of concrete presence, an
announcement mail and a changelog (even though yes, it's just a git
commit log). People can discuss the artifact called '3.17.1', say 'oh
hey that's broken in 3.17.1', whatever. There's no 'systemd 216.1' to
discuss, there's just a git branch which keeps changing. Sure, any
specific checkout of a git branch has superior capabilities to any
tarball and you can make one from the other, but the point of there
being a tarball called '3.17.1' is that *that's the thing that's
3.17.1*. A git branch that keeps changing is a very slippery thing to
try and do testing or communication or whatever in relation to.
The Fedora kernel maintainers maintain a clear distinction between
upstream and downstream 'hats'; we don't just have kernel 3.17-1, kernel
3.17-2, kernel 3.17-3, kernel 3.17-4 with changes from an upstream git
branch rolling in continuously, the upstream kernel releases are the
downstream package versions and the package releases are downstream
changes. The kernel package usually respects Fedora milestone freezes
very well, it's maintained in such a way that blocker/FE-fixing changes
can be isolated properly from other changes.
The kernel maintainers also decide a long time in advance what kernel
we're going to have in a Fedora release and stick to that. For F21 we
decided quite late to pull in 3.17 instead of 3.16, but the kernel
maintainers actively went out and talked to other groups (including QA)
about that, and made sure that everyone was on the same page about it
getting pulled in. (3.17 landed in stable on 10-12).
[snip]
> checkout of the 216-stable tree we bump the package release but when we
> add a downstream specific change we...bump the package release.
Well, there's really very little difference between upstream and downstream
here. stable/v216-stable is updated when I add patches to the Fedora package.
If they were both versioned, the version numbers would be pretty much the same
anyway.
But stable/v216-stable is *also* updated when you backport a whole bunch
of changes from upstream master, or whatever. Again, to you this all
feels like part of one process, but I'm not sure it really should be,
especially for a very significant project like systemd. For me, upstream
stable branches of something like systemd shouldn't really be intimately
associated with the Fedora package of that same branch. The upstream
stable branch should be maintained as a thing *in itself*, an object
with a clear raison d'etre and maintenance policy and so on, and the
Fedora package of that branch should be a separate thing. It shouldn't
'naturally' be the case that all these changes get sort of rolled
together into the same big blob of code which exists as both an upstream
git branch and a Fedora package which is a very direct reflection of
that git branch, with all the same stuff landing in both at the same
time.
There are usually different constraints on upstream and downstream at
different times; systemd isn't in a release freeze when Fedora is, for
instance. Maybe it makes sense for change (X) to land on the upstream
stable branch right now, but Fedora just wants blocker fix (Y). The
current process doesn't really seem to handle that kind of thing very
well, and it's exactly the kind of thing we have this distinction
between upstream and downstream maintenance for.
> One simple change that might help a bit right now is to follow
the
> Fedora package versioning convention for when your package is built from
> SCM snapshots:
>
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
>
> So the systemd package should not just be 'systemd-216-8', or whatever,
> but something like:
>
> systemd-216-8.20141104gitaf59039bc
Yes, this makes sense when building from upstream git, where the date
and the number correspond to something tangible. Here the list of
patches is somewhat arbitrary: patches are backported if they are easy,
or when they fix know problems. They often end up not in the same
order as upstream, for example where a cleanup patch is much later
cherry-picked to avoid diff conflicts in an actual patch that fixes
something. So the upstream git hash (or date) would be very misleading.
What I can do, and what should be useful, is to add tags to the stable
branches where fedora releases are built from.
I'm not sure if you're suggesting having tags on the *upstream* git repo
that reflect *downstream* package builds, but that seems like more
confusion between two separate processes to me - I'm suggesting more
separation between the two, not more conflation.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:06 p.m.
On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote:
On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek
wrote:
> I understand that systemd git is not easy to follow, but I don't think
> this differes that much from other fast-changing projects. If you take
> a random kernel release, it's not like there's a nice lwn-style description
> somewhere.
But there are actual releases. There's a kernel 3.17.1, and a kernel
3.17.2. They are artifacts with some sort of concrete presence, an
announcement mail and a changelog (even though yes, it's just a git
commit log).
Lots of things you say I agree with. Yesterday after you complained
that there the releases are not tagged in dist-git, I actually went
ahead and added tags for all post-F20 releases (haven't pushed them
yet).
The subject of point releases hasn't come up before. Actually I
haven't had *any* communication about the stable branches since they
were created apart from a few patches backported by other systemd
maintainers. If there are difficiencies, I need to hear about them.
I love working on Fedora, and I'm happy to fix whatever I can.
Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I
pushed aggressively for an update in F21 to diminish this backlog a
little. Some of those bugs have fixes upstream, but because of the
large code reorganization that was done after systemd-208, lots of
patches can't be really backported and would have to be rewritten to
apply to the version of systemd that is in F20. This situation is
something that I want to avoid as long as possible in F21, and that is
why pre-release F21 updates were following upstream closely.
I'm sorry about the timeout bug #1154768, it was my fault that it
landed in an update. We (upstream) knew about the issue, but I don't
think that anyone saw it as more than an annoyance, and that is why it
slipped through. Like I wrote before, that update *was* supposed to go
stable before the alpha freeze, and was supposed to go through all the
testing sufficiently early.
> Yes, this makes sense when building from upstream git, where the
date
> and the number correspond to something tangible. Here the list of
> patches is somewhat arbitrary: patches are backported if they are easy,
> or when they fix know problems. They often end up not in the same
> order as upstream, for example where a cleanup patch is much later
> cherry-picked to avoid diff conflicts in an actual patch that fixes
> something. So the upstream git hash (or date) would be very misleading.
>
> What I can do, and what should be useful, is to add tags to the stable
> branches where fedora releases are built from.
I'm not sure if you're suggesting having tags on the *upstream* git repo
that reflect *downstream* package builds, but that seems like more
confusion between two separate processes to me - I'm suggesting more
separation between the two, not more conflation.
I update the stable branches when
I work on a Fedora update. So I'll just
tag the stable branch at the time when it is pulled into a Fedora update.
The process will not change in any way from what happens currently, but
there'll be a visible tag.
Zbyszek
8:09 p.m.
On Wed, 2014-11-05 at 01:06 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote:
> On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote:
>
> > I understand that systemd git is not easy to follow, but I don't think
> > this differes that much from other fast-changing projects. If you take
> > a random kernel release, it's not like there's a nice lwn-style
description
> > somewhere.
>
> But there are actual releases. There's a kernel 3.17.1, and a kernel
> 3.17.2. They are artifacts with some sort of concrete presence, an
> announcement mail and a changelog (even though yes, it's just a git
> commit log).
Lots of things you say I agree with. Yesterday after you complained
that there the releases are not tagged in dist-git, I actually went
ahead and added tags for all post-F20 releases (haven't pushed them
yet).
The subject of point releases hasn't come up before. Actually I
haven't had *any* communication about the stable branches since they
were created apart from a few patches backported by other systemd
maintainers. If there are difficiencies, I need to hear about them.
I love working on Fedora, and I'm happy to fix whatever I can.
In the nature of things it tends to become most obvious around release
times, because that's when it gets really painful when things break :)
Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I
pushed aggressively for an update in F21 to diminish this backlog a
little. Some of those bugs have fixes upstream, but because of the
large code reorganization that was done after systemd-208, lots of
patches can't be really backported and would have to be rewritten to
apply to the version of systemd that is in F20. This situation is
something that I want to avoid as long as possible in F21, and that is
why pre-release F21 updates were following upstream closely.
I can see what you're trying to do there, and there's merit to it, but
it's best if it's carefully handled. Obviously there's a limit to how
much you can do as one person, I understand that.
I'm sorry about the timeout bug #1154768, it was my fault that
it
landed in an update. We (upstream) knew about the issue, but I don't
think that anyone saw it as more than an annoyance, and that is why it
slipped through. Like I wrote before, that update *was* supposed to go
stable before the alpha freeze, and was supposed to go through all the
testing sufficiently early.
10-14 was the date of the *Beta* freeze, not the Alpha freeze. Alpha
freeze was weeks ago, on 08-26; this change landed long after Alpha
shipped.
So what I'd suggest here is, at least in the conventional conception of
a 'stable' branch, this is a change that should never have come close to
one. It is clearly a feature addition, it's a substantial behaviour
change, and it was not in response to any specific bug report (no,
Lennart going 'hey, it's sure easy to push the power button on this
laptop' doesn't really count as a bug report :>)
A stable branch is supposed to be, well, stable. It shouldn't suddenly
start introducing significant behaviour changes. The typical mindset for
maintaining a stable branch isn't 'let's pull everything that isn't
obviously dangerous' but 'let's not pull anything unless we have a
really good reason to believe it's a) needed and b) safe'.
I certainly see the argument for pulling more changes downstream than
would be pulled by following a traditional 'stable branch', but I'm not
sure the system of having a branch that's called a stable branch but
really isn't one which you suck straight into the downstream package
without any kind of 'filtering' step is the best way to go about that.
It might really be a good idea to talk to the kernel maintainers about
their approach here, as over the years they've got to a point where they
strike a very decent balance between getting too far behind upstream
development and introducing de-stabilizing changes downstream at bad
times.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:52 p.m.
On Tue, Nov 04, 2014 at 06:09:35PM -0800, Adam Williamson wrote:
On Wed, 2014-11-05 at 01:06 +0100, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote:
> > On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> >
> > > I understand that systemd git is not easy to follow, but I don't
think
> > > this differes that much from other fast-changing projects. If you take
> > > a random kernel release, it's not like there's a nice lwn-style
description
> > > somewhere.
> >
> > But there are actual releases. There's a kernel 3.17.1, and a kernel
> > 3.17.2. They are artifacts with some sort of concrete presence, an
> > announcement mail and a changelog (even though yes, it's just a git
> > commit log).
> Lots of things you say I agree with. Yesterday after you complained
> that there the releases are not tagged in dist-git, I actually went
> ahead and added tags for all post-F20 releases (haven't pushed them
> yet).
>
> The subject of point releases hasn't come up before. Actually I
> haven't had *any* communication about the stable branches since they
> were created apart from a few patches backported by other systemd
> maintainers. If there are difficiencies, I need to hear about them.
> I love working on Fedora, and I'm happy to fix whatever I can.
In the nature of things it tends to become most obvious around release
times, because that's when it gets really painful when things break :)
> Systemd has 213 open bugs in Fedora, + another 49 marked as RFC.
I
> pushed aggressively for an update in F21 to diminish this backlog a
> little. Some of those bugs have fixes upstream, but because of the
> large code reorganization that was done after systemd-208, lots of
> patches can't be really backported and would have to be rewritten to
> apply to the version of systemd that is in F20. This situation is
> something that I want to avoid as long as possible in F21, and that is
> why pre-release F21 updates were following upstream closely.
I can see what you're trying to do there, and there's merit to it, but
it's best if it's carefully handled. Obviously there's a limit to how
much you can do as one person, I understand that.
> I'm sorry about the timeout bug #1154768, it was my fault that it
> landed in an update. We (upstream) knew about the issue, but I don't
> think that anyone saw it as more than an annoyance, and that is why it
> slipped through. Like I wrote before, that update *was* supposed to go
> stable before the alpha freeze, and was supposed to go through all the
> testing sufficiently early.
10-14 was the date of the *Beta* freeze, not the Alpha freeze. Alpha
freeze was weeks ago, on 08-26; this change landed long after Alpha
shipped.
You're right, I was thinking about the beta freeze.
The policy for updates says "Pre Beta. This is the time between the
Bodhi enabling point and the Beta release. During this time we are
attempting to stabilize the major versions of software that will be
shipped with the final release of the OS. Major updates can be
tolerated, but breaking things for early testers should be avoided if
possible. Additionally, as we get close to Alpha or Beta releases any
change that breaks composes of Live media, install media or testing
should be avoided. Packages for Changes should be landing and getting
major testing. Avoid ABI/API changes where possible." Once again, I
apologize for the timeout bug, had I know that it will interact badly
with fedup, I certainly wouldn't have included it. Otherwise, I still
feel the update was withing the confines of the policy. The patches
that I pushed introduced some new features, but nothing which would
count as an (intentional) "major feature" or significant change in the
codebase, or ABI/API break. I used the versions in question on a few
different machines, and I wasn't aware of any significant problems
with them. Of course I didn't upgrade them using fedup, so I didn't
hit the one bug that caused problem. If you look at the Fedora
bugzilla, the F21 version has *less* bugs than either the F20 and F19
versions.
So what I'd suggest here is, at least in the conventional
conception of
a 'stable' branch, this is a change that should never have come close to
one. It is clearly a feature addition, it's a substantial behaviour
change, and it was not in response to any specific bug report (no,
Lennart going 'hey, it's sure easy to push the power button on this
laptop' doesn't really count as a bug report :>)
It's not about
Lennart. Afaik he usually sticks to git HEAD and/or
rawhide. There are multiple reports about systemd entering an infinite
loop and I *thought* that this is a step in the right
direction. Systemd 217 was released with similar functionality, and
while it is now clear that this approach doesn't really solve
anything, the issues with it weren't clear at the time. The way I
understood the impact was "if your system hangs, it'll sync and
poweroff at some point." This change was pulled after testers reported
problems with it.
It might really be a good idea to talk to the kernel maintainers
about
their approach here, as over the years they've got to a point where they
strike a very decent balance between getting too far behind upstream
development and introducing de-stabilizing changes downstream at bad
times.
I'm very appreciative of the kernel promise of stability. But systemd
isn't at this stage yet, the codebase is much more in flux.
Zbyszek
1:17 a.m.
On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
I'm very appreciative of the kernel promise of stability. But
systemd
isn't at this stage yet, the codebase is much more in flux.
Well, it's in flux, but it *is* the init system. It's kind of
important. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:22 a.m.
On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
It's not about Lennart. Afaik he usually sticks to git HEAD
and/or
rawhide. There are multiple reports about systemd entering an infinite
loop and I *thought* that this is a step in the right
direction.
Well, looking at it practically as a user - if my system sticks in an
infinite loop on boot, and the message is 'well, this new release
doesn't make it boot properly, but it *will* time out and hard power off
after 15 minutes' - that doesn't really make me jump for joy. Has it
practically improved my situation? Not really.
To give a really personal example, I'm one of the people suffering from
https://bugzilla.redhat.com/show_bug.cgi?id=1123170 , I never have time
to investigate it properly and provide details - sorry about that. But I
guess the same way of thinking would say the timer is a 'step in the
right direction' for me because my system will eventually give up and
hard power off after 30 minutes - but does that really practically make
me feel like I'm getting a better experience? Honestly, not really. If
I'm actually sitting in front of the system I've usually lost patience
and hard rebooted after, like, five minutes. If I'm not, all the 30
minute timeout did was save me five cents of electricity.
The only case I could see where someone would really think 'hey, that
made my life better' is Lennart's case of a laptop sitting in a case or
a bag - but the thing is, the change only helps in that case *if you
happen to be using encrypted storage*! If you aren't, the boot will
complete without any user interaction needed, and the timeout will never
kick in. So it really seems like a change which doesn't provide an awful
lot of practical benefit. If boot or shutdown is failing so badly that a
15/30 minute timer would kick in, just adding a 15/30 minute timer
doesn't honestly make things seem a whole lot 'better'. Fixing whatever
bug is preventing the startup/shutdown from actually working is what
would make the experience feel better.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:56 a.m.
New subject: shutdown failure/delay (was: Note on 'systemd-216-9')
Adam Williamson composed on 2014-11-04 23:22 (UTC-0800):
https://bugzilla.redhat.com/show_bug.cgi?id=1123170 , I never have
time
to investigate it properly and provide details - sorry about that. But I
guess the same way of thinking would say the timer is a 'step in the
right direction' for me because my system will eventually give up and
hard power off after 30 minutes - but does that really practically make
me feel like I'm getting a better experience?
I've seen shutdown delays on various installations going back to when systemd
was very young. Often they seem to stem from start processes that reported
failure at init time, so at shutdown time, instead of stop jobs, I see
*start* jobs stalling.
One of the easier ways to cause a shutdown delay is to try to CAD right after
making a boot menu selection and realizing I chose the wrong one. That
typically will hang with message "failed to store sound card state", and
continually repeat for as long as CAD is held down. It doesn't happen on
every installation, but it is common. Rather than trying to troubleshoot any
of these hangs I invariably have more urgent things to do and reach for the
reset button or power switch.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
3:01 a.m.
New subject: shutdown failure/delay (was: Note on 'systemd-216-9')
On Wed, 2014-11-05 at 02:56 -0500, Felix Miata wrote:
Adam Williamson composed on 2014-11-04 23:22 (UTC-0800):
> https://bugzilla.redhat.com/show_bug.cgi?id=1123170 , I never have time
> to investigate it properly and provide details - sorry about that. But I
> guess the same way of thinking would say the timer is a 'step in the
> right direction' for me because my system will eventually give up and
> hard power off after 30 minutes - but does that really practically make
> me feel like I'm getting a better experience?
I've seen shutdown delays on various installations going back to when systemd
was very young.
That's not my bug.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:26 a.m.
On Tue, Nov 04, 2014 at 11:22:10PM -0800, Adam Williamson wrote:
On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek
wrote:
> It's not about Lennart. Afaik he usually sticks to git HEAD and/or
> rawhide. There are multiple reports about systemd entering an infinite
> loop and I *thought* that this is a step in the right
> direction.
Well, looking at it practically as a user - if my system sticks in an
infinite loop on boot, and the message is 'well, this new release
doesn't make it boot properly, but it *will* time out and hard power off
after 15 minutes' - that doesn't really make me jump for joy. Has it
practically improved my situation? Not really.
For powerup it doesn't, for
shutdown it might. If systemd got confused
in its little mind and cannnot unwind the stack of mounts, syncing the
filesystems and powering off *is* a better outcome than hanging. Even
more so for reboots - for a remote machine a hung reboot can be much
more problematic than a reboot after 30 minutes.
The issue is how to deal with long-running jobs. Current approach
doesn't work for them at all — so it is not a solution we can
enable. The timeouts are disabled in F21 packages and in upstream git
and will push and update that also removes them in rawhide.
To give a really personal example, I'm one of the people
suffering from
https://bugzilla.redhat.com/show_bug.cgi?id=1123170
I'd love to see this fixed
too :)
Zbyszek
10:48 a.m.
On Wed, 2014-11-05 at 15:26 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 11:22:10PM -0800, Adam Williamson wrote:
> On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
>
> > It's not about Lennart. Afaik he usually sticks to git HEAD and/or
> > rawhide. There are multiple reports about systemd entering an infinite
> > loop and I *thought* that this is a step in the right
> > direction.
>
> Well, looking at it practically as a user - if my system sticks in an
> infinite loop on boot, and the message is 'well, this new release
> doesn't make it boot properly, but it *will* time out and hard power off
> after 15 minutes' - that doesn't really make me jump for joy. Has it
> practically improved my situation? Not really.
For powerup it doesn't, for shutdown it might. If systemd got
confused
in its little mind and cannnot unwind the stack of mounts, syncing the
filesystems and powering off *is* a better outcome than hanging. Even
more so for reboots - for a remote machine a hung reboot can be much
more problematic than a reboot after 30 minutes.
Did it actually sync the filesystems? I'm pretty sure that when we hit
the bug with fedup, you got fsck's on the next boot.
The issue is how to deal with long-running jobs. Current approach
doesn't work for them at all — so it is not a solution we can
enable. The timeouts are disabled in F21 packages and in upstream git
and will push and update that also removes them in rawhide.
The timeouts seem to have come back in upstream 217:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f189ab18de69d3dee8...
http://cgit.freedesktop.org/systemd/systemd/commit/?id=3898b80d409ae16b04...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:05 a.m.
On Wed, Nov 05, 2014 at 08:48:37AM -0800, Adam Williamson wrote:
Did it actually sync the filesystems? I'm pretty sure that when
we hit
the bug with fedup, you got fsck's on the next boot.
Hm, I thought it does, but
this would suggest something different.
> The issue is how to deal with long-running jobs. Current
approach
> doesn't work for them at all — so it is not a solution we can
> enable. The timeouts are disabled in F21 packages and in upstream git
> and will push and update that also removes them in rawhide.
The timeouts seem to have come back in upstream 217:
I think my typo made things
unclear. The sentence above was supposed to say
"will push an update that also removes them in rawhide".
Zbyszek
8:32 a.m.
Hi
On Tue, Nov 4, 2014 at 7:06 PM, Zbigniew Jędrzejewski-Szmek wrote:
The subject of point releases hasn't come up before. Actually I
haven't had *any* communication about the stable branches since they
were created apart from a few patches backported by other systemd
maintainers. If there are difficiencies, I need to hear about them.
I love working on Fedora, and I'm happy to fix whatever I can.
So when there are bugs for which you are pulling in fixes, if you could
push them out to the stable branch and do point releases that just fixes
bugs, that could help Fedora bug reporters understand what is that they are
testing a little better. It also helps other distributions get upstream
reviewed bug fix releases.
Rahul
11:19 a.m.
On Tue, Nov 04, 2014 at 08:30:32 -0800,
Adam Williamson <adamwill(a)fedoraproject.org> wrote:
systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less
identical to upstream systemd-stable 216:
http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable .
systemd "216-9" is not built from 216 at all, it is in fact systemd-217
with some particular changes (presumably intended to be the most
There is a definite problem with 217 I have been seeing in rawhide.
I am seeing an intermittent (very roughly 50% of boots) problem where
copying logs to persistent storage hangs for a long time. This is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1159641
Though I actually filed that bug because the debug-shell was shutting the
system down.
2:13 p.m.
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
An update has been submitted for systemd today:
https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21
with a fairly short description. I wanted to flag up that, in fact,
systemd-216-9 is a major change from systemd-216-8 and is not really
systemd 216 at all.
Hi Adam,
this annoucement misrepresents the situation quite a bit. Since you
are speaking from your position as QA chief, your word carries a lot
of weight. We *were* in contact on IRC yesterday, I'm in #fedora-devel
semi-permanently, and it should not be a problem to show it to me
before you sent it out, since you are talking about updates I made. If
you disagreed with what I have to say and *then* sent the mail, that
would be fine, but not like this, out of the blue.
Anyway, returning to the matter at hand, systemd-216-9 is fairly close
to systemd-216-8, has patches over it to fix *known bugs*, the ones
listed in the update, a few listed on the freedesktop systemd bug
tracker, and a few small ones I found while testing the update. The
delta is not as small as I would like, but fits imho in the rules. If
systemd upstream was doing point releases, this would certainly
qualify as one.
Actually it was 216-2 which contained the biggest change. I built it
on Oct 7, before the alpha freeze. It was called "216" because 217
wasn't tagged yet, and I didn't want F21 to miss the bugfixes and
features which have accumulated in the upstream git. So 216-2 has most
of the post-216 commits, and 216-9 is fairly close to that. It *is*
built from 217 by reverting the major changes done after 216-2, but
that is a matter of convenience... It was simply simpler and more
explicit this way (reverts not ommitted patches).
systemd-216-8 (and 216-1 through 216-5) and earlier) was more or
less
identical to upstream systemd-stable 216:
http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable .
systemd "216-9" is not built from 216 at all, it is in fact systemd-217
with some particular changes (presumably intended to be the most
disruptive ones) reverted. When I dropped build-related files and
directories and documentation from the trees, did a context-free
recursive diff, and filtered out the metadata from the diff, it still
worked out at >7,000 lines worth of additions and removals between the
underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a lot of
change to land between Beta and Final.
Like I said on IRC yesterday, a large part
of this is code which is
not compiled for Fedora, or unsupported [*], or tests.
Testers, please take care to test the update thoroughly, despite the
small bump and small description it is a major change to the package.
That I can
agree with. I'd much prefer a concrete list of things to
test in this update though, which would be *useful* and lead to a
better release. Right now you suggest that anything might be broken.
Zbyszek
[*] systemd-resolved, systemd-networkd
2:27 p.m.
On Tue, 2014-11-04 at 21:13 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote:
> An update has been submitted for systemd today:
>
> https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21
>
> with a fairly short description. I wanted to flag up that, in fact,
> systemd-216-9 is a major change from systemd-216-8 and is not really
> systemd 216 at all.
Hi Adam,
this annoucement misrepresents the situation quite a bit. Since you
are speaking from your position as QA chief
I don't hold that position, and there isn't such a position.
, your word carries a lot
of weight. We *were* in contact on IRC yesterday, I'm in #fedora-devel
semi-permanently, and it should not be a problem to show it to me
before you sent it out, since you are talking about updates I made. If
you disagreed with what I have to say and *then* sent the mail, that
would be fine, but not like this, out of the blue.
Sorry for not running it by you first, but I'm just trying to stay on
top of a whole bunch of stuff for F21 right now. I wasn't *complaining*
about anything. I just wanted to make sure people didn't rubber-stamp
216-9 on the impression that it contained a single bugfix vs -8 or
something.
Anyway, returning to the matter at hand, systemd-216-9 is fairly
close
to systemd-216-8, has patches over it to fix *known bugs*, the ones
listed in the update, a few listed on the freedesktop systemd bug
tracker, and a few small ones I found while testing the update. The
delta is not as small as I would like, but fits imho in the rules.
I didn't say otherwise, but I wouldn't characterize the diff posted
earlier as 'fairly close', it really isn't. Anything past a dozen LOC is
not 'fairly close', IMHO.
If
systemd upstream was doing point releases, this would certainly
qualify as one.
Well, I didn't want to bring it up, but that would rather clarify
things, wouldn't it? Right now we have a sort of messy situation where
what the Fedora package is is basically 'whatever's on the
systemd-stable 216 branch upstream', and what that is is 'whatever you
find most convenient right at present' - like the Fedora package, up
until a couple of days ago that branch was a few hundred commits added
to the 216 tarball, whereas now it's been completely changed to be 217
minus a few reversions.
This I guess makes sense to you as you have this kind of mental vision
of what you want '216 stable' to be, so it makes sense to at some point
say 'oh hey, my mental 216 stable is just 217 minus X, Y and Z, so let's
make the branch be that' but it's rather difficult for anyone else to
follow, there isn't much continuity. Things like point releases and
changelogs and consistent maintenance procedures and more
differentiation between upstream and downstream changes would make the
picture clearer. While I was researching the mail I kind of pieced
together all this history from the package changelog, the package SCM
commit log, the upstream SCM log, and the Bodhi update comments, but you
*do* have to go through all of that to actually figure out what the
hell's going on, because it's all just '216-x', there's no 216 point
releases, no release documentation, not a lot to differentiate package
changes and upstream changes.
Actually it was 216-2 which contained the biggest change. I built it
on Oct 7, before the alpha freeze. It was called "216" because 217
wasn't tagged yet, and I didn't want F21 to miss the bugfixes and
features which have accumulated in the upstream git. So 216-2 has most
of the post-216 commits, and 216-9 is fairly close to that.
Again, well, I posted the diff, and I disagree that it's 'fairly close'.
216-2 was certainly hugely different to 216-1, but 216-1 never went to
updates-testing, so it doesn't really signify.
> systemd-216-8 (and 216-1 through 216-5) and earlier) was more or
less
> identical to upstream systemd-stable 216:
> http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable .
> systemd "216-9" is not built from 216 at all, it is in fact systemd-217
> with some particular changes (presumably intended to be the most
> disruptive ones) reverted. When I dropped build-related files and
> directories and documentation from the trees, did a context-free
> recursive diff, and filtered out the metadata from the diff, it still
> worked out at >7,000 lines worth of additions and removals between the
> underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a
lot of
> change to land between Beta and Final.
Like I said on IRC yesterday, a large part of this is code which is
not compiled for Fedora, or unsupported [*], or tests.
> Testers, please take care to test the update thoroughly, despite the
> small bump and small description it is a major change to the package.
That I can agree with. I'd much prefer a concrete list of things
to
test in this update though, which would be *useful* and lead to a
better release. Right now you suggest that anything might be broken.
Well, I just said it's a big change and the update description doesn't
accurately encapsulate it.
I would of course be very happy with a concrete list of things to test
in the update. The update description would be a good place for it.
Another good place for concrete lists of changes would be in the
changelogs for the upstream point releases which we don't have...:)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:37 p.m.
On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote:
> > Testers, please take care to test the update thoroughly,
despite the
> > small bump and small description it is a major change to the package.
> That I can agree with. I'd much prefer a concrete list of things to
> test in this update though, which would be *useful* and lead to a
> better release. Right now you suggest that anything might be broken.
Well, I just said it's a big change and the update description doesn't
accurately encapsulate it.
I would of course be very happy with a concrete list of things to test
in the update. The update description would be a good place for it.
Well, then ping
me on IRC to update the description (or even mail it
to test@ or whatever) and with luck 30 minutes later we would have a
much better picture than by looking at a squashed diff.
Another good place for concrete lists of changes would be in the
changelogs for the upstream point releases which we don't have...:)
Sure, that
would be nice.
Zbyszek
2:49 p.m.
On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote:
> > > Testers, please take care to test the update thoroughly, despite the
> > > small bump and small description it is a major change to the package.
>
> > That I can agree with. I'd much prefer a concrete list of things to
> > test in this update though, which would be *useful* and lead to a
> > better release. Right now you suggest that anything might be broken.
>
> Well, I just said it's a big change and the update description doesn't
> accurately encapsulate it.
>
> I would of course be very happy with a concrete list of things to test
> in the update. The update description would be a good place for it.
Well, then ping me on IRC to update the description (or even mail it
to test@ or whatever) and with luck 30 minutes later we would have a
much better picture than by looking at a squashed diff.
Well, that's more or less what my initial mail was meant to be. I didn't
post the diff initially, only in response to a follow-up mail asking
what the difference between the builds was.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:41 p.m.
On Tue, Nov 04, 2014 at 12:49:27PM -0800, Adam Williamson wrote:
On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote:
> > > > Testers, please take care to test the update thoroughly, despite the
> > > > small bump and small description it is a major change to the
package.
> >
> > > That I can agree with. I'd much prefer a concrete list of things to
> > > test in this update though, which would be *useful* and lead to a
> > > better release. Right now you suggest that anything might be broken.
> >
> > Well, I just said it's a big change and the update description doesn't
> > accurately encapsulate it.
> >
> > I would of course be very happy with a concrete list of things to test
> > in the update. The update description would be a good place for it.
> Well, then ping me on IRC to update the description (or even mail it
> to test@ or whatever) and with luck 30 minutes later we would have a
> much better picture than by looking at a squashed diff.
Well, that's more or less what my initial mail was meant to be. I didn't
post the diff initially, only in response to a follow-up mail asking
what the difference between the builds was.
The first mail I saw was this:
"""I wanted to flag up that, in fact, systemd-216-9 is a major change
from systemd-216-8 and is not really systemd 216 at all.
...
worked out at >7,000 lines worth of additions and removals between the
underlying code of 'systemd-216-8' and 'systemd-216-9'.
"""
Zbyszek
3:43 p.m.
On Tue, 2014-11-04 at 22:41 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 04, 2014 at 12:49:27PM -0800, Adam Williamson wrote:
> On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote:
> > > > > Testers, please take care to test the update thoroughly, despite
the
> > > > > small bump and small description it is a major change to the
package.
> > >
> > > > That I can agree with. I'd much prefer a concrete list of things
to
> > > > test in this update though, which would be *useful* and lead to a
> > > > better release. Right now you suggest that anything might be broken.
> > >
> > > Well, I just said it's a big change and the update description
doesn't
> > > accurately encapsulate it.
> > >
> > > I would of course be very happy with a concrete list of things to test
> > > in the update. The update description would be a good place for it.
>
> > Well, then ping me on IRC to update the description (or even mail it
> > to test@ or whatever) and with luck 30 minutes later we would have a
> > much better picture than by looking at a squashed diff.
>
> Well, that's more or less what my initial mail was meant to be. I didn't
> post the diff initially, only in response to a follow-up mail asking
> what the difference between the builds was.
The first mail I saw was this:
"""I wanted to flag up that, in fact, systemd-216-9 is a major change
from systemd-216-8 and is not really systemd 216 at all.
...
worked out at >7,000 lines worth of additions and removals between the
underlying code of 'systemd-216-8' and 'systemd-216-9'.
"""
Oh, sorry. I thought I'd cut that bit before sending the mail. It went
through a few revisions. Sorry :/ I was context-switching between a few
different things. I wrote the mail a few different ways and to a few
different recipients but in the end I only wanted to send out a more or
less factual 'hey, heads up this update needs full testing' mail.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3512
days inactive
3513
days old
25 comments
6 participants
participants (6)
-
Adam Williamson -
Bruno Wolff III -
Felix Miata -
Rahul Sundaram -
Tomasz Torcz -
Zbigniew Jędrzejewski-Szmek