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 02-27-2010, 09:15 PM
Josh Stone
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On 02/27/2010 02:05 PM, Orcan Ogetbil wrote:
> About F-11, F-12, F-13: yeah, pretty much. They should all contain the
> same stable version of most software.

Then why have numbered Fedora releases at all? Just so we can bump the
wallpaper every once in a while?

Josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-28-2010, 09:43 AM
Nicolas Mailhot
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Le vendredi 26 février 2010 à 21:17 +0100, Hans de Goede a écrit :

> When I started working for Red Hat everyone told me that the most important
> thing is that working for Red Hat should be fun, which I completely agree with.
>
> I seriously believe we should also make that an explicit goal for Fedora:
> contributing to Fedora should be fun. And FESco should seriously consider the
> impact on how much fun contributing to Fedora is, for each new rule they think
> they must introduce.

I completely agree here. That has been my goal since the fonts SIG was
started: make it easier for packagers to produce good font packages and
try to stamp down anything that experience showed made packagers
miserable.

I don't subscribe to "if they are not visibly suffering, they're not
trying hard enough" or "packagers should push perfect packages, even if
it means jumping through countless hoops because tools are not ready"
schools of thought.

There are things only packagers can fix. Everything else should be
handled by tools so packagers can focus on the parts where they add real
value. If a process change puts more burden on all packagers because
it's easier to ask packagers to do stuff than fix tools, it's a bad
process change. And yes I accept than in some cases not burdening
packagers means increasing the chance for some problems. Perfection is
the ennemy of good.

--
Nicolas Mailhot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-28-2010, 03:24 PM
Adam Williamson
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On Sun, 2010-02-28 at 11:43 +0100, Nicolas Mailhot wrote:

> There are things only packagers can fix. Everything else should be
> handled by tools so packagers can focus on the parts where they add real
> value. If a process change puts more burden on all packagers because
> it's easier to ask packagers to do stuff than fix tools, it's a bad
> process change. And yes I accept than in some cases not burdening
> packagers means increasing the chance for some problems. Perfection is
> the ennemy of good.

This is a wonderful sentiment. How does it apply to the current
situation, exactly? What 'tools' is it you're saying are not fixed?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

(Sorry, I reordered the replies a bit so I can reply to them without
referring back and forth.)

Frank Murphy wrote:
> On 02/27/2010 04:30 PM, Mail Lists wrote:
> an
>>
>> I do want updates. Kernel updates, for example, are very important -
>> they carry many improvements - not just drivers but functionality as
>> well. The ones that are less obvious are the bugs that happen rarely but
>> that can be nasty (an occasional file system glitch for example).
>>
>
> As as enduser.
> I would agree with this.

So you claim to agree with the parent poster…

>> These kind of non-user-demand driven fixes should not be ignored in any
>> noone-is-asking so dont release approach.
>
> If it's not broken, don't fix it.

… yet you actually don't, and…

>> The rare-but-nasty bug fixes will seldom have user demand - but
>> nonetheless once identified and fixed should be shared.
>
> Bug fixes would also be applied.

… so which is it now? Do you now think bugfixes which don't fix a bug in our
Bugzilla should be pushed or not? FWIW, I think they should indeed be
pushed, as the fact that the bug is not in our Bugzilla does not mean it
doesn't affect Fedora users (and so the package IS in fact broken and should
be fixed)!


And in addition:

> On the everyday boxes there is FedoraN + F13Rawhide Kernel(s).

… so the stable Fedora kernels aren't upgraded often enough for you, but …

> If it's not broken, don't fix it.
>
> Thats what the F13/Rawhide boxes are for.

… you seem to advocate an even more conservative upgrade policy?


I must say I don't understand your position at all.

Kevin Kofler

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

Adam Williamson wrote:
> It seems like extra work for packagers, but in the end it kinda takes the
> pressure off: you only *have* to ship the important fixes to /updates,
> /backports is optional,

