Missing expected images:
Cloud disk raw i386
Cloud disk raw x86_64
Cloud_atomic disk raw x86_64
Workstation live i386
Workstation live x86_64
No images in this compose but not Rawhide 20151124
No images in Rawhide 20151124 but not this.
Failed openQA tests: 28 of 49
ID: 9021Test:
On Wed, 2015-11-25 at 09:46 -0500, Richard Ryniker wrote:
> System-upgrade across two releases raises an interesting End-of-Life
> policy issue. If system-upgrade from N-2 to N is so important it will
> block release of N until it works, how do we explain why it is no
> longer important after
On Tue, 2015-11-24 at 06:33 -0500, Kamil Paral wrote:
> As a middle ground, what about having:
> .---.
> | BIOS UEFI|
> |Testcase_upgrade_dnf_previous_any |
>
The following Fedora 23 Security updates need testing:
Age URL
113 https://bodhi.fedoraproject.org/updates/FEDORA-2015-12739
python-kdcproxy-0.3.2-1.fc23
95 https://bodhi.fedoraproject.org/updates/FEDORA-2015-5eb2131441
conntrack-tools-1.4.2-9.fc23
66
On Wed, 2015-11-25 at 13:36 -0500, Richard Ryniker wrote:
> My reading of the EOL policy says "If it isn't fixed before EOL, it is
> unlikely to be fixed." If I encounter a problem with release-skipping
> system-upgrade, too bad. There is probably no time to fix it before EOL.
That's not really
On Wed, 2015-11-25 at 16:51 -0500, Richard Ryniker wrote:
> > A month is a pretty long time in Fedora development
>
> True, but a month is only available if the problem is reported on day 1.
> If it takes a week or two for a user to report a problem, that interval
> lessens the remaining time to
On Fri, 2015-11-20 at 16:18 +0530, Sudhir D wrote:
>
> > I don't think it's appropriate to turn FEs into blockers automatically,
> > in fact there are obvious cases where it certainly wouldn't be
> > appropriate: bugs in non-blocking desktops are typically taken as FEs,
> > for instance, as are
>A month is a pretty long time in Fedora development
True, but a month is only available if the problem is reported on day 1.
If it takes a week or two for a user to report a problem, that interval
lessens the remaining time to EOL.
On the other hand, there is no prohibition against a fix after
On Wed, 2015-11-18 at 16:36 -0800, Adam Williamson wrote:
> #2 MOAR METADATA
>
>
> The alternative is to make the existing Blocker trackers do more work.
> In this model we wouldn't add any new tracker bugs; we'd just add new
> 'magic words' in the Whiteboard field. Right now,
>It's not like dnf-system-upgrade would magically stop working when N-2
>reaches EOL, so honestly, overall, I just don't really see the problem
>you're describing
Like most of Fedora, dnf-system-upgrade gets limited testing before
release. When N is released, a large number of users who did not
Compose started at Wed Nov 25 05:15:03 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
Hello everyone,
I'm Tiago. I've been using Fedora for many many years and I'm a
Fedora Ambassador in the UK. As an Ambassador I haven't been very
active due to personal reasons, but I now want to get traction again
and be as active as I can.
I have more than 14 years of professional experience
System-upgrade across two releases raises an interesting End-of-Life
policy issue. If system-upgrade from N-2 to N is so important it will
block release of N until it works, how do we explain why it is no
longer important after four weeks when N-2 reaches End of Life?
Four weeks is little time
13 matches
Mail list logo
