Re: Fedora 24: i686 images no longer 'release blocking'

2016-04-01 Thread Adam Williamson 
On Fri, 2016-04-01 at 04:13 -0400, Kamil Paral wrote:
> > 
> > So I decided to just bite the damn bullet and do something here (I was
> > supposed to implement something weeks ago, it's been a running joke at
> > meetings). I mostly followed kparal's suggestion for 'if we didn't have
> > openQA': I kept the i386 tests only for 'Default boot and install' and
> > 'USB media' and split them into separate tables below the main tables
> > that are collapsed by default. I renamed all 'x86' environments to
> > 'x86_64'. This will need some changes to the openQA wiki result
> > reporting code, I'll fix that up right away.

> Thanks, looks good. One suggestion though, some of the tables have
> columns named "x86_64" and "UEFI", while other tables have columns
> named "x86_64 BIOS" and "x86_64 UEFI". For consistency reasons, I
> think we should make them look the same. Using the second approach
> seems clearer to me.

Hah, good point. I hadn't noticed. I'll clean it up. In the Days Before
ARM, 'i686', 'x86_64', 'UEFI' made sense. Now we have no i686 any more
and (soon) 64-bit ARM using UEFI, it doesn't...:)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-04-01 Thread Kamil Paral 
> So I decided to just bite the damn bullet and do something here (I was
> supposed to implement something weeks ago, it's been a running joke at
> meetings). I mostly followed kparal's suggestion for 'if we didn't have
> openQA': I kept the i386 tests only for 'Default boot and install' and
> 'USB media' and split them into separate tables below the main tables
> that are collapsed by default. I renamed all 'x86' environments to
> 'x86_64'. This will need some changes to the openQA wiki result
> reporting code, I'll fix that up right away.

Thanks, looks good. One suggestion though, some of the tables have columns 
named "x86_64" and "UEFI", while other tables have columns named "x86_64 BIOS" 
and "x86_64 UEFI". For consistency reasons, I think we should make them look 
the same. Using the second approach seems clearer to me.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-03-31 Thread Adam Williamson 
On Wed, 2016-03-30 at 16:47 -0700, Adam Williamson wrote:
> 
> So far as tracking the openQA i386 results goes I think the openQA web
> UI and the compose check emails ought to be enough. I might improve
> check-compose a bit to report separate pass/fail counts by arch, so
> it's clearer when i386 is totally busted.

If anyone was reading the compose reports closely this morning maybe
you noticed - I went ahead and did this. Pass and fail counts in the
compose check reports are now split by arch. So that should be an easy
way to spot when i386 is busted. Of course right now EVERYTHING is
busted, but when we get a working anaconda again x86_64 should go a lot
greener...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-03-30 Thread Adam Williamson 
On Fri, 2016-01-29 at 08:09 -0500, Kamil Paral wrote:
> > 
> > https://fedoraproject.org/wiki/Template:Installation_test_matrix
> > 
> > quite a lot of the tables have 'i386' and 'x86_64' as environments.
> > Especially with the Milestone column, listing i386 alongside x86_64 is
> > a bit misleading if i386 is no longer blocking. I can see a few
> > options:
> > 
> > 1) just ditch the i386 columns entirely; openQA can continue testing
> > it, and people can test manually if they want, but we don't bother
> > tracking the results in the validation pages
> > 
> > 2) stick an admon template at the top of the page saying 'the i386
> > tests aren't blocking', with links out to the criteria and/or the FESCo
> > ticket
> > 
> > 3) Duplicate each table which distinguishes between 'i386' and
> > 'x86_64', so we have one table with just an 'i386' column and all tests
> > marked Optional, and another table with the other columns and the
> > appropriate milestone

