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-07-2010, 11:49 AM
Thomas Janssen
 
Default Another great update

2010/3/7 Henrique Junior <henriquecsj@gmail.com>:
> From what I see, to educate our users to actually test and provide
> feedback is more laborious than educating our package maintainers. For
> maintainers, discussions such as those that have occurred serve to
> clarify, but I think in the case of users, it wouldn't be very painful
> to insert one more screen during the pos-installation asking if the user
> wants to test "bleeding edge" software (activating the updates-testing
> by default), something similar to what we already do with smolt,

Right, testing packages from updates-testing would be hard to explain
to new users. And it's not needed during installation..
But to convince more experienced users to do so we could add it to the
tour that's in early talking stage.

One possibility to teach even new users (and more experienced ones) to
do so would be a "class" in IRC. We have a classroom and it's used to
teach our users about various topics.

http://fedoraproject.org/wiki/Communicate/IRC/Classroom

Adding that to a tour trough fedora could bring in possible new testers.

CCing Ryan, if it's not at the talking points he can add it.

--
LG Thomas

Dubium sapientiae initium
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 02:40 PM
Peter Boy
 
Default Another great update

Am Sonntag, den 07.03.2010, 12:18 +0200 schrieb Debarshi Ray:
> > Others may be eager to test their software with 5.3, but can not spend
> > the time to make a system update to F12.
>
> All Koji builds are done using the same packages in the repository.
> eg., if Fedora has GCC x.y then GCC x.y is used to built the entire
> Fedora tree. Suddenly bumping a GCC version will cause a lot of builds
> to fail.

The 5.3 example was referring to php! There are different kinds of
updates which should be handled differently.

An update to some software may render the complete system useless - the
case of gcc. Others may have selective effects - the case of php (and
might be easily handled by a selective roll back).

The KDE update, which got the current discussion rolling, might be an
example of the former.

Instead of banning release updates completely (the convervative
approach) it might be advantageous, to use different strength /
different levels of testing (dwell time in testing repo, positive Karma,
etc).

> > You got the point. Therefore people are using Fedora and expect to get
> > newer software versions which may provide additional functions which may
> > come in handy, as soon as possible.
>
> Does 6 months not count as "as soon as possible"?

It depends. When e.g. OpenOffice releases a new version, I would be very
unhappy to have 6 months to wait. If a new kernel can handle my
broadband adapter I would be very unhappy to wait 6 months until I can
use it (milage of others will vary, but the same basic logic).


> Often "new and shiny" can mean "new bugs".

Of course! That's the other side of the coin (to be able to use new
functions, test the effects of a release to ones own development, not to
have to use an outdated (but very stable) software level as RHEL/CentOS,
etc).


