Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Sun, Nov 21, 2010 at 1:54 PM, Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: How do you expect to be able to maintain an entire desktop environment on a distribution you don't even have installed? I have some sympathy for the 'fifty people said it works on F14, it probably works on F12 too' argument, but for a *small, leaf* package, not for an entire desktop environment! If I were a KDE user running F12 I'd feel very unsafe knowing someone was happily pushing updates of the entire environment who did not even have a running F12 machine. I've sometimes actually done testing on older releases out of sheer laziness to upgrade to a newer one (see also me testing that F13 KDE 4.5.3 upgrade), but with all this bullying of Want current software? Upgrade your Fedora!, with previous supported releases getting only second-class upgrade support, that's going to stop soon (in fact, I'll probably upgrade my machines to F14 before the end of the month). (Pretty much everyone else in KDE SIG always runs the latest Fedora. I'm almost the only one left on F13.) So by limiting the kind of support previous releases get, you're actually INCREASING the risk of untested updates, by making it unattractive for your developers to run those releases. So they stay in updates-testing until someone does actually test them. We all know that the longer that updates wait in updates-testing the more likely the world will stop spinning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 7:01 AM, Kevin Kofler kevin.kof...@chello.at wrote: Michal Hlavinka wrote: this could help, but it's not always possible to add these test cases. One example: imap server package - new bug that can corrupt mail folders in some circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but not always it's possible to write down any test case. It's still a bug fix and it's better to be delivered sooner than wait if anyone out there get's his mail folders corrupted. Actual policy does not help proactivity. Right, and the big point there should be that a bug which can corrupt mail folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY testing requirement there is a failure. Install package from updates-testing, then +1 to karma after it works for you with your tests and normal workload. Simple. No need to foist possibly broken software on everyone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Mon, Nov 22, 2010 at 9:04 AM, Till Maas opensou...@till.name wrote: On Mon, Nov 22, 2010 at 09:57:40AM +0100, Henrik Nordström wrote: sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas: I guess this can be somehow automated. E.g. change Bodhi to drop the karma requirements for packages that had e.g. two subsequent updates without any Bodhi feedback and re-enable it if they get feedback. That would be somewhat counter productive for the goal of actually having testers, as it discourages maintainers looking for testers as a way to improve their release process. I do not see how this discourages maintainers. I do not know of any package maintainer that stated that he did not want his updates tested. This would at least encourage people that want better tested updates to commit into testing them. The current problem is not that package maintainers do not want their packages tested, but that updates are delayed without any visible testing. The result is that if you have several updates without any karma points (positive or negative) in bohdi, your updates get out faster. Once someone does start giving it karma (again, positive or negative) your update is not subject to getting more karma points in order to hit the updates repo. Thus you punish the maintainer by giving testing their packages. It may work better if karma enforcement only comes into effect if negative karma is given to an update. This still builds a reactive system instead of a preventative system. An only reactive system will not help prevent bad updates from getting out in the first place. That said, adding a reactive component to a preventative system would be a good thing. If a maintainer releases one package that puts regressions into the stable updates repo, then the minimum karma doubles on all of their packages doubles for 2 months or something like that. So feel free to push directly to stable as often as you want, but once you introduce one regression, you have to satisfy 10 karma on every package you update. The second time, you have to satisfy 20 karma on every package you update and so on. Simply because we can't trust that maintainer anymore. Really, allowing regressions to make it to stable is so costly simply because it has to be fixed several magnitudes more times than if it is caught by people actually testing packages before they're released to the masses. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 20, 2010 at 6:16 PM, Kevin Kofler kevin.kof...@chello.at wrote: But one of the main points of this subthread is that that waiting period is way too long for some urgent fixes (security fixes, regression fixes etc.). If it's really a regression, then you will have interested users who will test from updates-testing and provide karma. Security karma should come from the security team. Also security updates should not have any other changes mixed in. If it makes other changes take longer to get to stable (because the update after the security update needs the security update as well as the other updates that were queued up prior to the security update), well that's just how it is. So you have these package versions: foo-2 foo-2.1 foo-3 foo-2 is vulnerable to the exploit. foo-2.1 is and update that does not contain any changes except what is required to close the vulnerability. foo-3 has changes from foo-2.1 as well as the other updates that were planned. The idea is that you stop everything, make the security update based on the latest stable package, and then submit the update for testing (by the security team?). then you continue with your normal packaging workflow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Tue, Nov 16, 2010 at 11:13 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: * F12 critical path/update testing issues. (does it matter this close to EOL?) Now Fedora n-1 is F13 and we're already seeing the same sort of issues there (e.g. the KDE 4.5.3 (non-critpath) bugfix update has karma 4 on F14 and 0 on F13). Good. Let people actually test it before it goes to everyone. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bastion02.fedoraproject.org listed in sorbs.net DNSBL - can we get some better spam filtering so I don't end up blocking feodora's emails?
Nov 17 17:58:28 mail1 postfix/smtpd[29706]: NOQUEUE: reject: RCPT from bastion02.fedoraproject.org[209.132.181.3]: 450 4.7.1 Service unavailable; Client host [209.132.181.3] blocked using dnsbl.sorbs.net; Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?209.132.181.3; from=users-boun...@lists.fedoraproject.org to=mfe...@mikefedyk.com proto=ESMTP helo=bastion.fedoraproject.org Are the mail admins aware of this? Hopefully some better spam filtering can be implemented so that fedora's mail servers don't end up in spam block lists anymore. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ldd regression in F14B
On Mon, Oct 4, 2010 at 3:01 PM, Alberto Bertogli albert...@blitiri.com.ar wrote: On Mon, Oct 04, 2010 at 12:48:20PM -0700, Roland McGrath wrote: File a glibc bug. Upstream or in Fedora's bugzilla? (or both?) Upstream and link to upstream bug in fedora bug tracker. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
2010/9/14 Jóhann B. Guðmundsson johan...@gmail.com: On 09/15/2010 12:01 AM, Jeff Spaleta wrote: On Tue, Sep 14, 2010 at 3:56 PM, James Laskajla...@redhat.com wrote: Much like we introduced and communicated btrfs support in F-11, should we communicate systemd as a technology preview in Fedora 14? I would agree with this. I certainly plan to run F14 with systemd in anticipation of seeing it become the default at some point. Should gnome-shell and every other feature fall under technology preview and stay like that for sometime as well before becoming the default Yes, and please compile out support for spacial gnome while you're at it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