> I think the answer here is largely dependent on what we want to do
> about OpenQA. If we didn't have OpenQA at all, I'd do #1, and I'd
> also duplicate Workstation* and Server* rows in "Default boot and
> install" section, gray out x86_64 and UEFI columns, and mark the rows
> as optional. Therefore i686 would be handled the same way we handle
> spins - there's a way to mark a critical error which prevents default
> install and boot in the matrix, but that's it.
> 
> The same solution would probably apply if we decided to drop i686
> testing from OpenQA.
> 
> But if we want to still test i686 in OpenQA (at least on a best-
> effort basis), we somewhat rely on the wiki pages for reporting. (Or
> do you think that having it in OpenQA frontend is good enough?).
> So if we want to keep the matrices around for that purpose, I'd
> either do #3 and collapse them by default, or I'd create a separate
> wiki page just for i686 and direct OpenQA results there. This way we
> can still easily see what was and what wasn't tested, and tools like
> testcase_stats work for it, but we the core wiki matrices are not
> overflowing with non-essential stuff. But it is some work and
> maintenance, and I'm not sure it's worth it. Maybe the OpenQA
> frontend is just good enough?

So I decided to just bite the damn bullet and do something here (I was
supposed to implement something weeks ago, it's been a running joke at
meetings). I mostly followed kparal's suggestion for 'if we didn't have
openQA': I kept the i386 tests only for 'Default boot and install' and
'USB media' and split them into separate tables below the main tables
that are collapsed by default. I renamed all 'x86' environments to
'x86_64'. This will need some changes to the openQA wiki result
reporting code, I'll fix that up right away.

So far as tracking the openQA i386 results goes I think the openQA web
UI and the compose check emails ought to be enough. I might improve
check-compose a bit to report separate pass/fail counts by arch, so
it's clearer when i386 is totally busted.

We still have i386 Cloud images for right now so I kept that table in
the Cloud matrix, but they may go away Real Soon Now and if so I'll
ditch the table.

If anyone really hates this, do yell, nothing is permanent in the wiki
;)

https://fedoraproject.org/w/index.php?title=Template:Installation_test_matrix=441403=439868
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-29 Thread Kamil Paral 
> https://fedoraproject.org/wiki/Template:Installation_test_matrix
> 
> quite a lot of the tables have 'i386' and 'x86_64' as environments.
> Especially with the Milestone column, listing i386 alongside x86_64 is
> a bit misleading if i386 is no longer blocking. I can see a few
> options:
> 
> 1) just ditch the i386 columns entirely; openQA can continue testing
> it, and people can test manually if they want, but we don't bother
> tracking the results in the validation pages
> 
> 2) stick an admon template at the top of the page saying 'the i386
> tests aren't blocking', with links out to the criteria and/or the FESCo
> ticket
> 
> 3) Duplicate each table which distinguishes between 'i386' and
> 'x86_64', so we have one table with just an 'i386' column and all tests
> marked Optional, and another table with the other columns and the
> appropriate milestone

I think the answer here is largely dependent on what we want to do about 
OpenQA. If we didn't have OpenQA at all, I'd do #1, and I'd also duplicate 
Workstation* and Server* rows in "Default boot and install" section, gray out 
x86_64 and UEFI columns, and mark the rows as optional. Therefore i686 would be 
handled the same way we handle spins - there's a way to mark a critical error 
which prevents default install and boot in the matrix, but that's it.

The same solution would probably apply if we decided to drop i686 testing from 
OpenQA.

But if we want to still test i686 in OpenQA (at least on a best-effort basis), 
we somewhat rely on the wiki pages for reporting. (Or do you think that having 
it in OpenQA frontend is good enough?).
So if we want to keep the matrices around for that purpose, I'd either do #3 
and collapse them by default, or I'd create a separate wiki page just for i686 
and direct OpenQA results there. This way we can still easily see what was and 
what wasn't tested, and tools like testcase_stats work for it, but we the core 
wiki matrices are not overflowing with non-essential stuff. But it is some work 
and maintenance, and I'm not sure it's worth it. Maybe the OpenQA frontend is 
just good enough?
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-29 Thread Adam Williamson 
On Fri, 2016-01-29 at 08:09 -0500, Kamil Paral wrote:

