https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Christian
----- Original Message -----
From: "Paul W. Frields" stickster@gmail.com To: desktop@lists.fedoraproject.org Sent: Wednesday, August 19, 2015 2:29:46 PM Subject: Dropping i686 media for F24
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller cschalle@redhat.com wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller cschalle@redhat.com wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
On Wed, 2015-08-19 at 15:03 -0400, Paul W. Frields wrote:
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller < cschalle@redhat.com> wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
QA does indeed have to test i686, so it would be a significant reduction in effort for them at release validation time to drop i686.
On Wed, Aug 19, 2015 at 8:10 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, 2015-08-19 at 15:03 -0400, Paul W. Frields wrote:
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller < cschalle@redhat.com> wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
QA does indeed have to test i686, so it would be a significant reduction in effort for them at release validation time to drop i686.
I'm sure QA is more than capable of speaking for themselves :)
On Thu, 2015-08-20 at 12:35 +0100, Peter Robinson wrote:
On Wed, Aug 19, 2015 at 8:10 PM, Stephen Gallagher < sgallagh@redhat.com> wrote:
On Wed, 2015-08-19 at 15:03 -0400, Paul W. Frields wrote:
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller < cschalle@redhat.com> wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
QA does indeed have to test i686, so it would be a significant reduction in effort for them at release validation time to drop i686.
I'm sure QA is more than capable of speaking for themselves :)
I was speaking as someone who spends at least 8 hours every release milestone doing exactly that. And I am not alone. So yeah, it's a significant investment of time that we could reduce.
Hello,
My worry with this is that there's a lot of lower class hardware out there (thin clients, netbooks) where Fedora Workstation runs just fine and still use 32 bits CPUs. In terms of Fedora being adopted and useful for these people I do worry that just not bothering with those is going to constraint the possibilities of promoting Fedora Workstation for a certain audience in the mid run.
On Thu, Aug 20, 2015 at 1:36 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, 2015-08-20 at 12:35 +0100, Peter Robinson wrote:
On Wed, Aug 19, 2015 at 8:10 PM, Stephen Gallagher < sgallagh@redhat.com> wrote:
On Wed, 2015-08-19 at 15:03 -0400, Paul W. Frields wrote:
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller < cschalle@redhat.com> wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
QA does indeed have to test i686, so it would be a significant reduction in effort for them at release validation time to drop i686.
I'm sure QA is more than capable of speaking for themselves :)
I was speaking as someone who spends at least 8 hours every release milestone doing exactly that. And I am not alone. So yeah, it's a significant investment of time that we could reduce. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Thu, Aug 20, 2015 at 02:45:48PM +0100, Alberto Ruiz wrote:
use 32 bits CPUs. In terms of Fedora being adopted and useful for these people I do worry that just not bothering with those is going to constraint the possibilities of promoting Fedora Workstation for a certain audience in the mid run.
This is always the case. The question is: with our limited resources, do we do greater good spreading ourselves thin, or focusing that same time and effort on improving something that covers a more directed audience/use-case?
And it's not a trick question with one right answer, or which has to always go 100% in one direction -- it's a question where we can reevaluate and tweak the balance as we go.
QA does indeed have to test i686, so it would be a significant reduction in effort for them at release validation time to drop i686.
I'm sure QA is more than capable of speaking for themselves :)
Stephen is right, dropping i686 would save us a considerable amount of time. We definitely devote most of our effort to x86_64, but i686 testing is not negligible.
But even though I would appreciate having less work to do (who wouldn't), I don't want to imply Desktop SIG should drop i686 images. That's up to them to decide, based on many other factors. I don't personally don't have any strong opinion on that, when I try to look at it without my QA hat on.
On Wed, Aug 19, 2015 at 8:03 PM, Paul W. Frields stickster@gmail.com wrote:
On Wed, Aug 19, 2015 at 08:43:44PM +0200, drago01 wrote:
On Wed, Aug 19, 2015 at 8:36 PM, Christian Schaller cschalle@redhat.com wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
Its the kernel team that said that i686 bugs are low priority for them.
That was definitely a big motivator, yes. But in addition the statistics Matthew Miller showed at Flock clearly indicate the trend is against i686 for some time now. In fact, there's a good argument to be made that we haven't added any significant number of those systems in some time (years), and it's a zombie population at this point (q.v. http://jwboyer.livejournal.com/49909.html).
The overall WG response I recall is to the effect of, "If an i686 media/tree is not going to be well supported, we don't want it in the edition we ship."
I don't think it's extra rel-eng work to ship. It's not clear whether it costs QA any time, but if it doesn't I guess I'd wonder where the actual testing is happening. :-) (This is not in any way a dig at QA.) So for me, if we can't say with certainty an i686 installation is an equivalent experience to x86_64, with the same support, we shouldn't ship it.
I feel that there's still enough i686 around to make it worth continuing to ship an i686 installer. It's a single means of people being able to consume all the various bits of Fedora for those that are interested where specific products are dropped. So for example people could still run server if they so wish. While i686 has certainly dropped off I still would think it's in double percentage points of users and that's not a small amount IMO.
Peter
On Wed, Aug 19, 2015 at 7:36 PM, Christian Schaller cschalle@redhat.com wrote:
Well there seems to be more laptops/desktops still in use on i686, and it is not a lot of engineering overhead. Is there a request from release engineering to be allowed to drop i686 media? (I would assume the gains are relatively small since we would need to keep i686 packages around for some time regardless of having install media.)
No request from rel-eng here, it's no real extra work for us.
Peter
----- Original Message -----
From: "Paul W. Frields" stickster@gmail.com To: desktop@lists.fedoraproject.org Sent: Wednesday, August 19, 2015 2:29:46 PM Subject: Dropping i686 media for F24
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Paul W. Frields píše v St 19. 08. 2015 v 14:29 -0400:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/ 001661.html
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
Hi, ambassadors have not produced 32-bit Fedora DVDs since F21, we've come to a conclusion that there are not ordinary PCs and laptops which are still 32-bit CPU based and can reasonably run Fedora Workstation.
On the other hand, there are use cases when it makes sense to run a 32 -bit system on a 64-bit PC. I, for instance, installed 32-bit Fedora Workstation on an Endless PC because it only has 2 GB of memory and 32 -bit software is less memory hungry.
So I think the time for discontinuing it completely hasn't come, but I think it wouldn't be a problem to move it to the secondary architectures, right? We still provide it, but with not the same kind of assurance as 64-bit. Fedora QA wouldn't have to test it so extensively and it would free their hands for something else.
Jiri
On Mon, Aug 24, 2015 at 9:26 AM, Jiri Eischmann eischmann@redhat.com wrote:
Paul W. Frields píše v St 19. 08. 2015 v 14:29 -0400:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/ 001661.html
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
Hi, ambassadors have not produced 32-bit Fedora DVDs since F21, we've come to a conclusion that there are not ordinary PCs and laptops which are still 32-bit CPU based and can reasonably run Fedora Workstation.
On the other hand, there are use cases when it makes sense to run a 32 -bit system on a 64-bit PC. I, for instance, installed 32-bit Fedora Workstation on an Endless PC because it only has 2 GB of memory and 32 -bit software is less memory hungry.
So I think the time for discontinuing it completely hasn't come, but I think it wouldn't be a problem to move it to the secondary architectures, right? We still provide it, but with not the same kind of assurance as 64-bit. Fedora QA wouldn't have to test it so extensively and it would free their hands for something else.
"Secondary architecture" has a very specific meaning in Fedora. Once something is there, builds are asynchronous with the main koji and failures on a secondary arch do not fail builds in the main koji. It also requires them to provide and host their own build hardware (though in the case of i686 we can probably "cheat"). I don't believe secondary arch is something we can trivially do with i686 if only for multi-lib reasons.
However, not producing i686 install images is something that could be done without such a major change. That is what is being proposed.
josh
On Mon, Aug 24, 2015 at 3:26 PM, Jiri Eischmann eischmann@redhat.com wrote:
Paul W. Frields píše v St 19. 08. 2015 v 14:29 -0400:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/ 001661.html
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
Hi, ambassadors have not produced 32-bit Fedora DVDs since F21, we've come to a conclusion that there are not ordinary PCs and laptops which are still 32-bit CPU based and can reasonably run Fedora Workstation.
On the other hand, there are use cases when it makes sense to run a 32 -bit system on a 64-bit PC. I, for instance, installed 32-bit Fedora Workstation on an Endless PC because it only has 2 GB of memory and 32 -bit software is less memory hungry.
For that case a 64bit kernel + 32 bit user space would be a better choice ... but OTOH its to much of a corner case to justify the effort.
On Mon, Aug 24, 2015 at 4:26 PM, Jiri Eischmann eischmann@redhat.com wrote:
On the other hand, there are use cases when it makes sense to run a 32 -bit system on a 64-bit PC. I, for instance, installed 32-bit Fedora Workstation on an Endless PC because it only has 2 GB of memory and 32 -bit software is less memory hungry.
I think that we should set up zram by default on low memory machines, it should save a couple of megabytes at least.
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
Cheers, Kamil
[1] https://lists.fedoraproject.org/archives/list/desktop%40lists.fedoraproject.... [2] http://fedoraproject.org/wiki/Releases/24/ChangeSet [3] https://fedoraproject.org/wiki/Releases/24/Schedule
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
josh
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
I don't think they'll stop being produced/shipped unless you specifically ask releng to stop producing them, and it might be nice to have that tracked as a Change or similar indeed.
On Thu, Jan 14, 2016 at 2:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
If they are made, is QA going to commit to testing them as they have in the past even if none of the issues found are going to block the release? If so, then we have a discussion to have. If not, then I really don't see the point in shipping untested media.
(I will note that I am no longer a Workstation WG member, for clarity's sake.)
I don't think they'll stop being produced/shipped unless you specifically ask releng to stop producing them, and it might be nice to have that tracked as a Change or similar indeed.
Perhaps.
josh
On Thu, Jan 14, 2016 at 12:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 2:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
If they are made, is QA going to commit to testing them as they have in the past even if none of the issues found are going to block the release? If so, then we have a discussion to have. If not, then I really don't see the point in shipping untested media.
If it's non-blocking, QA may only incidentally tests them. Xfce spin is non-blocking. And while there is a test case for it, that doesn't mean QA makes sure that someone runs that test case. There's a pile of media and images that Fedora is shipping these days and I'd be surprised if QA is testing all of them.
On Thu, Jan 14, 2016 at 12:21 PM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jan 14, 2016 at 12:10 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 2:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
If they are made, is QA going to commit to testing them as they have in the past even if none of the issues found are going to block the release? If so, then we have a discussion to have. If not, then I really don't see the point in shipping untested media.
If it's non-blocking, QA may only incidentally tests them. Xfce spin is non-blocking. And while there is a test case for it, that doesn't mean QA makes sure that someone runs that test case. There's a pile of media and images that Fedora is shipping these days and I'd be surprised if QA is testing all of them.
Oh nevermind. Yeah, if Workstation WG is going to ship an i686 Workstation, then QA needs to test it, is what you're suggesting.
Is there any precedent for an official (blocking) product, to have an arch that is non-blocking? Fedora Server has ARM, but they block on it. So it seems like it's a grey area whether there can be such an unofficial non-blocking variant of Workstation and maybe isn't even a good idea and should be called something else. Presumably it'd go on a different page from Workstation? I think the WG should either own it completely, or walk away from it completely (it could become a spin), rather than have this less defined middle ground.
On Thu, 2016-01-14 at 12:29 -0700, Chris Murphy wrote:
Is there any precedent for an official (blocking) product, to have an arch that is non-blocking? Fedora Server has ARM, but they block on it.
There's a Workstation ARM image too, I think, that's not considered blocking.
But I don't think we really need an exact precedent, it's a pretty simple situation, it really works just like any other shipped-but-not- release-blocking media, of which we have many.
So it seems like it's a grey area whether there can be such an unofficial non-blocking variant of Workstation
I don't really see it as a grey area. Of course we can, we just...say that's what it is. All the definitions of what's 'release blocking' and what isn't are basically done by fiat, i.e. every image is just what we say it is.
I'm not saying we *ought* to do this, I don't really care either way. I'm just saying it's a valid and reasonable option.
On Thu, Jan 14, 2016 at 02:10:12PM -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 2:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
If they are made, is QA going to commit to testing them as they have in the past even if none of the issues found are going to block the release? If so, then we have a discussion to have. If not, then I really don't see the point in shipping untested media.
(I will note that I am no longer a Workstation WG member, for clarity's sake.)
I don't see how users can be well off thinking they're getting a well supported product, when we are not blocking the release for i686 issues. The majority of downloads are Workstation according to recent stats. I'd rather not have the most downloaded edition include untested media, either. I would like to discontinue shipping i686 Workstation media.
I don't think they'll stop being produced/shipped unless you specifically ask releng to stop producing them, and it might be nice to have that tracked as a Change or similar indeed.
Perhaps.
I would be happy to write up this Change page if we can get the WG to agree. Are there good reasons to hold on to shipping i686 Workstation media?
On Thu, Jan 14, 2016 at 04:55:24PM -0500, Paul W. Frields wrote:
I would be happy to write up this Change page if we can get the WG to agree. Are there good reasons to hold on to shipping i686 Workstation media?
If I remember mattdm's flock talk correctly, the statistics of downloads for 32-bit workstation are ~15% of all ISO downloads.
Zbyszek
On Thu, Jan 14, 2016 at 09:59:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 14, 2016 at 04:55:24PM -0500, Paul W. Frields wrote:
I would be happy to write up this Change page if we can get the WG to agree. Are there good reasons to hold on to shipping i686 Workstation media?
If I remember mattdm's flock talk correctly, the statistics of downloads for 32-bit workstation are ~15% of all ISO downloads.
I'm looking at the numbers I have. From the release of Fedora 21 until F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are ARM.) From F23 release to Flock, it's 20% (and 1.5% for ARM — almost 5× growth.) I don't remember right off where 15% came from. (Maybe I had a different breakdown? I honestly don't remember right now.)
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
And I say "pings" rather than downloads because we're counting top-level mirror requests, not the actual downloads, so SO MANY DINOSAURS are involved in this number.
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
One explanation for the discrepancy may be that people who have less powerful systems and therefore want i686 are less likely to be regularly connected to the Internet for updates. But that's just guesswork.
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
growth.) I don't remember right off where 15% came from. (Maybe I had a different breakdown? I honestly don't remember right now.)
Notice that I remembered halfway through writing this message, and then forgot to fix this. Time for the weekend!
On Fri, Jan 15, 2016 at 8:07 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 14, 2016 at 09:59:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 14, 2016 at 04:55:24PM -0500, Paul W. Frields wrote:
I would be happy to write up this Change page if we can get the WG to agree. Are there good reasons to hold on to shipping i686 Workstation media?
If I remember mattdm's flock talk correctly, the statistics of downloads for 32-bit workstation are ~15% of all ISO downloads.
I'm looking at the numbers I have. From the release of Fedora 21 until F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are ARM.) From F23 release to Flock, it's 20% (and 1.5% for ARM — almost 5× growth.) I don't remember right off where 15% came from. (Maybe I had a different breakdown? I honestly don't remember right now.)
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
And I say "pings" rather than downloads because we're counting top-level mirror requests, not the actual downloads, so SO MANY DINOSAURS are involved in this number.
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
One explanation for the discrepancy may be that people who have less powerful systems and therefore want i686 are less likely to be regularly connected to the Internet for updates. But that's just guesswork.
Or have multiple systems and sync down the updates once and distribute them from a local repo (satellite style).
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
On Thu, Jan 14, 2016 at 09:59:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 14, 2016 at 04:55:24PM -0500, Paul W. Frields wrote:
I would be happy to write up this Change page if we can get the WG to agree. Are there good reasons to hold on to shipping i686 Workstation media?
If I remember mattdm's flock talk correctly, the statistics of downloads for 32-bit workstation are ~15% of all ISO downloads.
One explanation for the discrepancy may be that people who have less powerful systems and therefore want i686 are less likely to be regularly connected to the Internet for updates. But that's just guesswork.
Yes, that's what I'd expect too. If you can fork out for a static internet connection, then you're also more likely to have upgraded your machine in the last ten years.
I'm looking at the numbers I have. From the release of Fedora 21 until F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
The exact number isn't terribly important. Either number supports my point: dropping i686 Workstations will _significantly_ reduce our installation base.
I know that it's hard to find volunteers to work on 32bit. I myself haven't used a non-arm 32bit machine in years. But we'd have to work a lot to increase the user base by 15% to make up this loss.
Zbyszek
On Jan 16, 2016 11:04 AM, "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl wrote:
I'm looking at the numbers I have. From the release of Fedora 21 until F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
The exact number isn't terribly important. Either number supports my point: dropping i686 Workstations will _significantly_ reduce our installation base.
I know that it's hard to find volunteers to work on 32bit. I myself haven't used a non-arm 32bit machine in years. But we'd have to work a lot to increase the user base by 15% to make up this loss.
Why?
josh
On Sat, Jan 16, 2016 at 05:09:47PM -0500, Josh Boyer wrote:
On Jan 16, 2016 11:04 AM, "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl wrote:
I'm looking at the numbers I have. From the release of Fedora 21 until F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
The exact number isn't terribly important. Either number supports my point: dropping i686 Workstations will _significantly_ reduce our installation base.
I know that it's hard to find volunteers to work on 32bit. I myself haven't used a non-arm 32bit machine in years. But we'd have to work a lot to increase the user base by 15% to make up this loss.
Why?
Why would we want to have more users in general? Why they would go away if we stop supporting their hardware? Why it will be hard to replace them?
Or more narrowly, why we would want to have this specific group of users?
I'm not sure what question you are asking, one of those, or maybe something completely different. The first three have obvious answers, and to anwer the fourth: I think it matches Fedora's foundations, and is an investment for the future. We strengthen our community by supporting people who for one reason or another are using old hardware. I presume that it's not because they want to, but because they don't have resources. At some point they will upgrade, and maybe get better internet access, and hopefully become fully contributing members of the community. "Freedom" and "friends".
Zbyszek
On Jan 16, 2016 6:23 PM, "Zbigniew Jędrzejewski-Szmek" zbyszek@in.waw.pl wrote:
On Sat, Jan 16, 2016 at 05:09:47PM -0500, Josh Boyer wrote:
On Jan 16, 2016 11:04 AM, "Zbigniew Jędrzejewski-Szmek" <
zbyszek@in.waw.pl>
wrote:
I'm looking at the numbers I have. From the release of Fedora 21
until
F22 release, 23% of all ISO "pings" are for i686. (Less than 1% are
The 15% 32-bit comes from a different data source: package update connections (again, pings, really).
The exact number isn't terribly important. Either number supports my point: dropping i686 Workstations will _significantly_ reduce our installation base.
I know that it's hard to find volunteers to work on 32bit. I myself haven't used a non-arm 32bit machine in years. But we'd have to work a lot to increase the user base by 15% to make up this loss.
Why?
Why would we want to have more users in general? Why they would go away if we stop supporting their hardware? Why it will be hard to replace them?
Or more narrowly, why we would want to have this specific group of users?
I'm not sure what question you are asking, one of those, or maybe something completely different. The first three have obvious answers, and to anwer the fourth: I think it matches Fedora's foundations, and is an investment for the future. We strengthen our community by supporting people who for one reason or another are using old hardware. I presume that it's not because they want to, but because they don't have resources. At some point they will upgrade, and maybe get better internet access, and hopefully become fully contributing members of the community. "Freedom" and "friends".
Well said. Thank you.
josh
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
I now have these updated numbers. For Workstation over the course of 2015, it's 20%. This is a lot higher than I expected given that 64-bit is given prominence on https://getfedora.org/en/workstation/download/.
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
On Wed, Jan 20, 2016 at 7:20 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
I now have these updated numbers. For Workstation over the course of 2015, it's 20%. This is a lot higher than I expected given that 64-bit is given prominence on https://getfedora.org/en/workstation/download/.
VMWare/VirtualBox are other candidates. For some reason people use the 32-bit versions of those and choose 32-bit images.
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
Were your numbers only for downloads, or were they for updates? Existing installs are a pain to convert so if the numbers included installs then you're dragging in a lot of pre-existing users.
josh
On Wed, Jan 20, 2016 at 12:24 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Jan 20, 2016 at 7:20 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
I now have these updated numbers. For Workstation over the course of 2015, it's 20%. This is a lot higher than I expected given that 64-bit is given prominence on https://getfedora.org/en/workstation/download/.
VMWare/VirtualBox are other candidates. For some reason people use the 32-bit versions of those and choose 32-bit images.
A lot of Windows instances are still 32 bit so presumably that might have some impact and presumably if the base OS is 32 bit you can only run a 32 bit guest even if underlying host is 64bit capable
On Wed, Jan 20, 2016 at 07:24:06AM -0500, Josh Boyer wrote:
Were your numbers only for downloads, or were they for updates?
These numbers are from web stats for getfedora.org. So, downloads, although the standard line about automated scripts, crawlers, etc., retries, etc., applies.
On 01/20/2016 01:20 PM, Matthew Miller wrote:
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
I wonder if this case could be fixable by replacing "Other Downloads" with "All Downloads" and sticking x86_64 in there as well.
On Wed, Jan 20, 2016 at 01:40:29PM +0100, Kalev Lember wrote:
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
I wonder if this case could be fixable by replacing "Other Downloads" with "All Downloads" and sticking x86_64 in there as well.
Yeah, not a bad suggestion for the web team. I think they like the less-cluttered look. It really would be nice to do the experiment.
On 01/20/2016 02:40 PM, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 01:40:29PM +0100, Kalev Lember wrote:
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
I wonder if this case could be fixable by replacing "Other Downloads" with "All Downloads" and sticking x86_64 in there as well.
Yeah, not a bad suggestion for the web team. I think they like the less-cluttered look. It really would be nice to do the experiment.
It just struck me that my sentence can be understood in two ways. What I meant here was to keep both the green button with the primary download, but at the same time put the primary download to the list of "All Downloads" as well.
I'm sure everybody understood it that way already, just wanted to clarify it so that nobody could take it out of context later and say I wanted to get rid of the big green primary download button :)
On Wed, Jan 20, 2016 at 04:11:32PM +0100, Kalev Lember wrote:
I wonder if this case could be fixable by replacing "Other Downloads" with "All Downloads" and sticking x86_64 in there as well.
Yeah, not a bad suggestion for the web team. I think they like the less-cluttered look. It really would be nice to do the experiment.
It just struck me that my sentence can be understood in two ways. What I meant here was to keep both the green button with the primary download, but at the same time put the primary download to the list of "All Downloads" as well.
I'm sure everybody understood it that way already, just wanted to clarify it so that nobody could take it out of context later and say I wanted to get rid of the big green primary download button :)
I understood, I think. :) See https://getfedora.org/en/cloud/download/ for an example of how putting duplicate links to All where Other is now would be really messy.
So I just read meeting minutes, and I think the WG should look into 64-bit kernel + 32-bit everything else. With that, there's a supported kernel. The i686 images will be created no matter what, per releng's comments, so they might as well be in a supportable condition.
This also means not quiting i686 cold turkey. And while unsupported, is not impracticle for users to tack on a 32-bit kernel themselves if they really have 32-bit only x86 hardware (if 32-bit kernels will continue being built, which arguably they shouldn't be if they can't be supported).
This is the path of least resistance and change. And acknowledges kernel team's concern/limitations.
I think status quo (32-bit kernel) is risky. It could turn out worse than dropping i686 altogether.
Chris Murphy
On Wed, 2016-01-20 at 19:15 +0000, Chris Murphy wrote:
So I just read meeting minutes, and I think the WG should look into 64-bit kernel + 32-bit everything else. With that, there's a supported kernel. The i686 images will be created no matter what, per releng's comments, so they might as well be in a supportable condition.
The problem with doing this, at least back in the yum era, is that yum derives its notion of host CPU architecture from that of the kernel (though whether that was by looking at package arch or uname I'm no longer able to recall), so the first 'yum upgrade' you ran would archgrade you to x86_64. So this would almost certainly require some support from the package manager.
In a more theoretical sense, really the set of kernel interfaces that can be _expected_ to work correctly in a U32/K64 setup are the interfaces that the i686 builders hit in the process of building packages, which is probably quite a bit less than the set a real desktop would use. That's not an argument against, necessarily, but I'd expect to hit at least a few sui generis bugs if I tried to use such a beast.
- ajax
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Christian
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, January 20, 2016 7:20:50 AM Subject: Re: Dropping i686 media for F24
On Fri, Jan 15, 2016 at 03:07:25PM -0500, Matthew Miller wrote:
(I'd bug Smooge for different slicing and updated numbers, but he's busy doing datacenter stuff this week and I've already overbugged him.)
I now have these updated numbers. For Workstation over the course of 2015, it's 20%. This is a lot higher than I expected given that 64-bit is given prominence on https://getfedora.org/en/workstation/download/.
(Although I wonder if it has something to with people skipping past the header and green button when looking for something to click, and going right to the "Other Downloads" column. It'd be interesting to do some web design A/B testing....)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Wed, Jan 20, 2016 at 9:01 AM, Christian Schaller cschalle@redhat.com wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Do you foresee options to build images for machines other than the one the tooling is running on (generic images or otherwise)? I would think that the common case is one image download and then use that on multiple machines, not all of which may be 64-bit or similar in GPU, etc.
josh
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
Change request Not filed yet, Jiri can you file a change request for this?
Christian
----- Original Message ----- From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, January 20, 2016 9:24:28 AM Subject: Re: Dropping i686 media for F24
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
There is already a change page for it: https://fedoraproject.org/wiki/C hanges/LiveUsbCreatorFacelift So I suppose I'll just update it.
Jiri
Christian Schaller píše v St 20. 01. 2016 v 14:18 -0500:
Change request Not filed yet, Jiri can you file a change request for this?
Christian
----- Original Message ----- From: "Matthew Miller" mattdm@fedoraproject.org To: "Discussions about development for the Fedora desktop" <desktop@l ists.fedoraproject.org> Sent: Wednesday, January 20, 2016 9:24:28 AM Subject: Re: Dropping i686 media for F24
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
On Thu, Jan 21, 2016 at 01:28:38PM +0100, Jiri Eischmann wrote:
There is already a change page for it: https://fedoraproject.org/wiki/C hanges/LiveUsbCreatorFacelift So I suppose I'll just update it.
Yeah, the change kind of undersells the idea of changing the primary deliverable. It just says "Design: Make the live-usb-creator a prominent download option on getfedora.org". Christian is suggesting a much bigger role than that, which has big implications for Scope.
I think it's a great idea (assuming the improved software addresses Adam's concerns), but let's not underestimate the impact. Both Design and Websites need to be involved in the actual change, and there's probably _something_ for Release Engineering, and it's a whole new thing for QA to worry about. And it will affect my metrics tracking, as well.
Matthew Miller píše v Čt 21. 01. 2016 v 07:40 -0500:
On Thu, Jan 21, 2016 at 01:28:38PM +0100, Jiri Eischmann wrote:
There is already a change page for it: https://fedoraproject.org/wi ki/C hanges/LiveUsbCreatorFacelift So I suppose I'll just update it.
Yeah, the change kind of undersells the idea of changing the primary deliverable. It just says "Design: Make the live-usb-creator a prominent download option on getfedora.org". Christian is suggesting a much bigger role than that, which has big implications for Scope.
I think it's a great idea (assuming the improved software addresses Adam's concerns), but let's not underestimate the impact. Both Design and Websites need to be involved in the actual change, and there's probably _something_ for Release Engineering, and it's a whole new thing for QA to worry about. And it will affect my metrics tracking, as well.
Well, let's assess feasibility of such a big change. If it's too big for one release. We can do it in two steps:
F24: the download page can still offer images to download and there will be just a link to Live USB Creator in the "What is a Live image?" section.
F25: the download page will primarily offer the Live USB Creator for download.
Jiri
Matthew Miller píše v Čt 21. 01. 2016 v 07:40 -0500:
On Thu, Jan 21, 2016 at 01:28:38PM +0100, Jiri Eischmann wrote:
There is already a change page for it: https://fedoraproject.org/wi ki/C hanges/LiveUsbCreatorFacelift So I suppose I'll just update it.
Yeah, the change kind of undersells the idea of changing the primary deliverable. It just says "Design: Make the live-usb-creator a prominent download option on getfedora.org". Christian is suggesting a much bigger role than that, which has big implications for Scope.
I think it's a great idea (assuming the improved software addresses Adam's concerns), but let's not underestimate the impact. Both Design and Websites need to be involved in the actual change, and there's probably _something_ for Release Engineering, and it's a whole new thing for QA to worry about. And it will affect my metrics tracking, as well.
OK, I've created a new change proposal that reflects the scope of the change more: https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloa dable
Help me improve it. The deadline for F24 changes is Tue Jan 26th, so we still have a couple of days to work on it.
Jiri
On Fri, Jan 22, 2016 at 04:41:31PM +0100, Jiri Eischmann wrote:
Matthew Miller píše v Čt 21. 01. 2016 v 07:40 -0500:
On Thu, Jan 21, 2016 at 01:28:38PM +0100, Jiri Eischmann wrote:
There is already a change page for it: https://fedoraproject.org/wi ki/C hanges/LiveUsbCreatorFacelift So I suppose I'll just update it.
Yeah, the change kind of undersells the idea of changing the primary deliverable. It just says "Design: Make the live-usb-creator a prominent download option on getfedora.org". Christian is suggesting a much bigger role than that, which has big implications for Scope.
I think it's a great idea (assuming the improved software addresses Adam's concerns), but let's not underestimate the impact. Both Design and Websites need to be involved in the actual change, and there's probably _something_ for Release Engineering, and it's a whole new thing for QA to worry about. And it will affect my metrics tracking, as well.
OK, I've created a new change proposal that reflects the scope of the change more: https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloa dable
Help me improve it. The deadline for F24 changes is Tue Jan 26th, so we still have a couple of days to work on it.
One big thing I see missing here is the expected QA work. To make LUC our primary downloadable we should logically have associated release criteria. What are the expected cases that must work, i.e. blockers for release? I could see that as a host OS matrix for each expected action; IOW there might be differences based on the OS where the user runs LUC (or maybe not).
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear. OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
On Mon, Jan 25, 2016 at 9:59 AM, Paul W. Frields stickster@gmail.com wrote:
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear. OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
Well if LUC is blocking on Linux, Windows, and OS X, that's three rows added to a matrix that has the same number of column as the total number of release blocking media per arch. So that's possibly a lot more testing, even if the only thing used by LUC on the backend is wipefs and dd. If it's different from dd in any way, then LUC tests can't be used as a substitute for testing with dd alone, because it couldn't be dropped as a release blocking method for media creation.
The media erase/restore option should probably be a non-blocking testcase.
If there's going to be a persistent overlay optional, it should also be non-blocking.
On Mon, 2016-01-25 at 13:20 -0700, Chris Murphy wrote:
On Mon, Jan 25, 2016 at 9:59 AM, Paul W. Frields stickster@gmail.com wrote:
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear. OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
Well if LUC is blocking on Linux, Windows, and OS X, that's three rows added to a matrix that has the same number of column as the total number of release blocking media per arch.
Well no it's not, because we already have one row for luc in the matrix. And we really haven't clearly defined in exactly what circumstances we expect luc to work; you can argue under the current criteria that we *already* require it to work on Fedora and Windows, since the wiki page on USB writing (which the criteria links to) lists it as a recommended tool for those platforms. If the current luc actually ran on OS X we'd probably list it for OS X too.
On Tue, Jan 26, 2016 at 12:32 AM, Adam Williamson adamwill@fedoraproject.org wrote:
What would actually be an *improvement* is if we killed litd and luc's 'cp mode', and only supported the new dd-only luc and dd-style writes. That would substantially reduce the exposure we currently have to three different writing modes: dd, litd, and luc-cp.
Yes tons.
On Mon, 2016-01-25 at 13:20 -0700, Chris Murphy wrote:
Well if LUC is blocking on Linux, Windows, and OS X, that's three rows added to a matrix that has the same number of column as the total number of release blocking media per arch.
Well no it's not, because we already have one row for luc in the matrix. And we really haven't clearly defined in exactly what circumstances we expect luc to work; you can argue under the current criteria that we *already* require it to work on Fedora and Windows, since the wiki page on USB writing (which the criteria links to) lists it as a recommended tool for those platforms. If the current luc actually ran on OS X we'd probably list it for OS X too.
OK.
I can see blocking on Windows LUC, because how else do they make media? If we really got down to blocking on OS X or Fedora LUC would we really block, or just expect people to use litd or dd?
And if any would block, does it make more sense to use Accepted0Day, rather than actually hold up the release?
On Tue, 2016-01-26 at 01:31 -0700, Chris Murphy wrote:
OK.
I can see blocking on Windows LUC, because how else do they make media? If we really got down to blocking on OS X or Fedora LUC would we really block, or just expect people to use litd or dd?
Well, if we're talking about the glorious future where the new-age LUC is the one promoted tool, it'd have a strong claim to be a blocker.
And if any would block, does it make more sense to use Accepted0Day, rather than actually hold up the release?
That's not necessarily an either/or proposition. It would certainly be a non-media blocker, but that doesn't necessarily mean it wouldn't hold up the release. What exactly the process we follow for non-media blockers should *be* is something that's under discussion right now.
On Mon, 2016-01-25 at 11:59 -0500, Paul W. Frields wrote:
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear.
Actually we are, though we have been known to handwave it a little:
"Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
from https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria%C2%A0, it's the first footnote to "Release-blocking images must boot", titled "Supported media types". So the official rule is that we block on all three 'officially supported methods' - dd-style write, litd, and luc. There's a bunch of wiggle room in terms of exactly how well we expect luc to work, and what exactly it means to 'block a release' on something that is not part of the release, but the criterion is there.
OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
What would actually be an *improvement* is if we killed litd and luc's 'cp mode', and only supported the new dd-only luc and dd-style writes. That would substantially reduce the exposure we currently have to three different writing modes: dd, litd, and luc-cp.
On Mon, Jan 25, 2016 at 11:28:25PM -0800, Adam Williamson wrote:
On Mon, 2016-01-25 at 11:59 -0500, Paul W. Frields wrote:
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear.
Actually we are, though we have been known to handwave it a little:
Thanks for the correction.
"Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
from https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria%C2%A0, it's the first footnote to "Release-blocking images must boot", titled "Supported media types". So the official rule is that we block on all three 'officially supported methods' - dd-style write, litd, and luc. There's a bunch of wiggle room in terms of exactly how well we expect luc to work, and what exactly it means to 'block a release' on something that is not part of the release, but the criterion is there.
In a recent release (maybe a year ago?) I recall we discussed whether we needed to pull out some stops to fix a LUC issue. I think my confusion about blocking may have come from that (sorry, it's hazy and I've no time to play email archaeology at the moment). :-)
But as you mention below, I agree we should cut down on the different vectors here, and do a better job of supporting one.
OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
What would actually be an *improvement* is if we killed litd and luc's 'cp mode', and only supported the new dd-only luc and dd-style writes. That would substantially reduce the exposure we currently have to three different writing modes: dd, litd, and luc-cp.
Agreed -- I think I heard (maybe elsewhere in this thread?) that the plan was to remove the cp option in LUC, but I'll check with mbriza.
On Tue, 26 Jan 2016 18:19:41 +0100, Paul W. Frields stickster@gmail.com wrote:
On Mon, Jan 25, 2016 at 11:28:25PM -0800, Adam Williamson wrote:
On Mon, 2016-01-25 at 11:59 -0500, Paul W. Frields wrote:
IIRC we aren't blocking on LUC currently -- so whether this means reviving old criteria or creating new ones, that needs to be clear.
Actually we are, though we have been known to handwave it a little:
Thanks for the correction.
"Release-blocking live and dedicated installer images must boot when written to optical media of an appropriate size (if applicable) and when written to a USB stick with any of the officially supported methods."
from https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria , it's the first footnote to "Release-blocking images must boot", titled "Supported media types". So the official rule is that we block on all three 'officially supported methods' - dd-style write, litd, and luc. There's a bunch of wiggle room in terms of exactly how well we expect luc to work, and what exactly it means to 'block a release' on something that is not part of the release, but the criterion is there.
In a recent release (maybe a year ago?) I recall we discussed whether we needed to pull out some stops to fix a LUC issue. I think my confusion about blocking may have come from that (sorry, it's hazy and I've no time to play email archaeology at the moment). :-)
But as you mention below, I agree we should cut down on the different vectors here, and do a better job of supporting one.
OTOH, the functions of LUC are pretty well constrained. So maybe this isn't too large a change.
What would actually be an *improvement* is if we killed litd and luc's 'cp mode', and only supported the new dd-only luc and dd-style writes. That would substantially reduce the exposure we currently have to three different writing modes: dd, litd, and luc-cp.
Agreed -- I think I heard (maybe elsewhere in this thread?) that the plan was to remove the cp option in LUC, but I'll check with mbriza.
To avoid the communication ping pong on IRC:
Yes, I'm removing the cp support from the code now in the feature/onlydd branch [1]. While I don't say the feature won't be reintroduced in the future, for now the features (and workflow) for LUC will be as follows: 1) List available Fedora Products/Spins/Labs for the current release - this will be updated automatically 2) Display additional information (text, screenshots, size, release date) for each Product/Spin/Lab 3) Allow the user to download the image directly through the UI 4) Then transparently write the image (or any other ISO from the user's drive) to a flash drive using dd (should work on Windows too) 5) When a flash drive that contains an image is inserted, show an option to fix its partition table (writing ISOs with dd breaks it) and format it to FAT32
Regarding 1 and 2: The information is now extracted from the websites like getfedora.org, including links to the ISO downloads.
5 is not implemented yet - I'm going to write the backend code at least for Linux today and then put up some makeshift UI before consulting and smoothing the design with jimmac.
Regarding testing, there's quite a number of combinations possible and most of them will require you to have a Mac and a "regular PC" both probably (not mentioning dual-boot to Windows), as I assume these two are not considered equivalent from our POV. Anyway, when dd is used, it should be pretty error-proof - and testing LUC and dd would be basically the same thing.
[1] https://github.com/lmacken/liveusb-creator/tree/feature/onlydd
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection, or download ISOs? I thought you had to point it to an ISO file. I was thinking of something like bfo except it does some kind of GPU detection.
On Wed, 2016-01-20 at 15:39 -0700, Chris Murphy wrote:
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection,
No, but Christian wrote "we could try to build" that, he didn't say we already had it.
or download ISOs? I thought you had to point it to an ISO file.
luc does do downloads - you *can* point it at a file, but it also has both a built-in list of images it can download and write, and a remote URL it queries for an updated list when you hit a 'refresh' button (it should really pull the list on startup if you're connected to the internet, but it doesn't, I tried to fix this once and failed, maybe I should take another shot).
On Thu, 21 Jan 2016 09:37:46 +0100, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 15:39 -0700, Chris Murphy wrote:
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports
it,
and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind
of
thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing
Fedora
users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection,
No, but Christian wrote "we could try to build" that, he didn't say we already had it.
or download ISOs? I thought you had to point it to an ISO file.
luc does do downloads - you *can* point it at a file, but it also has both a built-in list of images it can download and write, and a remote URL it queries for an updated list when you hit a 'refresh' button (it should really pull the list on startup if you're connected to the internet, but it doesn't, I tried to fix this once and failed, maybe I should take another shot).
Hey, I've been working on the facelift for a while now. I think most of this leering is caused by the fact it's not promoted very well (except a bunch of mails to Desktop and Devel lists I sent in the past). Except not being able to add a (buggy) permanent overlay for your files, it has every feature of the old tool and it works better - and it actually has the up-to-date list of Fedora Products/Spins/Labs. There are some URLs [0] with videos [2] and packages [1] in the bottom of this mail. It is packaged for Fedora of course (but the new version is just in my COPR - However. I'm planning to push it to updates-testing for some early adopters). Windows builds from Linux are possible (and available) too. Currently, I'm writing a Mac backend to the tool, which is kinda challenging provided there's no up-to-date version of syslinux. It's possible we'll be able to only dd on Mac. Anyway as always, I'm open to every kind of feedback so please hit me with anything you have on mind.
Martin
[0] https://github.com/lmacken/liveusb-creator [1] https://copr.fedoraproject.org/coprs/mbriza/liveusb-creator/ [2] https://mbriza.fedorapeople.org/liveusb-11.ogv - a bit old, there is a couple of things missing, like the information on what release are you going to download
On Thu, Jan 21, 2016 at 7:59 AM, Martin Bříza mbriza@redhat.com wrote:
Currently, I'm writing a Mac backend to the tool, which is kinda challenging provided there's no up-to-date version of syslinux. It's possible we'll be able to only dd on Mac.
This part is confusing to me. syslinux hasn't ever been used on Macs, why would it be now? Actually, why wouldn't LUC just dd *any* ISO to the USB stick so that we're assured that the same layout on the ISO is on the stick? If there's a completely different layout, that means changing bootloader configuration files, and that's now a lot more testing combinations. I don't see that as being more reliable than LUC using dd on the backend.That's actually a big part of what's made it so unreliable in the past, in my opinion. It pulls apart all the work done to make the ISO boot pretty much everything under the sun, reinvents the wheel, and then the wheel breaks on some edge case that turns out to be decently common.
On Thu, 2016-01-21 at 15:59 +0100, Martin Bříza wrote:
Hey, I've been working on the facelift for a while now. I think most of this leering is caused by the fact it's not promoted very well (except a bunch of mails to Desktop and Devel lists I sent in the past). Except not being able to add a (buggy) permanent overlay for your files,
...
Currently, I'm writing a Mac backend to the tool, which is kinda challenging provided there's no up-to-date version of syslinux. It's possible we'll be able to only dd on Mac.
FWIW, I think a sane design for luc in this day and age should be dd only. IIRC the *only* benefits of the non-dd mode are:
1) allow for non-destructive write 2) allow for overlays (persistence)
My opinion is that 1) is entirely uninteresting these days. It made sense back when USB sticks cost 50 bucks. It doesn't make sense when you get them free with a box of Cap'n Crunch and everyone has fifty of them stuck down the back of the couch.
2) is more interesting, but if it doesn't work anyway...well :) it's a bit fuzzy in my mind, but IIRC someone said it was entirely feasible to do overlays with a dd write; basically you'd write the image with dd then fiddle about a bit afterwards to create the overlays. That seems like something worth exploring.
Another note - I don't know if this is already how it's designed, but I think it would be *really* nice if an overhaul of luc including making it somewhat generic/modular: i.e. things like the list of image downloads and branding should be modules, so that the tool could be shared between distributions. Most distros produce hybridized ISOs these days and to me it'd make a whole lot of sense if we all collaborated on *one* graphical tool for downloading ISOs and writing them to USB sticks, rather than having a dozen different ones.
On Thu, 21 Jan 2016 22:03:35 +0100, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-21 at 15:59 +0100, Martin Bříza wrote:
Hey, I've been working on the facelift for a while now. I think most of this leering is caused by the fact it's not promoted very well (except a bunch of mails to Desktop and Devel lists I sent in the past). Except not being able to add a (buggy) permanent overlay for your files,
...
Currently, I'm writing a Mac backend to the tool, which is kinda challenging provided there's no up-to-date version of syslinux. It's possible we'll be able to only dd on Mac.
FWIW, I think a sane design for luc in this day and age should be dd only. IIRC the *only* benefits of the non-dd mode are:
- allow for non-destructive write
- allow for overlays (persistence)
My opinion is that 1) is entirely uninteresting these days. It made sense back when USB sticks cost 50 bucks. It doesn't make sense when you get them free with a box of Cap'n Crunch and everyone has fifty of them stuck down the back of the couch.
- is more interesting, but if it doesn't work anyway...well :) it's a
bit fuzzy in my mind, but IIRC someone said it was entirely feasible to do overlays with a dd write; basically you'd write the image with dd then fiddle about a bit afterwards to create the overlays. That seems like something worth exploring.
Another note - I don't know if this is already how it's designed, but I think it would be *really* nice if an overhaul of luc including making it somewhat generic/modular: i.e. things like the list of image downloads and branding should be modules, so that the tool could be shared between distributions. Most distros produce hybridized ISOs these days and to me it'd make a whole lot of sense if we all collaborated on *one* graphical tool for downloading ISOs and writing them to USB sticks, rather than having a dozen different ones.
1) Is not really a reason for non-destructive image writing - I'd say there's a third reason - it's hard to revert the iso partition scheme, as I mentioned in an other mail to Christian in this thread.
2) Yeah, adding another patition could be done quite easily I think, at least in Linux and on Mac. Probably more reliably too. Not sure how to solve this from inside the live image though.
Ad. modularity: It's pretty generic in my opinion - there is an occasional Fedora string here and there but overall these would be easy to remove. If you'd want to add your own distro/product/whatever, you'd just have to write your own provider of links to images, along with their descriptions and optionally some additional data like release date, version or links to screenshots. For Fedora, this is done by a PyQuery parser of the getfedora.org websites, that harvests all text that's stored there to present it in LUC too. You could possibly do that for other distros too if you'd want. Depends if folks from the other distros notice this and decide it's useful to them. I guess we could cooperate but until then, Fedora only.
On Fri, 2016-01-22 at 14:35 +0100, Martin Bříza wrote:
- Is not really a reason for non-destructive image writing - I'd say
there's a third reason - it's hard to revert the iso partition scheme, as I mentioned in an other mail to Christian in this thread.
That's a reasonable point indeed, but I like your proposed solution: simply have a 'restore this to being a regular data stick' button in the luc interface. Seems like the best approach to me.
- Yeah, adding another patition could be done quite easily I think, at
least in Linux and on Mac. Probably more reliably too. Not sure how to solve this from inside the live image though.
I'm afraid I don't know either, all the overlay stuff is ancient black magic I've never dug into :(
Ad. modularity: It's pretty generic in my opinion - there is an occasional Fedora string here and there but overall these would be easy to remove. If you'd want to add your own distro/product/whatever, you'd just have to write your own provider of links to images, along with their descriptions and optionally some additional data like release date, version or links to screenshots. For Fedora, this is done by a PyQuery parser of the getfedora.org websites, that harvests all text that's stored there to present it in LUC too. You could possibly do that for other distros too if you'd want. Depends if folks from the other distros notice this and decide it's useful to them. I guess we could cooperate but until then, Fedora only.
All distros which ship hybridized ISOs really *need* a tool like this; I've actually poked through the docs for most distros and they all have some kind of instructions for doing a dd-style write on Windows and OS X, and they all kinda suck just like ours. So I think a shared tool with good cross-OS support would be a huge win for all of us. I included links to the support pages for the major distros here:
https://www.happyassassin.net/2014/02/04/more-on-booting-a-practical-fedora-...
you can see from that that we're all promoting a kind of mish-mash of non-purpose-built tools which don't really give a great user experience overall.
- Is not really a reason for non-destructive image writing - I'd say
there's a third reason - it's hard to revert the iso partition scheme, as I mentioned in an other mail to Christian in this thread.
That's a reasonable point indeed, but I like your proposed solution: simply have a 'restore this to being a regular data stick' button in the luc interface. Seems like the best approach to me.
I have the same opinion. Presenting the user with choice "create a $DISTRO installer" / "reset back to a regular USB drive" is simple to understand and users will remember to return back to the program if it is presented properly.
Ad. modularity: It's pretty generic in my opinion - there is an occasional Fedora string here and there but overall these would be easy to remove. If you'd want to add your own distro/product/whatever, you'd just have to write your own provider of links to images, along with their descriptions and optionally some additional data like release date, version or links to screenshots. For Fedora, this is done by a PyQuery parser of the getfedora.org websites, that harvests all text that's stored there to present it in LUC too. You could possibly do that for other distros too if you'd want. Depends if folks from the other distros notice this and decide it's useful to them. I guess we could cooperate but until then, Fedora only.
All distros which ship hybridized ISOs really *need* a tool like this; I've actually poked through the docs for most distros and they all have some kind of instructions for doing a dd-style write on Windows and OS X, and they all kinda suck just like ours. So I think a shared tool with good cross-OS support would be a huge win for all of us.
Getting more distros on board would be a great win. With enough publicity, maybe people would finally forget about the broken unetbootin.
Adam Williamson píše v Pá 22. 01. 2016 v 11:43 -0800:
On Fri, 2016-01-22 at 14:35 +0100, Martin Bříza wrote:
- Is not really a reason for non-destructive image writing - I'd
say there's a third reason - it's hard to revert the iso partition scheme, as I mentioned in an other mail to Christian in this thread.
That's a reasonable point indeed, but I like your proposed solution: simply have a 'restore this to being a regular data stick' button in the luc interface. Seems like the best approach to me.
- Yeah, adding another patition could be done quite easily I
think, at least in Linux and on Mac. Probably more reliably too. Not sure how to solve this from inside the live image though.
I'm afraid I don't know either, all the overlay stuff is ancient black magic I've never dug into :(
Ad. modularity: It's pretty generic in my opinion - there is an occasional Fedora string here and there but overall these would be easy to remove. If you'd want to add your own distro/product/whatever, you'd just have to write your own provider of links to images, along with their descriptions and optionally some additional data like release date, version or links to screenshots. For Fedora, this is done by a PyQuery parser of the getfedora.org websites, that harvests all text that's stored there to present it in LUC too. You could possibly do that for other distros too if you'd want. Depends if folks from the other distros notice this and decide it's useful to them. I guess we could cooperate but until then, Fedora only.
All distros which ship hybridized ISOs really *need* a tool like this; I've actually poked through the docs for most distros and they all have some kind of instructions for doing a dd-style write on Windows and OS X, and they all kinda suck just like ours. So I think a shared tool with good cross-OS support would be a huge win for all of us. I included links to the support pages for the major distros here:
https://www.happyassassin.net/2014/02/04/more-on-booting-a-practical- fedora-uefi-guide-and-dont-use-universal-usb-stick-writers/
you can see from that that we're all promoting a kind of mish-mash of non-purpose-built tools which don't really give a great user experience overall.
Having one finalized tool for all distributions is frankly a no-go for me. The last thing I wanna have is a tool that people download at getfedora.org and that offers them a list of distributions including our competition. That would not be wise. Having some common base which every distribution would use to build their own branded LUC on? Why not, but it's definitely not in the scope of the current initiative. We will be glad if we have it ready for Fedora by 24. And I also think it's in the interest of other distributions to drive the project in that direction, we're not the ones to create the demand.
Jiri
On Thu, 2016-01-28 at 18:39 +0100, Jiri Eischmann wrote:
All distros which ship hybridized ISOs really *need* a tool like this; I've actually poked through the docs for most distros and they all have some kind of instructions for doing a dd-style write on Windows and OS X, and they all kinda suck just like ours. So I think a shared tool with good cross-OS support would be a huge win for all of us. I included links to the support pages for the major distros here:
https://www.happyassassin.net/2014/02/04/more-on-booting-a-practical- fedora-uefi-guide-and-dont-use-universal-usb-stick-writers/
you can see from that that we're all promoting a kind of mish-mash of non-purpose-built tools which don't really give a great user experience overall.
Having one finalized tool for all distributions is frankly a no-go for me. The last thing I wanna have is a tool that people download at getfedora.org and that offers them a list of distributions including our competition. That would not be wise.
That's not the idea.
Having some common base which every distribution would use to build their own branded LUC on?
That's the idea. The important bits of the tool are generic, anyway - the actual writing (and restoring) code (and if we ever get to the point of writing them, the overlay bits - or if there's distro specificity to this, it can be made one of the modular bits). The branding and the list of images for download can very easily be made modular, such that they can be specified as part of a build step. Then each distro can have its own 'personalized' package and/or executable distribution(s), but it's really the same tool under the covers, we aren't all wasting time working on a dozen bad implementations of the same thing.
Why not, but it's definitely not in the scope of the current initiative. We will be glad if we have it ready for Fedora by 24. And I also think it's in the interest of other distributions to drive the project in that direction, we're not the ones to create the demand.
I think it's in *everyone's* interests for distributions to collaborate where it makes sense. A decent USB writing tool is just a box all distros should be checking, and which we're currently all not checking while simultaneously wastefully spending separate resources on. A USB writing tool is really not a big enough deal to be a 'selling point' for a distribution, it's something we should just get together and maintain collaboratively to be more efficient and avoid the situation where we all have a half-assed tool that isn't maintained half the time and so people wind up using unetbootin or Rufus, failing, and deciding Linux sucks.
On Thu, 2016-01-28 at 12:09 -0800, Adam Williamson wrote:
I think it's in *everyone's* interests for distributions to collaborate where it makes sense. A decent USB writing tool is just a box all distros should be checking, and which we're currently all not checking while simultaneously wastefully spending separate resources on. A USB writing tool is really not a big enough deal to be a 'selling point' for a distribution, it's something we should just get together and maintain collaboratively to be more efficient and avoid the situation where we all have a half-assed tool that isn't maintained half the time and so people wind up using unetbootin or Rufus, failing, and deciding Linux sucks.
Hell, if we did it right, maybe we could kill rufus and unetbootin, at least for Linux purposes. Some third party could do a build of the tool with generic branding, and combining all the distro image lists. It seems that third-party USB writing tools are going to exist no matter what we do; if that's the case I'd much rather have one which was just a build of sensible, dd-style code we have a hand in maintaining, rather than the pile of crappy fail that is unetbootin.
On Thu, Jan 28, 2016 at 1:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-28 at 12:09 -0800, Adam Williamson wrote:
I think it's in *everyone's* interests for distributions to collaborate where it makes sense. A decent USB writing tool is just a box all distros should be checking, and which we're currently all not checking while simultaneously wastefully spending separate resources on. A USB writing tool is really not a big enough deal to be a 'selling point' for a distribution, it's something we should just get together and maintain collaboratively to be more efficient and avoid the situation where we all have a half-assed tool that isn't maintained half the time and so people wind up using unetbootin or Rufus, failing, and deciding Linux sucks.
Hell, if we did it right, maybe we could kill rufus and unetbootin, at least for Linux purposes. Some third party could do a build of the tool with generic branding, and combining all the distro image lists. It seems that third-party USB writing tools are going to exist no matter what we do; if that's the case I'd much rather have one which was just a build of sensible, dd-style code we have a hand in maintaining, rather than the pile of crappy fail that is unetbootin.
Whoaa! Calm down! That is such high order wishful thinking. I love this kind of irrational exuberance though. Getting older is so much fun.
Then: Cool! I just invented the goddamn wheel! BadASS!
Now: Make it go. And, make it go, without poking me in the eyeball.
On Thu, 2016-01-28 at 13:42 -0700, Chris Murphy wrote:
On Thu, Jan 28, 2016 at 1:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-28 at 12:09 -0800, Adam Williamson wrote:
I think it's in *everyone's* interests for distributions to collaborate where it makes sense. A decent USB writing tool is just a box all distros should be checking, and which we're currently all not checking while simultaneously wastefully spending separate resources on. A USB writing tool is really not a big enough deal to be a 'selling point' for a distribution, it's something we should just get together and maintain collaboratively to be more efficient and avoid the situation where we all have a half-assed tool that isn't maintained half the time and so people wind up using unetbootin or Rufus, failing, and deciding Linux sucks.
Hell, if we did it right, maybe we could kill rufus and unetbootin, at least for Linux purposes. Some third party could do a build of the tool with generic branding, and combining all the distro image lists. It seems that third-party USB writing tools are going to exist no matter what we do; if that's the case I'd much rather have one which was just a build of sensible, dd-style code we have a hand in maintaining, rather than the pile of crappy fail that is unetbootin.
Whoaa! Calm down! That is such high order wishful thinking. I love this kind of irrational exuberance though. Getting older is so much fun.
Then: Cool! I just invented the goddamn wheel! BadASS!
Now: Make it go. And, make it go, without poking me in the eyeball.
We're already writing all the hard bits. Making it possible to switch out the branding and the image metadata location really isn't a hard problem.
(OK, you can have lots of fun deciding on a format for the image metadata that makes all the distros happy, but that's what mailing lists are for...)
On Thu, Jan 28, 2016 at 3:50 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-28 at 13:42 -0700, Chris Murphy wrote:
On Thu, Jan 28, 2016 at 1:12 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2016-01-28 at 12:09 -0800, Adam Williamson wrote:
I think it's in *everyone's* interests for distributions to collaborate where it makes sense. A decent USB writing tool is just a box all distros should be checking, and which we're currently all not checking while simultaneously wastefully spending separate resources on. A USB writing tool is really not a big enough deal to be a 'selling point' for a distribution, it's something we should just get together and maintain collaboratively to be more efficient and avoid the situation where we all have a half-assed tool that isn't maintained half the time and so people wind up using unetbootin or Rufus, failing, and deciding Linux sucks.
Hell, if we did it right, maybe we could kill rufus and unetbootin, at least for Linux purposes. Some third party could do a build of the tool with generic branding, and combining all the distro image lists. It seems that third-party USB writing tools are going to exist no matter what we do; if that's the case I'd much rather have one which was just a build of sensible, dd-style code we have a hand in maintaining, rather than the pile of crappy fail that is unetbootin.
Whoaa! Calm down! That is such high order wishful thinking. I love this kind of irrational exuberance though. Getting older is so much fun.
Then: Cool! I just invented the goddamn wheel! BadASS!
Now: Make it go. And, make it go, without poking me in the eyeball.
We're already writing all the hard bits. Making it possible to switch out the branding and the image metadata location really isn't a hard problem.
(OK, you can have lots of fun deciding on a format for the image metadata that makes all the distros happy, but that's what mailing lists are for...)
Adam, I was teasing. I'm in so much agreement with the logic and the end result you're suggesting, that if asked I'll claim I'm the original proponent.
On Thu, Jan 21, 2016 at 12:37:46AM -0800, Adam Williamson wrote:
On Wed, 2016-01-20 at 15:39 -0700, Chris Murphy wrote:
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection,
No, but Christian wrote "we could try to build" that, he didn't say we already had it.
or download ISOs? I thought you had to point it to an ISO file.
luc does do downloads - you *can* point it at a file, but it also has both a built-in list of images it can download and write, and a remote URL it queries for an updated list when you hit a 'refresh' button (it should really pull the list on startup if you're connected to the internet, but it doesn't, I tried to fix this once and failed, maybe I should take another shot).
The interface could likely use some work as well. It contains jargon a new user has no way to decipher. So it would be a good idea to involve the Design team for that.
----- Original Message -----
From: "Paul W. Frields" stickster@gmail.com To: desktop@lists.fedoraproject.org Sent: Thursday, January 21, 2016 12:13:33 PM Subject: Re: Dropping i686 media for F24
On Thu, Jan 21, 2016 at 12:37:46AM -0800, Adam Williamson wrote:
On Wed, 2016-01-20 at 15:39 -0700, Chris Murphy wrote:
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote:
My hope that for F24 our download is not an iso image, but rather USB-creator. We could try to build some kind of GPU detection into USB creator to have it choose a 64 bit image if the CPU supports it, and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection,
No, but Christian wrote "we could try to build" that, he didn't say we already had it.
or download ISOs? I thought you had to point it to an ISO file.
luc does do downloads - you *can* point it at a file, but it also has both a built-in list of images it can download and write, and a remote URL it queries for an updated list when you hit a 'refresh' button (it should really pull the list on startup if you're connected to the internet, but it doesn't, I tried to fix this once and failed, maybe I should take another shot).
The interface could likely use some work as well. It contains jargon a new user has no way to decipher. So it would be a good idea to involve the Design team for that.
Yeah, I think we definitely need to make the text part of the Fedora release process as I would assume that we want to adjust the descriptive text over time. So maybe we can figure out a system where our design and marketing teams can provide updated textual decscriptions for each release and in a format that allows our translators to translate it before release.
Christian
On Thu, Jan 21, 2016 at 12:31:47PM -0500, Christian Schaller wrote:
----- Original Message -----
From: "Paul W. Frields" stickster@gmail.com To: desktop@lists.fedoraproject.org Sent: Thursday, January 21, 2016 12:13:33 PM Subject: Re: Dropping i686 media for F24
On Thu, Jan 21, 2016 at 12:37:46AM -0800, Adam Williamson wrote:
On Wed, 2016-01-20 at 15:39 -0700, Chris Murphy wrote:
On Wed, Jan 20, 2016 at 3:15 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2016-01-20 at 09:24 -0500, Matthew Miller wrote:
On Wed, Jan 20, 2016 at 09:01:47AM -0500, Christian Schaller wrote: > My hope that for F24 our download is not an iso image, but rather > USB-creator. We could try to build some kind of GPU detection into > USB creator to have it choose a 64 bit image if the CPU supports > it, > and maybe that would help reduce our 32 bit numbers.
Is there a change proposal filed for this? It's definitely the kind of thing which warrants it, for communication with the web and infrastructure teams, and for marketing.
The USB creator, presumably, is a small download, which then itself does download of the ISO? I assume it's packaged as an installer for Windows and OS X -- what about for Linux? (Either for existing Fedora users or distro-hoppers?)
I think he's talking about liveusb-creator, in which case yes, this is more or less what it is. I would be leery about making luc the 'main' download for Workstation given its current abilities and the resources currently devoted to it, though. In my experience it's the least reliable of the 'official' USB writing mechanisms, after dd-style writes (most reliable) and livecd-iso-to-disk. I'm also not sure if we have a packaging of luc for non-Fedora distros or OS X.
Yeah but does luc do GPU detection,
No, but Christian wrote "we could try to build" that, he didn't say we already had it.
or download ISOs? I thought you had to point it to an ISO file.
luc does do downloads - you *can* point it at a file, but it also has both a built-in list of images it can download and write, and a remote URL it queries for an updated list when you hit a 'refresh' button (it should really pull the list on startup if you're connected to the internet, but it doesn't, I tried to fix this once and failed, maybe I should take another shot).
The interface could likely use some work as well. It contains jargon a new user has no way to decipher. So it would be a good idea to involve the Design team for that.
Yeah, I think we definitely need to make the text part of the Fedora release process as I would assume that we want to adjust the descriptive text over time. So maybe we can figure out a system where our design and marketing teams can provide updated textual decscriptions for each release and in a format that allows our translators to translate it before release.
I'm not sure we are talking about the same thing, maybe I misunderstood?
I was referring to the actual interface of the liveusb-creator. It features jargon such as "destructive (cp)"/"non-destructive (dd)" and "persistence." I don't think that's going to work well for users on their first experience procuring and installing Fedora.
On Thu, Jan 21, 2016 at 12:17 PM, Paul W. Frields stickster@gmail.com wrote:
On Thu, Jan 21, 2016 at 12:31:47PM -0500, Christian Schaller wrote:
Yeah, I think we definitely need to make the text part of the Fedora release process as I would assume that we want to adjust the descriptive text over time. So maybe we can figure out a system where our design and marketing teams can provide updated textual decscriptions for each release and in a format that allows our translators to translate it before release.
I'm not sure we are talking about the same thing, maybe I misunderstood?
I was referring to the actual interface of the liveusb-creator. It features jargon such as "destructive (cp)"/"non-destructive (dd)" and "persistence." I don't think that's going to work well for users on their first experience procuring and installing Fedora.
Martin's message sounds like persistence is going away because it's buggy.
dd would be destructive, cp would be non-destructive.
dd is quite reliable since it keeps the ISO layout and bootloader completey intact; whereas with cp the bootloaders will need to be modified, which I still think is fraught with peril. I think the tool should just use dd on the backend and inform the user very strongly *ALL* data on the stick will be destroyed.
If the tool is using livecd-iso-to-disk on the backend, that seems to be pretty reliable on x86_64 for both BIOS and UEFI firmware types. But my understanding is livecd-tools is going away in favor of livemedia-creator. So...
Chris Murphy
On Thu, 21 Jan 2016 20:30:41 +0100, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jan 21, 2016 at 12:17 PM, Paul W. Frields stickster@gmail.com wrote:
On Thu, Jan 21, 2016 at 12:31:47PM -0500, Christian Schaller wrote:
Yeah, I think we definitely need to make the text part of the Fedora release process as I would assume that we want to adjust the descriptive text over time. So maybe we can figure out a system where our design and marketing teams can provide updated textual decscriptions for each release and in a format that allows our translators to translate it before release.
I'm not sure we are talking about the same thing, maybe I misunderstood?
I was referring to the actual interface of the liveusb-creator. It features jargon such as "destructive (cp)"/"non-destructive (dd)" and "persistence." I don't think that's going to work well for users on their first experience procuring and installing Fedora.
Martin's message sounds like persistence is going away because it's buggy.
dd would be destructive, cp would be non-destructive.
dd is quite reliable since it keeps the ISO layout and bootloader completey intact; whereas with cp the bootloaders will need to be modified, which I still think is fraught with peril. I think the tool should just use dd on the backend and inform the user very strongly *ALL* data on the stick will be destroyed.
If the tool is using livecd-iso-to-disk on the backend, that seems to be pretty reliable on x86_64 for both BIOS and UEFI firmware types. But my understanding is livecd-tools is going away in favor of livemedia-creator. So...
Chris Murphy
Regarding dd usage, there's another problem with the partition layout that's created in the process. It's not trivial to revert the changes that have been done. On every operating system, graphical tools inform you that you have a flash drive of a size of about 10MB - that's the first partition. Most partition editors (except gparted) see only this information, too. If dd is to be made the default (and possibly only) option, I'll add some way to put a basic FAT32 filesystem as the only partition on the drive. And honestly, this is the way I'd like most - to just tell the user to use the LUC again to have a working flash drive again. Do you think that's sane?
On Thu, Jan 21, 2016 at 12:30:41PM -0700, Chris Murphy wrote:
On Thu, Jan 21, 2016 at 12:17 PM, Paul W. Frields stickster@gmail.com wrote:
On Thu, Jan 21, 2016 at 12:31:47PM -0500, Christian Schaller wrote:
Yeah, I think we definitely need to make the text part of the Fedora release process as I would assume that we want to adjust the descriptive text over time. So maybe we can figure out a system where our design and marketing teams can provide updated textual decscriptions for each release and in a format that allows our translators to translate it before release.
I'm not sure we are talking about the same thing, maybe I misunderstood?
I was referring to the actual interface of the liveusb-creator. It features jargon such as "destructive (cp)"/"non-destructive (dd)" and "persistence." I don't think that's going to work well for users on their first experience procuring and installing Fedora.
Martin's message sounds like persistence is going away because it's buggy.
dd would be destructive, cp would be non-destructive.
I understand these options, but thanks. If these choices remain, it would be better for them to be written in plain English. For example:
"Overwrite the entire USB stick (destroys all data)" "Copy files to the USB stick (preserves data)"
dd is quite reliable since it keeps the ISO layout and bootloader completey intact; whereas with cp the bootloaders will need to be modified, which I still think is fraught with peril. I think the tool should just use dd on the backend and inform the user very strongly *ALL* data on the stick will be destroyed.
I tend to agree -- a more reliable tool is better, even if that means sacrificing choice of options.
If the tool is using livecd-iso-to-disk on the backend, that seems to be pretty reliable on x86_64 for both BIOS and UEFI firmware types. But my understanding is livecd-tools is going away in favor of livemedia-creator. So...
+1, this would need to be checked and tested.
On Fri, 2016-01-22 at 08:34 -0500, Paul W. Frields wrote:
I understand these options, but thanks. If these choices remain, it would be better for them to be written in plain English. For example:
"Overwrite the entire USB stick (destroys all data)" "Copy files to the USB stick (preserves data)"
I don't think that's sufficient. Presented with a choice to destroy data or preserve data, why would anyone want to destroy data for no apparent reason? It'd be silly to click "destroy" and not "preserve."
Please, just pick one mode or the other. I agree, we should probably force users to dd; I trust Adam that we will have fewer problems that way.
Michael
On Fri, Jan 22, 2016 at 08:39:33AM -0600, Michael Catanzaro wrote:
On Fri, 2016-01-22 at 08:34 -0500, Paul W. Frields wrote:
I understand these options, but thanks. If these choices remain, it would be better for them to be written in plain English. For example:
"Overwrite the entire USB stick (destroys all data)" "Copy files to the USB stick (preserves data)"
I don't think that's sufficient. Presented with a choice to destroy data or preserve data, why would anyone want to destroy data for no apparent reason? It'd be silly to click "destroy" and not "preserve."
Please, just pick one mode or the other. I agree, we should probably force users to dd; I trust Adam that we will have fewer problems that way.
Agreed. Notice the "If" statement in my original statement. :-)
On Thu, 2016-01-14 at 14:10 -0500, Josh Boyer wrote:
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
If they are made, is QA going to commit to testing them as they have in the past even if none of the issues found are going to block the release? If so, then we have a discussion to have. If not, then I really don't see the point in shipping untested media.
Well, we'd treat them just as any other non-release-blocking-but-still- kinda-significant media, I guess - like the Xfce images, for e.g. There'd be no need to drop the tests from the matrices, but they'd be done on a best-effort basis. We could still have openQA do the 32-bit testing it currently does (right now we only really test install of live media, but I may get around to adding a few of the 'desktop' tests to openQA before this cycle gets too busy).
On 01/14/2016 11:03 AM, Adam Williamson wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
I don't think they'll stop being produced/shipped unless you specifically ask releng to stop producing them, and it might be nice to have that tracked as a Change or similar indeed.
soas uses i686 media ...
Tom Gilliard satellit
On Thu, Jan 14, 2016 at 2:17 PM, Thomas Gilliard satellitgo@gmail.com wrote:
On 01/14/2016 11:03 AM, Adam Williamson wrote:
On Thu, 2016-01-14 at 05:27 -0500, Josh Boyer wrote:
On Thu, Jan 14, 2016 at 5:00 AM, Kamil Paral kparal@redhat.com wrote:
https://lists.fedoraproject.org/pipermail/devel-announce/2015-August/001661....
Stephen Gallagher has proposed a Change for Server to drop i686 media for F24. Given our previous list discussion, this is something for which we should probably follow suit. Thoughts?
-- Paul W. Frields http://paul.frields.org/
I wonder if this discussion (archive here [1]) had any conclusion? I just noticed that the Server SIG's proposal is in the F24 ChangeSet [2], but it is not the case for Workstation. If you plan to drop i686 medium, there are 12 more days until the proposal submission deadline [3].
FESCo voted that no i686 media will block the release from F24 and forward, so it doesn't make much sense to generate it.
Well, whenever I've seen it discussed, there's been an understanding that there's a difference there; we do ship a lot of non-release- blocking media, after all. The idea was that declaring that i686 media are not blocking is less drastic than out-and-out dropping them, and gives WGs / SIGs the power to choose whether they want to keep shipping the images or not. So I'd say you still have a choice to make here: do you want to keep producing non-blocking 32-bit Workstation media in a sort of 'here they are if you REALLY want them' way, or just stop producing them entirely?
I don't think they'll stop being produced/shipped unless you specifically ask releng to stop producing them, and it might be nice to have that tracked as a Change or similar indeed.
soas uses i686 media ...
The Sugar on a Stick spin is an entirely separate spin from Workstation and therefore not relevant to this particular discussion.
josh
desktop@lists.fedoraproject.org
-
Adam Jackson -
Adam Williamson -
Alberto Ruiz -
Chris Murphy -
Christian Schaller -
drago01 -
Elad Alfassa -
Jiri Eischmann -
Josh Boyer -
Kalev Lember -
Kamil Paral -
Martin Bříza -
Matthew Miller -
Michael Catanzaro -
Paul W. Frields -
Peter Robinson -
Stephen Gallagher -
Thomas Gilliard -
Zbigniew Jędrzejewski-Szmek