Jesse Keating wrote:
> The solution to "shit went out and broke my stuff" isn't to make it
> easier to put shit out, it's to make it harder to put broken shit out
> in the first place.
Sure, that's a nice theory, but in practice, no matter how much testing you
require, there will ALWAYS be regres
Jesse Keating wrote:
> If/when karma is required for an update to go out, or a timeout in
> -testing, we will see an uptick in karma.
You keep claiming that. You have no evidence whatsoever for that, and it
doesn't seem plausible to me at all. Users only care about having the issue
fixed for the
Peter Jones wrote:
> Wait just a second - you're arguing that requiring testing doesn't work
> because nobody tested the KDE spin within 8 days. You might want to
> rethink this position.
Why? I don't see the contradiction. If nobody tests things, testing doesn't
and can't work.
Kevin Ko
On 05/04/2010 02:14 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> This involved doing another build of the package, which could
>> involve changes in the buildroot and anomalies in the build
>> process. Ask DaveJ some time about what happened to his kernel
>> builds when the build host did a cl
On Tue, May 4, 2010 at 2:14 PM, Kevin Kofler wrote:
> Some risks are so low that they're basically negligible. If the 2 options
> are keeping an existing regression (which missed testing) in updates for a
> few more days or risking the off chance that there MAY be another regression
> with a proba
On 05/04/2010 01:40 PM, Kevin Kofler wrote:
> Peter Jones wrote:
>> I'm sorry you don't like it, but you've had ample occasion to come up with
>> a better idea, and you have roundly refused to make any attempt at doing
>> so.
>
> "I'm sorry you don't like my plate of Merde Provençale, but you've h
On Tue, May 4, 2010 at 9:50 AM, Jesse Keating wrote:
> If the breakage was more of a functional break and not a dep break,
> that's where automated testing comes in, and we grow the automated
> functional testing of updates so that if an update comes along we can
> detect the breakage and alert bo
Jesse Keating wrote:
> This involved doing another build of the package, which could involve
> changes in the buildroot and anomalies in the build process. Ask DaveJ
> some time about what happened to his kernel builds when the build host
> did a clock adjustment during the build. Shit happens, a
On 05/04/2010 06:04 PM, Kevin Kofler wrote:
Peter Jones wrote:
Wait just a second - you're arguing that requiring testing doesn't work
because nobody tested the KDE spin within 8 days. You might want to
rethink this position.
Why? I don't see the contradiction. If nobody tests things,
Michael Cronenworth wrote:
> It's common sense that older releases should be receiving more testing,
> but here in reality it is the opposite. If I am wrong, please prove it.
Indeed, that's the fact we have to deal with, and IMHO the solution is to
push the same changes to all releases wherever p
On Tue, 2010-05-04 at 09:07 -0800, Jeff Spaleta wrote:
> On Tue, May 4, 2010 at 8:45 AM, Jesse Keating wrote:
> > So I'd love to have multi-level policy, but in my opinion it should get
> > harder and harder to push an update as the release gets older, not
> > easier.
>
>
> In general I'm in agr
On Tue, 2010-05-04 at 12:04 -0500, Michael Cronenworth wrote:
> Jesse Keating wrote:
> > So this is kind of funny. You'd rather see testing become/less/
> > rigorous as the age of a release grows, and you want the most rigorous
> > testing done in rawhide. That's quite the opposite of what many o
Michael Cronenworth wrote:
> Fedora security updates are regularly given no testing and are pushed
> directly to stable. Perhaps you should classify your updates with a
> severity of security.
That doesn't work because security updates require security team approval
(another silly policy which wa
On Tue, 2010-05-04 at 19:40 +0200, Kevin Kofler wrote:
> There are changes
> which don't need testing, for example if a patch was dropped because we
> thought it wasn't needed anymore, and it turns out the patch is still
> needed, readding the patch needs no testing whatsoever because the patch
Peter Jones wrote:
> I'm sorry you don't like it, but you've had ample occasion to come up with
> a better idea, and you have roundly refused to make any attempt at doing
> so.
"I'm sorry you don't like my plate of Merde Provençale, but you've had ample
occation to come up with a better recipe fo
On Tue, May 4, 2010 at 8:45 AM, Jesse Keating wrote:
> So I'd love to have multi-level policy, but in my opinion it should get
> harder and harder to push an update as the release gets older, not
> easier.
In general I'm in agreement with this. But at the same time I'm
concerned that the policy
Jesse Keating wrote:
> So this is kind of funny. You'd rather see testing become/less/
> rigorous as the age of a release grows, and you want the most rigorous
> testing done in rawhide. That's quite the opposite of what many of us
> are trying to work toward, that is as the release moves from ra
On Tue, 2010-05-04 at 11:25 -0500, Michael Cronenworth wrote:
> Fedora Rawhide/Fedora N+1
> Yes, these need rigorous testing and QA. Policies and tests are being
> set in place that will make a better and brighter Fedora future.
> However, it seems that the same release-level criteria are eroding
On 05/04/2010 05:55 PM, "Jóhann B. Guðmundsson" wrote:
> On 05/04/2010 01:50 PM, Kevin Kofler wrote:
>> "Jóhann B. Guðmundsson" wrote:
>>> You must all realize that the ratio of bureaucracy/process burden and
>>> quality of maintainers/packagers go hand in hand. The better the
>>> maintainers/packa
Jesse Keating wrote:
> Which vision is that? The one where we should produce a generally
> usable stable operating system every 6 months, one that users can
> confidently use throughout the life of that release? Making sure our
> updates given to users are better tested seems to be working toward
On 05/04/2010 01:50 PM, Kevin Kofler wrote:
"Jóhann B. Guðmundsson" wrote:
You must all realize that the ratio of bureaucracy/process burden and
quality of maintainers/packagers go hand in hand. The better the
maintainers/packagers/components are less bureaucracy/process burden is
needed. Th
On Tue, 2010-05-04 at 10:00 -0500, Michael Cronenworth wrote:
> The recent upswing in
> policies and requirements is clouding Fedora's vision.
Which vision is that? The one where we should produce a generally
usable stable operating system every 6 months, one that users can
confidently use thr
On 05/03/2010 12:51 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>
>> On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote:
>>> [1] And I appreciate that I made a mistake with hal-storage in this
>>> cycle that caused inconvenience for people maintaining other spins, so
>>> I'm not going to
On 05/04/2010 09:50 AM, Kevin Kofler wrote:
> "Jóhann B. Guðmundsson" wrote:
>> You must all realize that the ratio of bureaucracy/process burden and
>> quality of maintainers/packagers go hand in hand. The better the
>> maintainers/packagers/components are less bureaucracy/process burden is
>> nee
Kevin Kofler wrote:
> I am saying that SOME updates can be pushed with less or even no testing.
> This does NOT mean that testing should not be used in most cases. It just
> means that it should be the maintainer's discretion whether to use it or
> not. The maintainer knows best how to handle his/h
Jesse Keating wrote:
> In many cases these do apply. I participate in cases such as this
> nearly every day, and it's working. We're testing fixes, rejecting bad
> ones, and getting the right builds into stable. The system is working,
> but as we all know, no system is perfect. However perfect
"Jóhann B. Guðmundsson" wrote:
> You must all realize that the ratio of bureaucracy/process burden and
> quality of maintainers/packagers go hand in hand. The better the
> maintainers/packagers/components are less bureaucracy/process burden is
> needed. The worse it gets more bureaucracy/process bu
On Tue, May 4, 2010 at 12:51, Richard W.M. Jones wrote:
> Secondly, a simple linear scale doesn't reflect the complexity of
> testing packages. I've had people downvote my packages because of FAQ
> issues or user error or long-standing bugs in some other package that
> we can't or don't want to f
On Mon, May 03, 2010 at 02:00:59PM -0700, Jesse Keating wrote:
> On Mon, 2010-05-03 at 18:45 +0200, Kevin Kofler wrote:
> > here will
> > ALWAYS be a need for a way to fasttrack regression fixes!
>
> The proposals I've seen include a way to fasttrack. That is you get the
> required karma betwee
On 05/04/2010 05:09 AM, Dave Airlie wrote:
> So it its none of these why do you want to fast track it into stable?
The fact nobody has reported a bug into Fedora's bugtracking system
doesn't mean a package is not bugged or doesn't suffer from defects.
The prototypical situations I am facing with
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote:
> On 05/03/2010 11:12 PM, Jesse Keating wrote:
> > On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote:
> >>
> >> Except karma requirements (which were in force due to the critical path
> >> process) did NOT prevent this particular regressi
On Tue, 2010-05-04 at 05:01 +0200, Ralf Corsepius wrote:
>
> You are presuming a bug
> * affects many people
> * is reproducable by many people
> * has "user visible" impacts
> * users are volunteering to provide feedback
>
> These presumptions are all wrong and do not apply.
In many cases thes
On 05/03/2010 11:12 PM, Jesse Keating wrote:
> On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote:
>>
>> Except karma requirements (which were in force due to the critical path
>> process) did NOT prevent this particular regression, nor would a "1 week
>> minimum in testing" requirement have pre
On 05/03/2010 10:30 PM, Jesse Keating wrote:
> The point here is that Kevin isn't perfect. As such, he can make
> mistakes, just like all of us. By asking for a couple karma nods from
> different people, we increase the chance of catching some of those
> mistakes. Since the delay exists anyway,
On Tue, 2010-05-04 at 01:27 +0300, shmuel siegel wrote:
> At the risk of putting words into Kevin's mouth, I think that you just
> made his point. I'd be very surprised if Kevin couldn't get x number of
> people to say yes to a fix that he considered urgent. This might confirm
> that the fix had
On 5/4/2010 12:57 AM, Jesse Keating wrote:
> Testing takes time, lets give up? Seriously? Pushes happen about once
> every 24 hours, do you really say it'll take longer than 24 hours to get
> a couple people to test the issue and confirm that your fix does indeed
> fix the issue, and doesn't seem
On Mon, 2010-05-03 at 23:49 +0200, Kevin Kofler wrote:
> Jesse Keating wrote:
> > The proposals I've seen include a way to fasttrack. That is you get the
> > required karma between the time the update was submitted to bodhi, and
> > the time a bodhi admin starts the push. In such cases your updat
Jesse Keating wrote:
> The proposals I've seen include a way to fasttrack. That is you get the
> required karma between the time the update was submitted to bodhi, and
> the time a bodhi admin starts the push. In such cases your update would
> go directly to stable. How is that not a fast track?
On Mon, 2010-05-03 at 18:51 +0200, Kevin Kofler wrote:
>
> Except karma requirements (which were in force due to the critical path
> process) did NOT prevent this particular regression, nor would a "1 week
> minimum in testing" requirement have prevented it (the update spent 8 days
> in testing
On Mon, 2010-05-03 at 18:45 +0200, Kevin Kofler wrote:
> here will
> ALWAYS be a need for a way to fasttrack regression fixes!
The proposals I've seen include a way to fasttrack. That is you get the
required karma between the time the update was submitted to bodhi, and
the time a bodhi admin st
On Mon, May 3, 2010 at 10:00 AM, Chris Adams wrote:
> Thanks a lot Kevin; you showed a lot of class trying to stir up the same
> arguments that you stirred up before. Maybe the reason you lost votes
> is that a lot of people just don't agree with you; pouting about that
> won't help anything.
Th
On Mon, May 3, 2010 at 8:00 PM, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
>> Matthew Garrett wrote:
>
>
> Can we PLEASE not rehash all of this again?
Generally agreed.
> Maybe the reason you lost votes is that a lot of people just don't agree with
>you
Doesn't automatically m
Once upon a time, Kevin Kofler said:
> Matthew Garrett wrote:
Can we PLEASE not rehash all of this again?
Thanks a lot Kevin; you showed a lot of class trying to stir up the same
arguments that you stirred up before. Maybe the reason you lost votes
is that a lot of people just don't agree with
Jesse Keating wrote:
> On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote:
>> [1] And I appreciate that I made a mistake with hal-storage in this
>> cycle that caused inconvenience for people maintaining other spins, so
>> I'm not going to claim any kind of perfection in this area
>
> Which
Matthew Garrett wrote:
> If updates cause regressions in functionality then that indicates that
> our update testing process failed. The answer to that is to fix the
> update testing process, not bypass it.
Your assumption there is that it is possible for a testing process to catch
ALL regression
On Mon, 2010-05-03 at 14:01 +0100, Matthew Garrett wrote:
> [1] And I appreciate that I made a mistake with hal-storage in this
> cycle that caused inconvenience for people maintaining other spins, so
> I'm not going to claim any kind of perfection in this area
Which just adds reason to why we a
On Mon, May 3, 2010 at 5:10 PM, Matthew Garrett wrote:
> On Mon, May 03, 2010 at 04:34:13PM +0200, Kevin Kofler wrote:
>
>> You make it look as if I was out to break people's systems
>
> Actually, I didn't intend to say anything about you. My point was that
> any increased bureaucracy has not been
Matthew Garrett wrote:
> My point was that
> any increased bureaucracy has not been generated with the intention to
> reduce the amount of fun that developers have.
Let me jump in just to say that I'm not a developer/packager, but it
was my intention to become a contributor for Fedora.
What scar
On Mon, May 03, 2010 at 04:34:13PM +0200, Kevin Kofler wrote:
> You make it look as if I was out to break people's systems
Actually, I didn't intend to say anything about you. My point was that
any increased bureaucracy has not been generated with the intention to
reduce the amount of fun that
Matthew Garrett wrote:
> The stable packages work is an extension of this. Even if we, as
> maintainers, have plenty of fun, that's pretty easily wiped out if even
> a small proportion of our users have to spend time fixing a system that
> a stable update has broken. And without users who enjoy usi
On Sun, May 02, 2010 at 07:02:23PM -0700, Henrique Junior wrote:
>Unfortunately, what I have seen over time is that Fedora is changing to
>something that worries me and that is getting less fun to contribute. I
>remember the time when I liked to say that fedora was the "voice of the
>
Unfortunately,
what I have seen over time is that Fedora is changing to something that
worries me and that is getting less fun to contribute. I remember the time when
I liked to say that fedora was the "voice of the community".
--
Henrique "LonelySpooky" Junior
___
52 matches
Mail list logo