> But if we want to still test i686 in OpenQA (at least on a best-
> effort basis), we somewhat rely on the wiki pages for reporting. (Or
> do you think that having it in OpenQA frontend is good enough?).

Well, there's one other venue where we get the info: the 'compose
check' reports. I'm honestly rather happy with those. They do the job;
I noticed as soon as i686 broke the other day.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-29 Thread Adam Williamson 
On Fri, 2016-01-29 at 08:55 -0500, Kamil Paral wrote:
> > I have tweaked the release criteria 'preamble' text slightly to mention
> > this explicitly, and also to link to the canonical list of release-
> > blocking images that the program manager is maintaining now (the F24
> > list is
> > https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24
> > ).
> 
> I wonder why these two images are marked as release blocking?
> 
> Cloud_Images/x86_64/Images/Fedora-Cloud-Base-_RELEASE_MILESTONE_-_DATE_.i686.qcow2
>  
> Cloud_Images/x86_64/Images/Fedora-Cloud-Base-_RELEASE_MILESTONE_-_DATE_.i686.raw.xz

Well, it might be because they're listed as being inside the /x86_64/
directory, and whoever's job it was to put 'no' by all the i686 images
saw that but missed the 'i686' in the image name.

I think the listed names and locations are wrong; at least according to
our (fedfind-generated) download table for 23 Final RC10, the locations
were:

https://dl.fedoraproject.org/pub/alt/stage/23_RC10/Cloud_Images/i386/Images/Fedora-Cloud-Base-23-20151030.i386.raw.xz
https://dl.fedoraproject.org/pub/alt/stage/23_RC10/Cloud_Images/i386/Images/Fedora-Cloud-Base-23-20151030.i386.qcow2

i.e. they're actually marked 'i386' and are in a directory called 'i386'.

CCing Jan and nirik (who's shown as creating the page in the edit log).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-29 Thread Kevin Fenzi 
On Fri, 29 Jan 2016 10:49:06 -0800
Adam Williamson  wrote:

> i.e. they're actually marked 'i386' and are in a directory called
> 'i386'.
> 
> CCing Jan and nirik (who's shown as creating the page in the edit
> log).

Yeah, just missed/typo/mistake. 

I have changed them to the i386 path and marked them "no" for blocking. 

kevin


pgpUsHtt99rkj.pgp
Description: OpenPGP digital signature
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Adam Williamson 
Hi, folks! As discussed at last week's meeting, it seemed a good idea
to flag this up on the list for anyone who missed it.

From Fedora 24 onwards, FESCo has decided that i686 (32-bit x86) images
are no longer 'release blocking', by policy:

https://fedorahosted.org/fesco/ticket/1469

I have tweaked the release criteria 'preamble' text slightly to mention
this explicitly, and also to link to the canonical list of release-
blocking images that the program manager is maintaining now (the F24
list is
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24
 ).

I noted that the question of whether we 'support' / block on 32-bit
*upgrades* is not yet resolved, so I've filed a FESCo ticket for that:

https://fedorahosted.org/fesco/ticket/1539

What this means to us is pretty simple: we no longer have to worry
about getting all the validation tests done for 32-bit images. Woot! We
still *can* test them, if we want, but we don't have to. They're just
like the LXDE live, or any other non-blocking image.

An outstanding question is what we do with the validation matrices.
Cloud was easy enough - I just marked all rows in the i386 table as
'Optional'. Base, Server and Desktop don't really split out x86_64 and
i386/i686 (sidebar: the best thing about ditching i386/i686/x86_32 is
we no longer have to be terminally confused about what it's freaking
*called*...), so they're OK too. However, Installation is a bit of a
problem:

https://fedoraproject.org/wiki/Template:Installation_test_matrix

quite a lot of the tables have 'i386' and 'x86_64' as environments.
Especially with the Milestone column, listing i386 alongside x86_64 is
a bit misleading if i386 is no longer blocking. I can see a few
options:

1) just ditch the i386 columns entirely; openQA can continue testing
it, and people can test manually if they want, but we don't bother
tracking the results in the validation pages

