promote package updates and any fedora-related work on the Fedora Magazine
If you are pushing an update to a package or application that contains some major updates, consider promoting the release on the Fedora Magazine. I have been trying to post some of these on the magazine in recent months, but it would be awesome to get these written and queued up before the package is released. If you want to draft up a post, simply log into the Magazine using your FAS account [1] and open a ticket in the marketing trac [2] and we can add you as a contributor to the Fedora Magazine, so you can draft up a post. Alternatively, just open a ticket in the queue[2] with a few details of the update or project that you want to promote, and someone will try to get it written up and posted for you. cheers, ryanlerch [1] - http://fedoramagazine.org/logging-into-fedora-magazine-with-fas/ [2] - https://fedorahosted.org/marketing-team/newticket -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Don't show applications in the software center with XPM icons
On 06/03/14 13:51, Tim Lauridsen wrote: Not showing app, because they have bad looking icons, seems like a bad idea to me. what about using some cairo magic to merge the .xpm icon with some other .png frame to make it look better http://stackoverflow.com/questions/10983739/how-to-composite-multiple-png-into-a-single-png-using-gtk-cairo cairo should be able to load XPM, as far as I know Or just show some standard icon base on the app category Tim IMHO, the proposal was less of "let's remove ugly icons" and more "lets hide applications that use icons in this particular format that doesn't support the features of the software application" It is still possible to have ugly icons, they just have to be in PNG, GIF or SVG format. cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: More unhelpful update descriptions
On Mon 01 Jul 2013 05:54:37 PM EDT, Dan Mashal wrote: On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten wrote: Not sure if it makes any sense but maybe could we have something like "freeze tag changes until desc is better". I propose this because testers will not _really_ want to -1 karma, and as a maintainer it might be a bit hard, but with a good reminder like "not pushed to stable until desc is better" I would have made less mistakes yes not being reminded is not an excuse and such proposal would not save time, still I believe it could help more than hurt There is already a perfect example of this. https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19 Dan is it possible for not the maintainer to be able to edit the update text of updates? I'm thinking, say, a member of the documentation team? regards, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 12:58 PM, Matthias Clasen wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. IIRC, in f17, the GRUB screen was not visible. (you could still press f11 to bring it up if you needed it to). Does anyone know why this behaviour changed? - Switch to a simple spinner for the plymouth theme This theme is available in plymouth today: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/boot.png I know when we've proposed this in the past, there was concern about loosing the one place where the Fedora logo is visible in the boot. I'd like to propose a compromise that will keep the Fedora logo _and_ improve the transition to the login screen: How about we use the spinner as in that mockup, but add a reasonably-sized Fedora logo in the top left corner. The current logo also currently behaves as a progress bar (the logo fills up). I know that currently it really doesn't match to any kind of progress, but is the idea here that there will be no progress indicator, just a spinner? Also, is there an intention here to explain to the user (e.g. text or icons) what is happening? In F18, the fedora logo progress bar in plymouth is the same for both bootup and when applying updates. cheers ryanlerch - Replace the small print logo on the login screen with a bigger one The idea here is to replace the small-print Fedora text logo that we currently have in that corner by the same Fedora logo thats used in plymouth, so that it remains unchanged as we transition from plymouth to gdm. What do you think ? Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 01:55 PM, Alec Leamas wrote: On 2013-03-11 18:49, Lennart Poettering wrote: On Mon, 11.03.13 12:58, Matthias Clasen (mcla...@redhat.com) wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key. This is probably relatively easy to do, we'd just need remove a lot of module loading lines from the generated grub.conf. Fine with me, but don't forget to have a hint to this key visible e. g., "Press F1 to..." in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the "main" boot process (and screen) that follows. With regards to a label on the screen instructing the user how to show the hidden preboot menu (GRUB), It is clutter that is not needed. It makes boot up longer, as that screen will need to appear on the screen long enough for the user to read, at which point why not just display the preboot menu? cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 02:21 PM, Tomasz Torcz wrote: On Mon, Mar 11, 2013 at 02:02:11PM -0400, seth vidal wrote: On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas wrote: Fine with me, but don't forget to have a hint to this key visible e. g., "Press F1 to..." in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the "main" boot process (and screen) that follows. I really do like the idea of a line which says: "Press to see what's going on right now" It creates a learning opportunity for new users and a relatively benign way to present this info. “Press ESC for details” is fine. The only problem is that we have to include half of graphical stack to render this text correctly. And in correct locale. Does the bootup screen require any keyboard other input at all other than escape to bring up the details? Would there be harm in allowing *any* keypress to bring up and hide the details, and not having a label? cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 04:56 PM, Lennart Poettering wrote: On Mon, 11.03.13 21:40, Björn Persson (bjorn@rombobjörn.se) wrote: Lennart Poettering wrote: If some text like "Press Esc now to choose which operating system to boot." would be displayed, then the pause would need to be long enough for the user to read and understand the instruction and then reach for the right key – and the terser the text is made the harder it will be to understand. I estimate that at least 15 seconds would be needed. Adding "Press Enter to save a few seconds." would make it even more text to read and understand. Yikes. On a modern system the BIOS POST finishes within 500ms, and kernel+userspace in 2s. And you want us to spend 15s for nothing in the boot loader, for a feature only the fewest people need, and those who need anyway know how to get? No, those 15 seconds were my argument for why it should NOT be done that way. As I already wrote, if the Grub menu is simply displayed, then five seconds is enough. Much better. And if you want to save those five seconds you just need to press Enter. No, 0s are about enough. Press some key while boot up your machine, that's fine. So just to clarify, just have a key (or keys) that need to be *held down* when you turn on your machine, that brings up GRUB? This is a great approach! --ryanlerch (And on EFI systems that do not initialize USB anymore during POST, you have to go through the OS to get into the boot loader anyway...) Lennart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 05:30 PM, Björn Persson wrote: Lennart Poettering wrote: On Mon, 11.03.13 21:20, Björn Persson (bjorn@rombobjörn.se) wrote: Peter Robinson wrote: It use to only be displayed if there was more than one OS configured or if the CTRL was held down. Having to press a particular key means you have to get it at the second or two where grub isn't displayed. The Ctrl option is quite nice as you can do it before the BIOS disappears. But how are users supposed to discover it? By hooking this up to keys people would natrually try, such as shift, space, enter, escape, or whatever windows does for their boot menu stuff. I would probably pound frantically on the keyboard trying to hit the right key during some unknown, short interval. If there were no interval at all and the right solution were to be holding a key at the right moment, then I'd probably have about a 50% chance of not pressing any key at that moment. And after I happened to press the right key at the right moment I still wouldn't know which of the keys I pressed was the right one, so I'd have to pound frantically the next time too. After a few iterations I'd also be cursing the idiots who designed such an unfriendly user interface just because they didn't want any text on the screen. Björn Persson I think the suggestion in this thread is to simply keep a key *pressed down* that way there are no issues with the user having to time a keypress. --ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 02:24 PM, Brian Wheeler wrote: On 03/12/2013 02:03 PM, Chris Murphy wrote: On Mar 12, 2013, at 10:35 AM, Reindl Harald wrote: Am 12.03.2013 17:32, schrieb Chris Murphy: On Mar 12, 2013, at 6:02 AM, Jiří Eischmann wrote: New kernels bring a lot of regressions and we don't have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve. This is completely specious. A user who considers falling back to an older kernel as a troubleshooting step also knows how this selection is made and where to go look for it THIS IS WRONG Oh really? Yes, it is wrong. We're not talking about just new users here. If you're going to hide how to select a different kernel, how am I, an experienced sysadmin supposed to figure it out when things go south? F18 screwed my computer royally with regards to sleep & restore and I had to boot older kernels to get the machine stable. As it stands, there were a list of kernels I chose the upper most one which didn't have problems...under what people are proposing I'd have to google it on some other machine or just mash the keyboard and hope I find something that gives me some options I don't know why people are so enamored by making it difficult to troubleshoot problems. I know it is a simplification, but to me, the two sides of this argument are: * remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on. * keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood. --ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
On Fri 01 Nov 2013 11:31:37 EDT, Bill Nottingham wrote: Richard Hughes (hughsi...@gmail.com) said: On 1 November 2013 14:53, Matthew Miller wrote: Okay, thanks. This is really cool good stuff. Guess it's time to update my other laptop to Rawhide. :) For those less brave, I've uploaded a screenshot here: http://people.freedesktop.org/~hughsient/temp/gnome-software-shell-search.png Also, if you want to try this out on F20, you can use the rawhide gnome-software package if you also update glib2-* from rawhide. If you do this and file bugs, they will be ignored. :) So if it has a session service, and a shell provider integration, does that mean we do overlays/highlighting on applications with updates pending in the shell, right-click->update in the app menu list, and other fun stuff like that? Bill Or even kick off a removal of an application from the overview? --ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri 01 Nov 2013 14:43:37 EDT, Bill Nottingham wrote: Christian Fredrik Kalager Schaller (cscha...@redhat.com) said: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. Something that doesn't seem specified here is any sort of a design style or guide for how apps used in the Workstation should generally be built and function. Is there intended to be that sort of standard? Bill The opening sentence is great, it provides a concise statement of intent: "The Fedora Workstation working group aims to create a reliable, user-friendly and powerful operating system for laptops and PC hardware." All the plans and goals under this should have a clear defined goal of how it contributes back to the main statement of intent. However, should the document also define what some of the terms in that statement actually mean? How do we define "reliable", "user-friendly" and "powerful" (and even "laptops" and "PC hardware") in relation to the Fedora Workstation. --ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. Sincerely, Christian F.K. Schaller P.S. I am celebrating both our wedding anniversary and my wifes birthday this weekend so I will not be able to be online a lot. That said I will make the time to go online to check my email from time to time so that I can respond to any questions that has come in, just don't expect immediate answers from me this weekend :) Although i am not sure if the PRD is the place for it, But should we also think about conducting some user surveys to help define our target audience further? Also, some User testing on what we have already would also be useful for a baseline to check against in the future when we start implementing changes. cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Decommissioning Nuancier
Plans are underway to decommission Nuancier[1]. Nuancier was custom built for the single task of voting for Fedora supplementary wallpapers, and has not been used for this task since Fedora 32. As such, Fedora Infra is moving towards decommissioning this application, and archiving all the data, images, and voting statistics. Also, the source of this application[2] will be archived in GitHub. For ongoing information and discussion on this process please view the fedora-infrastructure ticket [3] [1] - https://apps.fedoraproject.org/nuancier/ [2] - https://github.com/fedora-infra/nuancier [3] - https://pagure.io/fedora-infrastructure/issue/11371 ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Decommissioning Nuancier
On Tue, Jun 20, 2023 at 3:45 PM Benson Muite wrote: > > On 6/20/23 06:44, Ryan Lerch wrote: > > Plans are underway to decommission Nuancier[1]. Nuancier was custom > > built for the single task of voting for Fedora supplementary > > wallpapers, and has not been used for this task since Fedora 32. > > > Had offered to update this. Would it be ok for me to write something > new? Alternatively, Discourse does have some voting plugins. Could > create another plugin if that would be helpful. Note that Discourse is > used by the Krita community to enable discussions on artwork > https://krita-artists.org/ though storage requirements can increase > somewhat. > > To give better vote privacy, one typically has three separate databases, > ideally run completely separately. One database contains eligible voters > does vote verification, and a third contains a tally. A simpler but well > tested system is implemented in: > https://github.com/benadida/helios-server > Maybe this could also be helpful for Fedora elections? > > > As such, Fedora Infra is moving towards decommissioning this > > application, and archiving all the data, images, and voting > > statistics. Also, the source of this application[2] will be archived > > in GitHub. > > > > For ongoing information and discussion on this process please view the > > fedora-infrastructure ticket [3] That may be a discussion for the design team itself -- since supplemental wallpapers haven't really happened for the last few releases (AFAIK due to disinterest in organizing the event). So not sure how useful an entirely new tool will be. Discourse voting could be interesting, but again, will need someone to organize the actually submission and voting. --ryanlerch > > > > > > > > [1] - https://apps.fedoraproject.org/nuancier/ > > [2] - https://github.com/fedora-infra/nuancier > > [3] - https://pagure.io/fedora-infrastructure/issue/11371 > ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
New look for Koji Web
The Koji web front end is now running a new theme that brings it into line with the majority of our other devel focused web applications: https://koji.fedoraproject.org/ If there are any issues with the new theme, feel free to file an issue against it here: https://gitlab.com/fedora/websites-apps/themes/koji-theme-fedora cheers, ryanlerch ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
email / IRC notifications (FMN)
Hi all, I am currently trying to open a UI / UX review of the FMN / Notifications system and just chasing isome raw feedback on how you all get notifications (email / IRC / or otherwise) when developing / packaging / working on Fedora. Please check out the following discussion thread to log your raw feedback: https://discussion.fedoraproject.org/t/notifications-application-aka-fmn-aka-apps-fedoraproject-org-notifications/36914 cheers, ryanerch ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self-Service project creation on Pagure.io is now disabled.
This message announces a permanent change to project creation on pagure.io. The self-service creation of new projects (repositories) is now disabled. This decision is a direct response to the influx of spam projects. The ongoing effort to mitigate this spam has become unsustainable. Key Changes: * Self-Service Project Creation Disabled: The ability to create new projects independently on pagure.io is now permanently disabled. * Forking Functionality Retained: The forking of existing projects remains fully operational. * Managed Project Creation for Fedora Teams: Fedora teams requiring new projects on pagure.io should submit a request via the Fedora Infrastructure ticket tracker. The infrastructure team will manage the creation of these projects. * Forgejo-Based Platform Development: Concurrently, we are developing an alternative platform for Fedora teams, based on Forgejo. Updates concerning the managed project creation process and the Forgejo platform will be provided in the future. -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