That's already a bad thing, users can no longer expect anything, it depends
on the maintainer being willing to do a backport. Now I know our current
policy isn't any better, but that's why I think we should more strongly
encourage upgrades to stable releases. Yet, in practice, I still think a lot
more stuff gets backported in our updates repository than in those backports
repositories of other distros. Also because the maintainers don't have to
worry about a conservative updates stream at the same time. Having both,
we'd have to fix bugs in the conservative updates AND push backports. Of
course that'd tempt maintainers to just skip the backports step. Whereas our
policy is to prefer resolving issues by pushing new upstream releases (it's
even our default policy for security updates, unlike RHEL which defaults to
backporting), so we just do the backports as stable updates and that way
also resolve the bugs at the same time (including bugs which upstream fixed
and which didn't have a Fedora bug report in the first place, but still
affected Fedora users). Upgrading basically gives us the bugfixes "for free"
(in fact I usually just need to copy the specfile from devel to F-13, F-12
and F-11 and build for all).

> and /backports users are good about knowing that sometimes what they find
> there will be broken or have new bugs or whatever, and tend to know the
> drill about not getting too upset and reporting them to you to be fixed.

That also sucks. With Fedora's KDE updates, users can be sure that they'll
be as regression-free as humanely possible and we do all we can to keep
their updates stable. On the other hand, users of distros using the
backports model just get told "backports are unsupported". In fact their
builds of new KDE releases tend to carry only the same old distro patches as
the old version or even to be entirely vanilla, very little is done to e.g.
backport regression fixes from the branch. And KDE is just the example I'm
most familiar with, I'm pretty sure it's similar with other stuff that gets
updated in our stable updates vs. other distros' backports repositories.

Another big issue is that people will be drawn to selectively picking only
some stuff from the backports repository while staying with the official
updates for other stuff, leading to an untestable combinatorial explosion of
possible update combinations. (Now I know people can also selectively update
from our updates, but if things break, I can just tell them that selective
updates are not supported and that they should run "yum update" and come
back if their problem still happens after that.)

> And they know they can easily fall back to what's in /updates if they find
> /backports to be broken; it gives them an escape route.

That's the only advantage of that model, I'm not sure it's worth the
drawbacks.

Kevin Kofler

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

Ralf Corsepius wrote:
> * bugs being closed as "FIXED UPSTREAM/FIXED RAWHIDE" - This kind of
> "resolution" means a bug is not being fixed in the distro. It means the
> maintainer is refusing to fix a bug a reporter is facing. Reporters will
> learn their lessons and leave this kind of maintainers alone.
> Less patient reporters will leave Fedora alone.

