FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-03-2010, 08:24 AM
Jaroslav Reznik
 
Default Refining the update queues/process

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 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 do that, we need
> change. Your "just fine" isn't good enough.

And we are back in the beginning - what does "better OS" means - board is
trying to define it, every users has different view, every developer another...
And everyone is scared to make a decision. Yes, it's risky - you can kill
Fedora (for someone) or you can make Fedora best (for someone). You can never
satisfy everyone... There's advantage of open source - you are free to fork,
to start new project, to join another project if you think you have target
audience you want to work for.

But what we need really need is something, not two flamewars every week! So
let's prepare proposal(s), let developers vote and then implement it. Same for
board issues but it's not as easy to let users decide, to drag them into
decision process and it's the MUST for community project.

Jaroslav
--
Jaroslav Ňėezn√*k <jreznik@redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 12:42 PM
Seth Vidal
 
Default Refining the update queues/process

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.
>
> Congratulations for that sentence full of technical jargon designed to hide
> its true meaning.

If you can't understand it, perhaps you should reconsider your role on a
technical committee like fesco.


> * Who decides what updates are or are not "critical" or "important"? The
> criteria you brought up earlier in this thread (only security as critical)
> are way too restrictive, what about a fix for a regression?

Me and the rest of fesco. Oh and I didn't say only security as critical.
That's why I mentioned them separately.

> * Why would the QA team be better off having to test everything at the same
> time for the same deadline than the current flow of testing updates?

B/c we can call a moratorium a week before and have regular, scheduled
test days.

> * Why would we want to "align" our "testing goals and days"? It makes more
> sense to spread them so people can test one thing at a time!

Not for purposes of staging test events.

> * So would this really "create a more active and involved testing
> infrastructure"? IMHO it'd just create more painful deadlines, as if the
> releases weren't enough of a painpoint already.

Alternatively it makes things better for those folks who like to test
their software before releasing it.


> * And most importantly, even if we were to accept that it could lead to
> better QA (which I doubt), would it really be worth making users wait a FULL
> MONTH for their updates and forcing them to pull a HUGE update in one single
> transaction rather than spread over time? IMHO, HELL NO!

It will mean regularity and predictability. It will let users and admins
alike know when they can expect new things. Doing it once a month means
that they only need to cope with 13 of these per fedora release.

Predictability means you can plan for effectively.



>
> 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!

We will be doing it or something very much like it. Good luck with your
fight.

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 12:42 PM
Seth Vidal
 
Default Refining the update queues/process

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 change anything at
>>> all!
>>>
>>
>> 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 do that, we need
>> change. Your "just fine" isn't good enough.
>
> 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 updates. If updates are slowed
> down, this will get even worse. Especially because the proposal is to
> use time instead of test coverage as the criterion to push an update to
> stable.

Actually the proposal is time AND test coverage.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 12:47 PM
Seth Vidal
 
Default Refining the update queues/process

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 by Fedora users, them providing feedback
> and maintainers letting user feedback flow back into packages ASAP.

That's exactly the provlem. The qa team hasn't had the time to do so and
the explosive set of updates makes it difficult to keep a handle on.

Slowing them down and collecting them is to help that exactly.

> Feel free to think so, however can not disagree more.

Ralf, we've never agreed on much of anything. Why should this be
different?


> Or differently: The key to QA would not be bug-fixing, but to prevent
> bugs from entering Fedora - This is where Fedora has deficits.

That's exactly the point, Ralf, We need to let the QA team work on
problems in updates-testing and weed out the bogons and crap that find
their way in. It also means more time for autoqa to work it's magic.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 02:50 PM
Kevin Kofler
 
Default Refining the update queues/process

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), would it really be worth making users wait a
>> FULL MONTH for their updates and forcing them to pull a HUGE update in
>> one single transaction rather than spread over time? IMHO, HELL NO!
>
> It will mean regularity and predictability. It will let users and admins
> alike know when they can expect new things. Doing it once a month means
> that they only need to cope with 13 of these per fedora release.

