Re: RFE: Never, ever steal focus.
On 06/01/10 17:00, Adam Jackson wrote: On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: On 1/6/10 11:07 AM, Adam Jackson wrote: PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of "you were just typing into some other window, this must be a focus steal", then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as "stealing" or not, then great. I'd go with "don't let a different app steal focus". Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. There is one situation where the absolute of $SUBJECT is required: password windows. I end up typing passwords wholly or partially into other windows on a reasonably regular basis because of this. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Top Crashers
On 04/01/10 15:43, Michael Schwendt wrote: On Mon, 04 Jan 2010 15:12:18 +, Matthew wrote: Now we have abrt making it easier for lazy people to submit crash reports, do we have enough information for a 'Top Crashers' list? It would be good to highlight these centrally to provide an incentive to give them the attention they deserve. My specific motivation for this is: https://bugzilla.redhat.com/show_bug.cgi?id=532307 This crashes daily for me and, from the evidence of the BZ traffic, a whole lot of other people too. It has also been ignored for 2 months now. Highlighting and fixing this kind of high-impact bug would be a great way to improve the quality of Fedora. To say it has "been ignored for 2 months" does not sound fair to me. There is a much newer comment, https://bugzilla.redhat.com/532307#c59 which sort of is buried beneath the bugzilla spam. Raises the question: Who is able to reproduce it and continue with the debugging? The purpose of Top Crashers would be to aid in prioritisation. The comment you reference doesn't add anything useful to the discussion and probably took the maintainer seconds to write. This is presumably because he's busy working on new functionality or other bugs. My hope is that highlighting areas of real pain to a large number of users would help divert attention away from what are probably much more interesting pursuits. In general, I'm also interested in learning about packages with a growing number of bugzilla tickets where the package maintainers do not seem to give status updates in bugzilla. I wouldn't get that complicated. Fixing a bug should remove it from Top Crashers over time. If it stays there for a long time, perhaps it could be annotated. If it's not annotated, it should probably be highlighted to FESCo. The purpose would be to highlight actual user pain, rather than user pain with an excuse. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Top Crashers
Now we have abrt making it easier for lazy people to submit crash reports, do we have enough information for a 'Top Crashers' list? It would be good to highlight these centrally to provide an incentive to give them the attention they deserve. My specific motivation for this is: https://bugzilla.redhat.com/show_bug.cgi?id=532307 This crashes daily for me and, from the evidence of the BZ traffic, a whole lot of other people too. It has also been ignored for 2 months now. Highlighting and fixing this kind of high-impact bug would be a great way to improve the quality of Fedora. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 17:40, Jesse Keating wrote: On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote: * It shifts "costs" from "users" to "vendor" and from "mirrors" to "master". * It helps users who are using networked installs to spare bandwidth (avoids downloading obsolete packages from "Everything"/"Fedora"). Admitted, for most users, it would change almost nothing. People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, especially if we went the route of having updates-testing mixed in and only marked by some update tag. We'd have to keep sets of what's in updates-testing, updates, and the GA release set, and all of that would be in one repodata set. Everybody doing a network install, whether they wanted updates, updates-testing, or not would have to download and consume that larger repodata, introducing a higher cost for them. There's an argument for separate updates-testing. However, my original point was that nobody is interested in the original GA release set except historians. People should, and we rightly help them, be installing updates frequently. So, people doing network installs fall into: People who want to install GA only: Hopefully nobody. The only good reason to do this is if the distro is broken. People who want to install GA+updates: Everybody except testers. People who want GA+updates+testing: testers. The GA package could be kept around as a separate, static repo nobody uses under normal circumstances. Combining GA+updates into a single repo would not consume additional bandwidth for anybody at all, and only testers would have to do any additional configuration. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 16:06, Josh Boyer wrote: On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote: On 02/12/09 15:26, Josh Boyer wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. What you describe is effectively how the development repository is built, so it's certainly a technical possibility. It does have implications though. Off the top of my head, I can think of: 1) Composing a new everything tree for updates would lead to larger compose times. That could possibly mean that getting updates out would take> 1 day per 'push'. We've been trying to improve updates push times so it would be a bit detrimental to that goal. I can't comment on this. 2) There might be GPL compliance issues This line of reasoning sounds bizarre to me. You can publish things in multiple places. 3) You would still need an 'updates-testing' repository given that this is a supposedly stable release. So there is still going to be at least one additional repo regardless. Indeed, however that would only be testers. Most people can ignore it. However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? Any tool which deals with repositories requires the repo to be configured twice. Off the top of my head I can think of: 1. yum separate repo and updates-repo in yum.conf. 2. livecd tools two repos in kickstart 3. revisor two repos in kickstart 4. febootstrap two repos on command line Given that you almost always want updates, it would an improvement if all of the above could be replaced with a single configuration. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 16:09, Bill Nottingham wrote: Matthew Booth (mbo...@redhat.com) said: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. The separate Everything tree that does not get obsoleted is required in some form for GPL compliance, with respect to the ISO images that we ship. Any new solution would have to preserve this. This argument sounds weird to me. However, there no reason you can't keep around as many repositories as you like as long as the One True Repository exists and people can use it exclusively. Currently it doesn't exist. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 16:01, Justin M. Forbes wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. The only downside to merging updates into the main repository is that network installs from the repository will no longer install the "release" they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the "release" as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or F11 feature that anaconda allowed the user to specify that updates be installed at installation time? Certainly I used to have Debianites crow at me that my installation was vulnerable until I updated it. Not only that, but I had to download updated packages twice. These days I always install with updates. I find the installation argument dubious at best. Still, we could rename the main repo the 'installation' repo, and nothing but anaconda would ever look at it. Everything else would look at the main repo, which would be the same as the current updates repo except with everything in it from the start. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On 02/12/09 15:26, Josh Boyer wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. More involved would be: 1. Updating all packages which expect 2 repos to only expect 1. 2. Communicating the change effectively. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposed F13 feature: drop separate updates repository
The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
abrt and bugzilla
Firstly, I'd like to say I think abrt is fantastic. Call what follows a nit-pick. It's just a pretty in-your-face nit. After installing F12, after a short while I got presented with a couple of SELinux errors. This is nothing unusual in a new Fedora release, but this time it asked me for my bugzilla login details and offered to submit the bug automatically for me. Fantastic! The lazy person in me who wants to do the right thing truly appreciates this. Turns out I wasn't the first person report them, so it added me to the CC list. There are, however, still 2 significant problems with this. Firstly it needed a BZ login. I happen to have one, and I use it often enough that I don't need a password reset every time. However, I'll bet I'm in the minority of Fedora users[1]. To get useful bug reports from the unwashed masses we need anonymous submission, or at least submission which doesn't require any kind of account creation or authentication. Secondly, I'm now being subjected to bugzilla spam every time anybody else does the right thing. I have received 24 bugzilla spams in the last 12 hours telling me that other people have been added to the CC list. This information is interesting to people who want to know how to prioritise bugs, but it's not interesting to me, the submitter. I can remove myself from the CC list, but the lazy person in me whispers it might just be easier not to submit bugs. If you've used Windows, you'll be familiar with the Windows send bug report dialog. I've once seen it additionally give me useful information. After submission it told me a fix was available and sent me to a web page which told me where to get an updated third-party driver. That's what I really want to know: can I fix it? So, turning that into some feature requests: 1. Can Fedora enable anonymous/unauthenticated bug submission. 2. Can abrt not add duplicate reports to the CC list. 3. Can abrt/Fedora please ensure that original abrt reporters don't get email either. 4. Can abrt/Fedora track abrt submitted BZs and report only when there's a fix available. 5. Can abrt give me a list of submitted BZs so I can browse them if I want to? I suspect much of this would require infrastructure changes, so it would extend beyond abrt. However, I think this is the last mile required to get bug reports from absolutely everybody. Thanks again, Matt [1] As is everybody on this list! I know you all have BZ accounts, and know the passwords. -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Adding a new package to rawhide/F-12
I'd like to add a new package (virt-v2v) to rawhide/F-12. Nothing depends on it. I don't appear to be able to do this, although I can add it to the supposedly stable F-11. This seems like an unlikely state of affairs. Am I missing something? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Is Fedora Hosted ok?
If so, could somebody have a look at https://fedorahosted.org/fedora-infrastructure/ticket/1662 for me? There are also older outstanding hosting requests than mine on there. Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding a project to transifex
On 07/09/09 21:55, Kevin Kofler wrote: Matthew Booth wrote: I went over to https://translate.fedoraproject.org/ earlier with the idea of adding my project. The translations are now hosted at http://transifex.net/ (the main Transifex instance). Was there an official announcement about that? Matt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Adding a project to transifex
On 07/09/09 21:56, Orcan Ogetbil wrote: Despite that, I'd still like to add my project to Transifex! Can anybody point me to the process? Thanks, Matt Go to https://fedoraproject.org/wiki/L10N --> Frequently Asked Questions --> 1.3.8 How do I add a module to Transifex? (#add-transifex) This will tell you what to do step by step. Thanks, I'm fairly sure this is what I'm looking for. If anybody's listening, it would be nice to have this linked from the website! Matt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Adding a project to transifex
I went over to https://translate.fedoraproject.org/ earlier with the idea of adding my project. Firstly, there's no hint of how to do this from the front page. After some Leisure Suit Larry style clicking on stuff at random until something favourable happens, I found a link carefully hidden at the bottom of the browse all projects page. The link says: Couldn't find your project? Go ahead and add it! So, I clicked in 'add it', which gives me: === Forbidden access Looks like you do not have the necessary permissions to the required action. Here's a link to the homepage. You know, just in case. === That's everything, btw. No link to an admin contact, process, mailing list, documentation, or anything. Just a promise of being able to add my project, then a bucket of cold water. Despite that, I'd still like to add my project to Transifex! Can anybody point me to the process? Thanks, Matt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