> That is what makes Rawhide
> (or today's F13) what it is.

No! Rawhide affects the disto as a whole. Installation procedure may be
broken, hardware recognition, incompatible libs. Rawhide is not meant to
be stable all the time. A Fedora release is meant to be stable, but
sometimes something breaks as an accident, as a side effect of another,
partly rival goal (to provide a curent software level).



But to be honest, how often such an accident did occur over the last
years? You won't need more than one hand to count.

And how long did it take to resolve a problem? In most cases you had
just to wait a day.


Fedora is my day by day working instrument, and I am "happy with Fedora
as is"(tm)


Peter




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 02:47 PM
Toshio Kuratomi
 
Default Another great update

On Sun, Mar 07, 2010 at 01:32:42PM +0100, Michał Piotrowski wrote:
>
> I don't really care for desktop programs here. If you want to upgrade
> X.org or OpenOffice - I probably don't notice it. But if you plan to
> upgrade things like python, php - it can be a problem for me.
>
On the python side, we currently do not update python to a new major version
(like 2.6 to 2.7). Updates are maintainer dependent but the "language"
maintainers (interpreters, compilers, core libraries) have traditionally
been more conservative due to the number of packages that depend on them
that would need to be rebuilt and retested should the language be moved to
a new version.

python is about as important as C to Fedora since many of our desktop, GUI,
and supporting tools are written in it. So chances of it becoming less
conservative are small. However, be aware that Fedora does not *require*
backports so some of the libraries built on top of python may be updated to
incompatible versions if there is a severe enough reason (for instance
a security bug is only fixed in a newer, incompatible version of the
library).

One alternative that I have heard of that you might want to look into is
RHEL5 plus packages from iuscommunity.org. As I understand it, they are
trying to produce packages that you can install in parallel to the existing
versions of certain programs (like pyhton and php) on RHEL5. This gives you
a base os that's going to remain compatible for its long lifetime and the
ability to use newer versions of the components you care about.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 02:55 PM
Toshio Kuratomi
 
Default Another great update

On Sun, Mar 07, 2010 at 07:34:25AM -0500, Orcan Ogetbil wrote:
> On Sun, Mar 7, 2010 at 6:08 AM, Michael Schwendt wrote:
> > On Sat, 6 Mar 2010 20:47:40 -0500, Orcan wrote:
> >
> >> On Sat, Mar 6, 2010 at 8:20 PM, Rahul Sundaram wrote:
> >> > On 03/07/2010 06:47 AM, Orcan Ogetbil wrote:
> >> >>
> >> >> Again I say "updates-testing"! Leaving php-5.3 in testing on F-11 for
> >> >> a couple months will warn the users what is coming up and gives them
> >> >> plenty of time to adapt.
> >> >>
> >> >
> >> > If you have a large codebase two months is barely enough time to even
> >> > big evaluating a move
> >> >
> >>
> >> Then make it 3 months, 4 months... Leave it in testing forever if you
> >> get too many complaints. But make it available for those who want it.
> >
> > You want to force the dist users to consider updates-testing.
> > That isn't nice, and you won't be successful with such a strategy.
> >
>
> "it is nice." is what users say, not me. I am talking as someone who
> has been using this strategy for a long time now. And I claim to be
> successful. On the other hand you are claiming that someone who would
> do what I did will not be successful. Well, experience wins.
>
> So far (in the last 15 monnths or so) I have gotten many good comments
> and thanks by using this strategy. I got 0 (zero) complaints about a
> particular update that shouldn't go into a stable release. The only
> complaints I got were about a few packages that I didn't have time to
> update in stable releases. People wanted updates.
>
Just last night I ran into an issue with this model. Packages in
updates-testing aren't available to the buildroot by default. So when you
need a package in updates testing in order to build you need a buildroot
override. If you have a buildroot override, you no longer have the luxury
of leaving an update in updates-testing for as long as you think necessary;
you have to compromise with the schedule that the dependent package wants as
well. This is leaving aside the fact that our tools currently don't catch
packages being sent to updates before their dependencies arrive there --
that's hopefully something that will be caught by autoqa soon.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 03:02 PM
Orcan Ogetbil
 
Default Another great update

On Sun, Mar 7, 2010 at 10:55 AM, Toshio Kuratomi wrote:
> On Sun, Mar 07, 2010 at 07:34:25AM -0500, Orcan Ogetbil wrote:
>> On Sun, Mar 7, 2010 at 6:08 AM, Michael Schwendt wrote:
>> > On Sat, 6 Mar 2010 20:47:40 -0500, Orcan wrote:
>> >
>> >> On Sat, Mar 6, 2010 at 8:20 PM, Rahul Sundaram wrote:
>> >> > On 03/07/2010 06:47 AM, Orcan Ogetbil wrote:
>> >> >>
>> >> >> Again I say "updates-testing"! Leaving php-5.3 in testing on F-11 for
>> >> >> a couple months will warn the users what is coming up and gives them
>> >> >> plenty of time to adapt.
>> >> >>
>> >> >
>> >> > If you have a large codebase two months is barely enough time to even
>> >> > big evaluating a move
>> >> >
>> >>
>> >> Then make it 3 months, 4 months... Leave it in testing forever if you
>> >> get too many complaints. But make it available for those who want it.
>> >
>> > You want to force the dist users to consider updates-testing.
>> > That isn't nice, and you won't be successful with such a strategy.
>> >
>>
>> "it is nice." is what users say, not me. I am talking as someone who
>> has been using this strategy for a long time now. And I claim to be
>> successful. On the other hand you are claiming that someone who would
>> do what I did will not be successful. Well, experience wins.
>>
>> So far (in the last 15 monnths or so) I have gotten many good comments
>> and thanks by using this strategy. I got 0 (zero) complaints about a
>> particular update that shouldn't go into a stable release. The only
>> complaints I got were about a few packages that I didn't have time to
>> update in stable releases. People wanted updates.
>>
> Just last night I ran into an issue with this model. *Packages in
> updates-testing aren't available to the buildroot by default. *So when you
> need a package in updates testing in order to build you need a buildroot
> override. *If you have a buildroot override, you no longer have the luxury
> of leaving an update in updates-testing for as long as you think necessary;

From what I understand, this is not totally correct. You can ask for
removal from the buildroot override as soon as you are done building
your package. In fact, Releng explicitly asks us to tell them when we
are done so they can remove the override. (are we talking about the
same issue here?)

This is one part of my model which works but is not perfect. If this
can be automated, or a packager interface is written for overrides,
then we are in business.

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 03:03 PM
Michał Piotrowski
 
Default Another great update

2010/3/7 Toshio Kuratomi <a.badger@gmail.com>:
> One alternative that I have heard of that you might want to look into is
> RHEL5 plus packages from iuscommunity.org. *As I understand it, they are
> trying to produce packages that you can install in parallel to the existing
> versions of certain programs (like pyhton and php) on RHEL5. *This gives you
> a base os that's going to remain compatible for its long lifetime and the
> ability to use newer versions of the components you care about.

Looks very promising. But still I had to change/build many other
packages to fit CenOS5 to my needs.

I need to survive on F11 for some time. I hope it will not be a big
deal after all

>
> -Toshio
>

Regards,
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 03:15 PM
Toshio Kuratomi
 
Default Another great update

On Sun, Mar 07, 2010 at 12:03:57PM +0100, Michael Schwendt wrote:
> My reason to comment on those threads on devel list is really just that I
> want to retain the freedom to decide when my updates are ready to be
> released. I'm responsible for giving them adequate testing. Users
> expect the packager not to release broken crap. I don't want to wait for
> +N karma that previous updates haven't gotten either while new bugzilla
> tickets have shown that a problem *is* affecting N>1 users.
> If there are technical requirements for an update to make a temporary halt
> in updates-testing for a day, e.g. for scripts to be run (and mind you,
> repoclosure is run on updates-testing, too), fine. I can live with that.
> Just no silly rules, please, such as arbitrary "autoqa"-scripts getting
> veto powers to block updates, if perhaps rpmlint complains about a spec
> file. No experiments, please, just because some packagers are upgrade-mad.
>
+1

> > When version X of a software is supported in F-12, the same version X
> > can be supported most of the time in F-11. And if it can be supported,
> > it should be supported.
>
> "Can be supported" as in "if it builds, push it as an upgrade"?
> Wishful thinking. This is exactly why Fedora releases are _not_ supported
> for two years or more. Most package maintainers ought to focus on one
> dist release (at most two), as their daily usage only covers one dist,
> too. [The exception being those packagers who *really* run some software
> on multiple dist releases in the same way.]
>
One problem I'm finding here is that we've suddenly exploded the number of
releases we care about updating in the normal bugfix case. Currently, F-14,
F-13, and F-12. As you say, typical developers can really only test on one
of those because they're doing their daily work on only one. Rawhide has
traditionally had a lack of developers running it so we could say it's no
worse than normal. F-13, OTOH is being pushed as something for people to
actually run if they want a more adventurous update style. That means
developers who run F-13 won't be testing their updates to F-12 anymore and
developers running F-12 won't be testing their updates for the people
consuming F-13.... I think this is something we should be thinking about as
we push these discussions forward.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 03:33 PM
Toshio Kuratomi
 
Default Another great update

On Sun, Mar 07, 2010 at 11:02:46AM -0500, Orcan Ogetbil wrote:
> On Sun, Mar 7, 2010 at 10:55 AM, Toshio Kuratomi wrote:
> > On Sun, Mar 07, 2010 at 07:34:25AM -0500, Orcan Ogetbil wrote:
> >> On Sun, Mar 7, 2010 at 6:08 AM, Michael Schwendt wrote:
> >> > On Sat, 6 Mar 2010 20:47:40 -0500, Orcan wrote:
> >> >
> >> >> On Sat, Mar 6, 2010 at 8:20 PM, Rahul Sundaram wrote:
> >> >> > On 03/07/2010 06:47 AM, Orcan Ogetbil wrote:
> >> >> >>
> >> >> >> Again I say "updates-testing"! Leaving php-5.3 in testing on F-11 for
> >> >> >> a couple months will warn the users what is coming up and gives them
> >> >> >> plenty of time to adapt.
> >> >> >>
> >> >> >
> >> >> > If you have a large codebase two months is barely enough time to even
> >> >> > big evaluating a move
> >> >> >
> >> >>
> >> >> Then make it 3 months, 4 months... Leave it in testing forever if you
> >> >> get too many complaints. But make it available for those who want it.
> >> >
> >> > You want to force the dist users to consider updates-testing.
> >> > That isn't nice, and you won't be successful with such a strategy.
> >> >
> >>
> >> "it is nice." is what users say, not me. I am talking as someone who
> >> has been using this strategy for a long time now. And I claim to be
> >> successful. On the other hand you are claiming that someone who would
> >> do what I did will not be successful. Well, experience wins.
> >>
> >> So far (in the last 15 monnths or so) I have gotten many good comments
> >> and thanks by using this strategy. I got 0 (zero) complaints about a
> >> particular update that shouldn't go into a stable release. The only
> >> complaints I got were about a few packages that I didn't have time to
> >> update in stable releases. People wanted updates.
> >>
> > Just last night I ran into an issue with this model. *Packages in
> > updates-testing aren't available to the buildroot by default. *So when you
> > need a package in updates testing in order to build you need a buildroot
> > override. *If you have a buildroot override, you no longer have the luxury
> > of leaving an update in updates-testing for as long as you think necessary;
>
> From what I understand, this is not totally correct. You can ask for
> removal from the buildroot override as soon as you are done building
> your package.

This doesn't work either. If you do that, then the future package build
potentially won't run if you have updates-testing enabled (because the
library in updates-testing won't run with the program that was compiled
against the stable update.)

