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-26-2010, 01:07 PM
Kevin Kofler
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Ralf Corsepius wrote:
> * Many (most) packages get pushed without testing. I consider people who
> believe package to see tested in "testing", to be in error.
> To me, "testing" isn't much more but a delay queue.

Good point.

> * Some maintainers ignore feedback on "packages in testing".

Indeed, and the proposed policy would do absolutely nothing to stop that!

> * Some packages will never be "100% stable" (e.g. the kernel, gcc, kde).

Right, and especially for those, being able to rush out a regression fix
without delays is important!

> * The bugs with the highest visibilty are packages adding broken package
> dependencies. The fact these make it into the repos is a defect of
> Fedora's infrastructure.

In fact the fact they happen at all is often due to infrastructure/procedure
issues, e.g. buildroot overrides are a mess. (Rel-eng now recommends using
special build tags for the big updates, we'll see whether that'll help for
KDE or just cause more chaos.)

But yes, the lack of automatic depchecking is also a big source of trouble.

> * Banning direct pushes does not prevent Fedora from being hit by bad SW.

+1

> I think this FESCO is heading the wrong way.
>
> The real problem is not "broken updates", the problem is "badly
> maintained packages", "careless maintainers", "overzealous developerss"
> and defects of Fedora's infrastructure.

Indeed. This is a social problem (and yes, the lack of automated QA is also
an issue, but people are the main factor), it needs a social solution, not a
technobureaucratic one!

> Particularly delicate are cases when "upstream" and "maintainer" are
> identical.

Well, I'm not sure this is a big factor in this particular case. The
conflict of interest is more apparent in other situations, e.g. good luck
getting a broken upstream default fixed if upstream is also the Fedora
packager. (See e.g. spatial Nautilus, for which it took years for the
maintainer to realize it sucks, it's now finally getting disabled by default
in F13 according to the GNOME 2.30 feature page.)

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 07:17 PM
Hans de Goede
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Hi,

<speaking with my Red Hat firmly off here, just speaking as the good
old Fedora contributor from back before I was hired by RH>

> at the FESCo meeting on Tuesday, everyone except me seemed to be set on
> wanting to disable the possibility to queue updates directly to stable in
> Bodhi. The only reason this was not decided right there (with no outside
> feedback) is that Matthew Garrett (mjg59) wants to write down a precise
> policy (which may end up even more restrictive, like some arbitrary minimum
> time period of testing).
>

As I understand things from other posts this may be exaggerating a bit, still
I'll respond assuming for now that there are some plans to make it harder
to do direct pushes to stable.

As someone who still maintains circa 200 packages in his spare time (of which
I have a lot less now a days). I'm very much against this. Fedora carries I don't
know how many thousands of packages, and one size does not fit all. Which AFAIK
the whole new critical path package special handling ideas are for.

So lets expand that and also make a "part of default install" group which also
has some additional requirements for pushing to stable.

But amongst those thousands of packages there are a lot which have only
a small amount of users. Requiring maintainers to actively go out and find
multiple of those users and then get them to test it and provide feedback,
to get an updated pushed, is asking too much of the maintainer.

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.

Regards,

Hans

p.s.

With the risk of sort of invoking Godwins law, I would like to point out to
FESco that collective punishment is forbidden under the Geneva convention,
and has been declared as unlawful in several cases for the European court
for human rights. What is the relevance? Well tightening up bodhi pushing
rules because a hand full of maintainers is not handling there responsibilities
feels like a collective punishment to me. I think if FESco wants to do
something about to quick updates pushing by *some* maintainers, it should
come up with a solution which only targets specific maintainers.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-27-2010, 02:42 AM
Orion Poplawski
 
Default FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

On 2/26/2010 5:36 PM, Kevin Kofler wrote:
> Mike McGrath wrote:
>
>> Just so you can't ever use this argument again. I want fewer updates and
>> I'm a Fedora user.
>>
> IMHO you're really using the wrong distro. ;-)
>
> My point is that there are plenty of users who want the current updates or
> even more updates. And whereas the people like you have plenty of other
> choices, those users have very few choices, Fedora is the main one. See e.g.
> the strongly positive feedback we got from some users for our KDE 4.4.0
> update (and I'm sure there are many more happy users who just don't bother
> sending a "Thanks, you rule!" type mail).
>
I used to want more KDE updates, now I want fewer (be careful what you
wish for - you might get it). I use Fedora because it is a rapidly
moving distro and has good support to modern hardware because of that.
I also strongly agree with its principles of pure open source, openness
to volunteers, and close working with upstream. But as an administrator
of a couple dozen different hardware platforms running Fedora, testing
major updates every 6 months is work enough. Now I have to deal with it
constantly. I would happily wait until F13 for KDE 4.4.0. I certainly
can't see the need for it to appear in F11 (isn't the fact that someone
hasn't bothered upgrading to F12 indication that they are looking for a
little stability?). Even if things are "better:, it is disruptive
because my users have to deal with changing behavior on someone else's
schedule and I have to explain it to them.

I voted for you for FESCO because I thought having a KDE person on the
board would be helpful. Now I really regret it because you seem to have
no skills for actually promoting cooperation and understanding between
different groups of people.

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

On 2/26/2010 3:06 PM, Kevin Kofler wrote:
> Richard Zidlicky wrote:
>
>> lots of people. Some want to review changes manually and udpate only
>> "important" things,
>>
>> Others don not have gigabit internet access all around the clock. I am
>> trying to update my Netbook over a mobile connection as I write this.
>>
> Those people should use a more conservative distribution. Try CentOS maybe.
> Frequent updates are an integral part of the Fedora experience.
>
There is plenty of room for something in between your vision of Fedora
and CentOS. I strongly disagree that frequent updates are an integral
part of the Fedora experience.

