On Sun, Nov 28, 2010 at 13:38:36 +0100,
Till Maas wrote:
>
> I wrote to give +1 after using it and your original problem was, that
> you did not notice when something works. So if you updated firefox
> yesterday and used it to browse the world wide web without problems and
> run fedora-easy-kar
On Sun, Nov 28, 2010 at 05:36:58AM -0600, Bruno Wolff III wrote:
> On Mon, Nov 22, 2010 at 18:15:29 +0100,
> Till Maas wrote:
> >
> > You can very easy report that you have installed some update, used it
> > and it did not break. This is afaik enough to justify +1 karma.
>
> I thought you need
On Mon, Nov 22, 2010 at 18:15:29 +0100,
Till Maas wrote:
>
> You can very easy report that you have installed some update, used it
> and it did not break. This is afaik enough to justify +1 karma.
I thought you needed to do a bit more than just install a package to
give a +1. But hopefully thi
On Wed, 2010-11-24 at 13:07 +0100, Ralf Corsepius wrote:
> Also, it's this kind of situations, where Fedora's QA's "delays" have
> shown to be counter-productive.
To be clear, they are not QA's delays. The initial proposal to FESCo was
by mjg, the revised proposal was by notting, and it was FESC
On 11/24/2010 12:22 PM, Toshio Kuratomi wrote:
> On Tue, Nov 23, 2010 at 08:31:15AM +, "Jóhann B. Guðmundsson" wrote:
>> On 11/23/2010 06:51 AM, Ralf Corsepius wrote:
>>> IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs",
>>> it's bugs not getting fixed in Fedora, for a var
On Tue, Nov 23, 2010 at 08:31:15AM +, "Jóhann B. Guðmundsson" wrote:
> On 11/23/2010 06:51 AM, Ralf Corsepius wrote:
> > IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs",
> > it's bugs not getting fixed in Fedora, for a variety of reasons.
> >
> > Therefore, I consider try
On Tue, Nov 23, 2010 at 05:51:06AM +0100, Miloslav Trmač wrote:
> Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800:
> > Also security updates should not have any other changes mixed in.
> In the early days of Fedora, it was explicitly decided that (contra
> Debian) maintainers are not required to ba
On 11/23/2010 06:51 AM, Ralf Corsepius wrote:
> IMO, the real problem is not "backports" vs. "upgrading" to "fix bugs",
> it's bugs not getting fixed in Fedora, for a variety of reasons.
>
> Therefore, I consider trying to apply any such simple "policy" to be
> impossible and naive.
Agreeable logi
On 11/23/2010 05:51 AM, Miloslav Trmač wrote:
> Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800:
>> Also security updates should not have any other changes mixed in.
> In the early days of Fedora, it was explicitly decided that (contra
> Debian) maintainers are not required to backport patches and
Mike Fedyk píše v Po 22. 11. 2010 v 18:03 -0800:
> Also security updates should not have any other changes mixed in.
In the early days of Fedora, it was explicitly decided that (contra
Debian) maintainers are not required to backport patches and that
rebases (fixing a bug by updating to a new upstr
On Sat, Nov 20, 2010 at 6:16 PM, Kevin Kofler 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 up
On Mon, Nov 22, 2010 at 10:43:21AM -0800, Adam Williamson wrote:
> On Mon, 2010-11-22 at 19:29 +0100, Till Maas wrote:
> > On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote:
> >
> > > I do. I don't believe all maintainers do. It's pretty hard to explain
> > > why updates that complet
On Mon, 2010-11-22 at 19:29 +0100, Till Maas wrote:
> On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote:
>
> > I do. I don't believe all maintainers do. It's pretty hard to explain
> > why updates that completely prevent the app in question from working, or
>
> Btw. this is not a pr
On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote:
> I do. I don't believe all maintainers do. It's pretty hard to explain
> why updates that completely prevent the app in question from working, or
Btw. this is not a problem that might happen with updates, but also
happens with init
On 11/20/2010 06:02 PM, Adam Williamson wrote:
> That's not what I'm talking about. There have been multiple instances
> where updates have been pushed that were *completely broken*: they could
> not work at all, in any fashion, for anyone. It doesn't happen a lot,
> but it happens; enough to prov
On Sun, Nov 21, 2010 at 09:59:42PM -0600, Bruno Wolff III wrote:
> On Sun, Nov 21, 2010 at 10:35:31 +0100,
> Till Maas wrote:
> >
> > IMHO it is pretty unlikely that people use updates-testing but do not
> > care about posting feedback to Bodhi.
>
> I usually notice only when something breaks,
On Sun, Nov 21, 2010 at 11:39:14PM +0100, Kevin Kofler wrote:
> Let people use their brains. If they screw up, yell at them, and work on
> informing people in a better way so such mistakes don't happen again.
Everyone makes mistakes. The idea is to provide an opportunity for
people's mistakes t
On Sun, Nov 21, 2010 at 10:35:31 +0100,
Till Maas wrote:
>
> IMHO it is pretty unlikely that people use updates-testing but do not
> care about posting feedback to Bodhi.
I usually notice only when something breaks, not when it keeps working.
--
devel mailing list
devel@lists.fedoraproject.or
David Nalley wrote:
> I think this is an interesting idea, but I'll also say I think it can
> be made simpler. Why not just hold package maintainers accountable
> period. Make them accountable to FESCo (which in theory they are to
> begin with) If I, as a package maintainer continuously want to 'pu
On Sat, Nov 20, 2010 at 5:09 PM, Adam Williamson wrote:
> On Sat, 2010-11-20 at 14:49 -0700, Kevin Fenzi wrote:
>> On Fri, 19 Nov 2010 22:04:24 -0800
>> Adam Williamson wrote:
>>
>> ...snip...
>>
>> > > https://fedorahosted.org/bodhi/ticket/277
>> >
>> > hum, that wasn't well publicised, and I wa
On Sat, Nov 20, 2010 at 02:09:47PM -0800, Adam Williamson wrote:
> On Sat, 2010-11-20 at 14:49 -0700, Kevin Fenzi wrote:
> > On Fri, 19 Nov 2010 22:04:24 -0800
> > Adam Williamson wrote:
> >
> > ...snip...
> >
> > > > https://fedorahosted.org/bodhi/ticket/277
> > >
> > > hum, that wasn't well p
On Sun, 2010-11-21 at 12:42 -0500, David Nalley wrote:
> I am curious to know a few things?
>
> How many updates submitted to bodhi since the policy has been in place?
> How many updates received any feedback?
> How many updates received only neutral or negative feedback?
> How many updates had a
On Fri, Nov 12, 2010 at 11:42:19AM -0800, Adam Williamson wrote:
> it's worth noting that part of the point of the 7-day clause is to cover
> 'invisible testing'; even if people aren't posting feedback to Bodhi,
> it's likely that if the update actually is broken, we will find out one
> way or ano
On Sun, 2010-11-21 at 03:16 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Please remember the exact policy we have. There is still no absolute
> > requirement for testing for anything but critpath packages, which is a
> > fairly small number. All other packages can push updates without
>
Adam Williamson wrote:
> Please remember the exact policy we have. There is still no absolute
> requirement for testing for anything but critpath packages, which is a
> fairly small number. All other packages can push updates without
> testing; there's simply a short waiting period to do so.
But
On Sat, 2010-11-20 at 17:45 -0500, Tom Lane wrote:
> I don't by any means disagree with the idea that testing packages before
> they go out is a good thing. What I have a problem with is the idea
> that an "unfunded mandate" for that to happen is going to accomplish
> much. A policy isn't worth
On Sat, 2010-11-20 at 17:45 -0500, Tom Lane wrote:
> Adam Williamson writes:
> > I do. I don't believe all maintainers do. It's pretty hard to explain
> > why updates that completely prevent the app in question from working, or
> > even prevent the system from booting, got pushed in the past, if a
Adam Williamson writes:
> I do. I don't believe all maintainers do. It's pretty hard to explain
> why updates that completely prevent the app in question from working, or
> even prevent the system from booting, got pushed in the past, if all
> maintainers actually test their updates.
I don't thin
On Sat, 2010-11-20 at 14:49 -0700, Kevin Fenzi wrote:
> On Fri, 19 Nov 2010 22:04:24 -0800
> Adam Williamson wrote:
>
> ...snip...
>
> > > https://fedorahosted.org/bodhi/ticket/277
> >
> > hum, that wasn't well publicised, and I wasn't aware of it. (I should
> > probably show up to more FESCo m
On Fri, 19 Nov 2010 22:04:24 -0800
Adam Williamson wrote:
...snip...
> > https://fedorahosted.org/bodhi/ticket/277
>
> hum, that wasn't well publicised, and I wasn't aware of it. (I should
> probably show up to more FESCo meetings...picture FESCo members going
> 'no, no, really, it's fine!') I'
On Tue, 2010-11-16 at 17:22 -0500, Luke Macken wrote:
> On Fri, Nov 12, 2010 at 11:46:36AM -0800, Adam Williamson wrote:
> > On Fri, 2010-11-12 at 14:32 -0500, Tom Lane wrote:
> >
> > > It's absolutely crystal clear to me that we don't have enough tester
> > > manpower to make the current policy w
On Sun, Nov 14, 2010 at 08:03:35AM -0600, Bruno Wolff III wrote:
> On Sun, Nov 14, 2010 at 13:59:24 +0100,
> Till Maas wrote:
> > The optimal case is to provide well tested security updates fast, but
> > this is not what Fedora achieves. In my example there is no indication
> > that the update
* Jon Masters (jonat...@jonmasters.org) wrote:
> On Tue, 2010-11-16 at 23:35 +0100, François Cami wrote:
> > On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi wrote:
> > > On Fri, 12 Nov 2010 14:54:28 -0500
> > > Simo Sorce wrote:
> > >
> > >> Adam why should security updates wait at all ?
> > >> Do y
On Tue, 2010-11-16 at 23:35 +0100, François Cami wrote:
> On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi wrote:
> > On Fri, 12 Nov 2010 14:54:28 -0500
> > Simo Sorce wrote:
> >
> >> Adam why should security updates wait at all ?
> >> Do you fear some packager will flag as security updates that are
On Fri, Nov 12, 2010 at 9:14 PM, Kevin Fenzi wrote:
> On Fri, 12 Nov 2010 14:54:28 -0500
> Simo Sorce wrote:
>
>> Adam why should security updates wait at all ?
>> Do you fear some packager will flag as security updates that are not ?
>> Surely we can deal with such maintainer if that happens...
On Fri, Nov 12, 2010 at 11:46:36AM -0800, Adam Williamson wrote:
> On Fri, 2010-11-12 at 14:32 -0500, Tom Lane wrote:
>
> > It's absolutely crystal clear to me that we don't have enough tester
> > manpower to make the current policy workable; it's past time to stop
> > denying that. I'd suggest n
On Mon, Nov 01, 2010 at 09:35:49AM -0600, Kevin Fenzi wrote:
> On Sun, 31 Oct 2010 10:16:41 -0400
> "Clyde E. Kunkel" wrote:
>
> > On 10/31/2010 03:18 AM, Michael Schwendt wrote:
> > > Okay, feedback time.
> > >
> > > Lately, there have been several attempts at urging proventesters
> > > (and not
On Sun, Nov 14, 2010 at 13:59:24 +0100,
Till Maas wrote:
>
> If there are no security updates, people can not apply them. So what is
> worse? If people stop applying updates, then it is at least their
> decision. If there are no updates, people can only choose not to use
Many people are going
On Sat, Nov 13, 2010 at 02:22:42PM +, Matthew Garrett wrote:
> On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote:
>
> > The documented issues do not seem to be as bad as a system being
> > exploited. It is only about dependency breakage or services not working
> > anymore. There is no
On Sat, 2010-11-13 at 14:22 +, Matthew Garrett wrote:
> On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote:
>
> > The documented issues do not seem to be as bad as a system being
> > exploited. It is only about dependency breakage or services not working
> > anymore. There is no major d
On 11/12/2010 11:14 PM, Tom Lane wrote:
> "Clyde E. Kunkel" writes:
>>
> The major packages that I work with have regression test suites,
> which in fact get run as part of the RPM build sequence. It's not
> apparent to me that I should need to invent some more tests.
>
I did not know that. G
On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote:
> The documented issues do not seem to be as bad as a system being
> exploited. It is only about dependency breakage or services not working
> anymore. There is no major data corruption requiring access to backups
> and restoring the whole
On Fri, Nov 12, 2010 at 11:19:22AM -0800, Adam Williamson wrote:
> Thanks for flagging this up.
>
> I'm wondering if perhaps we should devise a system - maybe a sub-group
> of proventesters - to ensure timely testing of security updates. wdyt?
I am not sure if a smaller group would help here. Bu
On Fri, Nov 12, 2010 at 01:14:12PM -0700, Kevin Fenzi wrote:
> No. The issue is that in the past sometimes security updates have been
> rushed out with no testing and broken things badly. ;(
>
> See http://fedoraproject.org/wiki/Updates_Lessons
> For some small number of examples (yes, anyone is
On Fri, 2010-11-12 at 23:14 -0500, Tom Lane wrote:
> 2. I screwed up and introduced a packaging bug, for instance bad
> dependencies or inability to "yum update". That's been known to happen
> too. But I have a lot more faith in autoqa being able to catch that
> kind of problem in a timely fashi
"Clyde E. Kunkel" writes:
> On 11/12/2010 02:32 PM, Tom Lane wrote:
>> It's absolutely crystal clear to me that we don't have enough tester
>> manpower to make the current policy workable; it's past time to stop
>> denying that. I'd suggest narrowing the policy to a small number of
>> critical pa
On 11/12/2010 02:32 PM, Tom Lane wrote:
> Till Maas writes:
>>
>
> It's absolutely crystal clear to me that we don't have enough tester
> manpower to make the current policy workable; it's past time to stop
> denying that. I'd suggest narrowing the policy to a small number of
> critical packages
On Fri, 12 Nov 2010 14:54:28 -0500
Simo Sorce wrote:
> Adam why should security updates wait at all ?
> Do you fear some packager will flag as security updates that are not ?
> Surely we can deal with such maintainer if that happens...
No. The issue is that in the past sometimes security updates
On Fri, 12 Nov 2010 12:02:03 -0800
Adam Williamson wrote:
> On Fri, 2010-11-12 at 14:54 -0500, Simo Sorce wrote:
>
> > Adam why should security updates wait at all ?
> > Do you fear some packager will flag as security updates that are
> > not ? Surely we can deal with such maintainer if that hap
On Fri, 2010-11-12 at 14:54 -0500, Simo Sorce wrote:
> Adam why should security updates wait at all ?
> Do you fear some packager will flag as security updates that are not ?
> Surely we can deal with such maintainer if that happens...
I don't have a hugely strong opinion either way, but the stat
On Fri, 12 Nov 2010 11:19:22 -0800
Adam Williamson wrote:
> On Fri, 2010-11-12 at 20:03 +0100, Till Maas wrote:
> > On Mon, Nov 01, 2010 at 10:09:17AM -0700, Adam Williamson wrote:
> >
> > > I disagree. The evidence you cite does not support this
> > > conclusion. We implemented the policies for
On Fri, 2010-11-12 at 14:32 -0500, Tom Lane wrote:
> It's absolutely crystal clear to me that we don't have enough tester
> manpower to make the current policy workable; it's past time to stop
> denying that. I'd suggest narrowing the policy to a small number of
> critical packages, for which the
On Fri, 2010-11-12 at 14:32 -0500, Tom Lane wrote:
> Till Maas writes:
> > On Mon, Nov 01, 2010 at 10:09:17AM -0700, Adam Williamson wrote:
> >> I disagree. The evidence you cite does not support this conclusion. We
> >> implemented the policies for three releases. There are significant
> >> probl
Till Maas writes:
> On Mon, Nov 01, 2010 at 10:09:17AM -0700, Adam Williamson wrote:
>> I disagree. The evidence you cite does not support this conclusion. We
>> implemented the policies for three releases. There are significant
>> problems with one release. This does not justify the conclusion th
On Fri, 2010-11-12 at 20:03 +0100, Till Maas wrote:
> On Mon, Nov 01, 2010 at 10:09:17AM -0700, Adam Williamson wrote:
>
> > I disagree. The evidence you cite does not support this conclusion. We
> > implemented the policies for three releases. There are significant
> > problems with one release.
On Mon, Nov 01, 2010 at 10:09:17AM -0700, Adam Williamson wrote:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies shoul
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
> This is a reasonable modification of the idea that an update should only
> require karma for one release (which would be nice if it were true but
> unfortunately isn't). In practice, though, there isn't much wiggle room
> for requiring 'l
On Mon, 2010-11-01 at 22:54 +0100, Henrik Nordström wrote:
> mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
>
> > I disagree. The evidence you cite does not support this conclusion. We
> > implemented the policies for three releases. There are significant
> > problems with one release.
mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies should be en
On Mon, 01 Nov 2010 19:26:43 +0100
Kevin Kofler wrote:
> They also let several completely broken updates through and then
> delayed the FIXES for those updates, exactly as I had been warning
> about all the time.
Cite(s)?
>
> For example, my firstboot update which was required to make the Xfce
Adam Williamson wrote:
> I disagree. The evidence you cite does not support this conclusion. We
> implemented the policies for three releases. There are significant
> problems with one release. This does not justify the conclusion that the
> policies should be entirely repealed.
The evidence in TH
Adam Williamson wrote:
> The policies prevented us from shipping a number of completely broken
> updates, which is exactly what they were intended to do. I don't have a
> command handy to do a search for rejected proposed critpath updates for
> F14, but if you figure it out, you can see the precise
Adam Williamson wrote:
> On the other hand, other scenarios were also brought up, which have not
> come to pass - for instance, the same thing happening to Fedora 13 or
> Fedora 14.
Nonsense. We just do not have enough evidence yet to show such things
happening for F13 and F14. They CAN, and IMHO
Adam Williamson píše v Po 01. 11. 2010 v 10:55 -0700:
> On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote:
> > > Sorry, but characterizing it as a 'known problem' is misleading. It's
> > > easy to forecast failure, and you'll likely always be correct in *some*
> > > cases if you forecast eno
On Mon, 2010-11-01 at 18:51 +0100, Miloslav Trmač wrote:
> > Sorry, but characterizing it as a 'known problem' is misleading. It's
> > easy to forecast failure, and you'll likely always be correct in *some*
> > cases if you forecast enough failures. Only if you precisely forecast
> > only the fail
Adam Williamson píše v Po 01. 11. 2010 v 10:39 -0700:
> On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote:
> > > It's better to try things, with the proviso that
> > > you accept when they aren't working and withdraw or modify them.
> > It's even better not to dismiss known problems with the
On Mon, 2010-11-01 at 18:29 +0100, Miloslav Trmač wrote:
> > On the other hand, other scenarios were also brought up, which have not
> > come to pass - for instance, the same thing happening to Fedora 13 or
> > Fedora 14. If we had simply accepted the predictions of doom and not
> > implemented th
Adam Williamson píše v Po 01. 11. 2010 v 10:08 -0700:
> > > We designed a policy,
> > > put it into effect, now we're observing how well it works and we can
> > > modify its implementation on the fly. It doesn't need to be done in an
> > > adversarial spirit.
> > Given that _this exact scenario_ w
On Mon, Nov 1, 2010 at 5:08 PM, Adam Williamson wrote:
> Saying 'oh dear, this might not work, we'd better not try' is rarely a
> good approach, IMHO. It's better to try things, with the proviso that
> you accept when they aren't working and withdraw or modify them.
I would agree with this, if th
On Mon, 2010-11-01 at 03:54 +0100, Kevin Kofler wrote:
> There's exactly one constructive thing to do, it's repealing this set of
> policies (Critical Path and Update Acceptance Criteria) in its entirety.
>
> An update should go stable when the maintainer says so, karma should be
> purely infor
On Mon, 2010-11-01 at 02:18 +0100, Miloslav Trmač wrote:
> > Kevin, could you *please* not word things like that? There's just no
> > need for it.
> >
> > I already wrote this to -test a couple of days ago:
> >
> > http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html
> >
> > a
On Sun, 31 Oct 2010 10:16:41 -0400
"Clyde E. Kunkel" wrote:
> On 10/31/2010 03:18 AM, Michael Schwendt wrote:
> > Okay, feedback time.
> >
> > Lately, there have been several attempts at urging proventesters
> > (and not just testers in general) to give positive karma for aging
> > critpath updat
Adam Williamson wrote:
> I already wrote this to -test a couple of days ago:
>
> http://lists.fedoraproject.org/pipermail/test/2010-October/095135.html
>
> and we're discussing it there. I think the thread demonstrates things
> tend to go much more constructively if you avoid throwing words like
Adam Williamson píše v Ne 31. 10. 2010 v 18:06 -0700:
> On Sun, 2010-10-31 at 04:37 +0100, Kevin Kofler wrote:
> Yet another blatant example of
> > failure of the Update Acceptance Criteria, needlessly exposing our users to
> > critical vulnerabilities.
>
> Kevin, could you *please* not word th
On Sun, 2010-10-31 at 04:37 +0100, Kevin Kofler wrote:
> Martin Stransky wrote:
> > there's a new Firefox update waiting in Bodhi and we can't push it to
> > stable because of new rules. We recommend you to update to it ASAP as it
> > fixes a public critical 0day vulnerability
> > (https://bugzilla
On 10/31/2010 03:18 AM, Michael Schwendt wrote:
> On Sun, 31 Oct 2010 04:37:38 +0100, Kevin wrote:
>
>> Martin Stransky wrote:
>>> there's a new Firefox update waiting in Bodhi and we can't push it to
>>> stable because of new rules. We recommend you to update to it ASAP as it
>>> fixes a public cr
On Sun, 31 Oct 2010 04:37:38 +0100, Kevin wrote:
> Martin Stransky wrote:
> > there's a new Firefox update waiting in Bodhi and we can't push it to
> > stable because of new rules. We recommend you to update to it ASAP as it
> > fixes a public critical 0day vulnerability
> > (https://bugzilla.mozi
Martin Stransky wrote:
> there's a new Firefox update waiting in Bodhi and we can't push it to
> stable because of new rules. We recommend you to update to it ASAP as it
> fixes a public critical 0day vulnerability
> (https://bugzilla.mozilla.org/show_bug.cgi?id=607222).
Looks like the F13 build g
78 matches
Mail list logo
