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, 04:49 PM
Bill Nottingham
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Adam Williamson (awilliam@redhat.com) said:
> On Tue, 2010-03-02 at 17:52 -0800, Jesse Keating wrote:
> > On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
> > > But the problem is what to do if the testing ALREADY failed. Then the best
> > > strategy is to fix the problem ASAP, bypassing testing this time, to get the
> > > regression out of the way.
> >
> > So testing failed, ergo the best way to fix it is to bypass the testing
> > all together? Really?
>
> Don't worry, Muttley! I'm sure we've nailed it THIS time! What could
> possibly go wrong?

Yes, because having things like http://rhn.redhat.com/errata/RHSA-1999-052.html
always provides a better experience for your users.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 04:59 PM
Kevin Kofler
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

James Antill wrote:

> On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
>> People who use updates-testing under the current system are signing up to
>> doing testing. Under your proposal, they'd be forced to sign up to get
>> any current updates.
>
> Get current updates => so they can be tested!

But what if I want already tested (for a reasonable period, like 1-2 weeks,
not months!) current updates? I am not alone in that!

>> No, because updates may depend on previous updates to work properly. We
>> can't possibly test or support all possible combinations of updates.
>
> We can't _now_ ... because of packagers like you who want to release
> lots of updates with no or almost no testing!
> If we had less updates, that changed less things and required more
> testing before pushing them to users ... this would be entirely
> possible.

No. For n updates, there are 2^n possible combinations, even with critical
security updates alone, this would not scale.

RHL update announcements used to include this notice:
| Before applying this update, make sure all previously released errata
| relevant to your system have been applied.
IMHO we should add the same disclaimer to Fedora update announcements. The
same reasons which were valid back then still are.

> No, there's suffering because you are breaking their computers with
> your updates (which has been pointed out to you many times in this
> thread).

Nonsense. The bugs being fixed by new KDE releases are often bugs which have
been there all the time, not caused by an update.

> No, I for one will not be just enabling updates-testing if my proposal
> is passed. Again, I imagine that the major of users will not do this ...
> and will be happier to have a smaller number of tested updates.

I think you're illuding yourself. Mainly because updates under your proposal
would not just be "tested", but "arbitrarily delayed to penalize frequently-
updated packages". That has nothing to do with testing at all.

The time required to test an update does NOT depend on previous updates
having been issued for the same package! It is only a function of the
changes in THAT PARTICULAR update.

> You are _forcing_ people to use updates-testing because there is
> nothing else ... things can't be tested by the time they hit "updates",
> so updates is de. facto. "updates-testing".

This is complete and utter nonsense. Updates ARE being tested in updates-
testing. (In fact that's why some people want to ban direct stable pushes,
they want to make sure everything gets testing.) And you still don't justify
why the second update to a package would need more testing than the first
one etc., this makes absolutely no sense to me.

>> They're not testing it, they're receiving it already tested.
>
> Except that it breaks ... but of course that's their problem, not
> yours ... right?

What breaks?

> I think I'm starting to see a pattern here:
>
> . Kevin doesn't use DVD updates, so anything that needlessly breaks DVD
> updates is fine because DVD updates are worthless.

