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, 06:40 PM
Michael Schwendt
 
Default Another great update

On Sun, 7 Mar 2010 11:02:46 -0500, Orcan wrote:

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

That's inconvenient and limiting. You can only work on your test updates
when the buildroot override is still active. In case you need to fix the
test updates, you depend on the buildroot override again. The entire
koji buildroot override business is just poor man's means to prevent
upgrade-mad packagers from introducing incompatible builds whenever
they like.

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

Not for overrides, though, but for custom buildroots that would be
independent from the primary dist buildroot. An interface to let
packagers activate such buildroots, and releng to control whether
to merge the new builds done in those buildroots with the primary
dist.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 07:51 AM
Jaroslav Reznik
 
Default Another great update

On Saturday 06 March 2010 19:38:16 Michał Piotrowski wrote:
> 2010/3/6 Naheem Zaffar <naheemzaffar@gmail.com>:
> > 2010/3/6 Michał Piotrowski <mkkp4x4@gmail.com>
> >
> >> Why I can install KDE 4.4 in F11 and I can't install latest gnome?
> >> (I'm just asking because I'm curious, not because I use Linux on
> >> desktop)
> >
> > I think for many people the issue is not that it can be an update (maybe
> > the enhancements etc are useful to someone).
> >
> > As an end user, I would think there should be asafety precaution on non
> > urgent updates to go through updates-testing.
> >
> > FTR, I DO like and want feature updates.
> >
> > Updates-testing will not catch everything, but it should help catch soime
> > "nuclear" issues that otherwise may have sneaked past.
> >
> > I think the current update process is very good and well liked by me. But
> > tweaking it is not a big problem.
> >
> > PS other places that have more stable updates also have their problems -
> > there are many users who dislike Ubuntu because bugs are not fixed and
> > they have to live with them far too long.
>
> I generally agree with your POV for actual stable F12 - latest and
> greatest updates for peoples who likes bleeding edge. But previous
> stable (F11) IMHO should be considered as "in maintenance mode" -
> security and bug fixes only.

This is what I said 1000000 times in all previous threads in last two weeks!!!
Even KDE SIG is working on stability proposal that practically means - do not
touch Fn-1 and I'd like to generalize it match Fedora...

For mc update - no description is really very bad mistake!

Jaroslav

> Just my 0.02 $.
>
> Regards,
> Michal

--
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-08-2010, 08:20 AM
Jaroslav Reznik
 
Default Another great update