2) stick an admon template at the top of the page saying 'the i386
tests aren't blocking', with links out to the criteria and/or the FESCo
ticket

3) Duplicate each table which distinguishes between 'i386' and
'x86_64', so we have one table with just an 'i386' column and all tests
marked Optional, and another table with the other columns and the
appropriate milestone

I can see arguments for any of those approaches. #1 is nice and simple
and reduces the scariness of the page, but I guess means we don't get a
quick overview of i386 status and probably means fewer people bothering
to do i386 tests. I don't know how much we care about that.

#2 is also simple and keeps the tests around, but people are probably
going to miss the admon note and will therefore be confused about
whether we're "missing" a lot of required results, if i386 isn't done.

#3 is probably the most 'theoretically correct', but would probably be
something of a giant PITA to read. I suppose we could have the i386
tables collapsed by default. That might work. Now I think about it,
though, I think having rows that are identical except for their
environments might confuse python-wikitcms, I'd have to look into it.

If you're thinking "4) change the Milestone column", I'd rather not,
because those values are somewhat significant to Wikitcms. Other ideas
welcome!

If anyone can think of any other system/process which might need
adjusting for this change, too, please do let us know! Or just go fix
it. ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Adam Williamson 
On Fri, 2016-01-29 at 01:06 +, Francisco Villavicencio wrote:
> Dear Chris & Adam:
> I have an i686 - 32 bit computer for a long time an it works fine for
> me. Are you perhaps suggesting that I have to throw my old Camaro for
> a new Rolls Royce?

We didn't make this decision, and it's not going to get changed by the
QA team discussing it. I'm just reporting the decision that's been made
and the impact it will have on our team.

(however, I have to note that your analogy is a little off. It's more
the case that we're not providing guarantees that our parts will fit on
Model T's any more, but we continue to do so for 1963 Trans Ams.
Seriously. i686 hardware is *old*. There are people out there with
working 8088s. It doesn't mean we're obliged to provide Fedora builds
for them until the capacitors finally give out. There has to be *some*
point at which we can say "we just can't justify putting the work into
supporting those boxes any more". When we stopped supporting i386,
there were still people with working i386 boxes. Ditto i586. It
happens.)

>  I'm using my computer since Fedora 4 came on an now it has Fedora 23
> Workstation. Along those releases I noticed that there are some
> problems that goes from release to release without fixing  them. Only
> to shoe one example: I tried to run fedora-easy-karma on may f23 and
> I have this message: Line 47 import yum. It is supposed that yum is
> deprecated and in no more on f23+. This bug was reported last year
> when f22 was  still alive, now on 2016, no one cares about it. Who is
> supposed to fix that bug?

Not anything to do with this thread, but the yum import is conditional,
it only gets done if 'import dnf' fails, which should only happen if
python2-dnf isn't installed (which could be the case if you have a very
minimal Fedora install, since dnf itself is now py3 by default).
Installing python2-dnf should resolve it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Chris Murphy 
On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson
 wrote:

> 1) just ditch the i386 columns entirely; openQA can continue testing
> it, and people can test manually if they want, but we don't bother
> tracking the results in the validation pages

How about option 1. That leaves x86_64 and ARM only; and then where
appropriate the distinction between BIOS and UEFI.

Next, duplicate that page, deleting ARM and UEFI, and changing x86_64
and BIOS to i686. i.e., a 32-bit x86 only specific page.

At least it's available. And it might give us some gauge of
interest/activity in testing 32-bit?

I don't know how wide spread the 32-bit being dropped news has spread,
so it may turn out there will be a 32-bit SIG+spin that shows up one
more release. My understanding is releng doesn't have the time to just
axe all of i686 this cycle, so all of it is going to get built. I
think it's best to do the least amount of work now, that makes it
possible to support a hypothetical 32-bit SIG+spin to do the testing
they'd need to do, to have a quality release. Because it will be
released, and it'll be from Fedora.

