Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion
On Thu, Dec 12, 2019 at 9:40 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Drop_Optical_Media_Criterion > > = Drop Optical Media Release Criterion = > > == Summary == > Proposal to make all Fedora optical media non-blocking. This means > we'd stop blocking on bugs found during the installation of Fedora > from optical media (like CDs and DVDs). This doesn't mean that > installation from optical media would stop working, just that the > Fedora Release wouldn't be blocked on any issues that can pop up in > Fedora installation using this method. Installation from USB devices > will remain blocking. > This has been a long discussion. Let me sum up some answers and misunderstandings, as a member of the QA team. The sole reason for the proposal is that testing optical media is a long and tedious process and we believe that their importance has gone down massively in the last years. We understand that there are people whose hardware still requires optical media for installation. There will always be people like that, even in 10 years. And we don't revel in presenting them with additional obstacles. But we also have duties, priorities and limited resources, and must regularly re-assess what we do. In our opinion, optical media have fallen below the cut-off line. Especially with the recent deprecation of i386 architecture in terms of kernel/boot support, we assume that the number of affected hardware and people is just a very small minority in our user base. That's why we want to drop the release-blocking requirement and invest the time into testing something that affects more people. It's very important to understand that dropping a release criterion for optical boot doesn't mean Fedora can't be installed from a DVD in the future. The bugs that affect just bare-metal optical booting (and not virtual machines or usb booting) are very rare. Adam and Chris have provided some numbers and references. If such a problem is detected soon enough, we will definitely do our best to make sure it's resolved by the official release time. In the worst case scenario, where no one spotted it in advance and all installation media are affected, there are still avenues for affected users. An older installation medium can be used and the system upgraded. And older installation medium can be used and pointed at latest installation repositories (this is not guaranteed to work, but works in majority of cases). And we can also spin up unofficial install media post-release, once the bug is fixed (we've done this in the past). There are even community members who do these "media refreshes" regularly. Overall, yes, it might be uncomfortable if you have such hardware, but it's *not* game over. It's also important to understand the current state of optical media release criteria. We've dropped the blocker requirement for most installation media two years ago. Only Everything netinst and Workstation Live remained. This proposal suggests that we drop these last two as well. If you're concerned about Server DVD or KDE Live or something else - there is no change for you. Regarding virtual machines, you can rest assured that we'll still block on VMs booting from ISO files mounted as virtual optical drives. If Adam thinks this is a bit under-defined at the moment, we'll define it properly as part of this proposal. Regarding the topic of how many laptops/workstations/servers sell with an optical drives nowadays - this is completely irrelevant, let's just not waste time with this discussion. The important topic is how many of existing hardware can't boot using other means (that would be mostly USB for laptops/workstations and network for servers). Also, this is not something that has been announced suddenly. We've been discussing this for multiple years, and a year ago it was even proposed by Matthew Miller (Fedora Project Leader). This gets perhaps more visibility due to being a Change proposal, as we usually discuss QA matters in test or test+devel lists. And that's fine, we very much appreciate feedback. I'm just clarifying this is not some shocking news of the year. To reply to Justin Flory about Fedora Mindshare Committee - I think this is more of an engineering decision, really. Of course you'll find users who will want optical boot 100% supported (and that's true probably about anything). The question is how much testing we can provide and whether we want to block the whole release train on such issues, and that's likely just an engineering prioritization. Of course it's good to have user feedback. Regarding Miro Hrončok's proposal "let QA skip testing, but block on it if somebody else finds the problem" - yes, it's possible. QA is by definition best effort, even though we've considered a full test matrix coverage somewhat mandatory lately. We do practice this approach for many criteria for which we don't even have test cases written. In terms of boot support, though, I'm not particularly fond of it. Without regular
Re: For today's agenda item - Proposed disk unmount test case
On Wed, Dec 11, 2019 at 7:27 PM Chris Murphy wrote: > I'd also drop all the preconditions like using defaults. Pretty much > any possible installer allowed configuration that trips up this test > case is an eyeball opener and should be tracked down. > +1 > > > > > https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su > > > > *sigh* ten points > > How to test #1 can probably be omitted in favor of just using # in > front of commands that are expected to be run either as root user or > with sudo. *shrug* > I find it better to say "Run the following command with administrative privileges:" (or root or superuser privileges). Anyone who doesn't know what it means likely can't debug the issue anyway. The second approach I do (and probably even prefer to the above, because it is more explicit) is to prefix all such commands with sudo. Then it is clear that you need to run them as root. And if you run them verbatim under root directly (including sudo), there's no harm. > > (I'm also a fan of `sudo -i` anyway...) > > https://unix.stackexchange.com/questions/35338/su-vs-sudo-s-vs-sudo-i-vs-sudo-bash/35342 +1 "su -" and "sudo -i". Wipe everything else from your memory, people :-) I'd like the test case to have the least burden on the reporter that > also produces a useful report: > 1. includes the -b journal (current, shows journal replay messages) > 2. includes the -b -1 journal (previous, might show some evidence of > why unmount was not clean) > Yes, that's reasonable. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Wed, Dec 11, 2019 at 5:14 PM Adam Williamson wrote: > > What's the point of running the checks from Live image as well? The local > > filesystems will likely get wiped and re-created anyway. Extra failures > in > > the log might just confuse us when reading the bug report. > > That was in Pat's version, I just re-worded it. But yeah, this is a > reasonable point (in fact you can't check the logs after rebooting the > live image because they won't be there). I think this is a bit of an > artifact of the fact that this test case is trying to cover both 'does > it shut down / reboot correctly?' and 'do filesystems unmount > correctly?', and Pat was maybe more interested in emphasizing the > second. I think checking that the live image shuts down properly is > worthwhile, but we should reword it to reflect that's all there is to > check. > Ah, this is where the confusion comes from. I thought we've established that this testcase is about filesystem clean unmount, and we should have a separate test case if we want to cover reboot/poweroff. I support two separate test cases. > > > (Also, if we want to keep this, it should be the first step, not the > third > > one. I wouldn't expect the reader to go and read the whole test case > first, > > before starting with the first step.) > > Yeah, good point. > > > On the installed system, run a console and become root with sudo su or > su. > > > > > https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su > > *sigh* ten points > > > If there was output from the grep command, run the command journalctl -b > -l > > > > journal.log > > > > "The old options -l/--full are not useful anymore, except to undo > > --no-full." > > (man journalctl) > > Again, taken from Pat's version. Quit blaming me. :P > Sorry, I was enjoying it a bit:-) > > > Run the following command: journalctl -b | grep -E "dirty bit|data may be > > > corrupt|recovery|unmounted|recovering" and see whether there is any > output. > > > > > If there was output from the grep command, run the command journalctl -b > -l > > > > journal.log. Please file a bug report (the kernel is most likely the > > > correct package to file the report against) and attach the journal.log > file > > > to the bug report. > > > > > > > I'd probably add another step between those two. If there was some match, > > I'd ask the user to see the full journal, find the matched line, and > > inspect it in context. If it looks to be a standard operation printout, > > e.g. a successful unmount operation or a message coming from some > unrelated > > app and not from kernel/systemd/fsck, that message should be ignored. > Only > > if it looks like a filesystem error similar to the sample errors provided > > by Chris, the full log should be saved and a bug reported. Which means > I'd > > like to add sample errors inside the test case, e.g. into another section > > called "Filesystem errors examples". Those error samples might come in > > handy in the future revisions of the test case as well, e.g. if we find > out > > that the grep command is too broad. > > I can see this, but I'm not *sure* about the 'sample errors', because > that's the kind of content that goes stale very quickly. I usually work > quite hard to write test cases such that they shouldn't need much > updating, because no-one ever does update them... > Yes, but we use the keywords from those samples in the grep pattern. So if the sample is outdated, the grep pattern is likely outdated as well, and we need to update the test case anyway. And it might be even more obvious that we need to update it if the sample it there (otherwise you have no idea where the "unmounted" is coming from). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Mon, Dec 9, 2019 at 7:05 PM Adam Williamson wrote: > On Sat, 2019-12-07 at 09:45 -0500, pmkel...@frontier.com wrote: > > I think I have it close to what you want. Please let me know. > > > > Here's the link: > > > > https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot > > > > Have a Great Day! > > Hey folks! So as mentioned in the meeting today, here's my draft with a > few revisions to Pat's draft: > > https://fedoraproject.org/wiki/User:Adamwill/Draft_testcase_reboot Thanks Adam. Here are some questions and nitpicks, as always: If you are testing a live image, perform the steps below from the live > environment before doing the install. After this go ahead with the install. > Then perform the steps below from the installed system. > What's the point of running the checks from Live image as well? The local filesystems will likely get wiped and re-created anyway. Extra failures in the log might just confuse us when reading the bug report. (Also, if we want to keep this, it should be the first step, not the third one. I wouldn't expect the reader to go and read the whole test case first, before starting with the first step.) On the installed system, run a console and become root with sudo su or su. > https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su If there was output from the grep command, run the command journalctl -b -l > > journal.log > "The old options -l/--full are not useful anymore, except to undo --no-full." (man journalctl) Run the following command: journalctl -b | grep -E "dirty bit|data may be > corrupt|recovery|unmounted|recovering" and see whether there is any output. > If there was output from the grep command, run the command journalctl -b -l > > journal.log. Please file a bug report (the kernel is most likely the > correct package to file the report against) and attach the journal.log file > to the bug report. > I'd probably add another step between those two. If there was some match, I'd ask the user to see the full journal, find the matched line, and inspect it in context. If it looks to be a standard operation printout, e.g. a successful unmount operation or a message coming from some unrelated app and not from kernel/systemd/fsck, that message should be ignored. Only if it looks like a filesystem error similar to the sample errors provided by Chris, the full log should be saved and a bug reported. Which means I'd like to add sample errors inside the test case, e.g. into another section called "Filesystem errors examples". Those error samples might come in handy in the future revisions of the test case as well, e.g. if we find out that the grep command is too broad. Each grep command should produce no output. > Running reboot should cause an orderly shutdown and restart of the > system. > I think these "expected results" can be easily omitted, because they are obvious from how the test steps are written. No hard feelings, though. Draft testcase reboot > The testcase should be renamed, I think. Something like "Testcase filesystem consistency" or "Testcase clean unmount" or "Testcase reboot unmount". ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [Test-Announce] 2019-12-09 @ 16:00 UTC - Fedora QA Meeting
On Sat, Dec 7, 2019 at 2:46 AM Adam Williamson wrote: > # Fedora Quality Assurance Meeting > # Date: 2019-12-09 > # Time: 16:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: #fedora-meeting on irc.freenode.net > > Greetings testers! > > We have a couple of active proposals to discuss, so let's get together > on Monday and check in. > > If anyone has any other items for the agenda, please reply to this > email and suggest them! Thanks. > > == Proposed Agenda Topics == > > 1. Previous meeting follow-up > 2. Proposed asynchronous blocker review process > 3. Proposed disk unmount test case > I have a sick day today, I'm not sure if I'll be available. I'll be sure to read the meeting log, if I can't attend. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Thu, Dec 5, 2019 at 8:07 PM pmkel...@frontier.com
wrote:
>
> On 12/5/19 03:56, Kamil Paral wrote:
>
> >
> > Here's the email I had in mind, containing the important journal
> messages:
> >
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/S5LQTXKFPIUKBFC7HL5SNSAV3ZRFP6WV/
> >
> > We need to create a command or commands that will detect any of the
> failure
> > states (and ideally another command for any of the success states, for
> > confirmation).
> >
> >
> > It doesn't really matter if you grep the journal directly or save the
> > journal and grep the file. But it's one fewer command to grep the journal
> > directly. And if a failure is found, ask the user to save the journal and
> > report a bug.
> >
>
> I have the test case updated, but I ran into a problem with the test
> case template. The "|" character is apparently a reserved character in
> the template code. I couldn't get it to let me have the pipe from the
> journal to the grep. Nor could I use the -E option with the grep because
> that character is used to separate the match patterns.
>
Those are the joys of using wiki templates :-/
You can you "|" if you enclose it in command tag (instead of
using {{command|something}} template). There's also some way how to use it
inside the {{command}} template, but I forgot it as usual.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Thu, Dec 5, 2019 at 9:33 AM Julen Landa Alustiza < jla...@fedoraproject.org> wrote: > > 19/12/4 15:34(e)an, Kamil Paral igorleak idatzi zuen: > > On Tue, Dec 3, 2019 at 10:22 PM Tim Flink wrote: > >> Has anyone poked at scoping out the work required for either the bot or >> the enhancements we would need for pagure? >> > > Lukáš Brabec looked into it, and creating a new Pagure ticket is a matter > of a few lines of code (already written). Extending BBA with a "discussion > link" in each blocker row should be trivial as well. I think that's all we > need for trying it out. > > The blocker bot watching and updating the issue should be fairly easy as > well, I hope, but as described above, we've hit an issue where Pagure API > doesn't allow comment editing. Lukáš implemented a workaround that adds a > new metadata field on the right side of each Pagure ticket showing the > count summary. It's barebones, but at least something. We've haven't yet > looked into writing the listener code, that would listen for Pagure events > on the message bus and react to them. We also haven't looked at Bugzilla > updater as described in the proposed workflow (that's really a cherry on > top, we don't need it right away). > > Implementing an api endpoint to edit comment is easy, open an RFE on > pagure's issue tracker if you need it and I'll take it > I'm not going to say no to that! :-) Here it is: https://pagure.io/pagure/issue/4683 Thanks a lot. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Tue, Dec 3, 2019 at 3:29 PM pmkel...@frontier.com wrote: > On 12/3/19 06:27, Kamil Paral wrote: > > On Mon, Dec 2, 2019 at 7:43 PM pmkel...@frontier.com < > pmkel...@frontier.com> > > wrote: > > > >> I have the update ready. I think I interpolated the discussion > >> correctly, but probably leaned toward the "keep it simple for now" case. > >> Please let me know if there are further changes needed. Here's the link: > >> > >> https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot > > > > > > I was hoping you would include `journalctl | grep` commands that would > look > > for the strings Chris mentioned, so that it's easy for people or for > > scripts to confirm whether the filesystem was or wasn't properly > unmounted. > > It's still helpful to include the examples (they don't necessarily need > to > > be Expected Results, but it's fine there), so that people can compare the > > full text if they want or have doubts, but those grep commands would make > > the comparison much simpler. > > > > I took a quick tour back through some the the recent e'mail, but didn't > see any thing about grepping the journal. Here's the email I had in mind, containing the important journal messages: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/S5LQTXKFPIUKBFC7HL5SNSAV3ZRFP6WV/ We need to create a command or commands that will detect any of the failure states (and ideally another command for any of the success states, for confirmation). > From the above, I'm thinking > it might be good to do the journalctl -b > journal.log first and then > grep the file for the unfortunate result phrases. Then if one of the > phrases is found in the file ask the tester to file a bug report with > the journal file attached. Is that what you had in mind? > It doesn't really matter if you grep the journal directly or save the journal and grep the file. But it's one fewer command to grep the journal directly. And if a failure is found, ask the user to save the journal and report a bug. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Test request: BZ 1773879
On Wed, Dec 4, 2019 at 6:23 PM Ben Cotton wrote: > Hi team, > > If you have some spare time and a ThinkPad (particularly the T490), > can you please see if you can replicate the behavior reported in: > > https://bugzilla.redhat.com/show_bug.cgi?id=1773879 > > In today's Prioritized Bugs meeting, we decided we don't have enough > information to make a decision. We're particularly interested in: > 1. If you can replicate the behavior and > 2. If you can, if the 5.5.0 kernel (still building as of this writing) > fixes it. > I have T4*8*0s, I'm running kernel-5.3.14-300.fc31.x86_64, and touchpad and trackpoint work fine for me. PS: It's good to include some keywords in the email subject next time, e.g. "Test request: BZ 1773879 (touchpad broken on Thinkpad T490s)". Otherwise people with valuable input might skip it due to the title being too vague. It also makes it easier to navigate between threads. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Tue, Dec 3, 2019 at 5:15 PM Geoffrey Marr wrote: > Kamil, > > I wasn't intending the time we would get together each week for voting, > instead for time spent discussing and clarifying any discrepancies we may > have with the bugs. By the time we would have this 30 or so minute > get-together, our votes would already be cast in Pagure. We would make sure > we were all on the same page, and then use the meeting time to mark the > bugs as "Accepted ". > > I like the idea of somehow merging the live meetings with the asynchronous > process. Personally, I think the meeting I'm describing should be solely > purposed as the "Acceptance/Denial Meeting", where the point is to review > the votes in Pagure, and then manually accept/deny the position. That way, > we spend a small portion of time on each bug, not voting, but reviewing the > votes that should have been already cast. And, if any questions arise > regarding a particular bug, we have a platform in which to have a real-time > conversation with our peers. > OK. So what do you think about this? We'd use both the ticketing system and also have our regular Monday meetings. Simple or non-controversial tickets would get resolved through the ticketing system throughout the week. Complex tickets or tickets with balanced number of +1 and -1 votes would get further discussed and decided in our Monday's meeting, the same way we always do it. This keeps the advantage of reducing the meeting length by weeding out simple tickets in async manner. It also keeps the advantage of pinging/CCing developers and letting them respond/vote async. And not just developers, anyone who can't make the meeting can still provide their feedback in the ticket. And finally, this allows us to test the async approach without making a full switch. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Tue, Dec 3, 2019 at 10:22 PM Tim Flink wrote: > Has anyone poked at scoping out the work required for either the bot or > the enhancements we would need for pagure? > Lukáš Brabec looked into it, and creating a new Pagure ticket is a matter of a few lines of code (already written). Extending BBA with a "discussion link" in each blocker row should be trivial as well. I think that's all we need for trying it out. The blocker bot watching and updating the issue should be fairly easy as well, I hope, but as described above, we've hit an issue where Pagure API doesn't allow comment editing. Lukáš implemented a workaround that adds a new metadata field on the right side of each Pagure ticket showing the count summary. It's barebones, but at least something. We've haven't yet looked into writing the listener code, that would listen for Pagure events on the message bus and react to them. We also haven't looked at Bugzilla updater as described in the proposed workflow (that's really a cherry on top, we don't need it right away). > > It might be interesting to look at porting the blockerbugs app to > django if we can make use of some existing django plugins. In the past, > I would have hesitated to do this because of the packaging requirements > and the amount of fun that plugin ecosystems can present but we're > going to have to move to openshift sooner than later which makes the > prospect of using something like Django a lot less daunting. > Ehh. Hmm. I'd really like to avoid being responsible for showing the discussion, handling authentication, sending out notifications, etc. Right now, if BBA is down, we're fine, it's just less comfortable. If we own the full process, it's much more demanding. Also, converting BBA to Django and using some discussion+votes plugins sounds like more work than those quite simple changes in BBA + blocker bot. Plus Josef is the only one except you who has some Django experience, I think. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Tue, Dec 3, 2019 at 8:29 PM Kevin Fenzi wrote: > I pretty much agree with all the points you made on the various systems. > That said, I think this is kinda a bad time to be doing this change. > There's a lot of... (grumblings? rumors? idle converstations?) about the > various bug/issue/source/forges we are currently using. I don't know if > this means we will move to something else, try and consolidate more on > one or what, it's all very vuage at this point. So, IMHO, it's kind of a > bad time to be moving process to one or another things that might > require you to move again later (be that bugzilla or pagure or > whatever). Of course if the process is simple (which I think it should > be) it would translate pretty well to whatever system it's used on. > Thanks for the info. That means we probably shouldn't spend too much time on all the possible bells and whistles, and instead create something simple that a) will help us determine whether we like the async approach or not, and b) can be easily moved to a different ticketing system/source forge. In other words, stick to the basics. Or wait, of course, after F32 release cycle is over, and then perhaps the situation will be clearer. But I'd rather try it now, a simple experiment shouldn't hurt anybody and it's trivial to get back to IRC meetings any time :) > > As a side note I will note that bugzilla does allow voting also, we just > asked them to disable it on the Fedora component. Althought I am not > surre it works in a way thats useful for this workflow: Every user gets > X vote points per Y time and can distribute them accross bugs as they > like. I guess the idea is that then you could see the bugs users REALLY > want fixed. > > I guess I would be most in favor of something leveraging bugzilla, since > thats where our bugs are (at least now). > Pagure had two major benefits for me compared to Bugzilla: 1. Comments can be edited. I wanted to use comment 0 for vote summary. Unfortunately, Lukáš Brabec looked into this and current Pagure API doesn't allow comment editing, you can do it only using your browser. So Pagure API would have to be extended :-/ 2. Pagure can add tags to tickets. But after discussion, I agreed with Adam that it might not be wise to mirror all the blocker metadata (accepted/rejected, blocker/FE) in another system, at least initially. So none of those two is a benefit in the near future. Pagure still has a more comfortable UI, but it's more even now with Bugzilla. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Tue, Dec 3, 2019 at 1:18 PM Lukas Ruzicka wrote: > > Abstain is useful if there are conflicts of interest, or to indicate no >> preference either way, or as a result of confusion. I chock up more than >> one abstain vote as an indicator the proposal isn't persuasive enough. >> Indeed if everyone votes to abstain, that means the vote was premature/ill >> advised and that the arguments in favor and against must be improved, >> rather than literally do nothing. >> >> > Generally speaking yes, however deciding whether something is a blocking > bug (or not) will probably not fall into the category of premature or ill > advised votes. I assume that the vote will only take place when there will > have been at least some discussion about the problem, so people will > probably not arrive into a situation when "they would not know much about > it". > > Also, I assume that the common group of people who regularly attend the > blocker bug meeting are interested in casting the vote actually, so if they > do not, you could take it as a sign that the vote is not clear enough. > > I am perhaps projecting something, but I usually do not understand people > who give up on their vote by placing an empty envelope in general elections > to show that they really do not see a difference between the two final > presidential candidates. I just believe they simply have not been > investigating enough. I think also believe that throwing an empty envelope > can be a sign that they do not want to take the responsibility to decide. > However, since it is legal in the Czech republic, I live with that. > > The same holds true here, if people say that they want to be able to cast > a "0" for whatever reason, and we make it a legal choice, I will be fine > with that. Basically, to have or not to have a "zero" option in voting is > totally unimportant, when there are voices against asynchronous meetings. > So let's not waste time in arguments about the "immortality of the > cockchafer" as one of the Czech sayings says. > Let's just say we have a long history of +0 votes in our IRC meetings, and they are quite frequent. I don't intend to change that in the async blocker process proposal. As you say, "it's totally unimportant", primarily because it doesn't affect the vote result. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Mon, Dec 2, 2019 at 11:47 PM Geoffrey Marr wrote: > Kamil, > > Thanks for working on this. I am glad we are considering something > different here, as the current process is not perfect. > > Personally, of the suggested options, I think that using Pagure is my > preferred option. I think of the available options, it allows for the > easiest collaboration between folks who are contemplating and voting on the > bugs. > > However, I do resonate with some of what Ben said, specifically regarding > losing the "live" setting when we vote. The ability to hash things out over > IRC real-time is pretty valuable, and to use a different system where time > between comments could become large, I wonder if still having a meeting > every Monday would be advantageous. Something to go over the votes that > have been made on the Pagure page (or whatever system it ends up being). > The problem with that is keeping it from turning right back into the old > "blocker-review-meeting". We could possibly institute a 30(?) minute time > limit, where we go over the bugs to ensure we understand them and then > accept the vote right there. That way we have the opportunity to ask > questions/clarifications that might be tedious and take a lot of time over > a forum-style messaging app. Again, there would have to be some kind of > watchdog to prevent us from turning these meetings into what we have now. > All this said, should this IRC meeting idea come to fruition, I would be > more than happy to coordinate and run these, should anyone else not want to > (adamw! :P) > Hey Geoff. I'm afraid time limits wouldn't work well for us here. I wouldn't want to poorly decide a blocker status just because we were running out of time. In case of our IRC meeting, we also don't accept/reject something just because we're out of time. If that happens, we postpone it until the next meeting, or if we don't have the luxury of one more week, we schedule an exceptional meeting the very next day. I wonder if we could merge the live+async approaches to get the best of both. What if we handled simple/standard issues fully in tickets, and for complex issues which are difficult to understand and debug, or which have some heated discussions, we'd schedule an IRC meeting and resolve them there? We can either schedule the meetings ad-hoc, or we can use a special tag in Pagure, and the regular Monday blocker review meeting would only occur if there was at least a single open ticket marked with this tag. Does that sound better in your opinion? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Mon, Dec 2, 2019 at 4:19 PM pmkel...@frontier.com wrote: > > > On 12/2/19 07:03, Kamil Paral wrote: > > > > > I'm not familiar with kanban/taiga. What is the benefit over using > standard > > (Pagure) tickets? > > > > > > The kanban/taiga is what they use at Fedora Magazine. A Writer starts by > creating an Issue proposing a new article for the magazine. There is a > back and forth commentary and if the proposal gets two +1 votes then the > proposal is transfered to a job ticket in the kanban by one of the Editors. > > Then the writer picks up the job ticket and assigns it to them selves if > the Editor didn't already assign it to them. Editors can also create job > tickest for articles they want and a Writer who thinks they can write > the article can pick it up and write it. Once a writer is assigned to a > job ticket they write the article according to their free time or > according a requested time. > > When the draft is complete, the writer puts the job ticket into the > review queue and an editor will review it. Then the job ticket can be > put back in the in process queue if it needs a lot of work or it can be > placed in the To Edit queue for other work like having a feature image > added to it and it can wait there for scheduling. > > After the image is added and the schedule is decided the job ticket is > placed in the Queued queue. > > All through the process from when the writer starts writing the article > to publishing, the actual article is linked to the job ticket. > Thanks, Pat, for the description. Kanban seems to be just a workflow visualization that could be done with custom ticket status or tags the same way (but wouldn't look as pretty as a native kanban UI). Either way, I think this doesn't really apply to blocker discussion tickets. These tickets have a dead simple workflow open -> discuss (separating that would waste a lot of time) -> closed. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Mon, Dec 2, 2019 at 4:02 PM Ben Cotton wrote: > I want to speak up in defense of synchronous meetings. I acknowledge > that the timing is rather convenient for me personally (it's 12–3pm my > time), which makes it easier for me to see the upsides. > > The big benefit is the high bandwidth discussion. I have been in > plenty of meetings where someone initially feels one way and has their > mind changed over the course of the discussion. This is still possible > with asynchronous communication, but it's much more difficult. Yes, that is true. And perhaps if I had the meetings in the afternoon as you do, instead of late evening when I'd rather be with my family, I wouldn't mind them either :-) Alas, it's not the case, and I'd certainly like to test using tickets. I think having an experiment here is very valuable, we might realize a lot of up as we go, which we don't think about atm. For example, I believe that one of the most important advantages of async discussion is the ability to better gather developer feedback. Currently, it's very rare that we can contact the developer and gets some responses during our live meeting. But this is exactly what only experience can tell, whether the improvement will be substantial, or whether developers will ignore our tickets and we will be in the same state as we were. > We > generally end up at a pretty good consensus on blocker status, even if > it sometimes take two (or three!) meetings. I foresee more +4/0/-3 > type votes with an asynchronous method. > > Relatedly, any asynchronous voting mechanism must make it very easy to > know when someone has updated their vote. This is addressed some in > the thread, but any async method that requires coremodule (the forever > secretary!) to read through each comment to make sure no one changed > their mind is inflicting unnecessary pain. IRC has the same problem, > but because the time scale is shorter, it makes it easier to see IMO. > Well, the idea was that a bot keeps count of all the votes and updates a summary. That will not be available from day 1, most probably. But once implemented, that should address this concern, correct? > > Synchronous meetings give the voting period a defined end and makes > the process quick. If we do it asynchronously, there has to be some > deadline that allows people time to vote. Currently, the process is > (IIRC) if three people +1 in the BZ, it's counted as accepted. This > means a bug could potentially be accepted within minutes, denying > those who disagree the opportunity to raise their objections. Of > course, we don't want to set the deadline too long because then we > have a week of "yeah, it looks like this is a blocker, but also we > can't apply the label yet". > The current in-Bugzilla process is used just when we need a very fast decision, and I agree it's not ideal. The same approach can be used in tickets (we can say "there are only 3 hours to collect votes, please respond asap"). But we can also be much more flexible. If the QA person in charge (or however you want to name Adam:-)) decides that most of the usual suspects have already voted, he can close the vote. Or he can wait some more, call for more votes, etc. Unlike "in-BZ discussions", these tickets should be much easier to read and manage, you can easily see how old the ticket is, and decide how long you want to wait or if it was enough. And we'll probably have some recommended practices, e.g. unless we're in a rush, wait 2-3 days for votes. > > None of the above should be taken as me saying that the current > process is perfect. Nor should it be an objection to the idea of an > asynchronous process in principle. I just want to make sure we're > intentional about what we're giving up in order to get the benefits of > an async process. Thanks for your feedback! > For what it's worth, voting support in Pagure (or > another similar system) would be helpful for many teams within Fedora, > including Council, FESCo, and Mindshare who routinely vote on things > in tickets. > This is interesting. I believed that this is just us trying to bend Pagure a little to something it wasn't designed for. But if other groups could benefit from this functionality as well, perhaps we could look at how difficult it would be to implement voting natively in Pagure (and I might hate myself in the future for saying this out loud:)). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Mon, Dec 2, 2019 at 7:43 PM pmkel...@frontier.com wrote: > I have the update ready. I think I interpolated the discussion > correctly, but probably leaned toward the "keep it simple for now" case. > Please let me know if there are further changes needed. Here's the link: > > https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot I was hoping you would include `journalctl | grep` commands that would look for the strings Chris mentioned, so that it's easy for people or for scripts to confirm whether the filesystem was or wasn't properly unmounted. It's still helpful to include the examples (they don't necessarily need to be Expected Results, but it's fine there), so that people can compare the full text if they want or have doubts, but those grep commands would make the comparison much simpler. When asking for debug logs, tell people to save the whole journal and not just systemd-fsck output, i.e. `journalctl -b > journal.log`. I believe the poweroff cycle can be left out, and we can ask just for a single reboot. Also, can you please fix the formatting in Expected Results? Thanks. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Sat, Nov 30, 2019 at 10:40 PM Chris Murphy wrote: > On Thu, Nov 28, 2019 at 5:30 AM Kamil Paral wrote: > > > > Pagure > > *** > > > > This is very similar to the Bugzilla description. For each proposed > blocker, we (auto-)create a ticket in a "fedora-blockers" project, for the > purpose of a blocker discussion. We interlink the bug and the ticket. > > What about kanban? Is there kanban integration in pagure? > > Or what about a taiga method, e.g. using teams.fedoraproject.org? > I'm not familiar with kanban/taiga. What is the benefit over using standard (Pagure) tickets? > > I'm not opposed to dropping the live IRC blocker review entirely; but > even if it were true that they're cut down to a max 1 hour, or even an > informal day long working session on #fedora-qa, that would still be a > huge win. Probably a small subset of complex blocker bugs may benefit > from a live IRC meeting. > It should not be that hard to ping people participating in a particular blocker ticket, and discuss some complex details over IRC, then write some summary/findings to the ticket. That's a completely valid approach. Or would you like to see something more formalized? What would the process look like? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Fri, Nov 29, 2019 at 7:30 PM Chris Murphy wrote: > On Fri, Nov 29, 2019 at 5:10 AM Kamil Paral wrote: > > > > Sounds reasonable to test both LiveOS and the installed system. Does it > make sense to test both installed system's reboot and poweroff, though? Are > there any meaningful differences? > > i'm not certain. > In that case I'd probably start with the simpler version, and extended it if we detect it's not sufficient. So one reboot after installation -> fsck check -> one reboot from the installed system -> fsck check. Pat, can you update the test case according to the changes we've discussed above? Thanks. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Thu, Nov 28, 2019 at 8:29 PM Chris Murphy wrote: > FAT, ext4, and XFS all have a kind of "dirty bit" set upon mount. It's > removed when cleanly unmounted. Therefore if the file system isn't > mounted, but the "dirty bit" is set, it can be assumed it was not > cleanly unmounted. Both kernel code and each file system's fsck can > detect this, and the message you see depends on which discovers the > problem first. The subsequent messages about how this problem is > handled, I think we can ignore. As you say, it will be variable. All > we care about is the indicator that it was not properly unmounted. > Here are those indicators for each file system: > > FAT fsck (since /etc/fstab sets EFI system partition fs_passno to 2, > this is what's displayed for default installations) > Nov 28 12:04:21 localhost.localdomain systemd-fsck[681]: 0x41: Dirty > bit is set. Fs was not properly unmounted and some data may be > corrupt. > > FAT kernel > [ 205.317346] FAT-fs (vdb1): Volume was not properly unmounted. Some > data may be corrupt. Please run fsck. > > ext4 fsck (since /etc/fstab sets /, /boot, /home fs_passno to 1 or 2, > this is what's displayed for default installations) > Nov 28 12:07:21 localhost.localdomain systemd-fsck[681]: /dev/vdb2: > recovering journal > > ext4 kernel > [ 316.756778] EXT4-fs (vdb2): recovery complete > > XFS kernel (since /etc/fstab sets / fs_passno to 0, we should only see > this message with default installations) > [ 372.027026] XFS (vdb3): Starting recovery (logdev: internal) > > > If the test case is constrained only to default installations, the > messages to test for: > "0x41: Dirty bit is set" > "recovering journal" > "XFS" and "Starting recovery" > > If the test case is more broad, to account for non-default additional > volumes that may not be set in fstab or may not have fs_passno set, > also include: > "EXT4-fs" and "recovery complete" > "FAT-fs" and "Volume was not properly unmounted" > > In each case I'm choosing the first message that indicates previously > unclean shutdown happened. Whether fsck or kernel message, they should > be fairly consistent in that I'm not expecting them to change multiple > times per year. Thanks, this is pretty extensively covered. We can put these patterns into one big `journalctl | grep` and detect the unmount issues of the previous boot. With this, we can easily automate it. Who's feeling like updating the test case? > The gotcha is, how would we know? Failure to > automatically parse for these messages, should they change, will > indicate a clean shutdown. *shrug* > If that happens and a bug appears, I guess somebody will tell us sooner or later and we'll fix it. Parsing text output can only take us so far. > > >> Steps 4-7: I'm not following the purpose of these steps. What I'd like > >> to see for step 4, is, if we get a bad result (any result 2 messages), > >> we need to collect the journal for the prior boot: `sudo journalctl > >> -b-1 > journal.log` and attach to a bug report; or we could maybe > >> parse for systemd messages suggesting it didn't get everything > >> unmounted. But offhand I don't know what those messages would be, I'd > >> have to go dig into systemd code to find them. > > > > > > I think the purpose is to verify that both reboot and poweroff shut down > the system correctly without any filesystem issues (which means fully > committed journals and no dirty bits set). > > Gotcha. Yeah, I think it's reasonable to test the LiveOS reboot as > well as the installed system's reboot, to make sure they are both > properly unmounting file systems. > Sounds reasonable to test both LiveOS and the installed system. Does it make sense to test both installed system's reboot and poweroff, though? Are there any meaningful differences? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Fri, Nov 29, 2019 at 9:46 AM Lukas Brabec wrote:
> > 2. Blocker Bugs App (BBA) detects the new blocker and creates a new
> ticket in Pagure in the "fedora-blockers" project, then updates the bug to
> link to this ticket (a new comment, a Links entry). It shows both the bug
> and the discussion ticket in its UI.
>
> What about fedora-blockers group with FXX-{{Beta,
> Final}-Blockers,{Beta, Final}-FEs} projects. Issues would be filed
> against appropriate project in that group. I like the added hierarchy
> and that F32-Final-Blockers would have only relevant issues. Or does
> this sound too complicated?
>
The proposed milestone is often not the milestone we approve it for. For
example it might be proposed for Beta, but we agree that's a Final blocker.
How would you handle ticket transfers between projects?
Also, often a bug is a Final blocker and a Beta FE. How would you handle a
ticket that needs to be part of several projects?
Additionally, people would need to subscribe to all projects if they wanted
to receive notifications for new proposed blockers, and they would need to
repeat it every time a new release appears (because we'd create new
projects in that group every time a new Fedora is branched).
I think all of that is much easier solved by tags. Tags for F31, F32, etc,
tags for blocker/FE, tags for proposed/agreed. The only concern is not
getting out of sync with information in Bugzilla and BBA. Perhaps we don't
need tags at all, and can instead improve BBA to show us historical
bugs/tickets. Or perhaps the sync issues are not such a problem. Shrug.
>
>
> > 5. Once some kind of understanding of the issue is formed, a privileged
> member (e.g. a member of @fedora-qa FAS group) can start the vote by
> including a command in his comment, e.g. "START VOTE" on a separate line.
> (Note that this is just a proposal. We can easily let anyone start the
> vote, or we can allow voting right from the beginning without an explicit
> start.)
>
> I'd allow voting right from the beginning, OTOH I think we would often
> see a lot of votes, then proper discussion and RESTART command after
> that. We can try both (explicit START and right from the beginning)
> and see which is better.
>
Yeah, already replied to Frantisek, voting from the beginning seems like a
better option.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Thu, Nov 28, 2019 at 11:29 PM Frantisek Zatloukal wrote: > > > On Thu, Nov 28, 2019 at 1:31 PM Kamil Paral wrote: > >> >> 5. Once some kind of understanding of the issue is formed, a privileged >> member (e.g. a member of @fedora-qa FAS group) can start the vote by >> including a command in his comment, e.g. "START VOTE" on a separate line. >> (Note that this is just a proposal. We can easily let anyone start the >> vote, or we can allow voting right from the >> 9. If new important information appear or the vote needs to be repeated >> for any other reason, a privileged member can restart the vote e.g. by >> issuing RESTART VOTE command. (We can have more such administrative >> commands for any purpose we need, same as we have them with IRC bots). >> > > It's probably just a small detail, why would we need (RE)START VOTE > commands? It seems we can vote whatever/whenever we want, bot would just > count the last VOTE +/- 1, 0 comment (or rather command) from each > participant. > That's a good question. The START VOTE is optional and really up to us if we want to use it. I included it because it seemed to me to mirror what we do during IRC meetings - first we discuss the issue and come to an understanding of the problem, and then people vote (usually). But it's true that for clear-cut issues, people might want to vote immediately. And waiting for a privileged person to start voting every time could prove annoying. So after some consideration, I agree that it might be better to allow people voting right from the beginning. The RESTART VOTE is useful, though. Imagine a situation where several people voted but then the developer added a comment that the bug might in some cases wipe all user data (or the whole disk). There might be such a bump in severity of the issue, that a QA person might force the vote to be restarted. This makes sure that old votes won't be counted in by accident, and if you look at the vote summary, you can be certain that all the votes displayed were cast by people who were already aware of the increased gravity of the issue. One more note: During IRC meetings the chair usually posts "proposed #agreed statement" and people ack it or nack it, then it changes to "#agreed statement". I think that won't be possible with ticket meetings, because that would require one additional roundtrip of votes (which might take up to 1 day due to timezones). So I think the workflow will be for people to vote +1/0/-1, and then the selected QA person will simply summarize it into AGREED , and we will trust he/she will do the right thing and also formulate the justification well (of course, if people disagree, the ticket can always be reopened). For contentious issues where there are numerous +1's and -1's, we'll need to deal with it as usual - either punt it, or ask the minority if they're fine with using the majority decision (and then use the AGREED command). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Thu, Nov 28, 2019 at 5:59 PM Lukas Ruzicka wrote: > > 7. People vote by submitting comments containing VOTE +1/0/-1 on a >> separate line (and including any justification or feedback they wish in the >> comment as well; the command has to simply be on its own line so that we >> can detect it well). >> > > The VOTE must be only +1 or -1. Indecisive people do not need to put that > down, they just can do nothing. > The idea behind voting is that we can distinguish people who abstain from the vote from people who haven't voted yet. The summary at the top of the issue (populated by the bot) could look like this: Voting summary: *+2,1,-1* +1: kparal (hyperlink to comment) jskladan (hyperlink to comment) 0: lruzicka (hyperlink to comment) -1: lbrabec (hyperlink to comment) Commented but haven't voted yet: adamwill fzatlouk Because Pagure supports Markdown, we can create pretty summaries that actually contain links to where each individual provided their comment, without overloading the content with hyperlinks. We can also easily see who's missing from the vote, or perhaps mistyped their vote and hasn't been counted. The overall vote summary is displayed in the same format FESCo uses for voting "(plus votes, ambivalent votes, minus votes)". ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Asynchronous blocker review process (using Pagure)
On Thu, Nov 28, 2019 at 5:14 PM Adam Williamson wrote: > So overall I agree with a lot of what you wrote. It does cause me to > wonder if writing some kind of plugin/extension for Pagure, or just > writing the functionality into the blockerbugs app, might possibly be > *less* work than writing and maintaining the 'blocker bot', however. You mean patching Pagure to allow for voting? It's pretty specific to our use case, I'm not sure if Pagure would be interested in having that. There is something similar on Github/Gitlab by acking/nacking a pull request, but that is for PRs where it makes sense. We would need to use it on tickets, where it generally doesn't make much sense. I also considered voting by adding thumbs-up/thumbs-down reactions (already supported by Pagure), but that is a process that doesn't create any activity log and the result can be arbitrarily changed at any time, even after voting has ended. The process of VOTE +1/0/-1 and updating the summary is very lightweight on the blocker bot functionality (it should be really trivial to implement) and it doesn't hurt us much if the bot goes unresponsive - counting manually is not that much work. I see voting in BBA as a much more daunting task, because of authentication, notifications, long term logging, making sure the service is up at all times, etc. Also it wouldn't make much sense to have discussion and voting at two separate places, which means having the discussions in BBA as well, which brings yet more requirements. The other part of the bot, mainly updating blocker bugs in Bugzilla automatically, was something we've talked about a long time and that can't be done with any Pagure extensions etc. > My > other concern would be that if we use something other than the > blockerbugs app or Bugzilla, we now have *three* different systems > involved in the blocker review process - Bugzilla, the blockerbugs app, > and the discussion system. That seems like a lot of moving parts to > keep synchronized. > That is a valid concern. But, we already have three systems, the third being IRC :-) And that would get replaced by Pagure. If IRC is down, our processes are negatively affected (the same would happen if Pagure was down). My main goal is to avoid being overly reliant on BBA. If Bugzilla or Pagure are down, it's a Fedora-wide crisis and it will get resolved promptly. If BBA is down, just a few people from our team can do something about it, and if that is a complex issue, the priority to getting external help is much lower than with Bugzilla or Pagure. I also want us to stay away from the sysadmin roles as much as we can. So BBA (including the blocker bot, if we want to distinguish that) plays, in my ideal world, just a support role, but we don't depend on it. If things break, we can always do the same thing manually (list proposed blockers in bugzilla, have the discussion there or elsewhere, then set the right fields, etc). And that principle is valid even in the proposed scenario. You are right that synchronization issues might occur, especially when we start displaying the same data in several places. The canonical source is and will be Bugzilla, but we display blocker/FE status in BBA and now the same info would be visible through Pagure ticket tags. That... might not be a good idea. I was thrilled by the idea of having an easy-to-look-at and easy-to-use list of current and past blockers/FEs (because often I need to find a past accepted/rejected blocker and that is a painful experience using Bugzilla), but it's not necessary. All the tags are just sugar on top. Perhaps we should start without it, and add it later, if we feel it would be useful and we have no synchronization issues. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Proposal: Asynchronous blocker review process (using Pagure)
We've talked about replacing blocker bug review meetings with something else for a long time. The meeting has an upside of a higher communication bandwidth, but also a downside of requiring participants to be available at the same time (throughout the world), often being extremely long, and being scheduled just once per week (because of mentioned downsides). I've put some thoughts into making the process asynchronous, and you can see all the options I considered described below. I close up with a proposal for the best choice I found. Asynchronous blocker review process will: - allow more people to participate (they are not restricted to a particular time, which is inconvenient for some people) - allow us to better gather feedback from maintainers/developers by CCing them - possibly allow a faster turn-around for voting (if you propose a blocker on Tuesday, it doesn't have to wait for the next Monday's meeting) - reduce frustration from long meetings (but perhaps add different ones) - restrict our communication bandwidth somewhat (real-time chat makes it easier to debug issues than e.g. email) I think we'll need to try it first to decide if we like it or not. Here are my thoughts for different systems we could use: Blocker Bugs App (DIY solution) ** We can implement all the necessary features to our Blocker Bugs App [1]. We even talked about it in the past. There would be a Voting page where discussions could be held for each proposed blocker, and a voting system. We could tailor everything exactly to our needs. But it also implies a lot of time spent in development, writing from scratch features that already exist elsewhere (discussions, notifications, etc) and a long-term maintenance of it (we want out blocker decisions to be available basically indefinitely, ideally with a URL that doesn't change). I'm skeptical that we want to devote a lot of our time to implement such a system, and I don't even think it's a smart thing to do, if there are existing solutions (implemented and maintained by other people) which could work "well enough". That's why I'm mentioning this solution, but try to avoid it as much as possible, and explore other systems below. [1] https://qa.fedoraproject.org/blockerbugs/ Mailing lists This is trivial to use. For every proposed blocker, we simply start a thread on test list (with a predefined subject format), discuss & decide. It's simple, but also quite bare-bones. We can CC people easily, but that tends to be complicated with people not subscribed to the list. It's very easy to see just a partial conversation, due to the usual reply headers madness. We can link this conversation into the bug report using a hyperkitty view (as long as we have hyperkitty), but it suffers from the same issues, possibly showing just a partial conversation. It's very hard to count the votes across all the replies. It's also hard to track the status of the conversation (initial discussion, voting in progress, resolved, etc). Overall, mailing lists are workable, but far from a good solution, and that's why I'm looking into other solutions below. Bugzilla For each proposed blocker, we can create (ideally auto-create) a parallel bug report in Bugzilla (against "distribution" or a special component that we create). We will link those two bugs together, using Blocks or External Trackers. Then we simply have the conversation there. We can teach Blocker Bugs App to link to the "discussion bug" from its UI. We can easily CC and "needinfo" other people. Bugzilla automatically sends notifications for new comments, and anyone can subscribe to all blocker bug discussions (either by using Bugzilla's own component watcher, or by watching the appropriate distgit component in Pagure, if available). You can rely on having long-term stable URLs. You can list all open and closed blocker discussions tickets. We can use some additional status for marking "voting in progress" (though that won't be fully obvious). This all sounds pretty good. A slight drawback is that it's not easy to count votes - you have to go through all the comments, find the votes and manually count them. We could create a script that would parse all comments and update the vote summary in the Whiteboard (or perhaps Environment or Doc Text, which is multiline) after each discussion update. I believe Bugzilla is a decent solution for async blocker bug meetings. Its UI is not very pretty, but it has most of the necessary functions. Pagure *** This is very similar to the Bugzilla description. For each proposed blocker, we (auto-)create a ticket in a "fedora-blockers" project, for the purpose of a blocker discussion. We interlink the bug and the ticket. We teach Blocker Bugs App to link to the discussion ticket from its UI. We can easily ping other people using @name tagging. Pagure automatically sends notifications for new comments, and anyone can subscribe to all blocker bug discussions using Pagure UI
Re: For today's agenda item - Proposed disk unmount test case
On Wed, Nov 27, 2019 at 9:17 PM Chris Murphy wrote: > On Wed, Nov 27, 2019 at 10:35 AM pmkel...@frontier.com > wrote: > > > https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot > > Why does it need to happen on baremetal only? Any problem discovered > by this test case is sure to need a deep dive no matter baremetal or > VM. I also tend to think that this test case doesn't need to be bare metal exclusive. > One thing all my Btrfs effort has taught me is how underestimated > hardware and firmware bugs are in the storage stack (and even before > Btrfs, the ZFS folks knew about this which is why it was invented). > > A fair point about VM testing is whether the disk cache mode affects > the outcome. I use unsafe because it's faster and I embrace misery. I > think QA bots are now mostly using unsafe because it's faster too. So > depending on the situation it may be true that certain corruptions are > expected if unsafe is used, but I *think* unsafe is only unsafe in the > event the host crashes or experiences a power failure. I do forced > power offs of VMs all the time and never lose anything, in the case of > ext4 and XFS, journal replay always makes the file system consistent > again. And journal replay in that example is expected, not a bug. > By "that example", do you mean the story you just described, or the "bad result example" from the test case? Because in that test case example, if the machine was correctly powered off/rebooted, there should be no reason to reply journal or see dirty bits. > > How to test, step 2 and 3: > This only applies to FAT and ext4. XFS and Btrfs have no fsck, both > depend on log replay if there was an unclean shutdown. Also, there are > error messages for common unclean shutdowns, and error messages for > uncommon problems. I think we only care about the former, correct? > I believe so. Is there a tool that could tell us whether the currently mounted drives were mounted cleanly, or some error correction had to be performed? Because this is quickly getting into territory where we will need to provide a large amount of examples and rely on people parsing the output, comparing and (mis-)judging. The wording in journal output can change any time as well. And I don't really like that. > > Steps 4-7: I'm not following the purpose of these steps. What I'd like > to see for step 4, is, if we get a bad result (any result 2 messages), > we need to collect the journal for the prior boot: `sudo journalctl > -b-1 > journal.log` and attach to a bug report; or we could maybe > parse for systemd messages suggesting it didn't get everything > unmounted. But offhand I don't know what those messages would be, I'd > have to go dig into systemd code to find them. > I think the purpose is to verify that both reboot and poweroff shut down the system correctly without any filesystem issues (which means fully committed journals and no dirty bits set). If we can make all of this easy to test, then we can automate it, and it's a worthwhile effort. If this is mostly guesswork, I wonder whether we really need such a test case. Because yes, it is something that can go wrong (as everything can), but it's not very likely (and if it does, affected people will probably notice soon and file bugs). And we need to be picky when adding test cases, because we can't test anything and everything, we need to focus on those most important or problematic bits. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Updates to disk unmount test case.
On Tue, Nov 26, 2019 at 9:16 PM Adam Williamson wrote: > On Tue, 2019-11-26 at 13:59 -0500, pmkel...@frontier.com wrote: > > > > I assure you that I wasn't being lazy when I created the web draft test > > case. It wasn't copied from e'mail, but from my original LibriWriter > > file where I composed it. The formatting with the results right under > > the test step was a demonstration of a format that has some advantages > > over the existing format. Just a little demo; I will change it. > > I think it can be a good format indeed, and I've seen it used in other > test contexts, but all our other significant test cases use the format > intended by the template where all the test steps are together and all > the expected results are together after the test steps. So it'd > probably be best to stay consistent with that. > > You can use little writing tricks to help people map each test step to > the correct expected result, like you can write in a test step "run > command X and then check the output" (not just "run command X"), and > then in the results you write something like "The output of command X > should be..." I find that's usually enough to make it clear for > testers. > And I'm going to heartily disagree with Adam here. If I hate something about certain our test cases, it's when you have to constantly jump forward and back and look for expected results somewhere else on the page. This makes the test case very hard to follow and very easy to unintentionally omit important actions. Sometimes it makes you repeat the test case just because you read an important instruction too late. I wanted to rewrite all of those bad test cases a long time ago, but never forced myself to do it. The reasonable approach is to write steps one by one in the "How to test" section, and any time there is an expectation of something immediate, mention it at the very same step. It is not necessary to include obvious things. For example, this is not necessary: 1. Log in through virtual terminal. Login should be accepted. because broken login would obviously prevent you from continuing your test case steps. So this is enough: 1. Log in through virtual terminal. But in some cases you want to say something should happen right now that is not obvious and should be mentioned: 1. Create a disk layout without a swap partition. A warning dialog should appear, but it should not prevent you from confirming the layout. or 1. Execute command "foobar". The command should successfully finish (with return code 0) and its output should contain "all ok". The "Expected results" section should contain expectations that are relevant to the final state of the system (although these could be also written together with the last step in "How to test"), or to a condition that should be valid throughout the whole testing process. For example: 1. The final installed system must boot successfully and present a login screen. or 1. Throughout the whole installation process, all mentions of the system version or the edition on all screens must identify the current system correctly (e.g. version is always shown as "31" and edition is always shown as "Server"). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Updates to disk unmount test case.
On Tue, Nov 26, 2019 at 7:59 PM pmkel...@frontier.com wrote: > Kamil, > > I have received your input. Thank you; I appreciate your help. > > With the holiday this week, I will start on the updates next week and > send a note when it is done. > Sure, no rush. Pat, one more thing, can you please make sure you always reply to the same email thread instead of starting a new one? Do not change the subject and use Reply (All) on an existing conversation. Delete all quoted text that no longer relevant, and type in your reply. If you write a new email from scratch (like today), the conversation is no longer threaded, and it is very difficult to follow such a conversation (especially if one wants to read emails from the past). Thank you. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: For today's agenda item - Proposed disk unmount test case
On Mon, Nov 25, 2019 at 1:39 PM pmkel...@frontier.com wrote: > Here is a link to the List discussion on the subject item: > > > https://lists.fedoraproject.org/archives/search?q=drive+dismount+test+case=1=test%40lists.fedoraproject.org=date-asc > > I don't have a current example of this happening. It was originally > posted to the list by Alan Jenkins while F31 was still Rawhide. I had > seen the problem too; so after a few days and no replies, I picked it > up. The problem disappeared shortly after F31 branched. I didn't file a > bug report; though I would have if it had continued. It just seemed like > something important and basic that should get some attention. Especially > since it was once a test case and had been removed from the matrix. > As promised during yesterday's meeting, I looked at the proposed test case: https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot I have multiple comments: - It is trying to check two things at the same time: 1. that reboot/shutdown works as expected 2. that filesystems are properly unmounted. I believe there should be two separate test cases for these. So please split these into two. - Formatting needs be fixed to make it look like our other test case pages. Currently it looks like a copy-paste from email without effort to use wiki formatting. - Basics don't need to be explained, because the required knowledge level for performing the test case guarantees that the tester knows e.g. how to log in. So for example the first two points can be shortened to "Switch to a free virtual console using Ctrl+Alt+F shortcut and log in". - We don't need to mandate a particular disk layout in test case setup. It is more useful for different testers to have different environments, so that they have a higher chance to detect a bug. - I don't like checking pre-shutdown messages using halt very much. The first problem is that with plymouth installed (the default), you won't see the messages, but a frozen plymouth screen (unless you're quite fast and switch it to console messages before it freezes). The second problem is that it relies too much on user intuition in how to distinguish a success or a failure state. There is no example of either. Additionally, do we know for sure that a system that can't unmount filesystems will halt eventually? I'd expect it to hang forever. I'd rather leave all the error checking for the subsequent boot (or in the case of a hanging boot, it's obviously broken - but we won't need a test case for it, because you'll easily see it with regular interaction with the system). - When checking boot logs for fsck fixes, it's important to show an example of not just a successful case, but also of a failed case. And I seem to be lucky today [1]. - When testing system shutdown methods, I'd only use reboot and poweroff. Halt is very niche and shutdown is old and replaced by poweroff. Kamil [1] -- Logs begin at Tue 2019-08-27 09:26:40 CEST, end at Tue 2019-11-26 14:50:14 CET. -- Nov 25 10:25:20 phoenix systemd-fsck[684]: root: recovering journal Nov 25 10:25:20 phoenix systemd-fsck[684]: root: Clearing orphaned inode 12325283 (uid=1000, gid=1000, mode=0100644, size=641092) Nov 25 10:25:20 phoenix systemd-fsck[684]: root: Clearing orphaned inode 12331101 (uid=1000, gid=1000, mode=0100644, size=641092) ... Nov 25 10:25:20 phoenix systemd-fsck[684]: root: clean, 1023215/26869760 files, 46957728/107451392 blocks Nov 25 09:25:22 phoenix systemd-fsck[877]: boot: recovering journal Nov 25 09:25:22 phoenix systemd-fsck[878]: fsck.fat 4.1 (2017-01-24) Nov 25 09:25:22 phoenix systemd-fsck[878]: 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Nov 25 09:25:22 phoenix systemd-fsck[878]: Automatically removing dirty bit. Nov 25 09:25:22 phoenix systemd-fsck[878]: Performing changes. Nov 25 09:25:22 phoenix systemd-fsck[878]: /dev/nvme0n1p1: 34 files, 6897/51145 clusters Nov 25 09:25:22 phoenix systemd-fsck[877]: boot: clean, 103/65536 files, 67833/262144 blocks ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
On Mon, Nov 25, 2019 at 10:27 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault > > == Summary == > Remove ''nullok'' parameter from pam_unix module in default PAM > configuration in order to disallow authentication with empty password. > > == Owner == > * Name: [[User:pbrezina| Pavel Březina]] > * Email: > > == Detailed Description == > > Current default configuration allows users to login with an empty > password by setting nullok parameter to pam_unix module. This affects > only logins to local machine, it does not affect ssh logins as this > must be explicitly allowed in sshd_config. We want to disallow empty > password by default for local logins as well to improve system > hardening. > It makes sense to implement this functionality so that users/admins can harden their systems in this way if they prefer. But I don't think it should be the default all across Fedora. Especially in desktop space, empty passwords make sense. I think the best approach would be to provide the functionality and then let individual spins/editions enable this by default if they want (e.g. the Security spin, or Server). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Qemu issue upgrading to FC31
On Sun, Nov 3, 2019 at 1:02 AM ToddAndMargo via test < test@lists.fedoraproject.org> wrote: > Hi All, > > Fedora 30, attempting to upgrade to Fedora 31 > > # dnf system-upgrade download --refresh --releasever=31 --allowerasing > --best --skip-broken > > Error: > Problem: cannot install the best update candidate for package > qemu-system-x86-core-2:4.1.0-4.fc30.x86_64 >- problem with installed package > qemu-system-x86-core-2:4.1.0-4.fc30.x86_64 >- package qemu-system-x86-core-2:4.1.0-5.fc31.x86_64 requires > libvirglrenderer.so.0()(64bit), but none of the providers can be installed >- package qemu-system-x86-core-2:4.1.0-2.fc31.x86_64 requires > libvirglrenderer.so.0()(64bit), but none of the providers can be installed >- cannot install the best update candidate for package > virglrenderer-0.8.0-1.20191002git4ac3a04c.fc30.x86_64 >- cannot install both > virglrenderer-0.7.0-4.20190424gitd1758cc09.fc31.x86_64 and > virglrenderer-0.8.0-1.20191002git4ac3a04c.fc31.x86_64 >- qemu-system-x86-core-2:4.1.0-4.fc30.x86_64 does not belong to a > distupgrade repository > (try to add '--skip-broken' to skip uninstallable packages) > First, I believe you might avoid some trouble if you don't specify --best. Might not apply to this case. (You use --best exactly when you want to see dependency problems with the latest packages available). Second, virglrenderer-0.8.0 is not available in Fedora 31, there is 0.7.0. So you use some additional repositories, probably something containing bleeding edge qemu builds. You can use "dnf repolist" to see your repositories. Either wait until the third-party repository functions properly, or disable it and use "dnf distrosync" to sync to Fedora-provided package versions. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Toggle key criterion
On Mon, Oct 28, 2019 at 4:34 PM Ben Cotton wrote: > On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral wrote: > > > I guess the proposed criterion should get adjusted per our latest > discussion in blocker review meeting, i.e. this one: > > > > 16:28:24 #agreed 1755898 - AcceptedBlocker (Final) - per list > and meeting discussion of bcotton's proposed criterion, we agree in > principle to block on modifier key toggling working well and consistently > throughout the system, but not on the light state being correct (as that is > difficult to guarantee). consequently the 'shell and apps behave > differently' portion of this is accepted > > > https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-blocker-review.2019-10-07-16.02.log.html > > > Based on this, I am presenting a modified proposal: > > == Keyboard toggle keys == > > For all release-blocking desktops, the Caps Lock and Num Lock keys > must correctly toggle the relevant behavior for the desktop and all > applications. > I believe we should explicitly state that the light state might not match. Otherwise we'll forget about this discussion and many of us will assume the light state must match as well (and then Adam will have to use his infinite memory and dig through the archives to prove us wrong once again). But, I wonder if we perhaps still could make it more stricter about the light indicator. The argument was that there is some hardware that doesn't allow querying or something, and that's why we can't guarantee that. Well, what if we said the light state must reflect the reality in principle, but it doesn't need to work for hardware that doesn't support necessary capabilities or is otherwise hard to work with? Because if there's a race condition that lights up the indicator randomly whenever you boot, I'd like to cover that case with the criterion. If the light state is clearly broken in software, because it's inverted on *all* keyboards out there, I'd like to cover that case with the criterion. Only with problematic hardware, I'd make it non-blocking. What do you think? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Toggle key criterion
On Mon, Oct 7, 2019 at 5:47 PM Adam Williamson wrote: > On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote: > > As we discussed in today's blocker review meeting[1], I am presenting > > a draft proposal for the toggle keys. I am proposing this as a *final* > > criterion, but would not object to adding it as a beta criterion. > > > > == Keyboard toggle keys == > > > > For all release-blocking desktops, the Caps Lock and Num Lock keys > > must correctly toggle the relevant behavior for the desktop and all > > applications. The behavior must be consistent with the displayed > > status on physical or virtual keyboards, where applicable. > > I think I'm on board with this; however, it'd also be good to get input > from the desktop teams, as the responsibility for this ultimately falls > on them. So CCing desktop@ and kde@. What do you folks think about this > proposed criterion? > I guess the proposed criterion should get adjusted per our latest discussion in blocker review meeting, i.e. this one: 16:28:24 #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-blocker-review.2019-10-07-16.02.log.html ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Highlights from the latest Copr release
On Fri, Oct 4, 2019 at 3:37 PM Pavel Raiskup wrote: > Hello, > > today (on Oct 4, 2019), new Copr release landed production. > > This was mostly a bugfix release, with some optimization/reliability > patches interesting for copr administrators. But there were few exciting > changes for the end-users: > > Multilib projects > - > > If you go to the project settings, there's a new "multilib" checkbox. > When you (a) enable this feature and (b) you enable chroots that form a > "multilib pair" (for example fedora-rawhide-x86_64 and > fedora-rawhide-i386), the repofile generated for your users will contain > two repos with two baseurls, one for x86_64 and one for i386. So in turn > packages for both architectures will be available. This is also fixed in > `dnf enable copr USER/PROJECT` use-case on affected systems, but you need > to wait for `dnf-plugins-core >= 4.0.10`. > Awesome! Thank you. ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On Fri, Oct 4, 2019 at 3:37 PM Pavel Raiskup wrote: > Hello, > > today (on Oct 4, 2019), new Copr release landed production. > > This was mostly a bugfix release, with some optimization/reliability > patches interesting for copr administrators. But there were few exciting > changes for the end-users: > > Multilib projects > - > > If you go to the project settings, there's a new "multilib" checkbox. > When you (a) enable this feature and (b) you enable chroots that form a > "multilib pair" (for example fedora-rawhide-x86_64 and > fedora-rawhide-i386), the repofile generated for your users will contain > two repos with two baseurls, one for x86_64 and one for i386. So in turn > packages for both architectures will be available. This is also fixed in > `dnf enable copr USER/PROJECT` use-case on affected systems, but you need > to wait for `dnf-plugins-core >= 4.0.10`. > Awesome! Thank you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Gnome on F31: X and Wayland clipboard weirdness(es)/regressions
On Fri, Oct 4, 2019 at 12:50 PM Lukas Ruzicka wrote: > > > Both have been rejected as blockers due to being too "edge case". But >> pasting into QT applications seems sufficiently broad to be considering as >> blocking, I think. So if your problems are not related to those two issues >> (e.g. have a VM running), please file new bugs and feel free to propose >> them as blockers (or at least mark them as CommonBugs). >> > > I am not sure you would be able to block on this, since no QT applications > are in standard Workstation installation. As far as I have seen, there is a > tendency not to block on additional software. > It would be of course up to debate. I'm just saying it's a good topic for debate. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Gnome on F31: X and Wayland clipboard weirdness(es)/regressions
On Thu, Oct 3, 2019 at 3:30 PM Ankur Sinha wrote: > Hello, > > I ran into an issues with copy/pasting on F31 with the new Gnome 3.34. > Are these known, or are they expected and if not where should one file > bugs please? > > gnome-shell-3.34.0-3.fc31.x86_64 > > > --- Issue 1 > > X clipboards cleared when applications closed > > Steps to reproduce: > > 1. Run gnome with Wayland > 2. Install xsel and wl-clip to investigate the X and Wayland clipboard > contents respectively > 3. Open Gedit and write some text > 4. Open a terminal (tile them both for ease) > 5. In gedit copy the text: highlight and right click > copy > 5. In the terminal, run the following commands: > 5a. xsel -o (PRIMARY X selection buffer) > 5b. xsel -o -b (CLIPBOARD X selection buffer) > 5c. wl-paste (wayland selection buffer) > 6. Then, close gedit, and re-run these commands. > > When gedit is running, the copied text is available to the X and wayland > clipboards---all commands will show it. > > When gedit is closed, the `xsel` commands no longer show any results. > The contents of the clipboards have been cleared. wl-paste still pastes > the expected output. > > Is this expected behaviour? > > > Issue 2: cannot yank (copy) from gvim into Qt applications running on > Gnome > > Note that in the above, we used Gedit which I assume runs on wayland and > accesses the required wayland clipboard properly. > > In the second scenario, if one copies anything from Gvim, it is > available to the respective X clipboard, and the Wayland clipboard, but > Qt applications running in Gnome cannot access any of this. > > Steps to reproduce: > > 1. Run gnome with wayland > 2. Install xsel and wl-clip to investigate the X and Wayland clipboard > contents respectively > 3. Install qutebrowser and/or falkon > 4. Open a terminal, open qutebrowser and falkon > 5. Run a new Gvim instance: gvim -u NONE (ensures that no vimrc files are > read) > 6. Write two lines of text in Gvim (press i to enter insert mode, write a > line, hit enter, write another line, press ctrl c to exit insert mode) > 7. Copy the first line into the X CLIPBOARD selection buffer: go to the > start of the line, press v to enter visual mode, go to the end of the line > to highlight it; press "+y to yank to the + register (X CLIPBOARD selection) > 8. In a terminal, check if this is available: > 8a. wl-paste: shows copied text > 8b. xsel -o -b: shows copied text > 9. Try pasting in falkon or qutebrowser: ctrl v or right click > paste > (greyed out): nothing shown. > 10. Copy the second line into the X PRIMARY selection buffer: go to the > start of the line, press v to enter visual mode, go to the end of the line > to highlight it; press "*y to yank to the * register (X PRIMARY selection) > 10a. wl-paste: still shows first line > 10b. xsel -o -b: shows first line (as expected) > 10c. xsel -o -p: shows second line (as expected) > 11. Try pasting in falkon or qutebrowser: ctrl v or right click > paste > (greyed out): nothing shown. > 12. Open gedit, write something, copy it, try pasting in Falkon > 12a. Irrespective of whether gedit remains open or not, the text is > available the first time I try to paste it, and not any longer. > 12b. On qutebrowser, though, this remains available, so this is a falkon > thing/feature > 12c. wl-paste continues to show this value as many times as you run it. > 13. Since the x selections are cleared when gedit is closed (issue 1), vim > cannot access the copied text at all using either the + or * registers > later. > > So: > - the wayland buffer is synced with the X CLIPBOARD buffer, which is > fine: https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection > - but none of this is available to Qt applications running in Gnome if > if it originates from X buffers? > Hi, so far I'm aware of these two clipboard-related issues: https://bugzilla.redhat.com/show_bug.cgi?id=1751646 https://bugzilla.redhat.com/show_bug.cgi?id=1755038 Both have been rejected as blockers due to being too "edge case". But pasting into QT applications seems sufficiently broad to be considering as blocking, I think. So if your problems are not related to those two issues (e.g. have a VM running), please file new bugs and feel free to propose them as blockers (or at least mark them as CommonBugs). I have learned that mutter now contains a clipboard manager, that should keep clipboard contents even after an application is closed (that wasn't the case before). But I don't know which exact cases it should cover (X11, Wayland, Wayland<->XWayland). Hopefully some people here from the desktop list can clarify. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: Proposal: Toggle key criterion
On Mon, Sep 30, 2019 at 9:19 PM Ben Cotton wrote: > As we discussed in today's blocker review meeting[1], I am presenting > a draft proposal for the toggle keys. I am proposing this as a *final* > criterion, but would not object to adding it as a beta criterion. > > == Keyboard toggle keys == > > For all release-blocking desktops, the Caps Lock and Num Lock keys > must correctly toggle the relevant behavior for the desktop and all > applications. The behavior must be consistent with the displayed > status on physical or virtual keyboards, where applicable. > Sounds reasonable to me. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: move "image size" criterion from Beta to Final
I'm happy we have some automation in place now, but I feel this whole discussion went somewhat off-topic from the proposal. It seems I haven't gained any support for simply moving the criterion to Final, and I don't really want to make such a trivial check more complex (in terms of release criteria description or way of checking it) according to some suggestions here. So I withdraw my proposal. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: move "image size" criterion from Beta to Final
On Tue, Sep 17, 2019 at 10:35 PM Ben Cotton wrote: > On Tue, Sep 17, 2019 at 9:55 AM Kamil Paral wrote: > > > > Considering this, I believe it makes sense to move the current criterion > from Beta to Final. > > > I'd be okay with letting the responsible team specify a buffer they're > willing to accept for Beta (e.g. so Workstation might say "we can > allow 10% over our specified limit" and Server can say "if we go over > the DVD won't burn, so what's the point?") In other words, any overage > would be an automatic blocker, but teams can optionally pre-approve > exceptions. This way, teams can still make determinations that are in > the best interests of the deliverable they're targeting, but we don't > end up in a position we're slipping a week because a deliverable is 5 > bytes larger than desired. > While this sounds good in theory, I feel that it's over-engineering. It will be maintenance heavy for automated tests (to ensure the values hardcoded in the script match the wiki page or whatever true source there is) and it will be extremely painful to check manually (counting the numbers). It also makes a rather trivial thing quite complex. Boy, I had no idea this proposal would get so debatable :-) I'd rather keep the current situation (block hard for Beta) than complicate it so much. > > I like this approach better than just moving the criterion to Final > because in cases of large overages, the package gymnastics that might > be required to make it work could prove to be pretty impactful. I'd > have a lot more confidence in our ability to deliver a good experience > to our users if we're trying to trim half a gig from an image before > Beta than if we're doing it on the Monday before Go/No-Go. > Yes, but in all those years I don't remember a situation where we needed to shave more than 100MB or so. You don't get 500MB+ growth from some new library dependencies. And in cases where such a growth was at least semi-excepted, the image maximum size limit will probably get updated anyway. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: move "image size" criterion from Beta to Final
On Tue, Sep 17, 2019 at 8:38 PM Adam Williamson wrote: > We could consider still enforcing sizes which clearly relate to optical > media (so, basically, 700MB and 4.7GB sizes). > But we enforce them, for Final. And for Beta, we don't block on optical media anyway. That was one of my arguments why this criterion is no longer critical for Beta. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: move "image size" criterion from Beta to Final
On Tue, Sep 17, 2019 at 7:34 PM Chris Murphy wrote: > On Tue, Sep 17, 2019 at 7:55 AM Kamil Paral wrote: > > > > We currently have the following Beta criterion: > > "The release-blocking images must meet current size requirements." [1] > > > > The latest "Workstation image is oversized" bug [2] showed that we don't > consider this requirement to be that critical. People mostly agreed that > having a slightly oversized image at Beta is no big deal. And there's much > truth to it. The limits were critical when we used optical media, but with > flash drives, there is always an option to use a larger one. > > > > Considering this, I believe it makes sense to move the current criterion > from Beta to Final. > > > > There are other options to handle this, like giving the image size e.g. > 10% headroom during Beta. We can do this, but the more I think about it, > the less value I see in it. If the image was 11% over size, would it really > matter? I think we actually don't care image image size restrictions before > Final release at all. For Final release, sure, some groups want to fit X GB > flash drives, and some groups want to fit onto a DVD disc. But for Beta we > can always test it just fine, regardless the size (and no images are > release blocking for optical media for Beta). > > > > Thoughts? > > > Maybe the oversize tolerance for beta is 50%? I think it may at this > point be more about significantly impacting download speed than media > availability. At least in the U.S., bandwidth is highly variable [1] > with a large number of people having less than 10Mbps download rates. > I'm sure there's an oversize percent between 10% and 200% where most > of us would generally agree, umm yeah we should block beta and make > the image smaller. > I don't think it's realistic that the image size would increase by 100% or more by accident. That's why I'd have no such limit for Beta. I'd rather have the criteria simpler and then be surprised once in 10 years and deal with it, then have complex criteria and be covered against a very unlikely situation. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
proposal: move "image size" criterion from Beta to Final
We currently have the following Beta criterion: "The release-blocking images must meet current size requirements." [1] The latest "Workstation image is oversized" bug [2] showed that we don't consider this requirement to be that critical. People mostly agreed that having a slightly oversized image at Beta is no big deal. And there's much truth to it. The limits were critical when we used optical media, but with flash drives, there is always an option to use a larger one. Considering this, I believe it makes sense to move the current criterion from Beta to Final. There are other options to handle this, like giving the image size e.g. 10% headroom during Beta. We can do this, but the more I think about it, the less value I see in it. If the image was 11% over size, would it really matter? I think we actually don't care image image size restrictions before Final release at all. For Final release, sure, some groups want to fit X GB flash drives, and some groups want to fit onto a DVD disc. But for Beta we can always test it just fine, regardless the size (and no images are release blocking for optical media for Beta). Thoughts? [1] https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria#Image_size_requirements [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751438 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Mon, Sep 16, 2019 at 5:06 PM Adam Williamson wrote: > I still consider automatic blockers to be about obviousness (not > criticality), but I'm open to different resolutions here anyway, if we > want to come up with something really clear. > For the record, we talked about this yesterday in QA meeting [1], and the majority opinion was that last minute blocker policy is applicable to automatic blockers. Adam promised to slightly clarify that in the SOP. [1] search for "Automatic blockers vs. 'last minute' blockers" at https://meetbot.fedoraproject.org/teams/fedora-qa/fedora-qa.2019-09-16-15.01.log.html ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson wrote: > On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote: > > As I feel it (and would like to have it), "automatic blockers" imply they > > are such core and basic issues that they are non-questionable and > > non-waivable (except by FESCo, which is itself part of the same policy > and > > marked to have godly powers). If you read the list of automatic blockers > > [3], those are broken composes, dead-on-arrival images, incorrect > > checksums, broken dependencies, and *oversize images*. I don't think > anyone > > but FESCo should be able to say "go" in that case, regardless of when the > > problem was reported (even minutes before the final meeting). I'd really > > like automatic to mean automatic, without any consideration. > > FWIW, I respectfully disagree with this. The key factor for whether > something goes on the 'automatic' blockers list is *whether it could > possibly be ambiguous*, not how waivable it is. > > It happens to be the case that *most* things that are really non- > ambiguous are terribly critical things we would never postpone under > the last-minute policy - like an image simply failing to boot. That > kinda makes sense if you think about it: catastrophic things tend to be > very clear. But it's also possible for something to be very clear but > not necessarily critical. To me, the size limits - at least, ones which > don't match any significant media size - are that. Size limits are on > the automatic blocker list because there's really no need for three > teams to debate and vote on whether one number is bigger than another, > not because exceeding the size limit is a catastrophic bug. > There are two ways how to understand automatic blockers - that they are based on bug seriousness, or obviousness. I clearly use the former one, and you the latter one. I guess that's why our views differ. > > Note also that under the last-minute blocker policy as written we're > supposed to *first* decide that the issue is a blocker - i.e. accept it > in principle - *then* decide to push that status to a later milestone. > i.e. the policy effectively applies to bugs that are accepted as > blockers. The process isn't that we reject the bug as a blocker under > the last-minute blocker policy: the process is that we accept it but > agree that moving it to the next milestone is acceptable. So, I don't > think the incompatibility between the two policies is that bad at all. > I think we could simply clarify that the last-minute blocker policy can > also be applied to bugs that have already been accepted under the > 'automatic blocker' policy, so long as they were *proposed* within the > 5 day time limit. > You've lawyered me here (I should have expected that). I wanted to argue that the delaying is supposed to happen before accepting it as a blocker, but no, you're correct. What I see mildly annoying with this approach is that it bring uncertainty into the process. Before, an accepted blocker was an accepted blocker, and you could count on that and adjust your priorities appropriately. That means working on the fixes as a developer, or debugging it more as a QA. Now, a blocker can be delayed (postponed to a much later date) and so the dependability on the "AcceptedBlocker" label is suddenly no longer what it used to be. > > To me this was actually a very appropriate bug for the last-minute > policy: it's a not-terribly-critical problem that, through process > failure, was only raised at the last minute even though it was known > about for ages. I feel bad for not noticing it had been failing for two > months, but I don't feel bad about applying the last-minute blocker > policy to it. I don't think releasing a Beta with a Workstation live > image that's 2.04GB in size instead of 1.99GB in size is going to cause > Fedora huge problems. > I don't disagree here, but that's why I wanted to discuss the process separately from this particular issue. For me, automatic blockers were about bug criticality, and therefore my view was that we are too strict in this particular requirement for Beta release and should resolve it in a different way (e.g. by weakening the criterion). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: rename "target size" to "maximum size" for release-blocking images
On Fri, Sep 13, 2019 at 5:42 PM Adam Williamson wrote: > On Fri, 2019-09-13 at 08:44 -0400, Ben Cotton wrote: > > On Fri, Sep 13, 2019 at 8:09 AM Kamil Paral wrote: > > > Related to Workstation image oversize bug [1] and the related > > > Go/NoGo meeting, I'd like to propose to rename the image-related > > > term "target size" to "maximum size". > > > > +1. I see no downsides to this. > > Also +1, dunno why someone picked 'target' in the first place. > Thanks everyone, I went ahead and updated the three pages I listed and this one as well: https://fedoraproject.org/wiki/Releases/31/Spins ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
proposal: rename "target size" to "maximum size" for release-blocking images
Related to Workstation image oversize bug [1] and the related Go/NoGo meeting, I'd like to propose to rename the image-related term "target size" to "maximum size". The rename would affect the following pages: https://fedoraproject.org/wiki/Releases/31/ReleaseBlocking https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size I believe "target size" doesn't convey the meaning properly. For release-blocking purposes (and I'm not aware of any other purposes), this is really a hard stop. Exceeding the limit is an automatic blocker. That's why I believe it should be called "maximum size", to make it clear. There might also be a psychological impact on relevant SIGs, where "target size" can motivate you to keep the image size more-or-less around the number, while "maximum size" clearly tells you it's a hard stop, and that you don't _need to_ keep it as close as possible. Images which are on a long-term basis extremely close to the limit should be a point of concern, because the limit might be exceeded at the most inconvenient time by any library change, and I believe "maximum size" communicates that much better. Thoughts? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1751438 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Fri, Aug 30, 2019 at 3:11 AM Adam Williamson
wrote:
> On Fri, 2019-08-09 at 19:04 -0700, Adam Williamson wrote:
> > On Fri, 2019-08-09 at 18:26 -0700, Adam Williamson wrote:
> > > On Wed, 2019-07-24 at 10:04 -0400, pmkel...@frontier.com wrote:
> > > > I got feedback from Adam and Ben today; so the following changes
> have
> > > > been made:
> > > >
> > > > I have added a little paragraph at the beginning to say what a last
> > > > minute blocker bug is. I used freeze as the time anchor rather than
> a
> > > > meeting since that seems to be the most firm time constraint we work
> to.
> > > > Perhaps the review meetings could be anchored to the freeze as well.
> > > > There might be some merit to showing the critical meetings in the
> > > > schedule list that gets published.
> > > >
> > > > I changed "team" to "stakeholder groups"
> > > >
> > > > I removed "proposed" from places where it really didn't add anything.
> > > >
> > > >
> > > > Have a Great Day!
> > > >
> > > > Pat (tablepc)
> > >
> > > Thanks Pat! For future drafts, can you please just send them as plain
> > > text in line? It makes it more convenient to read them quickly. For the
> > > record, here is Pat's proposal:
> >
> > *snip*
> >
> > OK, so here is a new draft based on a kind of merge of Pat's recent
> > drafts and my earlier drafts. For the record, my previous draft was 555
> > words, Pat's last draft is 258 words (without counting the paragraph
> > numbers and without any wikitext like mine has), and this is 445 words.
> > I think Pat's draft left out some necessary connective tissue, though
> > (like what exactly this concept is *for*, and details on how exactly
> > the review should be handled, and it kinda smooshed together the 'last
> > minute' and 'difficult to fix' concepts), so I don't think I can cut
> > much more.
>
> OK, so based on the follow-ups here, I went ahead and merged this
> draft, only with '7 days' changed to '5 days':
>
>
> https://fedoraproject.org/w/index.php?title=QA%3ASOP_blocker_bug_process=revision=551137=503308
>
> Thanks folks!
>
I'd like to revive this topic. Yesterday [1], the last minute blocker
policy was misused (at least in my eyes) to ignore the workstation oversize
bug [2], which was already accepted as an automatic blocker. I believe it
was an inappropriate solution to the situation, and last minute blocker
policy directly contradicts automatic blocker policy, i.e. they can't be
used together, and the latter automatically beats the former.
As I feel it (and would like to have it), "automatic blockers" imply they
are such core and basic issues that they are non-questionable and
non-waivable (except by FESCo, which is itself part of the same policy and
marked to have godly powers). If you read the list of automatic blockers
[3], those are broken composes, dead-on-arrival images, incorrect
checksums, broken dependencies, and *oversize images*. I don't think anyone
but FESCo should be able to say "go" in that case, regardless of when the
problem was reported (even minutes before the final meeting). I'd really
like automatic to mean automatic, without any consideration.
As a result, I propose that we add a note to the automatic blockers policy
description that sounds something like this:
"Automatic blockers can't un-accepted (waived), with the exception of
FESCo."
An alternative option would be to exclude just "last minute blocker bugs"
exception, but keep "difficult to fix" exception:
"Automatic blockers can't be subject to last minute blocker bugs exception
policy."
This would allow people in blocker review/Go-NoGo meeting to delay an
automatic blocker because it was difficult to fix, but would not allow them
to delay it because it was reported too late ("delay" here can mean from
F31 to F32, not just Beta to Final). For any other reason, the issue would
have to be raised to FESCo.
I think the first proposal is better, but the second version works for me
as well.
Anything that we don't deem "absolutely essential" should not be part of
the automatic blocker list. If we're OK with not keeping the maximum image
size during Beta, we should not have it there. The same applies to anything
else in the list.
Don't misunderstand my email. I'm glad that F31 Beta is go. And I'm also
not sold on the idea of delaying Beta release because Workstation image is
50 MB over size. But I believe we shouldn't sacrifice our policies
consistency to achieve that goal. That's why I want to clarify our
policies. And then we can talk about dealing with this particular situation
in a better way (by excluding Beta image sizes from automatic blockers, or
perhaps keeping them just for release-blocking optical images, or bumping
the Workstation maximum size, improving our QA processes, etc).
Thanks,
Kamil
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-12/f31-beta-go_no_go-meeting.2019-09-12-17.00.log.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1751438
[3]
Re: Problem with locking user session
On Wed, Sep 11, 2019 at 2:46 PM Kamil Paral wrote: > On Tue, Sep 10, 2019 at 5:59 PM wrote: > >> F31 Workstation fully updated. >> Strange behaviour after I create a user in addition to the one created >> during initial setup. >> >> So, create a new user. >> Lock the current user session. >> Click on "Log in as another user". >> Click on the other user. Insert password and log in. It seems to log >> in, but after a couple of seconds, you are again on the Lock screen >> (where the clock is displayed). Press a key. The password of the user >> that locked the previous session is requested. >> Click on "Log in as another user". >> A subsequent login with another user, works. >> > > I can reproduce this. With the change that my second user is locked out of > the session every 10 seconds, no matter how many times switch back in. > > This is a great bug, thanks for reporting. I'll file a bugzilla ticket and > link it here. > Here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1751673 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Problem with locking user session
On Tue, Sep 10, 2019 at 5:59 PM wrote: > F31 Workstation fully updated. > Strange behaviour after I create a user in addition to the one created > during initial setup. > > So, create a new user. > Lock the current user session. > Click on "Log in as another user". > Click on the other user. Insert password and log in. It seems to log > in, but after a couple of seconds, you are again on the Lock screen > (where the clock is displayed). Press a key. The password of the user > that locked the previous session is requested. > Click on "Log in as another user". > A subsequent login with another user, works. > I can reproduce this. With the change that my second user is locked out of the session every 10 seconds, no matter how many times switch back in. This is a great bug, thanks for reporting. I'll file a bugzilla ticket and link it here. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Automatic blocker addition proposal: desktop background criterion
On Thu, Sep 5, 2019 at 8:59 PM Adam Williamson wrote: > Hey folks! So, it was suggested at the blocker review meeting on Monday > that violations of the Basic desktop background criterion: > > "The default desktop background must be different from that of the last > two stable releases." > > should be added to the 'automatic blocker' list: > > > https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers > > this is basically a list of cases where blocker status is so clear-cut > and obvious that there's no need for us to vote on it, and any > stakeholder can just invoke the 'automatic blocker' policy and mark a > bug as 'AcceptedBlocker' if it matches one of the cases in the list. > > Does anyone have any objection to adding this? If not, I'll go ahead > and do it next week. Thanks! > No objection. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: New version of Copr
On Wed, Sep 4, 2019 at 2:29 PM Dominik Turecek wrote: > Hello. > > Today, we have released a new version of Copr. > Main highlights from the release was the addition > of discussion panels in Copr projects and speed > optimization of front page. > The discussion page is a neat idea. For some projects, I see "start discussion" button, but for others, I see just "Loading Discussion..." that eventually changes to "Error embedding". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Gnome + VNC
On Tue, Sep 3, 2019 at 11:52 AM wrote: > On F31 with latest updates, in GNOME Settings I enabled Sharing then > Screen Sharing. > I use Remmina to connect via VNC, and it works. > But when the system, after the default 5 minutes of inactivity blanks > the screen and locks the user session, VNC session is terminated. > Can you re-connect and unlock the session? > While on F30 the VNC session is not terminated even if the screen goes > blank and the session is locked; I can unlock the session via VNC. > Do you use X11 in both releases? I don't know if Wayland can already work with VNC through Pipewire, so just checking. > > I tested it on bare metal and in a KVM VM. > In addition, when I try to unlock the session, on the bare metal > machine the cursor arrow appears, but the screen stays black and the > mouse and the keyboard don't work. > You mean unlocking by re-connecting VNC, or unlocking locally? Does this happen only after the VNC use case, or always? > > I would like to wait the GNOME mass rebuild before filing a bug (if it > wasn't already filed by someone else). > If you continue to see it after the rebuild, please file bugs and possibly even propose them as blockers. "Screen sharing" is one of the options in gnome-control-center, so it's expected to work reasonably well. Screen unlocking even more so :-) Thanks! ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Thu, Aug 29, 2019 at 4:33 PM Dusty Mabe wrote: > I don't know the formal process for proposal but here is a shot at a bare > minimum > start for trying to add containers to the existing release criteria. This > is a suggestion > after we found podman can't pull containers from a registry in f31 [1]. > > New section for Containers and Container tools: > > - A Fedora system can install the podman container runtime > - The podman container runtime can pull/run a container from Fedora's > registry as root > - The podman container runtime can pull/run a container from Fedora's > registry as a non-root user > > As for the container I'd suggest the previous fedora release's container > (i.e. f30 for f31). > Correct me if I'm not thinking straight, but Fedora containers are not release blocking right now. If we require that latest stable fedora container must be pulled and run correctly, we will corner ourselves if the container is broken. Because we will block the release on a compose artifact which is itself not release blocking. So unless I'm talking nonsense, it might be better to specify "any container" (and recommend to test with latest stable fedora container). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide gating: What shell be done with failed updates?
On Wed, Aug 28, 2019 at 1:24 PM Pierre-Yves Chibon
wrote:
> Is the issue about updates lingering in -testing?
>
I imagine this could cause some issues for e.g. generic tests that test
everything in -testing in one go, instead of just one particular NVR, for
performance reasons (like rpmdeplint). Or perhaps for tests that try to
push changes in some batches ("every 30 minutes create a batch of
everything proposed in -testing, test it and push to stable together). But
this is just brainstorming, it depends very much on implementation details
and particular use cases. Something to be aware of.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes wrote: > From my standpoint, ext4 and xfs are the primary supported root > filesystems. I don't think that anything else should be release > blocking. If this is the case, we can explicitly list the supported file systems in criteria. The list would need to be extended with at least vfat, which is used for ESP, though. If we go this route, it would be nice to communicate this somehow to the end user, directly in anaconda interface. Either by showing a warning when a "not officially supported" filesystem is selected, or by hiding those filesystems in dialogs when creating a new partition (with a documented override). Existing partitions still need to be handled somehow, so the warning bar might need to be implemented in any case (warn that the existing partition is unsupported by allow to use it, or warn that the existing partition can't be used unless the override is activated). ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Discussion: what would not blocking on btrfs look like?
On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes wrote: > From my standpoint, ext4 and xfs are the primary supported root > filesystems. I don't think that anything else should be release > blocking. If this is the case, we can explicitly list the supported file systems in criteria. The list would need to be extended with at least vfat, which is used for ESP, though. If we go this route, it would be nice to communicate this somehow to the end user, directly in anaconda interface. Either by showing a warning when a "not officially supported" filesystem is selected, or by hiding those filesystems in dialogs when creating a new partition (with a documented override). Existing partitions still need to be handled somehow, so the warning bar might need to be implemented in any case (warn that the existing partition is unsupported by allow to use it, or warn that the existing partition can't be used unless the override is activated). ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: fedora-gpg-keys not updated yet again
On Fri, Aug 23, 2019 at 10:39 AM Vít Ondruch wrote:
>
> Dne 22. 08. 19 v 18:57 Kevin Fenzi napsal(a):
>
> On 8/21/19 3:24 AM, Vít Ondruch wrote:
>
>
> That is not completely true. The only possible way is to update the
> `fedora-gpg-keys` first without anything else and that was the reason
> for [1]. But since [1] did not landed in Fedora prior the branch, there
> is no way to update Rawhide and keep everything Rawhide and at the same
> time keep checking signatures all the time.
>
> But you could upgrade to the f31 version and then to rawhide.
>
> IOW prior branch, I had installed fedora-repos-31-0.2 together with
> fedora-gpg-keys-31-0.2. As long as there was no F31 compose, there was
> available fedora-repos-32-0.2 together with fedora-gpg-keys-32-0.2 (or
> 0.1, it does not really matter), but those were not possible to install,
> because they are signed by F32 GPG key, which is not available on my
> system yet. The fedora-repos-31-0.5 is the first post branch package
> signed with the key on my system. This allows me to install
> fedora-gpg-keys-31-0.5 but at the same time it changes the configuration
> of /etc/yum.repos.d/fedora{,-rawhide}.repo making the system F31 instead
> of Rawhide. And this is wrong.
>
> Wrong how? What do you want there?
>
>
> My system is Rawhide and should stay Rawhide. I don't want to stay on F31
> by mistake. I don't ever wan't to install anything from stable branch.
>
>
> Most/many people want to folow the
> branch, so thats what we have always done there.
>
>
> Some people want, but I doubt it is majority. It makes no sense to
> suddenly switch from Rawhide to F31. Rawhide should be always Rawhide and
> switching to stable branch should be conscious decision.
>
>
> In any event, hopefully soon we will have rawhide named rawhide and not
> 31 or 32 and with that you can indicate what you want to do much more
> clearly.
>
>
> Looking forward to this.
>
External testing is very welcome:
https://pagure.io/releng/issue/7445
https://copr.fedorainfracloud.org/coprs/kparal/rawhide-releasever/
This will also have the effect that Rawhide installation will always stay
Rawhide, and you'll need to explicitly switch to Branched, if you want to
do so.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Mon, Aug 12, 2019 at 11:40 PM Adam Williamson wrote: > On Mon, 2019-08-12 at 22:39 +0200, Kamil Paral wrote: > > On Sat, Aug 10, 2019 at 4:04 AM Adam Williamson < > adamw...@fedoraproject.org> > > wrote: > > > > > > > > +++ DRAFT START +++ > > > > > > === Exceptional cases === > > > > > > Generally speaking, any bug that is agreed to be a violation of the > > > [[Fedora Release Criteria|release criteria]] should be accepted as a > > > blocker bug for the next relevant milestone release. However, bearing > > > in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis > > > on '''both''' time '''and''' quality, in some cases we may make an > > > exception. There are two main categories of bug that may be > > > 'exceptional': > > > > > > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or > > > fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release > > > (Beta or Final) can be considered under this policy, as there are some > > > circumstances in which we believe it is not sensible to delay an > > > otherwise-impending release to fix a bug which would usually be > > > accepted as a blocker if discovered earlier. In these circumstances, > > > the bug can instead be accepted as a blocker for the ''next'' milestone > > > release. > > [snip] > > > That's very well written and I don't have any concerns about its wording. > > I'm a bit hesitant whether 7 is the right number, but we can try it and > see. > > I should've called that up for discussion more prominently, I guess. > Yes, I just picked that number out of the air, it's absolutely up for > debate. Do you think it should be a bigger number or a smaller number? > :) I wondered about whether to build in some fudge space here - say the > number's a guideline and we can go beyond it if we think it's a good > idea - but worried that might be a bit too messy. > I thought about it and 7 days probably sounds OK, considering it also includes the weekend. I think I wouldn't increase it, but consider decreasing it if people think it's the right way to go. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: A Friday with Infra [fedocal possible retirement]
On Fri, Aug 9, 2019 at 5:16 PM Adam Williamson wrote: > In case folks didn't see it on devel@, I wanted to flag this up here. > Infra is talking about no longer maintaining fedocal. We do use it for > some purposes, the most notable I can think of is the Test Day calendar > - we used to keep the Test Day schedule in the wiki, effectively, then > a few years back moved to doing it in fedocal. Anyone have any thoughts > on how we should handle this? > It's not just test days, it's also our other events - QA meetings, blocker review meetings, maybe something else (we used to have QA devel meetings). Unless somebody steps up to maintain Fedocal, the simple yet probably unpopular solution is to maintain it in Google Calendar or something similar. Yes, it's a proprietary service, and the admin privileges can't be maintained through FAS. But the end-user experience is very similar - people can see a web view of the events, and they can add an ical link to their calendar client of choice. If somebody knows of a FOSS service to host calendars accessible through ical, speak up please. I can also think of some bear-bone solution e.g. by storing the ics file in a git repo, pull, edit in Evolution/etc, push. People could still link it to their calendar client, but we wouldn't have any web view. I don't think we want to go this route, though. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Update to last minute blocker bugs proposal (Rev:07242019)
On Sat, Aug 10, 2019 at 4:04 AM Adam Williamson wrote: > > > +++ DRAFT START +++ > > === Exceptional cases === > > Generally speaking, any bug that is agreed to be a violation of the > [[Fedora Release Criteria|release criteria]] should be accepted as a > blocker bug for the next relevant milestone release. However, bearing > in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis > on '''both''' time '''and''' quality, in some cases we may make an > exception. There are two main categories of bug that may be > 'exceptional': > > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or > fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release > (Beta or Final) can be considered under this policy, as there are some > circumstances in which we believe it is not sensible to delay an > otherwise-impending release to fix a bug which would usually be > accepted as a blocker if discovered earlier. In these circumstances, > the bug can instead be accepted as a blocker for the ''next'' milestone > release. > # '''Difficult to fix blocker bugs''' - bugs which it may not be > practical to fix within a reasonable time frame for the release to be > made (due to e.g. complexity or resource constraints) > > The stakeholder groups must first agree, following the procedures > described above, that the bug violates the release criteria and so > would otherwise be accepted as a blocker bug for the imminent release. > > After that, the stakeholder groups may separately make a decision as to > whether to invoke this policy and consider delaying the blocker status > to a future milestone release. Anyone attending the meeting (or > otherwise taking part in the discussion, if it is being done outside of > a meeting) can suggest that this evaluation be done. In making the > decision, the following factors can be considered: > > * How prominently visible the bug will be > * How severe the consequences of the bug are > * How many users are likely to encounter the bug > * Whether the bug could or should have been proposed earlier in the > cycle > * Whether the current stable release is affected by the bug > * Whether delaying the release may give us an opportunity to carry out > other desirable work > * Possible effects of the expected delay on Fedora itself and also to > downstream projects > * Whether an additional delay to fix the bug, combined with any prior > delays in the cycle, results in the total delay becoming unacceptable > in regard to the [[Fedora_Release_Life_Cycle]] > > In almost all 'exceptional' cases, the bug should be accepted as a > blocker either for the very next milestone release, or for the > equivalent milestone for the next release (if it would not violate the > criteria for the very next milestone). For very complex '''difficult to > fix''' cases, a longer extension may be needed. > > +++ DRAFT END +++ > That's very well written and I don't have any concerns about its wording. I'm a bit hesitant whether 7 is the right number, but we can try it and see. Whether this new policy is a good idea, that's a separate question. The idealist in me cries every time we sacrifice quality. And this policy will probably result in more bugs being waved compared to the past. However, I feel it's better to have the rules formalized than to wave such bugs without any real grounds and feel like cheating on our policies every time we actually need waive something. So yeah, I guess I have no objections to this being a part of our release criteria. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On Tue, Jul 30, 2019 at 10:41 AM Pierre-Yves Chibon wrote: > On Tue, Jul 30, 2019 at 10:11:07AM +0200, Fabio Valentini wrote: > > On Thu, Jul 25, 2019 at 5:25 PM Pierre-Yves Chibon > wrote: > > > > > > Good Morning Everyone, > > > > > > I just wanted to let everyone know that this is now live. > > > You can see all the updates going through (or not) to rawhide in: > > > https://bodhi.fedoraproject.org/releases/F31 > > > > > > Many many thanks to all the people involved, I'm afraid I'll miss some > but I'll > > > take the risk, so here it is (in no particular order): > > > Many thanks to Clément, Aurélien, Kevin, Nils, Mohan, Michal, Randy, > Ryan, > > > Patrick, smooge, Troy and of course Leigh, Jim and Paul who have made > this > > > possible. > > > > > > > That's great, thanks to everyone who made this possible :) > > > > Just s small question, is it possible to include a small default > > "installable" CI test for all packages, which checks if the newly > > built packages are actually installable in rawhide? > > I know of a few issues that could have been prevented if > > non-installable packages (because they introduce broken dependencies) > > were not allowed to enter rawhide without manual intervention. > > It is my understanding that this is something that Dominik's team is > working on > under their "distro-wide" tests that is part of the new CI objective: > https://fedoraproject.org/wiki/Objectives/CI:2019 Hopefully a generic test like rpmdeplint (currently executed in Taskotron against proposed updates) can be executed by Fedora CI as part of Rawhide gating, once the feature is done. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On Wed, Jul 24, 2019 at 2:33 PM Josh Boyer wrote: > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok wrote: > > > > On 24. 07. 19 10:24, Tom Hughes wrote: > > > That said, having to go round adding a mega ugly config file > > > to every package that looks an awful lot like an internal braindump > > > from some system doesn't really inspire confidence, or make for an > > > easy way of opting in. > > > > This. The gating.yaml file is terrible. > > Do either of you have a better suggestion? > If most people would have the same default yaml file copy-pasted into a thousand places, it could be easily replaced with just: ``` gating: default ``` And allow people to override the default policy (with the current syntax or hopefully something more readable) only when they really have some specific needs. This will also help in future when the defaults need to be changed. More preset values can be defined subsequently, e.g.: gating: default/minimal/custom/disabled etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > The Manual Partitioning screen supports all actions of the Resize Disk > Space dialog, so it doesn't make sense to have two user interfaces > with the same functionality. > The manual partitioning screen is also much more complex and therefore more difficult to use. For the common use case of installing Fedora alongside Windows (where you need to shrink the Windows partition), the simple dialog is/was great. Linux novice users might not be able to accomplish that in the manual partitioning screen. Just my personal opinion, I'm not trying to convince you to revert your plan. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
On Mon, Jul 22, 2019 at 8:52 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > = Detailed Description == > > After preliminary discussions with CPU vendors, we propose AVX2 as the > new baseline. AVX2 support was introduced into CPUs from 2013 to > 2015. See [ > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 > CPUs with AVX2]. > We have 3 test machines in Brno's Fedora QA office, none of which support AVX2. Both my parents run Fedora on their laptops, none of which support AVX2. My own desktop machine at home is on the borderline (Haswell). I consider this proposal a complete no-go. That said, I think it might be interesting to have a way for newer CPUs to make use of the new instructions, and people proposed ways to achieve that. But first, we should gather some performance numbers, whether it's worth it at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Mon, Jul 8, 2019 at 6:12 PM Adam Williamson wrote: > On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote: > > > > > > "The release must boot successfully as Xen DomU with releases > providing > > > > > > a functional, supported Xen Dom0 and widely used cloud providers > > > > > > utilizing Xen." > > > > > > > > > > > > and change the 'milestone' for the test case - > > > > > > > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - > > > > > > from Final to Optional. > > > > > > > > > > > > Thoughts? Comments? Thanks! > > > > > > > > > > I would prefer for it to remain as it is. > > > > > > > > This is only practical if it's going to be tested, and tested > regularly > > > > - not *only* on the final release candidate, right before we sign off > > > > on the release. It needs to be tested regularly throughout the > release > > > > cycle, on the composes that are "nominated for testing". > > > > > > Would the proposal above work for you? I think it satisfies what you > are > > > looking for. We would also have someone who monitors these test results > > > pro-actively. > > > > In theory, yeah, but given the history here I'm somewhat sceptical. I'd > > also say we still haven't really got a convincing case for why we > > should continue to block the release (at least in theory) on Fedora > > working in Xen when we don't block on any other virt stack apart from > > our 'official' one, and we don't block on all sorts of other stuff we'd > > "like to have working" either. Regardless of the testing issues, I'd > > like to see that too if we're going to keep blocking on Xen... > > So, this died here. As things stand: I proposed removing the Xen > criterion, Lars opposed, we discussed the testing situation a bit, and > I said overall I'm still inclined to remove the criterion because > there's no clear justification for it for Fedora any more. Xen working > (or rather, Fedora working on Xen) is just not a key requirement for > Fedora at present, AFAICS. > > It's worth noting that at least part of the justification for the > criterion in the first place was that Amazon was using Xen for EC2, but > that is no longer the case, most if not all EC2 instance types no > longer use Xen. Another consideration is that there was a time when KVM > was still pretty new stuff and VirtualBox was not as popular as it is > now, and Xen was still widely used for general hobbyist virtualization > purposes; I don't believe that's really the case any more. > > So...with thanks to Lars / Xen Project for their input, I'm afraid I'm > still in favor of this proposal, and still think we should drop the Xen > criterion for F31. This wouldn't mean Xen is out of Fedora and we don't > care about it any more, or anything like that; it would still be a part > of Fedora and we still would like Xen to work on Fedora and Fedora to > work on Xen, just like any other non-release-blocking package. It just > means we would no longer block releases if it does not work. > Agreed. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Mon, Jul 8, 2019 at 6:12 PM Adam Williamson wrote: > On Tue, 2019-05-21 at 11:14 -0700, Adam Williamson wrote: > > > > > > "The release must boot successfully as Xen DomU with releases > providing > > > > > > a functional, supported Xen Dom0 and widely used cloud providers > > > > > > utilizing Xen." > > > > > > > > > > > > and change the 'milestone' for the test case - > > > > > > > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt - > > > > > > from Final to Optional. > > > > > > > > > > > > Thoughts? Comments? Thanks! > > > > > > > > > > I would prefer for it to remain as it is. > > > > > > > > This is only practical if it's going to be tested, and tested > regularly > > > > - not *only* on the final release candidate, right before we sign off > > > > on the release. It needs to be tested regularly throughout the > release > > > > cycle, on the composes that are "nominated for testing". > > > > > > Would the proposal above work for you? I think it satisfies what you > are > > > looking for. We would also have someone who monitors these test results > > > pro-actively. > > > > In theory, yeah, but given the history here I'm somewhat sceptical. I'd > > also say we still haven't really got a convincing case for why we > > should continue to block the release (at least in theory) on Fedora > > working in Xen when we don't block on any other virt stack apart from > > our 'official' one, and we don't block on all sorts of other stuff we'd > > "like to have working" either. Regardless of the testing issues, I'd > > like to see that too if we're going to keep blocking on Xen... > > So, this died here. As things stand: I proposed removing the Xen > criterion, Lars opposed, we discussed the testing situation a bit, and > I said overall I'm still inclined to remove the criterion because > there's no clear justification for it for Fedora any more. Xen working > (or rather, Fedora working on Xen) is just not a key requirement for > Fedora at present, AFAICS. > > It's worth noting that at least part of the justification for the > criterion in the first place was that Amazon was using Xen for EC2, but > that is no longer the case, most if not all EC2 instance types no > longer use Xen. Another consideration is that there was a time when KVM > was still pretty new stuff and VirtualBox was not as popular as it is > now, and Xen was still widely used for general hobbyist virtualization > purposes; I don't believe that's really the case any more. > > So...with thanks to Lars / Xen Project for their input, I'm afraid I'm > still in favor of this proposal, and still think we should drop the Xen > criterion for F31. This wouldn't mean Xen is out of Fedora and we don't > care about it any more, or anything like that; it would still be a part > of Fedora and we still would like Xen to work on Fedora and Fedora to > work on Xen, just like any other non-release-blocking package. It just > means we would no longer block releases if it does not work. > Agreed. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
fedora-easy-karma "fixed"
Hello, anyone using fedora-easy-karma to submit feedback to proposed Bodhi updates might be interested to know that we've fixed some issues that appeared recently after Bodhi updated to version 4. F-e-k no longer crashes and can list all your karma-able updates. However, due to a bodhi bug [1] it can't submit karma on its own, so for each such update you'll be asked to open the URL manually in a web browser and provide the feedback there. That might be inconvenient for some, but at least you can still use f-e-k to figure out *which* updates you can provide feedback on. I hope the Bodhi bug can be resolved quickly once Bodhi maintainers are back from vacation. The "fixed" f-e-k is already available in stable updates for Fedora 30, and it's in testing updates for Fedora 29 [2] (more karma is welcome). Cheers, Kamil [1] https://github.com/fedora-infra/bodhi/issues/3298 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2019-793e240ce0 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: DNF Make Best Mode the Default
On Fri, Jun 28, 2019 at 11:12 AM Miroslav Suchý wrote: > Dne 27. 06. 19 v 23:56 Zbigniew Jędrzejewski-Szmek napsal(a): > > (try to add '--allowerasing' to command line to replace conflicting > packages or '--skip-broken' to skip uninstallable packages) > > This is message for people who are willing/are able to fix or report > things. For regular user this should be > .. or run with "--nobest" to skip broken deps. > Can somebody clarify the difference between --skip-broken and --nobest? Because even after reading the man page, I still don't get it. And I believe most our users will not get it either. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What to do when Fedora CI run failed?
On Tue, Jun 4, 2019 at 3:29 PM Jan Pazdziora wrote: > > Hello, > > I have run fedora-rawhide-build-pipeline > > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/ > > that failed in the > > cloud-image-compose > > stage, something which (I believe) have very little control over. > > What is the recommended way to remedy the situation, for example for > reruning that pipeline run? > Hi Jan, you might want to cc the CI list: https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
On Wed, May 29, 2019 at 10:20 PM Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
>
> = Switch RPMs to zstd compression =
>
> == Summary ==
> Binary RPMs are currently compressed with xz level 2.
> Switching to zstd would increase decompression speed significantly.
>
> == Owner ==
> * Name: [[User:dmach| Daniel Mach]]
> * Email: dm...@redhat.com
>
> == Detailed Description ==
> * The change requires setting a new compression algorithm in rpm
> macros. Then a mass rebuild of all packages is required.
> * The macro for setting the compression is: %define _binary_payload
> w19.zstdio
> * The recommended compression level is 19. The builds will take
> longer, but the additional compression time is negligible in the total
> build time and it pays off in better compression ratio than xz lvl2
> has.
> * SRPM payload compression should stay at gzip (there's almost no
> benefit in changing the compression, because SRPM's contents is
> compressed already)
>
> === Use case: Firefox installation ===
> I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
> Then I compared installation times with the original (xz compressed)
> package:
>
> {| class="wikitable"
> |-
> ! Compression !! Target File System !! Time
> |-
> | xz level 2 || tmpfs || 8s
> |-
> | xz level 2 || ext4 on nvme || 11s
> |-
> | zstd level 19 || tmpfs || 2s
> |-
> | zstd level 19 || ext4 on nvme || 4s
> |-
> |}
>
>
> === Comparison of compression algorithms and levels ===
> Following table shows '''cpio''' and '''compressed cpio''' extraction
> times into a tmpfs. Actual times in decompressing RPMs will differ due
> to extracting on an actual disk and also some overhead in the RPM tool
> (checks, scriptlets).
>
> {| class="wikitable"
> |-
> ! Compression !! Level!! Size B !! Size GiB
> !! Compression time !! Compression time, 4 threads !!
> Decompression time !! Comment
> |-
> | CPIO || -|| 5016785692 || 4,7
> || -|| -|| -
> ||
> |-
> | xz|| 2|| 1615017616 || 1,6
> || 9m55s|| -|| 1m36s
> || slow decompression
> |-
> | pxz || 2|| 1631869880 || 1,6
> || -|| 6m11s|| 1m38s
> || slow decompression
> |-
> | gzip || 9|| 2086354992 || 2,0
> || 10m23s || -|| 31s
> || insufficient compression ratio
> |-
> | bzip2 || 9|| 1889161565 || 1,8
> || 8m || -|| 2m50s
> || very slow decompression; compression ratio could be
> better
> |-
> | zstd || 3|| 1913536587 || 1,8
> || 31s || 29s || 6,5s
> ||
> |-
> | zstd || 10 || 1737928978 || 1,7
> || 3m27s|| 2m34s|| 6,3s
> ||
> |-
> | zstd || 15 || 1717303256 || 1,7
> || 9m37s|| 6m34s|| 6,3s
> || identical compression speed to xz; fast decompression;
> slightly worse compression ratio than xz
> |-
> | zstd || 17 || 1635525492 || 1,6
> || 16m16s || 11m20s || 6,7s
> ||
> |-
> | zstd || 19 || 1575843696 || 1,5
> || 24m2s|| 18m55s || 7,7s
> ||
> |-
> |}
>
> == Benefit to Fedora ==
> * Faster installations/upgrades of user systems
> * Faster koji builds (installations in build roots)
> * Faster container builds
> * Lower bandwidth on mirrors if we choose the highest compression level
>
> == Scope ==
> * Proposal owners: submit a patch to redhat-rpm-config
> * Other developers: redhat-rpm-config maintainer: include the patch
> and make a new build
> * Release engineering: [https://pagure.io/releng/issue/8345 #8345]
> mass rebuild is needed
>
> == Upgrade/compatibility impact ==
> * RPM in Fedora supports zstd compression already (from Fedora 28,
> rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
> * Fedora <= 27 and some other distros will not be able to decompress
> zstd-compressed RPMs.
>
> == How To Test ==
> * dnf install
> * rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n"
> * expected output: zstd 19
>
> Also the overall system installation time should decrease significantly.
>
> == User Experience ==
> See '''Benefit to Fedora'''
>
> == Dependencies ==
> N/A
>
> == Contingency Plan ==
> * Contingency mechanism: Not needed, Fedora will stay at current
> compression.
> * Contingency deadline: N/A
> * Blocks release? No
> * Blocks product? N/A
>
> == Documentation ==
> N/A
>
> == Release Notes ==
> RPMs have
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Mon, May 20, 2019 at 7:45 PM Lars Kurth wrote: > @Adam and Fedora Testing & QA: > any views on my proposal? > Regards > Lars > Hi Lars, thanks for your reply. Adam was on a long vacation and he's probably the most qualified person to reply to you, sorry for not telling you sooner. Adam is now back, so he should hopefully join the conversation shortly. Cheers, Kamil ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Criteria / validation proposal: drop Xen
On Mon, May 20, 2019 at 7:45 PM Lars Kurth wrote: > @Adam and Fedora Testing & QA: > any views on my proposal? > Regards > Lars > Hi Lars, thanks for your reply. Adam was on a long vacation and he's probably the most qualified person to reply to you, sorry for not telling you sooner. Adam is now back, so he should hopefully join the conversation shortly. Cheers, Kamil ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Media writer
On Tue, May 14, 2019 at 12:56 PM pmkel...@frontier.com < pmkel...@frontier.com> wrote: > Lukas, > > When a system is installed to hard disk from Workstation Live, Media > Writer is not part of that install. The thinking is that people use > Media Writer as the main way they create install media; so it would be > handy to have it installed with the Anaconda install of Workstation. > Rather than installing Media Writer later on. > If somebody has already booted a Fedora install medium (either live or netinst), they already know how to create it, and they already either used FMW or didn't need it (dd etc). Why would we need to add FMW to the default installation then? They can install any time they need it. It would just consume more space and add some QA work (although not much because we already test it). What's the point? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: vsync in VM?
On Thu, May 2, 2019 at 6:19 PM Adam Jackson wrote: > On Thu, 2019-05-02 at 17:05 +0200, Kamil Paral wrote: > > Hello, > > > > I wonder whether it's expected that vsync doesn't work in VMs. I've > > tested Fedora 28/29/30 Workstation and Fedora 30 KDE guests on Fedora > > 30 host, with virtio GPU (3D acceleration on and off) or QXL GPU, and > > in all cases, I'm seeing hundreds or thousands of FPS in glxgears, > > implying that vsync is not working. > > > > Is that an expected state? Is there a simple way to force vsync on > > inside a VM? (using virt-manager + libvirt) > > Short answer: yes it's expected, no there's no way to do that, probably > there should be. > > Long answer: > > The concept of "vsync" in a virtual machine is a bit fuzzy. What > monitor's timings do you think you're syncing to? What do you do when > there's more than one host process watching the framebuffer (think both > gtk and vnc views on the same device)? But, assuming you manage to > answer those questions... > > At least in qemu's implementation neither qxl nor bochs has any > "hardware" concept of a vertical retrace interrupt. And for both of > those you'll end up with llvmpipe for the 3D driver, which doesn't have > any concept of vsync either. The latter we could maybe fix in a few > ways, but I wouldn't expect the former to ever change. > > virtio looks like it has _some_ internal notion of interrupts, but if > that's supposed to be implementing vsync it's not obvious to me how > it's accomplishing that. vmwgfx I suspect does have synthetic vsync > events, but I think you'd need to be using an actual vmware vm to make > that happen and not qemu. > Thanks, Adam, for a detailed answer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
vsync in VM?
Hello, I wonder whether it's expected that vsync doesn't work in VMs. I've tested Fedora 28/29/30 Workstation and Fedora 30 KDE guests on Fedora 30 host, with virtio GPU (3D acceleration on and off) or QXL GPU, and in all cases, I'm seeing hundreds or thousands of FPS in glxgears, implying that vsync is not working. Is that an expected state? Is there a simple way to force vsync on inside a VM? (using virt-manager + libvirt) Thanks a lot. Kamil ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FF v dnf needs-restarting
On Wed, Apr 24, 2019 at 9:20 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Last time I used tracer, it had several issues. It was breaking > dist-upgrades and hogged the CPU for tens of seconds after the dnf > transaction was done. needs-restarting can be run after multiple > dnf updates. > > Is it better nowadays? > Tracer seems pretty fast now. It also seems pretty reliable (compared to needs-restarting, which sometimes shows bogus processes, and sometimes doesn't show processes which tracer identified correctly). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: FF v dnf needs-restarting
On Tue, Apr 16, 2019 at 4:56 PM Bojan Smojver wrote: > I'm guessing most of you here probably observed this behaviour with dnf > when FF is upgraded. Even after FF restarted, dnf needs-restarting reports > that it needs restarting. Does that sound like a bug or is this somehow > intentional? > > I'm seeing this in f29 and previous releases are the same. Once I upgrade > to f30, I'm planning to open a bug on this if it's still the same, unless > someone tells me this is how it's supposed to work. > I see the same behavior (F29). However, "sudo tracer -ea" doesn't complain about Firefox. The question is which tool is correct. My current guess is tracer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Basic graphics mode / 'nomodeset' testing request, round 2
On Wed, Apr 10, 2019 at 3:21 PM Kamil Paral wrote: > Then I tried with Thinkpad T450s. I had to boot in UEFI with CSM on, > because CSM off or even SecureBoot on make the image unbootable (I'll > report a separate bug about that). > https://bugzilla.redhat.com/show_bug.cgi?id=1698550 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Basic graphics mode / 'nomodeset' testing request, round 2
On Wed, Apr 10, 2019 at 3:21 PM Kamil Paral wrote: > Then I tried with Thinkpad T450s. I had to boot in UEFI with CSM on, > because CSM off or even SecureBoot on make the image unbootable (I'll > report a separate bug about that). > https://bugzilla.redhat.com/show_bug.cgi?id=1698550 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Basic graphics mode / 'nomodeset' testing request, round 2
On Tue, Apr 9, 2019 at 3:03 AM Adam Williamson wrote: > Hi folks! > > A few weeks back we asked for testing of 'basic graphics mode' / > nomodeset booting - the feedback from that was very helpful in > establishing that we had a generic issue which dated back to Fedora 29, > thanks a lot. We have now established more or less what that initial > issue is, and work is ongoing to get it fixed entirely. However, it's > already been fixed *partially*, and that revealed a subsequent bug. > > The initial bug is fixed for the case of UEFI native boots (it is not > fixed for BIOS native boots yet). However, in testing, I and others > found that several UEFI test systems still do not boot successfully to > GDM, because they run into a *different* bug later: > > https://bugzilla.redhat.com/show_bug.cgi?id=1693409 > > This bug can be identified by the presence of the following string in > the journal: > > "(EE) Cannot run in framebuffer mode. Please specify busIDsfor > all framebuffer devices" > > (yes, with a bunch of spaces - but just the first part of the line is > sufficient to identify the problem, I think). > > It would be great if folks with UEFI-capable systems could try booting > a recent Fedora 30 Workstation live image on them, e.g. this one: > > > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso > > ensure you boot in UEFI mode. Please report back whether it works. If > it doesn't work, please check the logs - you should be able to log into > a console on tty3 (ctrl-alt-f3 to get there) as root with no password, > then run 'journalctl -b' to see the logs - and report if that line is > present or not. If it isn't, it'd be useful to know if some other error > message is present. > Using the linked 20190408 image, I'm seeing this on my desktop PC with Radeon 580 (booted with UEFI + basic graphics mode): Apr 10 11:39:19 localhost gnome-shell[1730]: Failed to create backend: No > GPUs found with udev > Apr 10 11:39:19 localhost gnome-session[1631]: gnome-session-binary[1631]: > WARNING: App 'org.gnome.Shell.desktop' exited with code 1 > Apr 10 11:39:19 localhost gnome-session-binary[1631]: WARNING: App > 'org.gnome.Shell.desktop' exited with code 1 > Apr 10 11:39:19 localhost gnome-session-binary[1631]: Unrecoverable > failure in required component org.gnome.Shell.desktop > The card is: > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] > (rev e7) > So the error message is different, but the outcome is the same - a black screen with a flashing cursor instead of GDM. Enabling integrated Intel graphics in BIOS doesn't help (but I can't disable the AMD card in BIOS, I'd have to pull it out physically, so both cards are visible to the system). Then I tried with Thinkpad T450s. I had to boot in UEFI with CSM on, because CSM off or even SecureBoot on make the image unbootable (I'll report a separate bug about that). With UEFI+CSM, I see exactly the same error as before: Apr 10 15:01:04 localhost gnome-shell[1773]: Failed to create backend: No > GPUs found with udev > The card is: > 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics > 5500 [8086:1616] (rev 09) > Finally I tried with Thinkpad T480s (here CSM=off and even SecureBoot=on works fine). I see again the same error: Apr 10 15:07:47 localhost gnome-shell[1806]: Failed to create backend: No > GPUs found with udev > And I finally see even the error you mentioned (I have no idea why I haven't seen it on other machines): Apr 10 15:07:48 localhost /usr/libexec/gdm-x-session[1897]: (EE) Cannot run > in framebuffer mode. Please specify busIDsfor all framebuffer > devices > The card is: > 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics > 620 [8086:5917] (rev 07) > So, for me, not a single machine where fallback graphics would work with UEFI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Basic graphics mode / 'nomodeset' testing request, round 2
On Tue, Apr 9, 2019 at 3:03 AM Adam Williamson wrote: > Hi folks! > > A few weeks back we asked for testing of 'basic graphics mode' / > nomodeset booting - the feedback from that was very helpful in > establishing that we had a generic issue which dated back to Fedora 29, > thanks a lot. We have now established more or less what that initial > issue is, and work is ongoing to get it fixed entirely. However, it's > already been fixed *partially*, and that revealed a subsequent bug. > > The initial bug is fixed for the case of UEFI native boots (it is not > fixed for BIOS native boots yet). However, in testing, I and others > found that several UEFI test systems still do not boot successfully to > GDM, because they run into a *different* bug later: > > https://bugzilla.redhat.com/show_bug.cgi?id=1693409 > > This bug can be identified by the presence of the following string in > the journal: > > "(EE) Cannot run in framebuffer mode. Please specify busIDsfor > all framebuffer devices" > > (yes, with a bunch of spaces - but just the first part of the line is > sufficient to identify the problem, I think). > > It would be great if folks with UEFI-capable systems could try booting > a recent Fedora 30 Workstation live image on them, e.g. this one: > > > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190408.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso > > ensure you boot in UEFI mode. Please report back whether it works. If > it doesn't work, please check the logs - you should be able to log into > a console on tty3 (ctrl-alt-f3 to get there) as root with no password, > then run 'journalctl -b' to see the logs - and report if that line is > present or not. If it isn't, it'd be useful to know if some other error > message is present. > Using the linked 20190408 image, I'm seeing this on my desktop PC with Radeon 580 (booted with UEFI + basic graphics mode): Apr 10 11:39:19 localhost gnome-shell[1730]: Failed to create backend: No > GPUs found with udev > Apr 10 11:39:19 localhost gnome-session[1631]: gnome-session-binary[1631]: > WARNING: App 'org.gnome.Shell.desktop' exited with code 1 > Apr 10 11:39:19 localhost gnome-session-binary[1631]: WARNING: App > 'org.gnome.Shell.desktop' exited with code 1 > Apr 10 11:39:19 localhost gnome-session-binary[1631]: Unrecoverable > failure in required component org.gnome.Shell.desktop > The card is: > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] > (rev e7) > So the error message is different, but the outcome is the same - a black screen with a flashing cursor instead of GDM. Enabling integrated Intel graphics in BIOS doesn't help (but I can't disable the AMD card in BIOS, I'd have to pull it out physically, so both cards are visible to the system). Then I tried with Thinkpad T450s. I had to boot in UEFI with CSM on, because CSM off or even SecureBoot on make the image unbootable (I'll report a separate bug about that). With UEFI+CSM, I see exactly the same error as before: Apr 10 15:01:04 localhost gnome-shell[1773]: Failed to create backend: No > GPUs found with udev > The card is: > 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics > 5500 [8086:1616] (rev 09) > Finally I tried with Thinkpad T480s (here CSM=off and even SecureBoot=on works fine). I see again the same error: Apr 10 15:07:47 localhost gnome-shell[1806]: Failed to create backend: No > GPUs found with udev > And I finally see even the error you mentioned (I have no idea why I haven't seen it on other machines): Apr 10 15:07:48 localhost /usr/libexec/gdm-x-session[1897]: (EE) Cannot run > in framebuffer mode. Please specify busIDsfor all framebuffer > devices > The card is: > 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics > 620 [8086:5917] (rev 07) > So, for me, not a single machine where fallback graphics would work with UEFI. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Introduction for gaming packaging/maintaining
On Mon, Apr 8, 2019 at 7:34 PM Karsten Andreas Artz wrote: > Hi guys, > > my name is Andi, 29 and I'm from Germany. I'm using Fedora almost 2 years > (Fedora 26). My programming skills are on Python, Java/Java Script, and > C/C++. But acutally I prefer mostly Python hacking. I studied B.A. of Arts > History, Archaeology and Cath.Theology. Besides this, I can speak a lot of > languages: German, English, French, a bit Italian and Spanish. > > It would be glad starting contributing on Fedora as a maintainer. > Therefore I hope to work on a small project soon. > I'm interested in games packaging, but I don't know where to start. > Hi Andi, only opensource software can be part of Fedora, and there are not that many opensource games out there (which are not already packaged for Fedora), so it might be a bit difficult to find something suitable and interesting (but some of the OS clones might be a good idea). Additionally regarding games packaging, you can consider making flatpaks instead of RPMs and submitting them to Flathub [1]. Flathub can not only contain opensource games, but also freeware and free-to-play games (let's talk about Linux-native games at the moment, incorporating Wine into them would be another level of difficulty). For example, I'd personally love to see The Dark Mod [2] available at Flathub. In Fedora you can also participate on packaging and maintaining game-related software, like emulators and launchers. Wine, Lutris and PLayOnLinux are the most visible ones, but then there are also lots of retro emulators, many of them not even in Fedora yet, I'd guess. So it depends on your experience and interests (both gaming and packaging). You could even participate in e.g. Lutris community in creating and maintaining scripts to allow easy installation of Windows and other platforms' games on Linux. The Gaming SIG [3] might provide a better advice, this is just what I know. [1] https://flathub.org [2] http://www.thedarkmod.com [3] https://fedoraproject.org/wiki/SIGs/Games ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 8:21 PM Lennart Poettering wrote: > Hmm, but the installed OS is not 100% the same as the livesys, or is > it? If not, it should be possible to add a "systemctl disable > dmraid.service --root=/path/to/os" somewhere, no? > AFAIK, they are 100% same. There's a hack, check your /etc/rc.d/init.d/livesys /etc/rc.d/init.d/livesys-late They are executed every time during boot, but immediately quit if they detect they're not running on a Live image (using kernel command line). You can see them also here: https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_73 https://pagure.io/fedora-kickstarts/blob/f30/f/fedora-live-base.ks#_232 They are ugly, I think, and many improvements could be made there. But some Live image adjustments are possible through them. But those are just runtime changes for Live environment, they don't affect the installed system. If anaconda had a post-install phase where it would make appropriate changes to the installed system (and also ideally removed itself and those livesys scripts), that would be great, yes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy wrote: > > 1. multipathd. > > I'm pretty sure it gets dragged in by the installer Nope, multipath seems to be present because libblockdev and udisks (and perhaps some more), which is in turn required by GNOME: $ rpm -q --whatrequires device-mapper-multipath libblockdev-fs-2.21-2.fc30.x86_64 libblockdev-part-2.21-2.fc30.x86_64 libblockdev-mpath-2.21-2.fc30.x86_64 fcoe-utils-1.0.32-6.fc29.x86_64 $ rpm -q --whatrequires libblockdev-fs udisks2-2.8.2-1.fc30.x86_64 $ rpm -q --whatrequires udisks2 gvfs-1.40.0-1.fc30.x86_64 gnome-disk-utility-3.32.0-1.fc30.x86_64 That was latest F30 Workstation Live. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: "Basic graphics mode" feature and criterion discussion
On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson
wrote:
> "The boot menu for all release-blocking installer and live images
> should include an entry which causes both installation and the
> installed system to use a generic, highly compatible video driver (such
> as 'vesa')."
>
Maybe change "causes" to "attempts", so that it's clear it has to do
something (e.g. add a kernel cmdline option), but the thing doesn't have to
succeed ("causes" sounds to me like a successful attempt). But perhaps
that's just me not being a native speaker, though.
>
> i.e. remove the second sentence (and change 'supported' to 'release-
> blocking' - that is a better form of words that should have been used
> all along).
>
> At Final we would add this requirement:
>
> "The generic video driver option ('basic graphics mode') on all
> release-blocking installer and live images must function as intended
> (launching the installer or desktop and attempting to use a generic
> driver), and there must be no bugs that clearly prevent the installer
> or desktop from being reached in this configuration on all systems or
> on wide classes of hardware."
>
Here I'd probably remove "attempting" in favor of a stricter "using a
generic driver". But even your version sounds ok.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: "Basic graphics mode" feature and criterion discussion
On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson
wrote:
> "The boot menu for all release-blocking installer and live images
> should include an entry which causes both installation and the
> installed system to use a generic, highly compatible video driver (such
> as 'vesa')."
>
Maybe change "causes" to "attempts", so that it's clear it has to do
something (e.g. add a kernel cmdline option), but the thing doesn't have to
succeed ("causes" sounds to me like a successful attempt). But perhaps
that's just me not being a native speaker, though.
>
> i.e. remove the second sentence (and change 'supported' to 'release-
> blocking' - that is a better form of words that should have been used
> all along).
>
> At Final we would add this requirement:
>
> "The generic video driver option ('basic graphics mode') on all
> release-blocking installer and live images must function as intended
> (launching the installer or desktop and attempting to use a generic
> driver), and there must be no bugs that clearly prevent the installer
> or desktop from being reached in this configuration on all systems or
> on wide classes of hardware."
>
Here I'd probably remove "attempting" in favor of a stricter "using a
generic driver". But even your version sounds ok.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
FYI: Workstation netinst+tree removed in F31
Workstation netinst and package tree will be removed from F31 onward: https://pagure.io/fedora-workstation/issue/45 https://pagure.io/releng/issue/7403 It seems regular netinst will be used to install Workstation over the network. We'll need to adjust our test matrices/test cases and automated tests. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: "Basic graphics mode" feature and criterion discussion
On Tue, Mar 26, 2019 at 9:31 PM Chris Murphy wrote: > My two cents: > > If there's a fallback option, and if the user selects it, they > shouldn't end up in an unambiguous state. Right now we're seeing > systems hanging. I'd rather see a crash than a hang where the user > can't get to a shell, and sees no useful information on the screen > that tells them why they're hung up; or even generically that "by now > you should see a login screen and if you don't we've faceplanted > somewhere, sorry". > > Maybe split the criterion: > > Basic criterion: installation media must have a basic video boot entry > that uses the accepted fallback boot parameter(s), e.g. nomodeset. The > criterion just means the media must have the menu entry, and that it > passes something intentional for this purpose as a boot parameter. > Sounds good. > > Final criterion: installation media's basic video boot entry should > either work (we get a successful graphical boot), or it should > faceplant in some unambiguous way. > I'd rather require it to just work. Based on Ajax's response that the code path is here to stay and they still need to support it because of VMs and fresh new graphics cards. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: "Basic graphics mode" feature and criterion discussion
On Tue, Mar 26, 2019 at 9:31 PM Chris Murphy wrote: > My two cents: > > If there's a fallback option, and if the user selects it, they > shouldn't end up in an unambiguous state. Right now we're seeing > systems hanging. I'd rather see a crash than a hang where the user > can't get to a shell, and sees no useful information on the screen > that tells them why they're hung up; or even generically that "by now > you should see a login screen and if you don't we've faceplanted > somewhere, sorry". > > Maybe split the criterion: > > Basic criterion: installation media must have a basic video boot entry > that uses the accepted fallback boot parameter(s), e.g. nomodeset. The > criterion just means the media must have the menu entry, and that it > passes something intentional for this purpose as a boot parameter. > Sounds good. > > Final criterion: installation media's basic video boot entry should > either work (we get a successful graphical boot), or it should > faceplant in some unambiguous way. > I'd rather require it to just work. Based on Ajax's response that the code path is here to stay and they still need to support it because of VMs and fresh new graphics cards. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Tip for upgrade testers: disable hide boot menu, enable debug shell
On Fri, Mar 8, 2019 at 8:46 PM Chris Murphy wrote: > There's a new feature in Fedora 29, hide the grub menu, that can make > it difficult to troubleshoot system upgrades if you run into a > problem. Here's what you can do to get more information for a one time > boot without obliterating the default behavior you'll maybe want for > future testing: > > - enable a one time show boot menu for 60 second > $ sudo grub2-editenv - set menu_show_once=1 > > - Now do `dnf system-upgrade reboot` > Or you can simply mash F8 on reboot to show the grub menu, right? Seems easier than remembering the grub command. > > - At the grub menu insert the following boot parameter > systemd.debug-shell=1 > > That enables early debug shell, soon after systemd is running. The > shell is on tty9, and it gives root access without credentials > required! Super powerful, and super duper security risk. So I advise > adding it only at the grub menu, for one time use. > That's useful. Thanks for a tip. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Modularity test cases for a review
On Fri, Mar 8, 2019 at 3:21 PM Lukas Ruzicka wrote: > Hello, > > I have updated the modularity test cases according to what we discussed in > a meeting with @Stephen Gallagher , @Petr Sabata > , @Adam Samalik , @Mohan Boddu > . Currently, we have the following test cases defined > to cover modular use cases in Fedora (see below). > Can you please take a look and provide some additions or comments if > needed. If there are no comments, I will assume that we have the issue > covered and will work from there. > Thanks, > Lukas > >- Find out about modules - >https://fedoraproject.org/wiki/User:Lruzicka/Testcase_module_information >- Install a module - >https://fedoraproject.org/wiki/QA:Testcase_Modularity_install_module >- Switch a module stream - >https://fedoraproject.org/wiki/User:Lruzicka/Testcase_switch_stream >- Remove a module - >https://fedoraproject.org/wiki/User:Lruzicka/Testcase_remove_module >- Enable and disable a module"- >https://fedoraproject.org/wiki/QA:Testcase_Modularity_enable-disable_module >- Update or upgrade a modular system - >https://fedoraproject.org/wiki/User:Lruzicka/Testcase_modular_update > > I haven't reviewed the actual content of the test cases, but one thing that struck my mind when skimming through is that you're requiring people to use *gnome-terminal* specifically. Just say "terminal" and it's clear that you mean any terminal emulator or a virtual console. Or even drop the whole sentence and just say "run command foo". ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Mon, Feb 18, 2019 at 7:34 PM Matthew Miller wrote: > On Mon, Feb 18, 2019 at 05:48:15PM +0100, Lukas Ruzicka wrote: > > > servers also need security and bug fixes. > > If so and local repository is always needed ... why keep a server spin > > then? Why not install from Everything netinst? > > Lots of people use Fedora in a server context. If we don't have a > server-focused deliverable, it's really easy for overall project decisions > to lean too far towards desktop use cases and not provide a balanced venue. > (See historical discussions on value of LVM in Fedora, for example.) > Lukas' question can be rephrased, though, to "why keep Server DVD at all, and not just Server netinst"? I personally see the difference in the fact that Server DVD, even when pruned down, still provides a functional system to install completely offline. That doesn't mean you want to run it offline for a long term, but at least for experimenting or familiarizing, you can. It's also great for creating kickstarts and similar, because you can re-run it constantly and fine tune it with each iteration, without getting slowed down by the network. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Fri, Feb 15, 2019 at 4:50 PM Stephen Gallagher wrote: > For a long time, the Fedora Server Edition has provided a fairly > lightweight default installation, but a fairly heavyweight DVD. This > is because we opted to include a lot of infrastructure-related content > on the disk, such as BIND, FreeIPA, MariaDB and PostgreSQL, among > others. > > The reality these days is that this is probably more or less > unnecessary. There's no such thing as a server that is not connected > to a network and since we aren't shipping the entirety of the Fedora > package collection on this disk, inevitably anyone installing from it > is going to need to have access to package mirrors anyway. > > So I'd like to propose that we get rid of nearly the entirety of the > section from comps.xml[1][2] and variants-fedora.xml[3]. > The result will be a far smaller install DVD, less space wasted on the > mirrors (both for the DVD and the install tree) and very little > difference in user experience. > > Arguments against this have historically been that having it all on > one disk is better for network-constrained environments to avoid > downloading content multiple times. Realistically, however, I think > this is generally going to be solved by local mirroring in most > real-world scenarios. > Makes sense to me. > > > [1] https://pagure.io/fedora-comps/blob/master/f/comps-f30.xml.in To be exact, you mean adjusting just "server-product-environment" section, right? https://pagure.io/fedora-comps/blob/611004df1857f118f1d25ab1218124dd6144994d/f/comps-f30.xml.in#_6262 > > [2] With the exception of the "server-hardware-support" and > "guest-agents" which may be needed for proper installation, depending > on the hardware. > [3] https://pagure.io/pungi-fedora/blob/master/f/variants-fedora.xml > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Is Bodhi's fedmsg integration in the UI useful?
On Wed, Jan 9, 2019 at 7:01 PM Randy Barlow wrote: > Greetings again! > > In my quest to kill Bodhi features so I can have a smaller codebase to > maintain, I am considering getting rid of the fedmsg integration in the > web interface: > > https://github.com/fedora-infra/bodhi/issues/2913 > > I don't know of a way that integration is useful, but I wanted to see > if others thought it was useful. So, do you find it useful? > Not useful. Notifications for my own actions (comment added, etc) are of course useful (also show up as notifications, not sure if this shares code or just appearance). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Tue, Nov 27, 2018 at 4:39 PM Owen Taylor wrote: > And if we did do updates like that, would we consider respinning media > and making a "F30.1"? > What's the difference between re-spinning install media and doing a proper F31 release? At least from QA point of view, I see very little difference. We would need RCs, we would need a freeze, blocker bug meetings, the whole process. And of course some of our tooling might not account for a special F30.1 release-but-not-really, so it might end up more work than a standard release. I can't speak for releng, but I'd expect a similar story. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: the purpose of "workstation core applications" testcase
On Tue, Nov 27, 2018 at 5:12 PM Adam Williamson wrote: > On Tue, 2018-11-27 at 12:48 +0100, Kamil Paral wrote: > > Hi Adam, > > > > I and Lukas are in the process of drafting an email to Desktop SIGs > > regarding basic functionality criteria for all apps available on blocking > > desktops (as discussed recently in the QA meeting), and I need to clarify > > the purpose of the "workstation core applications" testcase [1]. You > > created it, I hope you have the best insight here :) > > > > What confuses me: > > 1. I'm not clear on the purpose of this test case. The initial comment in > > history says "create test case to check Workstation core application > > availability", so it seems just about the apps being present. But the > > Expected results also talk about successful launch. > > If this is solely about availability, I'd rather omit the "successful > > launch" note, because that is already covered by basic functionality test > > case, let's not mix them up. > > 2. The test case is marked with Beta milestone, but I can't find any > > release criterion that would refer to Workstation Core apps, not even at > > Final, let alone at Beta. I can't even find the Technical Specification > > page [2] linked from anywhere from criteria pages, even transitively. Is > > this test case supposed to be Optional, or are we missing a criterion? > > > > Thanks for clarification. > > > > [1] > https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications > > [2] https://fedoraproject.org/wiki/Workstation/Technical_Specification > > The test case is a direct representation of > > https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications > . We should probably link them to clarify > that. > > The launch requirement is there because, IIRC, Workstation SIG > specified that they wanted these apps to be available and runnable at > Beta time. 'desktop menus' is a Final criterion. > Right, that link is even in the testcase, and I understand the connection. What confuses me is that it's marked as Beta, i.e. a potential Beta blocker, while we have no Beta/Final/any criterion for it. If say Boxes dropped out of the compose (but still was listed on the wiki page), would we block the release? And on what grounds? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
the purpose of "workstation core applications" testcase
Hi Adam, I and Lukas are in the process of drafting an email to Desktop SIGs regarding basic functionality criteria for all apps available on blocking desktops (as discussed recently in the QA meeting), and I need to clarify the purpose of the "workstation core applications" testcase [1]. You created it, I hope you have the best insight here :) What confuses me: 1. I'm not clear on the purpose of this test case. The initial comment in history says "create test case to check Workstation core application availability", so it seems just about the apps being present. But the Expected results also talk about successful launch. If this is solely about availability, I'd rather omit the "successful launch" note, because that is already covered by basic functionality test case, let's not mix them up. 2. The test case is marked with Beta milestone, but I can't find any release criterion that would refer to Workstation Core apps, not even at Final, let alone at Beta. I can't even find the Technical Specification page [2] linked from anywhere from criteria pages, even transitively. Is this test case supposed to be Optional, or are we missing a criterion? Thanks for clarification. [1] https://fedoraproject.org/wiki/QA:Testcase_workstation_core_applications [2] https://fedoraproject.org/wiki/Workstation/Technical_Specification ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: repos used by anaconda during Branched
On Mon, Nov 26, 2018 at 6:20 PM Adam Williamson wrote: > On Mon, 2018-11-26 at 15:41 +0100, Kamil Paral wrote: > > > > > > * Into Additional Repositories section, add updates-testing repo > item, > > > > disabled by default, and only visible in pre-release composes. > Mkolman > > > from > > > > anaconda said they definitely don't want to offer updates-testing in > > > public > > > > releases, because some people then use it without understanding what > it > > > is, > > > > and they get all the bug reports then. And I can understand that. But > > > > perhaps they could be convinced to show it up just for us, during > > > > pre-release. That would make enabling updates-testing simple, and it > > > would > > > > also make the checkbox behavior clear (that it's related to stable > > > updates > > > > only). > > > > > > I'm not really a huge fan of this one, it seems like it'd be a moderate > > > amount of implementation work for a fairly small gain. > > > > > > > It depends whether there are some use cases for performing an > installation > > with updates-testing enabled. For example testing a fixed package that > > previous broke installation/system boot? If we disable updates-testing > for > > installation by default, there's no *easy* way to re-enable it, outside > of > > a kickstart or spending a lot of effort by defining an additional repo in > > the GUI. > > My opinion here is just that "use a kickstart, inst.repo , or add a > repo in the GUI" are not that hard and sufficient to the purpose. I > wouldn't agree that it's "a lot of effort" to add the repo in the GUI, > tbh. Step 1) copy the URL from the /etc/yum.repos.d/ file. Step > 2)...there is no step 2... > As long as the clipboard integration is working, which sadly is often broken (at least in my experience). Then it means retyping a very long URL manually each time you want to perform an installation. The same problem applies to inst.addrepo (you can't use inst.repo for additional repos, but today I learned about inst.addrepo), you have to type it manually each time or execute it from a pxe-like environment. Kickstart is fine, but it's non-trivial to write it and understand all the commands and it depends whether you need to test a "default install process" or not. So I still think this is quite a lot of effort (assuming some package is broken for several days and you need to perform a larger number of installations using updates-testing). But if the clipboard integration is working, it's ok. I don't know how often it works and how often it doesn't, I tend get unlucky more often than I'd like :) PS: I think there are also some traps about naming your additional repos. If you name it "updates-testing", as many people probably might, it can easily get ignored, because it clashes with an already defined name in the system. I haven't tested it lately, but I remember there have been some issues like this in the past. I'm not completely married to the idea of showing an extra repo item in the list just in pre-release versions (more on that later), I just considered it low enough risk and a reasonable gain. We can definitely do without it, though. > > > > > > Can you imagine anything else, or would modify some of that above? > > > > > > An option that's easy but I also don't really like a lot would be to > > > just hide the checkbox for pre-releases (assuming we went with b)), > > > i.e. don't display it if isFinal is false. > > > > > > I guess another fairly easy option is just to display some additional > > > explanatory text when isFinal is false: a note explaining that the box > > > only enables the stable updates repos, which will probably not make any > > > difference, and that if the tester wants to enable updates-testing they > > > should do it using the additional repos box or whatever. > > > > > > > Why is so important that pre-release testers are 100% aware that stable > > updates repo is empty? People familiar with our processes should know > that > > already, if they don't - what's the harm? The wide audience testing Beta > > release doesn't care either, they get the same package set regardless of > > the checkbox status. > > I don't think it's "so important", but I think it's worth a trivial fix > (adding a text label conditional on isFinal is not a difficult thing to > do). > Here I have a different view of the risk involved. Anything that changes a GUI layout (e.g. showing a message under the checkbox, or omitting the checkbox complet
Re: repos used by anaconda during Branched
On Fri, Nov 23, 2018 at 5:47 PM Adam Williamson wrote: > On Fri, 2018-11-23 at 10:02 +0100, Kamil Paral wrote: > > On Thu, Nov 22, 2018 at 6:22 PM Adam Williamson < > adamw...@fedoraproject.org> > > wrote: > > > > > Here's a bit of background: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=962522 > > > > > > The key point there is that if we implement your b), the checkbox would > > > effectively do nothing in the pre-release phase at all, because there > > > are no 'stable updates' until we freeze the release tree and do the > > > first set of post-release updates. If you checked it, you'd get the > > > latest 'stable' packages (for a netinst) or the packages from your DVD > > > (for a DVD). If you un-checked it, you'd get...the same thing. As > > > things stand now, the checkbox always does *something*, both pre- > > > release and post-release. > > > > > > > Internally, it should do something a bit different. If updates are > enabled, > > the 'updates' repo would be used, even though it is empty. If updates are > > not used, the 'updates' repo would not be touched. So it might be > possible > > to verify from anaconda logs that the checkbox does the right thing, even > > though the outcome is the same (the same package set). It's not ideal, > but > > if we used updates+updates-testing during pre-release, it would still not > > be a guarantee that the checkbox will work correctly post-release, we'd > > still need to check the logs (and hope). > > > > This is further complicated by the new modular repos (updates-modular, > > updates-testing-modular), which we should ideally check to be covered > > properly by the checkbox as well. The best avenue again seems to be > > checking the logs (and if they're not clear, ask anaconda devs to make > them > > clearer). > > Looking at the code, I don't think they are covered, so that'd be > something to file a bug or PR on. :) The code is in > pyanaconda/payload/dnfpayload.py , in setUpdatesEnabled(). > Yes, I know. I plan to file several tickets once we agree what we want. > > > Yes, some UI changes would be nice. But those would be mostly targeted at > > us (QA), because the current UI is mostly confusing during pre-release. > > Sure, other people *do* use pre-releases though :P > > > So > > I figured we can propose some changes once we clarify what default > behavior > > we want to see. > > > > Do you have any specific proposals for UI? > > > > I could imagine this: > > * Rephrase the current updates checkbox from "Don't install latest > updates" > > to "Install latest updates". A negative sentence in a checkbox is a > > designer's no-no, because it makes all conversations and even thinking > > about it difficult. Mkolman from anaconda already said he would be happy > to > > change that. > > Yeah, it sure made writing the explanation weird... > > > * We could always think about adding "Install latest *stable* updates" > word > > into it, to make it clear for us, but I'm not sure if it's not > superfluous > > for the general user. > > I think it is, a bit. I don't think it really helps a lot with the pre- > release case either, as it doesn't address the fundamental weirdness > that the checkbox simply doesn't change the resulting package set at > all in that case. It still suggests that it will do *something* merely > by virtue of, well, being there. > > > * Into Additional Repositories section, add updates-testing repo item, > > disabled by default, and only visible in pre-release composes. Mkolman > from > > anaconda said they definitely don't want to offer updates-testing in > public > > releases, because some people then use it without understanding what it > is, > > and they get all the bug reports then. And I can understand that. But > > perhaps they could be convinced to show it up just for us, during > > pre-release. That would make enabling updates-testing simple, and it > would > > also make the checkbox behavior clear (that it's related to stable > updates > > only). > > I'm not really a huge fan of this one, it seems like it'd be a moderate > amount of implementation work for a fairly small gain. > It depends whether there are some use cases for performing an installation with updates-testing enabled. For example testing a fixed package that previous broke installation/system boot? If we disable updates-testing for installation by default, there's no *easy* way to re-enable it, outside of a kickstart or spen
