On Mon, 8 Mar 2010, Bruno Wolff III wrote:
> On Mon, Mar 08, 2010 at 17:30:14 -0600,
> Mike McGrath wrote:
> > On Mon, 8 Mar 2010, Bruno Wolff III wrote:
> >
> > > On Fri, Mar 05, 2010 at 23:52:24 +0100,
> > > Michael Schwendt wrote:
> > > >
> > > > It takes days for updates to be distribute
On Mon, Mar 08, 2010 at 17:30:14 -0600,
Mike McGrath wrote:
> On Mon, 8 Mar 2010, Bruno Wolff III wrote:
>
> > On Fri, Mar 05, 2010 at 23:52:24 +0100,
> > Michael Schwendt wrote:
> > >
> > > It takes days for updates to be distributed to mirrors. A week may be
> > > nothing for that importan
On Mon, 8 Mar 2010, Bruno Wolff III wrote:
> On Fri, Mar 05, 2010 at 23:52:24 +0100,
> Michael Schwendt wrote:
> >
> > It takes days for updates to be distributed to mirrors. A week may be
> > nothing for that important power-user of app 'A', who would find a problem
> > as soon as he *would* t
On Fri, Mar 05, 2010 at 23:52:24 +0100,
Michael Schwendt wrote:
>
> It takes days for updates to be distributed to mirrors. A week may be
> nothing for that important power-user of app 'A', who would find a problem
> as soon as he *would* try out a test-update.
Some mirrors. Others have stuff
On Fri, Mar 05, 2010 at 06:39:02PM -0800, Adam Williamson wrote:
> On Fri, 2010-03-05 at 23:47 +0100, Till Maas wrote:
> > to how these numbers have changed in a week. I hope then everyone from
> > the QA SIG is using the script to report feedback, so it will be save to
> > say that an update was
On Fri, 2010-03-05 at 23:52 +0100, Michael Schwendt wrote:
> On Fri, 05 Mar 2010 13:46:34 -0800, Adam wrote:
>
> > Ah. You're looking at it on a kind of micro level; 'how can I tell this
> > package has been tested?'
>
> Exactly. Because I don't like to act on assumptions.
>
> And "zero feedback
On Fri, 2010-03-05 at 23:47 +0100, Till Maas wrote:
> On Fri, Mar 05, 2010 at 01:46:34PM -0800, Adam Williamson wrote:
>
> > Ah. You're looking at it on a kind of micro level; 'how can I tell this
> > package has been tested?'
>
> For a package maintainer it is especially interesting, whether the
On Fri, 05 Mar 2010 13:46:34 -0800, Adam wrote:
> Ah. You're looking at it on a kind of micro level; 'how can I tell this
> package has been tested?'
Exactly. Because I don't like to act on assumptions.
And "zero feedback" is only an indicator for "doesn't break badly", if
there are N>1 testers
On Fri, Mar 05, 2010 at 01:46:34PM -0800, Adam Williamson wrote:
> Ah. You're looking at it on a kind of micro level; 'how can I tell this
> package has been tested?'
For a package maintainer it is especially interesting, whether the own
update has been tested.
> Maybe it makes it clearer if I e
On Fri, 2010-03-05 at 22:16 +0100, Michael Schwendt wrote:
> On Fri, 05 Mar 2010 09:33:02 -0800, Adam wrote:
>
> > > No, not in a clear way. Instead, you keep emphasising that no negative
> > > feedback is not equal to a package not having been tested at all. That's
> > > just plain useless. Not e
On Fri, 05 Mar 2010 09:33:02 -0800, Adam wrote:
> > No, not in a clear way. Instead, you keep emphasising that no negative
> > feedback is not equal to a package not having been tested at all. That's
> > just plain useless. Not even all broken deps are reported in bodhi.
>
> Why do you keep talki
On Fri, 2010-03-05 at 18:26 +0100, Michael Schwendt wrote:
> > Nothing like that. It just frustrates me when people don't debate
> > correctly.
>
> Then consider stopping to send further replies. You -- and some other
> participants in these threads -- pipe out way too many replies in
> quick suc
On Fri, 05 Mar 2010 09:11:10 -0800, Adam wrote:
> On Fri, 2010-03-05 at 18:01 +0100, Michael Schwendt wrote:
>
> > It doesn't change anything, though. No feedback => nothing to rely on.
> > These recent discussions on this list could have been fruitful, btw.
> > For some people it has become a ga
On Fri, 2010-03-05 at 18:01 +0100, Michael Schwendt wrote:
> It doesn't change anything, though. No feedback => nothing to rely on.
> These recent discussions on this list could have been fruitful, btw.
> For some people it has become a game of "I'm right - you aren't",
> unfortunately.
Nothing l
On Fri, 05 Mar 2010 08:19:25 -0800, Adam wrote:
> On Fri, 2010-03-05 at 14:38 +0100, Michael Schwendt wrote:
>
> > > which go through updates-testing. They do not file positive
> > > feedback for every single package because there's just too many, but if
> > > they notice breakage, they file nega
On Fri, 2010-03-05 at 14:38 +0100, Michael Schwendt wrote:
> > which go through updates-testing. They do not file positive
> > feedback for every single package because there's just too many, but if
> > they notice breakage, they file negative feedback.
>
> And they simply don't and can't notice
On Wed, 03 Mar 2010 14:06:33 -0800, Adam wrote:
> as we've explained several times,
It won't get more correct by simply repeating it over and over again.
> most packages that go to
> updates-testing for a few days *are* being tested, even if they get no
> apparent Bodhi feedback.
Certainly not
On Wed, 2010-03-03 at 17:04 +0100, Till Maas wrote:
> I mind have misunderstood it, but afaics it only says that it will be
> tested, because it spent time in updates-testing, but this is not even
> true nowadays, even if packages stay long in updates-testing.
as we've explained several times, mo
On Wed, Mar 03, 2010 at 11:07:27AM -0500, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Till Maas wrote:
>
> > On Wed, Mar 03, 2010 at 08:42:57AM -0500, Seth Vidal wrote:
> >
> >> On Wed, 3 Mar 2010, Till Maas wrote:
> >
> >>> Are there even any metrics about how many bad updates happened? For me
On Wed, Mar 03, 2010 at 19:14:09 +0100,
Ralf Corsepius wrote:
> Seth doesn't fix bugs even when they are apparent and when there is no
> risk at all.
yum is a very critical package. Even if the chance of an undetected regression
is low, the consequences of pushing an update with one can be pre
Ralf Corsepius wrote:
> Your testing group will *never* be able to test much more than a very
> tiny subset of use cases -- Let them test their limited testing
> scenarios, but keep them out of the rest of testing.
>
> => Instead of slowing down things by deploying a testing group, speed up
> thin
Seth Vidal wrote:
> Those items will be released in the next release of yum or in the next
> fedora release.
That can be quite a long time. Providing bugfixes to our stable releases is
important! I won't complain if you do upstream releases regularly and
systematically push them as updates, but
On 03/03/2010 07:03 PM, James Antill wrote:
> On Wed, 2010-03-03 at 18:06 +0100, Ralf Corsepius wrote:
>> On 03/03/2010 05:10 PM, Seth Vidal wrote:
>>>
>>>
>>> On Wed, 3 Mar 2010, Peter Lemenkov wrote:
And what about tickets, closed with "FIXED UPSTREAM" w/o actually
applying fix to a pac
Seth Vidal wrote:
> Having more time opens us up to more testing days and in the near future
> autoqa to help us bounce obviously bad things.
The whole point of AutoQA is that it can get (some) testing done fast
(otherwise why bother with automation?), I don't see why we need to slow
things down
On Wed, 2010-03-03 at 18:06 +0100, Ralf Corsepius wrote:
> On 03/03/2010 05:10 PM, Seth Vidal wrote:
> >
> >
> > On Wed, 3 Mar 2010, Peter Lemenkov wrote:
> >> And what about tickets, closed with "FIXED UPSTREAM" w/o actually
> >> applying fix to a package?
> >>
> >
> > Those items will be released
On 03/03/2010 05:10 PM, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Peter Lemenkov wrote:
>
>> 2010/3/3 Seth Vidal:
>>>
>>>
>>> On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>>>
>>>
>> Feel free to think so, however can not disagree more.
> Ralf, we've never agreed on much of anything. Why shou
On 03/03/2010 04:51 PM, Jesse Keating wrote:
> For me personally the type of update I'd like to see slowed down is the
> pure enhancement update or new package updates, ones that do nothing but
> swallow up the latest upstream build or scm snapshot to add new
> features.
#1 on your personal list
On Wed, 3 Mar 2010, Peter Lemenkov wrote:
> 2010/3/3 Seth Vidal :
>>
>>
>> On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>>
>>
> Feel free to think so, however can not disagree more.
Ralf, we've never agreed on much of anything. Why should this be
different?
>>>
>>> What do you expect?
On Wed, 3 Mar 2010, Till Maas wrote:
> On Wed, Mar 03, 2010 at 08:42:57AM -0500, Seth Vidal wrote:
>
>> On Wed, 3 Mar 2010, Till Maas wrote:
>
>>> Are there even any metrics about how many bad updates happened? For me
>>> bug that can be fixed issuing an update are a lot more than regressions
>
2010/3/3 Seth Vidal :
>
>
> On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>
>
>> >> Feel free to think so, however can not disagree more.
>> >Ralf, we've never agreed on much of anything. Why should this be
>> >different?
>>
>> What do you expect? I consider you (and a couple of other further
>> member
On Wed, Mar 03, 2010 at 08:42:57AM -0500, Seth Vidal wrote:
> On Wed, 3 Mar 2010, Till Maas wrote:
> > Are there even any metrics about how many bad updates happened? For me
> > bug that can be fixed issuing an update are a lot more than regressions
> > with updates or new bugs introduced with u
On Wed, 3 Mar 2010, Ralf Corsepius wrote:
> >> Feel free to think so, however can not disagree more.
> >Ralf, we've never agreed on much of anything. Why should this be
> >different?
>
> What do you expect? I consider you (and a couple of other further
> members of FPB and FESCO) to be graduall
On 03/03/2010 02:47 PM, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>
>>
>> So far, I haven't seen any indication of such a team being in existance
>> (c.f. dnssec-conf, kernel) nor am I aware of any means for testing such
>> perl-modules (perl-modules typically are equipped w
On Wed, 2010-03-03 at 09:45 +0100, Till Maas wrote:
> On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote:
> > On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> > > Why? Because you say so? We aren't doing that stuff now and things are
> > > working just fine, thank you very much!
Seth Vidal wrote:
> If you can't understand it, perhaps you should reconsider your role on a
> technical committee like fesco.
I understood your sentence, that doesn't make it any less jargon.
>> * And most importantly, even if we were to accept that it could lead to
>> better QA (which I doubt)
On Wed, 3 Mar 2010, Ralf Corsepius wrote:
>
> So far, I haven't seen any indication of such a team being in existance
> (c.f. dnssec-conf, kernel) nor am I aware of any means for testing such
> perl-modules (perl-modules typically are equipped with a testsuite).
>
> The real testing is performed
On Wed, 3 Mar 2010, Till Maas wrote:
> On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote:
>> On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
>>> Why? Because you say so? We aren't doing that stuff now and things are
>>> working just fine, thank you very much! We don't HAVE to
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
>> And stages non-critical/important updates so our QA team can test and
>> check them over more thoroughly and align testing goals and days to help
>> foster and create a more active and involved testing infrastructure.
>
> Congratulat
On Wednesday 03 March 2010 08:05:23 Jesse Keating wrote:
> On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> > Why? Because you say so? We aren't doing that stuff now and things are
> > working just fine, thank you very much! We don't HAVE to change anything
> > at all!
>
> This I believe t
On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote:
> On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> > Why? Because you say so? We aren't doing that stuff now and things are
> > working just fine, thank you very much! We don't HAVE to change anything at
> > all!
> >
>
> Thi
Jesse Keating wrote:
> This I believe to be the crux of the problem. When multiple updates go
> out that break large or important segments of our user base, many of us
> see a problem. You however seem to think it's "just fine". Many of us
> would rather put out a better operating system, and to
On 03/03/2010 07:28 AM, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Kevin Kofler wrote:
>
>> Seth Vidal wrote:
>>> At the risk of complicating the world would it make any sense for us to
>>> have (in increasing order of importance)
>>>
>>> updates-testing
>>> updates
>>> updates-important
>>>
>>> p
On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> Why? Because you say so? We aren't doing that stuff now and things are
> working just fine, thank you very much! We don't HAVE to change anything at
> all!
>
This I believe to be the crux of the problem. When multiple updates go
out that
Seth Vidal wrote:
> And stages non-critical/important updates so our QA team can test and
> check them over more thoroughly and align testing goals and days to help
> foster and create a more active and involved testing infrastructure.
Congratulations for that sentence full of technical jargon des
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
>> At the risk of complicating the world would it make any sense for us to
>> have (in increasing order of importance)
>>
>> updates-testing
>> updates
>> updates-important
>>
>> packages that are security or critical go from updates-te
Seth Vidal wrote:
> At the risk of complicating the world would it make any sense for us to
> have (in increasing order of importance)
>
> updates-testing
> updates
> updates-important
>
> packages that are security or critical go from updates-testing to
> updates-important - and that happens as
On Tue, 2 Mar 2010, Jesse Keating wrote:
> On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
>> The issue right now appears to be the same as when we have a critical
>> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
>> in updates-testing.
>
> I don't know if this will
On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
> The issue right now appears to be the same as when we have a critical
> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
> in updates-testing.
I don't know if this will help. Once a release has gotten a number of
upd
On Tue, 2 Mar 2010, Toshio Kuratomi wrote:
>> the suggestion I had made at fudcon went something like this:
>>
>> 1. all packages being put in as updates would need to be marked as per
>> the type of update. the default is 'trivial'. Options might include: new
>> pkg, trivial, feature, bugfix, s
49 matches
Mail list logo