Is that reasonable?

I even think it's reasonable if you just went with option 1; noting
the derived page as I've described is offered if/when i686 interested
persons show up to the testing party. Honestly if no one asks (and I'm
not asking for it), then that pretty much tells us at least the
testing state of i686.


-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Adam Williamson 
On Thu, 2016-01-28 at 17:43 -0700, Chris Murphy wrote:
> On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson
>  wrote:
> 
> > 1) just ditch the i386 columns entirely; openQA can continue testing
> > it, and people can test manually if they want, but we don't bother
> > tracking the results in the validation pages
> 
> How about option 1. That leaves x86_64 and ARM only; and then where
> appropriate the distinction between BIOS and UEFI.
> 
> Next, duplicate that page, deleting ARM and UEFI, and changing x86_64
> and BIOS to i686. i.e., a 32-bit x86 only specific page.
> 
> At least it's available. And it might give us some gauge of
> interest/activity in testing 32-bit?

Well, it's possible. Speaking selfishly (as the one who's likely going
to wind up doing it), it involves a bit more work than the other
options. It would be included in the 'Summary' pages, I don't know if
that's a good or a bad thing.

> I don't know how wide spread the 32-bit being dropped news has spread,
> so it may turn out there will be a 32-bit SIG+spin that shows up one
> more release. My understanding is releng doesn't have the time to just
> axe all of i686 this cycle, so all of it is going to get built.

Well yes, and FESCo explicitly didn't say "no-one's allowed to build
32-bit Intel images any more", just "they're not allowed to be release
blocking". i.e. they explicitly drew a distinction between *not having
the images at all* (which is a pretty big step) and not blocking the
release on them (which is a smaller step).

I think there's sort of an idea that WGs can choose to stop building
32-bit images entirely if they can get releng on board, and of course
there's the possibility of building them but then burying them in
Douglas Adams' filing cabinet (the one in the basement, where the
lights are out, and so are the stairs, and there's a sign on the door
saying Beware Of The Leopard) - i.e. not publicizing their existence at
all. But that's a bit beyond our scope; the Cliff Notes for us are
'there will probably still be at least some i686 images, but they're no
longer release blocking'.

>  I
> think it's best to do the least amount of work now, that makes it
> possible to support a hypothetical 32-bit SIG+spin to do the testing
> they'd need to do, to have a quality release. Because it will be
> released, and it'll be from Fedora.
> 
> Is that reasonable?

Sure, it's an option. I don't hate it. Again on an entirely selfish
level I'd prefer some of the other options purely because they involve
less work, but if enough people would actually perform the 32-bit tests
 (and if anyone is going to care about the results) then I'm willing to
make the effort (of course, if someone else wants to do it, that is
also great, I'm happy to lend a hand with any Wikitcms mysteries that
transpire).

> I even think it's reasonable if you just went with option 1; noting
> the derived page as I've described is offered if/when i686 interested
> persons show up to the testing party. Honestly if no one asks (and I'm
> not asking for it), then that pretty much tells us at least the
> testing state of i686.

Yep, that's also a possibility - thanks for the idea.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Francisco Villavicencio 
Dear Chris & Adam:
I have an i686 - 32 bit computer for a long time an it works fine for me. Are 
you perhaps suggesting that I have to throw my old Camaro for a new Rolls 
Royce? I'm using my computer since Fedora 4 came on an now it has Fedora 23 
Workstation. Along those releases I noticed that there are some problems that 
goes from release to release without fixing  them. Only to shoe one example: I 
tried to run fedora-easy-karma on may f23 and I have this message: Line 47 
import yum. It is supposed that yum is deprecated and in no more on f23+. This 
bug was reported last year when f22 was  still alive, now on 2016, no one cares 
about it. Who is supposed to fix that bug?
Francisco Villavicencio.
 