- Orion Poplawski

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

Orion Poplawski wrote:
> I certainly can't see the need for it to appear in F11 (isn't the fact
> that someone hasn't bothered upgrading to F12 indication that they are
> looking for a little stability?).

We're evaluating the option of not doing the updates for the oldstable [1]
releases. We can see the rationale:
* people who haven't upgraded to the current stable might indeed also not
want a newer KDE,
* updates for the oldstable release also tend to get much fewer testing,
* people can always upgrade to the current stable release to get the current
KDE,
* it limits the big KDE upgrades to 1/release instead of 2/release as now,
but it also has drawbacks:
* it means we have to maintain 2 separate KDE sets, or even 3 when we import
prereleases of the next KDE into Rawhide, instead of the current 1 or 2,
* there's the issue of bugfixes:
- not all bugfixes are backported to the stable branch upstream, sometimes
they can't be backported upstream because they require e.g. a new Qt,
because they add translatable strings or for whatever reason,
- upstream stops releasing 4.n.x bugfix releases as they release 4.n+1.0,
=> therefore, upgrading to 4.n+1 is the easiest way, and sometimes the
only practical one, to get those bugfixes. We'd be stuck with either
bugs no longer getting fixed or us having to massively backport
bugfixes, which I'm not convinced we have the manpower for (I don't
think any distro has, really; those distros which don't do upgrades
backport only select few bugfixes, sometimes only security fixes). The
question is: is this a price we want to pay? I always feel bad for
leaving issues unsolved, but of course introducing new issues is also
not a nice thing to do. ;-)
Personally, I'm not convinced that not upgrading is a good idea (e.g. I used
F9 until EOL and 4.2 was really great there, then I went to F10 and used
that until its EOL with 4.3 and that also worked great), but this option IS
being evaluated in KDE SIG.

[1] Yes, I'm stealing Debian terminology here. ;-)

Kevin Kofler

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

Orion Poplawski wrote:
> There is plenty of room for something in between your vision of Fedora
> and CentOS.

But that room is filled by other distros, such as Ubuntu. Why do we need to
be another Ubuntu?

Kevin Kofler

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

Oh, and by the way:

Orion Poplawski wrote:
> There is plenty of room for something in between your vision of Fedora
> and CentOS.

There is plenty of room for something in between your vision of Fedora
and Rawhide. :-)

Kevin Kofler

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

On Fri, Feb 26, 2010 at 08:45:11PM -0700, Orion Poplawski wrote:
> >>
> > Those people should use a more conservative distribution. Try CentOS maybe.
> > Frequent updates are an integral part of the Fedora experience.
> >
> There is plenty of room for something in between your vision of Fedora
> and CentOS. I strongly disagree that frequent updates are an integral
> part of the Fedora experience.

I don't think that the point here is the stability of the distribution.
I am very in favor of a stable distro, and on that point, I think that
I side more with you than with Kevin K. But, in my opinion, having a
policy that renders pushing to stable harder is not a good move, at least
for many packages, since for those packages there is no real test
done in updates-testing, and they are specialized packages so that
there little chance of attracting more testers.

Having such a policy for critical packages or packages with a large
user base, and so a large number of testers, why not, but I don't think
that it should be a general policy. At least I know that for the packages
I maintained (and you now maintain a fair share of those packages ;-),
such a policy would have been very unproductive.

In fact, I think that I would be in favor of selecting a set of important
packages that would have specific procedures for update, but not for all
fedora packages. Good candidates would be rpm, kernel, yum, hal, X,
gnome libraries, gtk, kde libraries for the packages that are critical.
openoffice, firefox, the gnome and kde desktops, fluxbox would certainly
qualify as huge userbase software that may also have more requirements
on updates testing since they are likely to attract users. But definitly
not the packages with low userbase (for example, most of the scientific
related packages, dockapps, xdm...).

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

On 02/27/2010 02:08 AM, Kevin Kofler wrote:
> Matthew Garrett wrote:
>> At the point where you have a reported bug, you have a tester.
>
> Not necessarily. Sadly, there are people who report bugs and then don't read
> their bugmail, ever. :-(

Also does not apply to

* sporadic bugs.

* non-deterministic bugs (c.f. pulseaudio)

* bugs caused by cross-effects of other packages (c.f. dbus,
kernel-bugs' impact on applications)

* users, who start to modify their use-case, because they desparately
are searching for an escape (c.f. dnssec-conf)
=> No easy reproducer/tester, anymore.

* 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.

* maintainers not responding in timely manners. In this case a system's
setup (e.g. set of installed packages) might have changed sufficiently a
reporter is not able to reproduce a bug. In extreme cases, the reporter
might not even recall a report he issued.



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

On 02/27/2010 03:13 AM, Orcan Ogetbil wrote:
> On Sat, Feb 27, 2010 at 12:52 AM, James Antill wrote:
>> On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
>>> My point is that there are plenty of users who want the current updates or
>>> even more updates.
>>
>> "Citation needed"
>>
>
> Just a few out of so many:
> https://bugzilla.redhat.com/show_bug.cgi?id=529433
> https://bugzilla.redhat.com/show_bug.cgi?id=562645
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=1066
> https://bugzilla.redhat.com/show_bug.cgi?id=457480
> http://ccrma-mail.stanford.edu/pipermail/planetccrma/2010-January/016353.html
>
> Orcan


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).

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

These kind of non-user-demand driven fixes should not be ignored in any
noone-is-asking so dont release approach.


[speaking of which where on earth is 2.6.32.9 ????]


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:34 AM.

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