I'll note that "fixed upstream" is a valid reason to consider an issue
resolved if the upstream release is going to be pushed within a few days
anyway (like KDE's monthly bugfix releases).

But of course, just saying it's fixed upstream and not pushing the new
upstream release nor a backport of the fix is not helpful (and neither is
fixing bugs only in Rawhide), you're very much right there.

Kevin Kofler

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

Kevin Kofler said the following on 02/28/2010 03:41 PM Pacific Time:
> Till Maas wrote:
>> My proposal: If it passes all AutoQA tests and matches the criteria by
>> Kevin Koffler[0], then the update is ok, except that critical path
>> packages should be inspected more carefully.
>>
>> [0]
>> [http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html
>
> I think I've written more complete writeups in earlier mailing list posts,
> it may make sense to dig them up.
>

It would make more sense to end the madness that is this mail thread and
start a wiki page that clearly outlines your position. You lost me about
200 posts ago.

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

On Sun, 2010-02-28 at 21:30 -0800, John Poelstra wrote:
> Kevin Kofler said the following on 02/28/2010 03:41 PM Pacific Time:
> > Till Maas wrote:
> >> My proposal: If it passes all AutoQA tests and matches the criteria by
> >> Kevin Koffler[0], then the update is ok, except that critical path
> >> packages should be inspected more carefully.
> >>
> >> [0]
> >> [http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html
> >
> > I think I've written more complete writeups in earlier mailing list posts,
> > it may make sense to dig them up.
> >
>
> It would make more sense to end the madness that is this mail thread and
> start a wiki page that clearly outlines your position. You lost me about
> 200 posts ago.

+1

One thing I would suggest being considered in an alternative proposal is
a compromise policy for specific stacks or non-critical path packages.
For example, if the standard policy affecting me as a GNOME user is that
major changes will be confined to new releases (my very strong personal
preference) then I don't personally much care if it is official policy
that KDE is allowed an exception to rebase on some other schedule.

Jon.


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

On 01/03/10 00:06, Kevin Kofler wrote:
> (Sorry, I reordered the replies a bit so I can reply to them without
> referring back and forth.)

It's also called "political licence"

>
> Frank Murphy wrote:
>> On 02/27/2010 04:30 PM, Mail Lists wrote:
>> an
>>>
1:

>>> I do want updates. Kernel updates, for example, are very important -
>>> they carry many improvements - not just drivers but functionality as
>>> well. The ones that are less obvious are the bugs that happen rarely but
>>> that can be nasty (an occasional file system glitch for example).
>>>
>>
>> As as enduser.
>> I would agree with this.
>
> So you claim to agree with the parent poster…

If you mean these points from "Mail Lists" then yes.

>
>>> These kind of non-user-demand driven fixes should not be ignored in any
>>> noone-is-asking so dont release approach.
>>
>> If it's not broken, don't fix it.
>
> … yet you actually don't, and…
>
>>> The rare-but-nasty bug fixes will seldom have user demand - but
>>> nonetheless once identified and fixed should be shared.
>>
>> Bug fixes would also be applied.
>
> … so which is it now? Do you now think bugfixes which don't fix a bug in our
> Bugzilla should be pushed or not?

The whyhow is it a bug?
Who decided?
Handshake?
If it's a bug and you (generic) know about it,
please refrence it in bugzilla,
even if only providing a link to upstream BugzillaSimilar


FWIW, I think they should indeed be
> pushed, as the fact that the bug is not in our Bugzilla does not mean it
> doesn't affect Fedora users (and so the package IS in fact broken and should
> be fixed)!
>

Thats what Bugzilla is for.
If people so not report bugs,
they should be educated to do so.
Whether userdevpackager etc..
No one is a mind reader.

>
> And in addition:
>
>> On the everyday boxes there is FedoraN + F13Rawhide Kernel(s).
>
> … so the stable Fedora kernels aren't upgraded often enough for you, but …

As "1" above. (fixes things for me)
I do report bugs.

I also read Koji notes.
But it's not a repo.

>
>> If it's not broken, don't fix it.
>>
>> Thats what the F13/Rawhide boxes are for.
>
> … you seem to advocate an even more conservative upgrade policy?

Semantics.
You want embellishment go Rawhide.
otherwise stick with SecurityBugs as updates.

>
>
> I must say I don't understand your position at all.
>
> Kevin Kofler
>

It's still the same.
SecurityBugfixes(BZ'ed ones).
So there is a refrence point.

--
Regards,

Frank Murphy
UTF_8 Encoded
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 09:47 AM
Kevin Kofler
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Jon Masters wrote:
> One thing I would suggest being considered in an alternative proposal is
> a compromise policy for specific stacks or non-critical path packages.
> For example, if the standard policy affecting me as a GNOME user is that
> major changes will be confined to new releases (my very strong personal
> preference) then I don't personally much care if it is official policy
> that KDE is allowed an exception to rebase on some other schedule.

Well, IMHO GNOME should get the same treatment KDE is already getting, but I
don't care all that much about GNOME, so I could probably agree to such a
compromise.

Still, don't you want to run an actually maintained GNOME where bugs are
still being fixed rather than being stuck with them forever? Does GNOME
continue releasing bugfixes for the old branch after the new release? (KDE
definitely doesn't.)

But this has absolutely nothing to do with direct stable pushes anymore!

Kevin Kofler

--
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:52 AM.

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