On Thursday, January 28, 2016 7:43 PM, Chris Murphy 
 wrote:
 

 On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson
 wrote:

> 1) just ditch the i386 columns entirely; openQA can continue testing
> it, and people can test manually if they want, but we don't bother
> tracking the results in the validation pages

How about option 1. That leaves x86_64 and ARM only; and then where
appropriate the distinction between BIOS and UEFI.

Next, duplicate that page, deleting ARM and UEFI, and changing x86_64
and BIOS to i686. i.e., a 32-bit x86 only specific page.

At least it's available. And it might give us some gauge of
interest/activity in testing 32-bit?

I don't know how wide spread the 32-bit being dropped news has spread,
so it may turn out there will be a 32-bit SIG+spin that shows up one
more release. My understanding is releng doesn't have the time to just
axe all of i686 this cycle, so all of it is going to get built. I
think it's best to do the least amount of work now, that makes it
possible to support a hypothetical 32-bit SIG+spin to do the testing
they'd need to do, to have a quality release. Because it will be
released, and it'll be from Fedora.

Is that reasonable?

I even think it's reasonable if you just went with option 1; noting
the derived page as I've described is offered if/when i686 interested
persons show up to the testing party. Honestly if no one asks (and I'm
not asking for it), then that pretty much tells us at least the
testing state of i686.


-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

  --
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Felix Miata 
On one of my Athlon XP machines, yesterday after dnf updating f24 to 4.5rc
kernel it would lock up attempting to start X. On another Athlon XP today, it
locks up trying to boot 4.5rc kernel, before even displaying any init
messages. F23's 4.3.x on both is OK.
-- 
"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/
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Chris Murphy 
On Thu, Jan 28, 2016 at 6:01 PM, Adam Williamson
 wrote:
> On Thu, 2016-01-28 at 17:43 -0700, Chris Murphy wrote:
>> On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson
>>  wrote:
>>
>> > 1) just ditch the i386 columns entirely; openQA can continue testing
>> > it, and people can test manually if they want, but we don't bother
>> > tracking the results in the validation pages
>>
>> How about option 1. That leaves x86_64 and ARM only; and then where
>> appropriate the distinction between BIOS and UEFI.
>>
>> Next, duplicate that page, deleting ARM and UEFI, and changing x86_64
>> and BIOS to i686. i.e., a 32-bit x86 only specific page.
>>
>> At least it's available. And it might give us some gauge of
>> interest/activity in testing 32-bit?
>
> Well, it's possible. Speaking selfishly (as the one who's likely going
> to wind up doing it), it involves a bit more work than the other
> options. It would be included in the 'Summary' pages, I don't know if
> that's a good or a bad thing.

Yeah I forget that this isn't just a single static page, but there's
more going on with it. OK so how about doing 1 and then punt? i.e.
just wait to see who shows up for the testing party, and then decide
exactly what this i686 variant page would look like? Maybe it's a
mirror in functionality to the main one; or maybe it can just be a
static checklist?

There are quite a few things in the matrix that are considered
"likely" working for one arch if it works on the other. Whoever's
testing may end up wanting to chop up that page into something smaller
anyway, depending on their resources. If that's plausible, all the
more reason for you to not spend a lot of time on this until there's
less uncertainty. There's a good chance it'll mostly be tested in VMs
running on 64-bit hardware.