> In fact, Releng explicitly asks us to tell them when we
> are done so they can remove the override. (are we talking about the
> same issue here?)
>
I can't find the wiki page documenting buildroot overrides so I can't
confirm this. I thought that releng was asking for the overrides to be
removed when the package was pushed to stable but I could be wrong.

> This is one part of my model which works but is not perfect. If this
> can be automated, or a packager interface is written for overrides,
> then we are in business.

If the idea is that every packager that has a dependent package is supposed
to turn the override on or off depending on whether they anticipate their
package going to stable before or after the library they're compiling
against we'll need some tools, not just to make submission easier, but also
to inform packagers (before they build) that they must make a choice about
what libraries they want to compile against in updates-testing.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 05:51 PM
Denis Leroy
 
Default Another great update

On 03/07/2010 02:42 AM, Jonathan Underwood wrote:
> On 6 March 2010 17:00, Christoph Wickert
> <christoph.wickert@googlemail.com> wrote:
>> While we are at it, here is another great update:
>> https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326
>>
>> * New version introduced in F11.
>> * Doesn't fix any bugs but it's an enhancement only.
>> * Useless update description "update to 4.7.1".
>> * And *of course* it was pushed directly to stable, even in F-13.
>>
>> Dear maintainers, please stop this!
>
> What broke for you in this update?

Whether it's backward compatible or not, or did break something or not,
is irrelevant.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-07-2010, 06:11 PM
Ville Skytt
 
Default Another great update

On Sunday 07 March 2010, Panu Matilainen wrote:
> I've been refraining from commenting on these update-threads but as it
> seems folks have started actually counting the pro semi-rolling vs
> conservative updates style replies... for the record:
>
> On Sun, 7 Mar 2010, Kalev Lember wrote:
> > I'd personally want to be able to _choose_ if and when I want to get all
> > the new stuff. If I have time, I upgrade to new Fedora release and
> > happily deal with all the problems that come up. This is exactly what
> > new distro releases are for -- people prepare for the upgrade and take
> > time to do it.
>
> Amen to this.

Mine as well, ditto to the rest in Panu's message.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 08:49 AM.

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