13 huge updates are a lot more pain for people with slow connections than
many small ones. It'd also make Fedora effectively useless for those people
like me who use it because of the frequent updates. It makes this look like
M$ Patch Tuesdays instead of a fast-moving GNU/Linux distribution.

The solution to get more effective testing is to speed up pushes to testing
(and the technical issues with that are already being discussed), not to
slow down pushes to stable. Time is critical. Waiting a full month is only
going to cause problems and not solve anything at all.

> Predictability means you can plan for effectively.

No. It means a user can't plan when to update anymore, you're forcing your
schedule on the user! With the current system, the user can update on
his/her OWN schedule, daily, weekly, monthly or whatever, and at whatever
moment he/she wishes. With your M$-style system, they'd have to deal with
monthly big dumps and no other choice.

>> 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!
>
> We will be doing it or something very much like it. Good luck with your
> fight.

I don't see how you can be this definite. There was far from a consensus
that a time-based solution is the right thing to do even among those who
opposed direct stable pushes, I was clearly not the only one opposed to
that!

It's quite sad that you fail to realize how badly your proposal is flawed
and what disastrous consequences its implementation would have. We'd be
breaking Fedora for a huge portion of its current userbase!

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 02:51 PM
Jesse Keating
 
Default Refining the update queues/process

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! 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 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 do that, we need
> > change. Your "just fine" isn't good enough.
>
> 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 updates. If updates are slowed
> down, this will get even worse. Especially because the proposal is to
> use time instead of test coverage as the criterion to push an update to
> stable.
>

There are so many "proposals" out there that it's hard to know which
ones we're arguing about. In fact, none have been presented to FESCo
yet as far as I'm aware.

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. I'm more than happy to see bugfix and security updates go
through, and I don't really buy into time based delays, or time based
only delays. Karma has a role to play here, even though it is a simple
+1/-1, it is data not otherwise obtained. If your update gets enough
positive karma 2 hours after it hits updates-testing, by all means push
it to stable.

As far as metrics of bad updates, I don't have any off hand. We've had
to issue public apologies for screwing up our release in updates more
than once, which is more than once too many times. We are operating
without a safety net, and we've had some accidents. I'd like to see a
safety net be put in place, even if to begin with it is a manual safety
net, until such time as AutoQA can take over more and more of the tasks.

--
Jesse Keating
Fedora -- Freedom≤ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 03:01 PM
Ralf Corsepius
 
Default Refining the update queues/process

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 with a testsuite).
>>
>> The real testing is performed by Fedora users, them providing feedback
>> and maintainers letting user feedback flow back into packages ASAP.
>
> That's exactly the provlem. The qa team hasn't had the time to do so and
> the explosive set of updates makes it difficult to keep a handle on.
>
> Slowing them down and collecting them is to help that exactly.
You violently don't want understand anything what I have been trying to say?

I say:

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
things by fixing bug ASAP and ban "FIX UPSTREAM" (Like you are usually
doing).

It might be news to you, but experience tells this kind of strategy
converges towards "stability", in mid-terms.

Your strategy leads to over-all less testing, more bureaucracy and low
quality.

>> 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 gradually running down Fedora, e.g. by
advocating ever more regulations, installing more and more committees,
and by trying to suppress the community.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 03:02 PM
Seth Vidal
 
Default Refining the update queues/process

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 gradually running down Fedora, e.g. by
> advocating ever more regulations, installing more and more committees,
> and by trying to suppress the community.

Fantastic.
You have a nice day.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 03:04 PM
Till Maas
 
Default Refining the update queues/process

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 updates. If updates are slowed
> > down, this will get even worse. Especially because the proposal is to
> > use time instead of test coverage as the criterion to push an update to
> > stable.
>
> Actually the proposal is time AND test coverage.

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.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 03:06 PM
Peter Lemenkov
 
Default Refining the update queues/process

2010/3/3 Seth Vidal <skvidal@fedoraproject.org>:
>
>
> 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 gradually running down Fedora, e.g. by
>> advocating ever more regulations, installing more and more committees,
>> and by trying to suppress the community.

> Fantastic.
> You have a nice day.

And what about tickets, closed with "FIXED UPSTREAM" w/o actually
applying fix to a package?


--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org