On Saturday 06 March 2010 23:48:23 Kalev Lember wrote:
> On 03/07/2010 12:25 AM, Orcan Ogetbil wrote:
> > On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote:
> >> +1, Michał! People who want the latest and greatest have already updated
> >> to F12 months ago anyway, so there is not much use in pushing new
> >> versions to F11.
> >
> > Why? I don't want to update/reinstall all my machines every 6 months.
> > And I expect the same amount of latestness an greatestness from F-11 and
> > F-12. And I am not alone. (See the discussions in the devel list for the
> > last 2 weeks.
> >
> > 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.
>
> 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.
>
> But what happened now is that a major Desktop Environment version was
> dumped in a stable Fedora release, and it annoyed some people (me
> included). If the new version had only come with F-13 instead, then I'd
> have an option to choose _when_ I want to upgrade from F-12 to F-13 to
> deal with the problems that might arise with the new version. But if the
> new version is dumped upon me in the middle of a week, I'm left without
> a choice. I have to immediately deal with whatever problems arise from
> the upgrade. Now think how someone who administers more than one
> computer would react to that -- I'm sure they also want to choose when
> to get major upgrades so that they could upgrade when they feel they
> have enough time for that.

Major KDE update was in time of Fedora 9, so it's not an issue today.

And this it the first problem - we should not call major, minor, bugfix release
because it doesn't mean the same for every each app out in the wild!!!

(KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix release).

Jaroslav

> So yes, I'd prefer to upgrade (not reinstall! as you said) once every 6
> months, instead of having to deal with changing expectations every
> single day.

--
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-08-2010, 08:41 AM
Kalev Lember
 
Default Another great update

On 03/08/2010 11:20 AM, Jaroslav Reznik wrote:
> Major KDE update was in time of Fedora 9, so it's not an issue today.
>
> And this it the first problem - we should not call major, minor, bugfix release
> because it doesn't mean the same for every each app out in the wild!!!

Yes, it can get confusing. I think it was Kevin Kofler who suggested to
talk about "feature releases" vs. "bugfix releases" instead
to avoid confusion.


> (KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix release).

I disagree. According to kde.org and wikipedia, X.Y is called a major
release, and Z is maintainance update. A few quotes:

KDE 4.3.0 announcement, http://www.kde.org/
> KDE 4.3.0 released
> /.../ KDE 4.3 is the latest major release in the KDE 4 series /.../

KDE standard releases, http://en.wikipedia.or/wiki/KDE#Standard_releases
> There are two main types of releases, major releases and maintenance
> releases.
> Major releases (with two version numbers, for example 3.5) contain
> new features.

--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 08:54 AM
Jaroslav Reznik
 
Default Another great update

On Monday 08 March 2010 10:41:18 Kalev Lember wrote:
> On 03/08/2010 11:20 AM, Jaroslav Reznik wrote:
> > Major KDE update was in time of Fedora 9, so it's not an issue today.
> >
> > And this it the first problem - we should not call major, minor, bugfix
> > release because it doesn't mean the same for every each app out in the
> > wild!!!
>
> Yes, it can get confusing. I think it was Kevin Kofler who suggested to
> talk about "feature releases" vs. "bugfix releases" instead
> to avoid confusion.

Again you can't cut bugfixes from features

> > (KDE versioning is X.Y.Z where X is major, Y is minor and Z is bugfix
> > release).
>
> I disagree. According to kde.org and wikipedia, X.Y is called a major
> release, and Z is maintainance update. A few quotes:

Ah, you're probably right - I've read it somewhere...

> KDE 4.3.0 announcement, http://www.kde.org/
>
> > KDE 4.3.0 released
> > /.../ KDE 4.3 is the latest major release in the KDE 4 series /.../
>
> KDE standard releases, http://en.wikipedia.or/wiki/KDE#Standard_releases
>
> > There are two main types of releases, major releases and maintenance
> > releases.
> > Major releases (with two version numbers, for example 3.5) contain
> > new features.

--
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-08-2010, 09:27 AM
Juha Tuomala
 
Default Another great update

On Mon, 8 Mar 2010, Jaroslav Reznik wrote:
>> Yes, it can get confusing. I think it was Kevin Kofler who suggested to
>> talk about "feature releases" vs. "bugfix releases" instead
>> to avoid confusion.
>
> Again you can't cut bugfixes from features

Again, you can't cut regressions from features

To name few, your last push comes with:
- kmail that can't anymore 'Add address to book'.
- kaddressbook doesn't have 'Merge' feature anymore.
- kaddressbook View, Edit, Tools menus are empty. Probably caused by
some clitch in configs, which i could not find. Same version
ubuntu binaries have them populated.
- constant 'whining dialogs' from Akonadi, which probably confuse users.
- konqueror RMB-click on tab-header doesn't open tab-menu anymore.
Probably caused by fixing the 'rmb against page goes back in
history' bug, being a new bug itself.

while the previous installed version did not have them. Those
are regressions that probably get fixed in coming releases, but
are real pita for people providing support and probably have
to spend time holding hands and explaining them to users.

Someone said it well:

You take away the consumer's ability to CHOOSE themselves

by pushing features to every release. That ability is very
much what UNIX, opensource etc is all about.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:02 AM
Christoph Wickert
 
Default Another great update

Am Montag, den 08.03.2010, 12:27 +0200 schrieb Juha Tuomala:

> Again, you can't cut regressions from features
>
> To name few, your last push comes with:
> - kmail that can't anymore 'Add address to book'.
> - kaddressbook doesn't have 'Merge' feature anymore.
> - kaddressbook View, Edit, Tools menus are empty. Probably caused by
> some clitch in configs, which i could not find. Same version
> ubuntu binaries have them populated.
> - constant 'whining dialogs' from Akonadi, which probably confuse users.
> - konqueror RMB-click on tab-header doesn't open tab-menu anymore.
> Probably caused by fixing the 'rmb against page goes back in
> history' bug, being a new bug itself.

Have you filed *all* of them in bugzilla? This is important, otherwise
the KDE SIG wont be able to see how many regressions were introduced.

TIA,
Christoph

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

On Mon, Mar 08, 2010 at 12:27:07PM +0200, Juha Tuomala wrote:
>
>
>
> On Mon, 8 Mar 2010, Jaroslav Reznik wrote:
> >> Yes, it can get confusing. I think it was Kevin Kofler who suggested to
> >> talk about "feature releases" vs. "bugfix releases" instead
> >> to avoid confusion.
> >
> > Again you can't cut bugfixes from features
>
> Again, you can't cut regressions from features
>
Two notes:
1) regressions can occur whether you're introducing features or bugfixes in
your new version.
2) The novelist in me cringes when we use absolutes.

Better wording, which maybe we all understand by now would be:
>> KDE upstream releases bugfixes and features in the same release.
> KDE releases both fix bugs and introduce new bugs.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 06:30 PM
Adam Williamson
 
Default Another great update

On Sat, 2010-03-06 at 20:47 -0500, Orcan Ogetbil wrote:

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

This is not the purpose of updates-testing, it is not an alternative
update repo. It is there for focused testing of packages you - the
developer - believe are already ready to be pushed out as updates;
basically it's where you send your update 'release candidates' for
others to make sure you got it right. If it works, it goes to updates.
If not, you unpush it, fix it, and try again. Things should not live
there.

What you describe is the function of a separate 'backports' style repo,
as discussed earlier in the thread. Since we don't have one at present,
the best option is to do a scratch build and host it yourself, *not*
misuse updates-testing to host a package you have no immediate intention
of shipping as an update. The current processes just are not set up for
updates-testing to be used for this purpose.
--
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 03-08-2010, 06:31 PM
Adam Williamson
 
Default Another great update

On Sat, 2010-03-06 at 22:17 -0500, Orcan Ogetbil wrote:

> And as you obviously didn't finish reading my sentence, that is not
> the only solution I proposed. Read again, there is a 0 additional repo
> proposal too.

Having multiple package versions in a single repository is essentially
like having multiple repositories, only much worse managed...
--
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
 

Thread Tools




All times are GMT. The time now is 02:54 PM.

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