11 a.m.
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!
Regards,
Christoph
11:17 a.m.
Hi,
2010/3/6 Christoph Wickert <christoph.wickert(a)googlemail.com>:
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!
Regards,
Christoph
Is there any Fedora update policy? Because I don't understand the
criteria for Fedora package update.
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)
From my user point of view, I would prefer to don't have any
significant updates in previous stable version - just security fixes.
Regards,
Michal
11:49 a.m.
Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski:
Hi,
2010/3/6 Christoph Wickert <christoph.wickert(a)foomail.com>:
> 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!
>
> Regards,
> Christoph
>
Is there any Fedora update policy?
Not yet, but we are working on it, see
http://jwboyer.livejournal.com/36737.html
Because I don't understand the
criteria for Fedora package update.
Why I can install KDE 4.4 in F11 and I can't install latest gnome?
Because the KDE SIG uses different criteria than most of the other
packagers.
From my user point of view, I would prefer to don't have any
significant updates in previous stable version - just security fixes.
Fully agreed, but this is something we are discussing for the last two
weeks and I don't expect an agreement in the near future. While I think
that the decision about an update should generally be up to the
maintainers, I think KDE or this update show that we were better off
with an official policy.
Regards,
Michal
Regards,
Christoph
12:22 p.m.
On 03/06/2010 11:28 PM, Till Maas wrote:
On Sat, Mar 06, 2010 at 06:49:03PM +0100, Christoph Wickert wrote:
> maintainers, I think KDE or this update show that we were better off
> with an official policy.
>
Did the mc update break something?
Even if it did not it would be useful to get a proper description of
what the updates involves and as the current guidelines recommend a
summary of the changes or link to the upstream changelog
Rahul
12:30 p.m.
2010/3/6 Christoph Wickert <christoph.wickert(a)googlemail.com>:
Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski:
> Hi,
>
> 2010/3/6 Christoph Wickert <christoph.wickert(a)foomail.com>:
> > 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!
> >
> > Regards,
> > Christoph
> >
>
> Is there any Fedora update policy?
Not yet, but we are working on it, see
http://jwboyer.livejournal.com/36737.html
> Because I don't understand the
> criteria for Fedora package update.
>
> Why I can install KDE 4.4 in F11 and I can't install latest gnome?
Because the KDE SIG uses different criteria than most of the other
packagers.
> From my user point of view, I would prefer to don't have any
> significant updates in previous stable version - just security fixes.
Fully agreed, but this is something we are discussing for the last two
weeks
I have seen some discussions, but I don't follow them. I'm waiting for
results ;)
and I don't expect an agreement in the near future.
Pity. There are many Fedora policies that are useless for end users
like me, but update policy would be quite usefull.
While I think
that the decision about an update should generally be up to the
maintainers, I think KDE or this update show that we were better off
with an official policy.
> Regards,
> Michal
Regards,
Christoph
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Regards,
Michal
3:45 p.m.
Am Samstag, den 06.03.2010, 19:30 +0100 schrieb Michał Piotrowski:
I have seen some discussions, but I don't follow them. I'm
waiting for
results ;)
Get involved, try to influence the discussion.
Pity. There are many Fedora policies that are useless for end users
like me, but update policy would be quite usefull.
Then you should at least vote at:
http://forums.fedoraforum.org/showthread.php?t=241710
Regards,
Christoph
4:44 p.m.
2010/3/6 Christoph Wickert <christoph.wickert(a)googlemail.com>:
Am Samstag, den 06.03.2010, 19:30 +0100 schrieb Michał Piotrowski:
> I have seen some discussions, but I don't follow them. I'm waiting for
> results ;)
Get involved, try to influence the discussion.
I'm just a guest here :)
I'm not a Fedora developer so my vote doesn't really matter.
Regards,
Michal
5:01 p.m.
On 03/07/2010 04:14 AM, Michał Piotrowski wrote:
I'm just a guest here :)
I'm not a Fedora developer so my vote doesn't really matter.
Getting involved does not require a vote and any user position if
expressed in a constructive fashion does matter and is part of how we
can form a decision
Rahul
2:10 p.m.
On Saturday, 06 March 2010 at 18:49, Christoph Wickert wrote:
Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski:
[...]
> Because I don't understand the
> criteria for Fedora package update.
>
> Why I can install KDE 4.4 in F11 and I can't install latest gnome?
Because the KDE SIG uses different criteria than most of the other
packagers.
How do you know what criteria most packagers use? I assume you have done
some analysis, since you stated that so authoritatively. Can we see your
analysis?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
4:07 p.m.
Am Samstag, den 06.03.2010, 21:10 +0100 schrieb Dominik 'Rathann'
Mierzejewski:
On Saturday, 06 March 2010 at 18:49, Christoph Wickert wrote:
> Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski:
[...]
> > Because I don't understand the
> > criteria for Fedora package update.
> >
> > Why I can install KDE 4.4 in F11 and I can't install latest gnome?
>
> Because the KDE SIG uses different criteria than most of the other
> packagers.
How do you know what criteria most packagers use? I assume you have done
some analysis, since you stated that so authoritatively. Can we see your
analysis?
I didn't state anything authoritatively and what I described is what
everybody who looks at https://admin.fedoraproject.org/updates will see.
He will see huge KDE updates like
https://admin.fedoraproject.org/updates/search/kdebase-runtime
By taking a closer look he will then see that KDE in F11 was released
with KDE 4.2.2, then updated to 4.2.3, then 4.2.4, 4.3.0, 4.3.1, 4.3.2,
4.3.3, 4.3.4, 4.3.5 and finally to 4.4.0. This means that
kdebase-workspace is one of the most updated packages in Fedora:
https://admin.fedoraproject.org/updates/metrics/?release=F11
Most of our packagers follow the guidelines from the wiki:
http://fedoraproject.org/wiki/Package_update_guidelines
This means, they apply at least three criteria:
* An update should not break something
* An update should be backwards compatible, e.g. it should not
change the syntax or location of a config file so that old
settings can no longer be applied.
* An update should not change the behavior of an basic
application, e.g. think of when Thunderbird started indexing
automatically after an update.
Summing it all up I think I don't think it is pretty obvious that the
KDE SIG uses different criteria then most other maintainers. This is
just a statement and no criticism.
Regards,
R.
Regards,
Christoph
6:05 p.m.
On Sat, Mar 06, 2010 at 11:07:13PM +0100, Christoph Wickert wrote:
Most of our packagers follow the guidelines from the wiki:
http://fedoraproject.org/wiki/Package_update_guidelines
This means, they apply at least three criteria:
* An update should not break something
* An update should be backwards compatible, e.g. it should not
change the syntax or location of a config file so that old
settings can no longer be applied.
* An update should not change the behavior of an basic
application, e.g. think of when Thunderbird started indexing
automatically after an update.
Summing it all up I think I don't think it is pretty obvious that the
KDE SIG uses different criteria then most other maintainers. This is
just a statement and no criticism.
Since I just re-read that page when it came up in a different thread, I have
to say that your bullet points don't seem to quite match what I read on that
page.
* An update should not break something
On the wiki page it's not so black and white -- instead it's a decision that
the package maintainers must make to balance: "The benefit of the bugfixes
and new features should be weighed up against the risk of regressions."
* An update should be backwards compatible
This is not really on there. Your example is a subset of backwards
compatibility which can find justification here:
"an update doesn't cause a users' applications or system to stop working
suddenly."
But other examples of backwards incompatibility (for instance updated
libraries with new SONAMES to address critical bugs if rebuilds of apps in
fedora are performed, changes to config files if an automatic conversion
is available) would be allowed.
* An update should not change the behavior
This is actually not mentioned at all.
As for whether the KDE SIG is currently following the guidelines on
http://fedoraproject.org/wiki/Package_update_guidelines I would argue that
they are. Their upstream is providing releases that have both bugfixes and
enhancements in one release. They've evaluated the risk of regression and
figure that backporting of requested features and bugfixes is more likely to
cause regresions than upgrading to upstreams supported release. They push
the updates to multiple repos for testing before it gets to the normal
updates repository in order to mitigate the risk of regression. They did
not push KDE4 to a release that only had KDE3 because the update was
considerd to break working systems. All this seems to indicate that the KDE
SIG is working hard to evaluate the stuff they're pushing with the guidance
on the Package_update_guidelines page rather than blindly pushing new
upstream releases which have no benefit to Fedora users.
-Toshio "Wondering how your post about a midnight commander update not
following good update practices turned into claiming the same for KDE"
Kuratomi
12:13 p.m.
2010/3/6 Michał Piotrowski <mkkp4x4(a)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.
12:38 p.m.
2010/3/6 Naheem Zaffar <naheemzaffar(a)gmail.com>:
2010/3/6 Michał Piotrowski <mkkp4x4(a)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.
Just my 0.02 $.
Regards,
Michal
4:16 p.m.
Am Samstag, den 06.03.2010, 19:38 +0100 schrieb Michał Piotrowski:
2010/3/6 Naheem Zaffar <naheemzaffar(a)gmail.com>:
>
[snipped]
> 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.
Nobody is talking about bugfix updates here. Bugfixes are always
allowed.
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.
+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.
Regards,
Christoph
4:25 p.m.
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.
However, this mc update should have gone to testing and stayed there
for a couple weeks before pushed to stable. I agree at that point.
Orcan
4:40 p.m.
2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
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
But you are updating to latest KDE in f11. So what is the deal with
full system 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.
Ok, but what is the point of previous stable version then? If you have
the same software in F11 and F12, I really don't see the reason to
support f11. Just update all machines to f12...
OTOH - don't release F13 - just push updates to F12 - will be the same thing ;)
I hope you get my POV.
However, this mc update should have gone to testing and stayed there
for a couple weeks before pushed to stable. I agree at that point.
Orcan
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Regards,
Michal
4:48 p.m.
2010/3/6 Michał Piotrowski :
2010/3/6 Orcan Ogetbil :
> 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
But you are updating to latest KDE in f11. So what is the deal with
full system update?
Time. A simple "yum update" or make a selective update takes a few
minutes. A whole system update takes more.
> /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.
Ok, but what is the point of previous stable version then? If you have
the same software in F11 and F12, I really don't see the reason to
support f11. Just update all machines to f12...
OTOH - don't release F13 - just push updates to F12 - will be the same thing ;)
Nope it won't. As I already said in the long discussion, the core
components need updates too. It is impractical to update them in
stable releases.
So F-11, F-12 should be constantly updated, except the limitations
caused by core components.
Moreover, stuff like default filesystem, bootloader, etc change in
time. These kind of updates cannot be done in an easy way in stable
releases on the fly. The numbers 11, 12 should only indicate the core
components revision number .
Orcan
5:05 p.m.
2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
The numbers 11, 12 should only indicate the core
components revision number .
I'm not convinced to this philosophy. I have used a few Linux distros
in past 11 years, and this is something new to me...
I hope that RHEL 6 will be released soon, Fedora 11 is going to be too
bleeding edge for me ;)
Regards,
Michal
5:14 p.m.
2010/3/6 Michał Piotrowski:
2010/3/6 Orcan Ogetbil:
> The numbers 11, 12 should only indicate the core
> components revision number .
I'm not convinced to this philosophy. I have used a few Linux distros
in past 11 years, and this is something new to me...
I understand that. However there are philosophies that don't convince
me either. If you consider gtk2-2.18 to be stable enough to support in
Fedora 12, then why can't you support it in F-11? Laziness? Lack of
manpower? Is it because F-11 is supposed to be "more stable" than
F-12? Then why do we stop supporting F-11 (such a stable release by
this logic) after only a couple months?
Orcan
6:49 p.m.
2010/3/7 Orcan Ogetbil <oget.fedora(a)gmail.com>:
2010/3/6 Michał Piotrowski:
> 2010/3/6 Orcan Ogetbil:
>> The numbers 11, 12 should only indicate the core
>> components revision number .
>
> I'm not convinced to this philosophy. I have used a few Linux distros
> in past 11 years, and this is something new to me...
>
I understand that. However there are philosophies that don't convince
me either. If you consider gtk2-2.18 to be stable enough to support in
Fedora 12, then why can't you support it in F-11? Laziness? Lack of
manpower? Is it because F-11 is supposed to be "more stable" than
F-12? Then why do we stop supporting F-11 (such a stable release by
this logic) after only a couple months?
Let's consider a situation - I'm developing a project in php 5.2. This
project might work fine on php 5.3 - I don't know I didn't tested it
yet. I'm depending on 5.2 version. Testing this code for a new php
will take some time.
Php 5.3 is considered as stable in F12 - fine for me, but IMHO should
never be considered as an update for F11. Some people depend on some
constant values here - php 5.2, postgres 8.3 etc.
I know that there is a RHEL5/CentOS5 for such things, but this is
pretty outdated OS for my needs.
Orcan
Regards,
Michal
7:17 p.m.
2010/3/6 Michał Piotrowski <mkkp4x4(a)gmail.com>:
2010/3/7 Orcan Ogetbil <oget.fedora(a)gmail.com>:
> 2010/3/6 Michał Piotrowski:
>> 2010/3/6 Orcan Ogetbil:
>>> The numbers 11, 12 should only indicate the core
>>> components revision number .
>>
>> I'm not convinced to this philosophy. I have used a few Linux distros
>> in past 11 years, and this is something new to me...
>>
>
> I understand that. However there are philosophies that don't convince
> me either. If you consider gtk2-2.18 to be stable enough to support in
> Fedora 12, then why can't you support it in F-11? Laziness? Lack of
> manpower? Is it because F-11 is supposed to be "more stable" than
> F-12? Then why do we stop supporting F-11 (such a stable release by
> this logic) after only a couple months?
Let's consider a situation - I'm developing a project in php 5.2. This
project might work fine on php 5.3 - I don't know I didn't tested it
yet. I'm depending on 5.2 version. Testing this code for a new php
will take some time.
Php 5.3 is considered as stable in F12 - fine for me, but IMHO should
never be considered as an update for F11. Some people depend on some
constant values here - php 5.2, postgres 8.3 etc.
I know that there is a RHEL5/CentOS5 for such things, but this is
pretty outdated OS for my needs.
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.
Orcan
7:20 p.m.
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
Rahul
7:35 p.m.
2010/3/7 Rahul Sundaram <metherid(a)gmail.com>:
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
True.
The other thing is that I don't plan to stick with Fedora on servers.
I want to move to CentOS6. I don't know which version of php will be
included there, so moving forward is not an option now.
Rahul
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Regards,
Michal
7:47 p.m.
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.
Orcan
7:45 p.m.
On 03/07/2010 07:17 AM, 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.
updates-testing should not be used for this purpose because among other
things you might want to push a bug fix for the previous release that is
more urgent and if we are doing this we need a separate update stream
Rahul
8:13 p.m.
On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote:
On 03/07/2010 07:17 AM, 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.
>
updates-testing should not be used for this purpose because among other
things you might want to push a bug fix for the previous release that is
more urgent and if we are doing this we need a separate update stream
So? That is not a common situation and does not happen with most
packages. But you are right it does happen. Supporting a small "urgent
fixes" repo, OR being able to have multiple versions of one package in
updates-testing shouldn't be too hard.
Meanwhile, I believe in that updates-testing should be extensively
used for such upcoming updates by (almost) everyone.
The pros are obvious. What are the cons of this model?
Orcan
8:28 p.m.
2010/3/7 Orcan Ogetbil <oget.fedora(a)gmail.com>:
On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote:
> On 03/07/2010 07:17 AM, 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.
>>
>
> updates-testing should not be used for this purpose because among other
> things you might want to push a bug fix for the previous release that is
> more urgent and if we are doing this we need a separate update stream
>
So? That is not a common situation and does not happen with most
packages. But you are right it does happen. Supporting a small "urgent
fixes" repo, OR being able to have multiple versions of one package in
updates-testing shouldn't be too hard.
Meanwhile, I believe in that updates-testing should be extensively
used for such upcoming updates by (almost) everyone.
The pros are obvious. What are the cons of this model?
"entities must not be multiplied beyond necessity"
Now we got:
fedora-updates
fedora-updates-testing
It's easy to add another repos:
fedora-updates-urgent
fedora-updates-really-urgent
fedora-updates-not-really-urgent
fedora-updates-next-year
Adding additional repo _won't_ solve the problem. I only use packages
from fedora-updates-testing from time to time - many regular users do
the same thing. I bet that most users don't even know about this
repo...
Orcan
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Regards,
Michal
9:17 p.m.
2010/3/6 Michał Piotrowski:
2010/3/7 Orcan Ogetbil:
> On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote:
>> On 03/07/2010 07:17 AM, 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.
>>>
>>
>> updates-testing should not be used for this purpose because among other
>> things you might want to push a bug fix for the previous release that is
>> more urgent and if we are doing this we need a separate update stream
>>
>
> So? That is not a common situation and does not happen with most
> packages. But you are right it does happen. Supporting a small "urgent
> fixes" repo, OR being able to have multiple versions of one package in
> updates-testing shouldn't be too hard.
>
> Meanwhile, I believe in that updates-testing should be extensively
> used for such upcoming updates by (almost) everyone.
>
> The pros are obvious. What are the cons of this model?
"entities must not be multiplied beyond necessity"
Now we got:
fedora-updates
fedora-updates-testing
It's easy to add another repos:
fedora-updates-urgent
fedora-updates-really-urgent
fedora-updates-not-really-urgent
fedora-updates-next-year
Adding additional repo _won't_ solve the problem. I only use packages
from fedora-updates-testing from time to time - many regular users do
the same thing. I bet that most users don't even know about this
repo...
I only gave 1 small repo suggestion, not 4.
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.
Orcan
1:31 p.m.
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
2:19 a.m.
On Sun, Mar 7, 2010 at 3:13 AM, Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote:
> On 03/07/2010 07:17 AM, 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.
>>
>
> updates-testing should not be used for this purpose because among other
> things you might want to push a bug fix for the previous release that is
> more urgent and if we are doing this we need a separate update stream
>
So? That is not a common situation and does not happen with most
packages. But you are right it does happen. Supporting a small "urgent
fixes" repo, OR being able to have multiple versions of one package in
updates-testing shouldn't be too hard.
Meanwhile, I believe in that updates-testing should be extensively
used for such upcoming updates by (almost) everyone.
The pros are obvious. What are the cons of this model?
I can't see cons. And thanks to Till Maas and his karma.py it's very
very easy to give karma (and comments) for updates in updates-testing.
--
LG Thomas
Dubium sapientiae initium
7:53 p.m.
>> 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.
They can get it from Koji or Rawhide too, can't they?
Let's look at who will be looking for a new PHP. Normal Joe User won't
look for it. Developers will. Developers are more likely to be able to
deal with the added pain of having to build something from somewhere.
But Normal Joe User can not be expected to deal with any breakages or
the burden of too many updates. There are people in this world who are
not blessed with super fast, limitless Internet connections.
Cheers,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
2:34 a.m.
On Sun, Mar 7, 2010 at 2:53 AM, Debarshi Ray <debarshi.ray(a)gmail.com> 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.
They can get it from Koji or Rawhide too, can't they?
Let's look at who will be looking for a new PHP. Normal Joe User won't
look for it. Developers will. Developers are more likely to be able to
deal with the added pain of having to build something from somewhere.
But Normal Joe User can not be expected to deal with any breakages or
the burden of too many updates. There are people in this world who are
not blessed with super fast, limitless Internet connections.
So as developer i have to go trough some more pain, ok.
Well, i hope such people with limited internet connections can handle
a GUI or CLI command, read how big an update in question would be and
can click [cancel] or write 'no' to the commandline if they think
that's too much. *sigh*
I obviously don't know what kind of people do live out there in the
wild. All the people i know, and i know a lot, are able to choose what
they want and what fits their needs.
--
LG Thomas
Dubium sapientiae initium
5:08 a.m.
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.
6:34 a.m.
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.
I am quite happy with the feedback I get from the people who use my
packages from updates-testing. The feedback as in bodhi, in mailing
lists, forums, private messages in forums, private emails etc. I don't
claim that all my packages got feedback. But the major ones do, most
of the time. And at various times, I fixed stuff based on feedback, on
the enchancement updates I made in updates-testing of stable releases.
Upstreams benefited from this too.
Orcan
9:55 a.m.
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
10:02 a.m.
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
10:33 a.m.
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
3:24 p.m.
On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote:
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.
https://fedoraproject.org/wiki/Buildroot_override_SOP
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:32 p.m.
On Mon, Mar 08, 2010 at 01:24:24PM -0800, Jesse Keating wrote:
On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote:
> 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.
>
https://fedoraproject.org/wiki/Buildroot_override_SOP
That's the page for releng's actions in response to a buildroot override
request. I'm looking for where it's documented when to ask for a buildroot
override, when to request the override go away, (and how to request the
override but that's a tangent to the question I needed answering).
-Toshio
4:05 p.m.
On Mon, 2010-03-08 at 16:32 -0500, Toshio Kuratomi wrote:
On Mon, Mar 08, 2010 at 01:24:24PM -0800, Jesse Keating wrote:
> On Sun, 2010-03-07 at 11:33 -0500, Toshio Kuratomi wrote:
> > 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.
> >
>
> https://fedoraproject.org/wiki/Buildroot_override_SOP
>
That's the page for releng's actions in response to a buildroot override
request. I'm looking for where it's documented when to ask for a buildroot
override, when to request the override go away, (and how to request the
override but that's a tangent to the question I needed answering).
I don't know if such a page exists. If anybody would like to create
one, that would be awesome.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:11 p.m.
On Mon, Mar 08, 2010 at 02:05:05PM -0800, Jesse Keating wrote:
On Mon, 2010-03-08 at 16:32 -0500, Toshio Kuratomi wrote:
> That's the page for releng's actions in response to a buildroot override
> request. I'm looking for where it's documented when to ask for a buildroot
> override, when to request the override go away, (and how to request the
> override but that's a tangent to the question I needed answering).
>
I don't know if such a page exists. If anybody would like to create
one, that would be awesome.
I thought I recalled a page that at least spoke about when to request
a buildroot override and when to request the override be removed so that
I could answer the original question but I guess I'm misremembering.
-Toshio
1:40 p.m.
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.
1:30 p.m.
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
11:07 p.m.
On Mon, Mar 8, 2010 at 2:30 PM, Adam Williamson wrote:
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.
I don't want to repeat myself all the way again. I don't buy this "you
should, you shouldn't, supposed to..." arguments. I have been using
updates-testing this way for a long time and I got nothing but
compliments.
Orcan
10:28 p.m.
Am Sonntag, den 07.03.2010, 01:49 +0100 schrieb Michał Piotrowski:
Let's consider a situation - I'm developing a project in php
5.2. This
project might work fine on php 5.3 - I don't know I didn't tested it
yet. I'm depending on 5.2 version. Testing this code for a new php
will take some time.
Php 5.3 is considered as stable in F12 - fine for me, but IMHO should
never be considered as an update for F11. Some people depend on some
constant values here - php 5.2, postgres 8.3 etc.
Others may be eager to test their software with 5.3, but can not spend
the time to make a system update to F12.
For your issue: have a look at /etc/yum.conf and exclude php from
updates (instead of expecting all users of f11 to do without newer
software).
I know that there is a RHEL5/CentOS5 for such things, but this is
pretty outdated OS for my needs.
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.
Peter
4:18 a.m.
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. Or if the new GCC is placed in a "separate" repository then
the tree won't be built using it and it won't be that well tested.
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"?
Often "new and shiny" can mean "new bugs". That is what makes Rawhide
(or today's F13) what it is. Some say it is unstable, some say it eats
babies. But it is definitely "new". :-)
Cheers,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
9:40 a.m.
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
2:14 a.m.
2010/3/7 Michał Piotrowski <mkkp4x4(a)gmail.com>:
2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
> The numbers 11, 12 should only indicate the core
> components revision number .
I'm not convinced to this philosophy. I have used a few Linux distros
in past 11 years, and this is something new to me...
I hope that RHEL 6 will be released soon, Fedora 11 is going to be too
bleeding edge for me ;)
Well, sorry, but you clearly state that Fedora is something new to you
and you don't like the philosophy. So why don't you use something that
fits your needs like CentOS 5 as you mentioned RHEL 6 but rather try
to make something out of Fedora that Fedora isn't? Or become familiar
with what Fedora is and stands for.
Would be the same as if i try to change another Distro just because
their philosophy is new to me and i don't like it.
Maybe you can explain?
--
LG Thomas
Dubium sapientiae initium
5:25 a.m.
2010/3/7 Thomas Janssen <thomasj(a)fedoraproject.org>:
2010/3/7 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> 2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
>> The numbers 11, 12 should only indicate the core
>> components revision number .
>
> I'm not convinced to this philosophy. I have used a few Linux distros
> in past 11 years, and this is something new to me...
>
> I hope that RHEL 6 will be released soon, Fedora 11 is going to be too
> bleeding edge for me ;)
Well, sorry, but you clearly state that Fedora is something new to you
and you don't like the philosophy.
No, I clearly state, that this "new way" described by Orcan is
something new to me (and I not really convinced to this).
RH6 was my first distro and I'm using mostly RedHat things since then.
So why don't you use something that
fits your needs like CentOS 5 as you mentioned RHEL 6 but rather try
to make something out of Fedora that Fedora isn't? Or become familiar
with what Fedora is and stands for.
The same version numbers for stable version and previous stable
version is not a Fedora way that I know. I used Fedora since FC5 and I
wasn't aware about such plans.
Would be the same as if i try to change another Distro just because
their philosophy is new to me and i don't like it.
Maybe you can explain?
--
LG Thomas
Dubium sapientiae initium
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Regards,
Michal
5:55 a.m.
2010/3/7 Michał Piotrowski <mkkp4x4(a)gmail.com>:
2010/3/7 Thomas Janssen <thomasj(a)fedoraproject.org>:
> 2010/3/7 Michał Piotrowski <mkkp4x4(a)gmail.com>:
>> 2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
>>> The numbers 11, 12 should only indicate the core
>>> components revision number .
>>
>> I'm not convinced to this philosophy. I have used a few Linux distros
>> in past 11 years, and this is something new to me...
>>
>> I hope that RHEL 6 will be released soon, Fedora 11 is going to be too
>> bleeding edge for me ;)
That is you compare a few Linux distros with Fedora and "this" is
something new to you.
It's not for Fedora users. So the question is still alive:
Why are you trying to change the Face and Character of Fedora instead
of using what fits your needs (your own mentioned RHEL/CentOS)?
> Well, sorry, but you clearly state that Fedora is something new
to you
> and you don't like the philosophy.
No, I clearly state, that this "new way" described by Orcan is
something new to me (and I not really convinced to this).
See above, and there is no new way yet. But people trying to make a
copy of Ubuntu or openSUSE out of Fedora.
> So why don't you use something that
> fits your needs like CentOS 5 as you mentioned RHEL 6 but rather try
> to make something out of Fedora that Fedora isn't? Or become familiar
> with what Fedora is and stands for.
The same version numbers for stable version and previous stable
version is not a Fedora way that I know. I used Fedora since FC5 and I
wasn't aware about such plans.
Since you haven't noticed it in all that time, it looks like it can't
be that bad ;)
--
LG Thomas
Dubium sapientiae initium
6:04 a.m.
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,
--
Henrique Junior <henriquecsj(a)gmail.com>
6:49 a.m.
2010/3/7 Henrique Junior <henriquecsj(a)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
6:32 a.m.
2010/3/7 Thomas Janssen <thomasj(a)fedoraproject.org>:
Why are you trying to change the Face and Character of Fedora
instead
of using what fits your needs (your own mentioned RHEL/CentOS)?
RHEL5/CentOS5 is outdated for my needs.
I had two ways:
1 update many packages in old distro
2 use previous stable Fedora, that fits to my needs (at least in that
point in time)
Now I'm not sure that I made the right decision.
Since you haven't noticed it in all that time, it looks like it
can't
be that bad ;)
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.
Regards,
Michal
6:37 a.m.
2010/3/7 Michał Piotrowski <mkkp4x4(a)gmail.com>:
2010/3/7 Thomas Janssen <thomasj(a)fedoraproject.org>:
> Why are you trying to change the Face and Character of Fedora instead
> of using what fits your needs (your own mentioned RHEL/CentOS)?
RHEL5/CentOS5 is outdated for my needs.
I had two ways:
1 update many packages in old distro
2 use previous stable Fedora, that fits to my needs (at least in that
point in time)
Now I'm not sure that I made the right decision.
> Since you haven't noticed it in all that time, it looks like it can't
> be that bad ;)
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.
Yeah, that can be a problem, indeed. I personally do exclude stuff i
don't want to be upgraded (or tested and downgraded until a newer
version is out).
--
LG Thomas
Dubium sapientiae initium
9:47 a.m.
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
10:03 a.m.
2010/3/7 Toshio Kuratomi <a.badger(a)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
5:16 p.m.
On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote:
2010/3/6 Michał Piotrowski :
> But you are updating to latest KDE in f11. So what is the deal with
> full system update?
>
Time. A simple "yum update" or make a selective update takes a few
minutes. A whole system update takes more.
I've been upgrading my systems for a few years now with a simple yum
upgrade, i.e. install the new fedora-release package and run "yum
update".
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
5:29 p.m.
On Sat, Mar 6, 2010 at 6:16 PM, Jussi Lehtola wrote:
On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote:
> 2010/3/6 Michał Piotrowski :
> > But you are updating to latest KDE in f11. So what is the deal with
> > full system update?
> >
>
> Time. A simple "yum update" or make a selective update takes a few
> minutes. A whole system update takes more.
I've been upgrading my systems for a few years now with a simple yum
upgrade, i.e. install the new fedora-release package and run "yum
update".
That broke stuff for me in the past. It might have changed since. Yet
I feel the need to clone the root partition to somewhere before
attempting again, which, with limited hardware supplies, takes time.
Orcan
4:49 p.m.
On Sat, Mar 06, 2010 at 11:40:20PM +0100, Michał Piotrowski wrote:
2010/3/6 Orcan Ogetbil <oget.fedora(a)gmail.com>:
> 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
But you are updating to latest KDE in f11. So what is the deal with
full system update?
> 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.
Ok, but what is the point of previous stable version then? If you have
the same software in F11 and F12, I really don't see the reason to
support f11. Just update all machines to f12...
Not everything can be supported in both releases, e.g. when KDE 4 was
released, the older Fedora release with KDE 3 did not update to KDE 4.
Also e.g. when pam_mount (a package I maintain) was partly rewritten and
changed the config file from custom to XML, this disqualified this
update to happen in a released version of Fedora.
Regards
Till
4:48 p.m.
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.
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.
--
Kalev
4:52 p.m.
On Sat, Mar 6, 2010 at 5:48 PM, 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.
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.
Thus you have the option of not doing an update every day.
Moreover you also have the option of updating security fixes only.
Yet moreover you also have the option of updating bugfixes in
addition, leaving the enhancement updates out.
Orcan
5:28 p.m.
On 03/07/2010 12:52 AM, Orcan Ogetbil wrote:
Yet moreover you also have the option of updating bugfixes in
addition, leaving the enhancement updates out.
I really don't think I have that option. It might work in some cases,
but generally it's bound to fail.
A security update in an application which uses KDE or Qt libs (both of
which were upgraded to a new feature release recently in F-11 and F-12)
will be built against those new libs. It's a common practice that new
versions of libraries continue working with programs that were compiled
against an older version of said library. But it doesn't work the other
way around: something built against Qt 4.5 is supposed to continue
working with Qt 4.6, but an application built against Qt 4.6 will have
no guarantees that it also runs with Qt 4.5. This is the reason why only
applying security updates doesn't work if underlying libraries get
upgraded to new feature releases meanwhile.
Let me quote mail titled "Read this if your package BuildRequires
qt(4)-devel!!!" here.
On 02/22/2010 05:40 AM, Kevin Kofler wrote:
for all maintainers of packages which BuildRequire qt4-devel (or
qt-devel, but
the versioned virtual Provides is preferred): please, when you plan to push
updates for your packages, ALWAYS CHECK what version of Qt your package got
built against and DO NOT PUSH your update to stable before that version of Qt
goes stable! A package built against Qt 4.6 WILL NOT WORK AT ALL with Qt
4.5!!! (This is always the case, Qt is backwards- but not forwards-
compatible.)
--
Kalev
5:45 p.m.
On Sun, Mar 07, 2010 at 01:28:32AM +0200, Kalev Lember wrote:
On 03/07/2010 12:52 AM, Orcan Ogetbil wrote:
> Yet moreover you also have the option of updating bugfixes in
> addition, leaving the enhancement updates out.
I really don't think I have that option. It might work in some cases,
but generally it's bound to fail.
But you have nothing to loose if you try it. You won't get more updates
than without trying to reduce them to the security updates. Even if it
might in theory not work that good, maybe it does in practice.
Regards
Till
7:13 p.m.
On Sat, Mar 6, 2010 at 6:28 PM, Kalev Lember wrote:
On 03/07/2010 12:52 AM, Orcan Ogetbil wrote:
> Yet moreover you also have the option of updating bugfixes in
> addition, leaving the enhancement updates out.
I really don't think I have that option. It might work in some cases,
but generally it's bound to fail.
A security update in an application which uses KDE or Qt libs (both of
which were upgraded to a new feature release recently in F-11 and F-12)
will be built against those new libs. It's a common practice that new
versions of libraries continue working with programs that were compiled
against an older version of said library. But it doesn't work the other
way around: something built against Qt 4.5 is supposed to continue
working with Qt 4.6, but an application built against Qt 4.6 will have
no guarantees that it also runs with Qt 4.5. This is the reason why only
applying security updates doesn't work if underlying libraries get
upgraded to new feature releases meanwhile.
Let me quote mail titled "Read this if your package BuildRequires
qt(4)-devel!!!" here.
You are correct. But we are talking about Fedora, right? Going to the
latest is the ultimate goal. The question is: when?
This is the reason why I believe in extensive use of updates-testing.
Big updates such as the one you pointed above should stay in testing
for a longer period of time, until it is safe for most to update.
Orcan
6:28 p.m.
Orcan Ogetbil wrote:
Moreover you also have the option of updating security fixes only.
That option doesn't really exist, as was already demonstrated:
http://lists.fedoraproject.org/pipermail/devel/2010-March/131926.html
Björn Persson
6:25 a.m.
On Sun, Mar 07, 2010 at 01:28:39AM +0100, Björn Persson wrote:
Orcan Ogetbil wrote:
> Moreover you also have the option of updating security fixes only.
That option doesn't really exist, as was already demonstrated:
http://lists.fedoraproject.org/pipermail/devel/2010-March/131926.html
So how many real problems did this cause? And why does nobody work on
fixing this, if it's not working? Also is there any real information
about how many packages switch to a different upstream branch within a
release lifetime while the old branch is still supported? E.g. for KDE
afaik the KDE SIG only switched to a new branch when the old one was not
supported anymore.
Regards
Till
4:59 p.m.
On Sun, Mar 07, 2010 at 12:48:23AM +0200, Kalev Lember wrote:
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
You do not have to update immediately and for security updates you can
use "yum --security update" or PackageKit.
Regards
Till
3:51 a.m.
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. I use Fedora for doing my day-job, along with all the other
"freetime surfing" type activities. My wife also runs Fedora exclusively
on her laptop and is perfectly happy with it and doesn't even mind the
occasional bug + working around it too much, as long as updates dont break
*new* things. Distro upgrades to latest and greatest new Fedora release
get done on an idle weekend when we've time to deal with the inevitable
changes (including but not limited to potential breakage) - the silly
little preferences like "where did the knob to switch off blinking
terminal cursor move /this/ time?"
Dealing with disruptive updates to a supposedly stable, released distro
version means time taken away from something else, when you're not
prepared to do so. For me, it means time away from developing rpm (ie
making the *next* version of Fedora hopefully that little bit better for
all). I don't want to have to spend time cherry-picking updates either, I
want to be able to just run "yum update" and trust that whatever it brings
in, fixes bugs important enough to warrant the update. Without having to
worry if I can still connect to company VPN afterwards to get my job done,
or having to figure out and explain to my wife how feature XYZ now works
after she applied the latest update-pile at a time it seemed convenient
for her to do but wasn't as the update brought in something unexpected.
And also just for the record, I'd be screaming bloody murder if the entire
desktop environment got changed one day in an "innocent little bugfix
update."
- Panu -
1:11 p.m.
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.
3:20 a.m.
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(a)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/
3:41 a.m.
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
3:54 a.m.
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(a)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/
4:27 a.m.
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
5:02 a.m.
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
noon
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
7:23 p.m.
Why? I don't want to update/reinstall all my machines every 6
months.
Since you don't want to update every 6 months, you want people to keep
updating every now and then?
Cheers,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
5:03 a.m.
On Sat, 6 Mar 2010 17:25:18 -0500, Orcan 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.
+1
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.
Those discussions have had only few participants. Don't jump to
conclusions.
It would be mad to throw away all the efforts that have been spent on
preparing F-11 and its choice of components. What has been built and
tested over several months, should not be replaced by over-ambitious
packagers who want to push upgrades to all released dists.
While it would be possible to replace *some* packages without the users
noticing any difference, replacing larger package sets (not limited to
frame-works) bears much more risks. Not only with regard to changed
behaviour [and breakage] at run-time, but also related to changing
dependencies in a way that might cause chain-reactions. E.g., suddenly you
cannot prepare a bug-fix for an App anymore, because its build
requirements have changed too much since F-11 release, and perhaps you
would need to run with a development snapshot instead.
For some packages there are additional dependencies in 3rd parties, and
don't forget users and developers. Any incompatibility an update creates
is bad. Interrupting the work-flow of distribution users and developers
is _bad_. Even an upgrade of a -devel package might change a directory
from /usr/include/foo-1.0 to /usr/include/foo-1.0.1 and require a
developer to reconfigure and rebuild a working-copy.
Of course there are exceptions, where upgrades may be necessary.
With the example of Audacious, it would have been a big mistake to push
2.1 (an official "stable" release that F-12 had been released with) to
upgrade F-11 which is still at 1.5.1. It has taken many bug-fixes to make
2.1 usable for the majority of bug-reporters on F-12, only to reach a
point where upstream decided to release 2.2 (another "stable" release)
including rewritten code and API changes, because of memory corruption
which they could not locate, and without ensuring that the problem is
fixed. And again, 2.2 resulted in bug-reports only after it hit F-12's
stable updates repo. So, once released I want to push bug-fix releases
quickly. Without arbitrary hurdles, such as an enforced halt in the
updates-testing repo, which doesn't help me with improving the software.
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.
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.]
10:15 a.m.
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
4:33 p.m.
On Sat, Mar 06, 2010 at 11:16:45PM +0100, Christoph Wickert wrote:
Am Samstag, den 06.03.2010, 19:38 +0100 schrieb Michał Piotrowski:
> 2010/3/6 Naheem Zaffar <naheemzaffar(a)gmail.com>:
> >
[snipped]
> > 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.
Nobody is talking about bugfix updates here. Bugfixes are always
allowed.
There are also proponents who want less bug fixes to lower the chances
of regressions. Btw. upstream releases most often contain bug fixes, even
if they also contain new features.
Regards
Till
2:51 a.m.
On Saturday 06 March 2010 19:38:16 Michał Piotrowski wrote:
2010/3/6 Naheem Zaffar <naheemzaffar(a)gmail.com>:
> 2010/3/6 Michał Piotrowski <mkkp4x4(a)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(a)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/
5:50 p.m.
Em Sáb, 2010-03-06 às 18:00 +0100, Christoph Wickert escreveu:
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!
Regards,
Christoph
A few days ago the discussion on policy updates are maturing and that it
is beneficial to Fedora, but it's useless to start threads with the
attitude of "pointing fingers and accusing" using an ironic tone.
--
Henrique Junior <henriquecsj(a)gmail.com>
6:54 p.m.
On Saturday 06 March 2010 03:50:22 pm Henrique Junior wrote:
A few days ago the discussion on policy updates are maturing and that
it
is beneficial to Fedora, but it's useless to start threads with the
attitude of "pointing fingers and accusing" using an ironic tone.
Agreed. Please stop starting flamewar threads, folks (it seems to be quite
intentional). All Fedora developers are people, too -- please remember to show
some respect.
Thanks,
--
Conrad Meyer <cemeyer(a)u.washington.edu>
1:55 a.m.
On Sat 6 March 2010 5:54:11 pm Conrad Meyer wrote:
All Fedora developers are people, too -- please remember to show
some respect.
"Be excellent to eachother"
http://fedoraproject.org/wiki/Overview#Our_Community
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
7:42 p.m.
On 6 March 2010 17:00, Christoph Wickert
<christoph.wickert(a)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?
12:51 p.m.
On 03/07/2010 02:42 AM, Jonathan Underwood wrote:
On 6 March 2010 17:00, Christoph Wickert
<christoph.wickert(a)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.
5154
days inactive
5158
days old
85 comments
26 participants
participants (26)
-
Adam Williamson -
Björn Persson -
Christoph Wickert -
Conrad Meyer -
Debarshi Ray -
Denis Leroy -
Dominik 'Rathann' Mierzejewski -
Henrique Junior -
Jaroslav Reznik -
Jesse Keating -
Jonathan Underwood -
Juha Tuomala -
Kalev Lember -
Michael Schwendt -
Michał Piotrowski -
Naheem Zaffar -
Orcan Ogetbil -
Panu Matilainen -
Peter Boy -
Rahul Sundaram -
Ryan Rix -
Susi Lehtola -
Thomas Janssen -
Till Maas -
Toshio Kuratomi -
Ville Skyttä