Wrong. DVD updates are broken by design. It's impossible to support them in
its current state and it's unreasonable to expect Fedora to radically change
(we couldn't even do version bumps to fix security issues anymore!) to
accomodate this usecase. The proper solution is to fix Anaconda to include
the updates repository for upgrades. That I happen not to use this broken
feature is entirely irrelevant.

> . Kevin doesn't use selective updates, so packagers doing less work and
> not testing for selective updates is fine because selective updates are
> worthless.

Wrong. Selective updates are broken by design. It's impossible to support
them because the exponential amount of testing will never be achievable,
even if Fedora were to radically minimize its updates. They will always be
something that "may or may not work" and is not recommended. That I happen
not to use this broken feature is entirely irrelevant.

> . Kevin doesn't use --security, so packagers ignoring security issues is
> fine because --security is worthless.

Wrong. --security is broken by design. It's impossible to support it because
it is just a special case of selective updates above. There are also other
technical issues with it (like upgrades which happen to fix security issues,
but this is discovered or announced only after they already got pushed as
non-security). That I happen not to use this broken feature is entirely
irrelevant.

> . Kevin doesn't mind restarting KDE after updates, so any users
> complaining their desktop doesn't work after an update can be ignored.

Wrong. KDE upstream requires restarting KDE after upgrading, there is
nothing Fedora can do about it, and not pushing any KDE bugfixes just to
prevent this minor inconvenience would be a disservice to many more users.
For the vast majority of our users, restarting KDE is not a big deal at all
(in fact I don't remember having received more than that one single
complaint about it, out of thousands of users). That I happen not to mind
this personally is entirely irrelevant.

> . Kevin likes lots of updates, and having them forced onto others so
> they get tested for him, so anything that provides more updates is good
> and anything that slows them down for testing is bad.

Wrong. That "having them forced onto others so they get tested for him" part
is complete nonsense. I update very often, so other users of the stable
updates are NOT testing things for me, they're getting them no sooner than I
do. Sure, users of updates-testing are testing things for me and many other
people, but that's what they voluntarily signed up to, so I fail to see the
problem.

And the really bad thing about your proposal is that it does NOT slow down
the updates *for testing*, but for very long periods of time which have
nothing to do with testing anymore. In particular, the second, third etc.
update to a package requires no more testing time than the first. (This is
the major flaw in your proposal, yet you see this as an essential feature
and fail to realize it doesn't make sense.)

> ...if only someone had let me know that Fedora had become your personal
> distro.

It's not. I just don't see why I should be expected to support things that
don't work and can't work.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 10:14 PM
Michael Schwendt
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:

> Extras had significantly fewer packages,

Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
than F11 stable updates.

http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html

> no multilib,

Just want to correct you here as "no multilib" isn't true. It implemented
a whitelist, a blacklist and a multiarch depsolver, but it was decided to
turn on full *-devel multiarch pushing no earlier than during Fedora 7
development. Previously (up to and including Fedora Extras 6), only some
packages (like "wine") were pulled in via the whitelist.

> no deltarpms, no update metadata,

These two features predate the Fedora Extras era. The post-Fedora Extras
pushscripts have been enhanced to create deltarpms
( http://download1.rpmfusion.org/free/fedora/updates/11/i386/drpms/ )
including basic repo inheritance.

> fewer arches

i386, x86_64 and ppc

> and was ran on different hardware.

It's an apples vs. oranges comparison anyway.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 12:11 AM
James Antill
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
>
> > Extras had significantly fewer packages,
>
> Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
> than F11 stable updates.
>
> http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html

*sigh*, I almost managed to not respond to any of these threads today.
Anyway (trying to say just the facts):

% yum repolist --releasever=11 updates
repo id repo name status
updates Fedora 11 - x86_64 - Updates 9,390
repolist: 9,390

...and it's only ~65% done. That also doesn't take into account the fact
that we've released ~17k F11 updates, which I'm pretty sure didn't
happen for F6 extras.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 01:30 AM
Jesse Keating
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
> On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
> >
> > > Extras had significantly fewer packages,
> >
> > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
> > than F11 stable updates.
> >
> > http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html
>
> *sigh*, I almost managed to not respond to any of these threads today.
> Anyway (trying to say just the facts):
>
> % yum repolist --releasever=11 updates
> repo id repo name status
> updates Fedora 11 - x86_64 - Updates 9,390
> repolist: 9,390
>
> ...and it's only ~65% done. That also doesn't take into account the fact
> that we've released ~17k F11 updates, which I'm pretty sure didn't
> happen for F6 extras.
>

This probably won't go well unless you two are talking about the right
terms. I believe that Michael was talking srpm numbers, where you
appear to be talking binary numbers. Those are obviously not going to
match up.

--
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-05-2010, 06:41 AM
James Antill
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Thu, 2010-03-04 at 18:30 -0800, Jesse Keating wrote:
> On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
> > On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
> > > than F11 stable updates.
> > >
> > > http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html
> >
> > % yum repolist --releasever=11 updates
> > repo id repo name status
> > updates Fedora 11 - x86_64 - Updates 9,390
...
> This probably won't go well unless you two are talking about the right
> terms. I believe that Michael was talking srpm numbers, where you
> appear to be talking binary numbers.

The Michael gave was for binary packages in FC 6 x86_64 extras:

% GET http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/ |
fgrep '.rpm' |
wc -l
5129

...maybe he thought that was srpms though.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 07:27 AM
Michael Schwendt
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Thu, 04 Mar 2010 20:11:47 -0500, James wrote:

> On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
> >
> > > Extras had significantly fewer packages,
> >
> > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
> > than F11 stable updates.
> >
> > http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html
>
> *sigh*

No need to do that.

> I almost managed to not respond to any of these threads today.
> Anyway (trying to say just the facts):
>
> % yum repolist --releasever=11 updates
> repo id repo name status
> updates Fedora 11 - x86_64 - Updates 9,390
> repolist: 9,390

So what? That's not twice as much as FE6, which would not have taken
several hours to push into such a repo. Not even when running repoclosure
on the needsign repo prior to pushing and when updating repoview pages
afterwards. Simply because the code that was used worked very differently
than "mash".

> ...and it's only ~65% done. That also doesn't take into account the fact
> that we've released ~17k F11 updates, which I'm pretty sure didn't
> happen for F6 extras.

What are you trying to point out? Not everything is better or more convenient
with the current push/compose infrastructure.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 07:28 AM
Michael Schwendt
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Fri, 05 Mar 2010 02:41:46 -0500, James wrote:

> > > % yum repolist --releasever=11 updates
> > > repo id repo name status
> > > updates Fedora 11 - x86_64 - Updates 9,390
> ...
> > This probably won't go well unless you two are talking about the right
> > terms. I believe that Michael was talking srpm numbers, where you
> > appear to be talking binary numbers.
>
> The Michael gave was for binary packages in FC 6 x86_64 extras:
>
> % GET http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/ |
> fgrep '.rpm' |
> wc -l
> 5129
>
> ...maybe he thought that was srpms though.

No, I compared that number to those displayed in bodhi, assuming they
would be the updates count instead of the tickets count. What is being
displayed in bodhi is inconsistent and misleading, as it says "3 pending"
for EPEL 4 in one place, but "7 pending" in another place. I just didn't
want to compare with F12 updates, which has a much lower package count
than FE6. Or F13, which is one arch less than FE6.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:33 AM.

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