-- 
Chris Murphy
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Adam Williamson 
On Thu, 2016-01-28 at 19:23 -0700, Chris Murphy wrote:
> On Thu, Jan 28, 2016 at 6:01 PM, Adam Williamson
>  wrote:
> > On Thu, 2016-01-28 at 17:43 -0700, Chris Murphy wrote:
> > > On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson
> > >  wrote:
> > > 
> > > > 1) just ditch the i386 columns entirely; openQA can continue testing
> > > > it, and people can test manually if they want, but we don't bother
> > > > tracking the results in the validation pages
> > > 
> > > How about option 1. That leaves x86_64 and ARM only; and then where
> > > appropriate the distinction between BIOS and UEFI.
> > > 
> > > Next, duplicate that page, deleting ARM and UEFI, and changing x86_64
> > > and BIOS to i686. i.e., a 32-bit x86 only specific page.
> > > 
> > > At least it's available. And it might give us some gauge of
> > > interest/activity in testing 32-bit?
> > 
> > Well, it's possible. Speaking selfishly (as the one who's likely going
> > to wind up doing it), it involves a bit more work than the other
> > options. It would be included in the 'Summary' pages, I don't know if
> > that's a good or a bad thing.
> 
> Yeah I forget that this isn't just a single static page, but there's
> more going on with it.

To give the quick version of the implementation details, it's not a
*huge* problem - the way python-wikitcms works, when you create
validation event, you more or less automatically get result pages for
every matrix template that exists. So adding a new page is really just
a case of adding a new matrix template page, and then everything else
sort of magically happens. It's been like a year or two since I set
this stuff up so there may be some little details I forget, but that's
the big picture. So it's not a big issue, if we really think it's the
best approach.

Now I refresh my memory on the details of how the Summary page is
generated it wouldn't be a huge problem to leave a page out of the
summary if we wanted to, even. So it's all possible.

>  OK so how about doing 1 and then punt? i.e.
> just wait to see who shows up for the testing party, and then decide
> exactly what this i686 variant page would look like? Maybe it's a
> mirror in functionality to the main one; or maybe it can just be a
> static checklist?

The only issue with this, I'd say, is that of course the material we
have available affects the testing that gets done. If someone's
*really* motivated to do i686 testing they'll do it anyway. If they
don't care at all they won't. But if they're somewhere in the middle,
maybe they'll do it if the empty spaces are right there in front of
them, but not if they aren't...

Since I've built the whole whizzy clanking Wikitcms setup anyway, we
may as well use it. So if we're gonna keep i686 testing, I'd prefer to
do it in such a way that it works within the Wikitcms stuff. It's no
harder than setting up a 'static checklist' page anyway, really, now I
put my mind to remembering the details.

> There are quite a few things in the matrix that are considered
> "likely" working for one arch if it works on the other. Whoever's
> testing may end up wanting to chop up that page into something smaller
> anyway, depending on their resources. If that's plausible, all the
> more reason for you to not spend a lot of time on this until there's
> less uncertainty. There's a good chance it'll mostly be tested in VMs
> running on 64-bit hardware.

One situation I can kinda see is if we (Fedora as a whole) really make
it *look* like we're completely going away from i686 with F24 - then
see how hard the pushback is. As you said, if people *really* care,
probably the way to move forward is some kind of 'i686 SIG' or
whatever. If there's a group of people really dedicated to maintaining
and testing i686, then it gives us a clear way to move forward: we talk
to them about what would help them do the testing, and we provide it -
much as we provide the matrices and the release blocker process and
whatnot for Server and Cloud, but they clearly have or share
responsibility for doing the actual *testing*.

If it turns out there are people who complain but no-one who actually
steps up and says "yes, we are willing to test i686 and fix the bugs
that show up", then we just leave it all gone.

So, that's kind of a scenario for the 'do 1) and punt' idea, I guess.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: Fedora 24: i686 images no longer 'release blocking'

2016-01-28 Thread Adam Williamson 
On Thu, 2016-01-28 at 22:09 -0500, Felix Miata wrote:
> On one of my Athlon XP machines, yesterday after dnf updating f24 to 4.5rc
> kernel it would lock up attempting to start X. On another Athlon XP today, it
> locks up trying to boot 4.5rc kernel, before even displaying any init
> messages. F23's 4.3.x on both is OK.

That second one sounds like it's probably the same bug we're seeing in
VMs (including openQA) and some bare metal -
https://bugzilla.redhat.com/show_bug.cgi?id=1302071 .
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org