FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-05-2010, 05:10 PM
Kevin Kofler
 
Default how to make things better(tm)

Adam Williamson wrote:

> On Fri, 2010-03-05 at 11:25 +0100, Thomas Janssen wrote:
>> The nepomuk problem some face is something that falls under, damn,
>> that shouldn't happen, but sh!t happens. I saw a lot more and even
>> terrible stuff happen in Fedora.
>
> So first you claim there's no regressions, then you acknowledge a
> specific one and excuse it by saying 'shit happens'? And 'I saw a lot
> more and even terrible stuff happen in Fedora'? The whole point of the
> discussion is that not everyone is happy that 'shit happens', and some
> wish to reduce the about of 'terrible stuff' that happens in Fedora.

Assuming he's talking about this problem:
http://userbase.kde.org/Akonadi#Nepomuk_Indexing_Agents_have_been_Disabled
then I'd argue this is not a noticeable regression for most users if it
weren't for the annoying message box.

As of 4.4 (4.5 will probably need both Akonadi and Akonadi's Nepomuk
integration for more stuff, but we aren't pushing 4.5 any time soon, there
isn't even any alpha or beta release of it yet), if you don't happen to use
some contacts-related features ("ranging from displaying upcoming birthdays,
over handling free/busy lists to showing a contact photo in the message
viewer" according to upstream), the only thing you'll notice is the message
box. If you do use those features, the message box tries to tell you what's
wrong and how to fix it (but admittedly does a very poor job of it), so
there's a pretty straightforward workaround.

That said, we have acknowledged the annoyance factor (which we had
underestimated) and we also had apparently underestimated the reduction in
functionality from not having Nepomuk running (we thought it was only used
for searches). Updates to our default settings rectifying this (by enabling
Nepomuk by default) are now queued for testing:
https://admin.fedoraproject.org/updates/kde-settings-4.3-18
https://admin.fedoraproject.org/updates/kde-settings-4.2-18

We apologize for the inconvenience and we acknowledge that we made a
mistake, but still I personally think this issue has been way overblown.
I've seen other annoying incomprehensible message boxes in Fedora in the
past, and Window$ (which many people believe is "user friendly") is full of
them.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 05:16 PM
Thomas Janssen
 
Default how to make things better(tm)

On Fri, Mar 5, 2010 at 7:07 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
>> On 03/05/2010 03:25 PM, Thomas Janssen wrote:
>> > So i (and others who think like me), have no reason to use Fedora
>> > over one of the other mainstream Distros if Fedora is the same. And
>> > we will not get users like me if we dont offer that. Sure, there
>> > might be people who dont give a darn about people like me.
>>
>> Well, that's a rather specialized taste.
>>
> And since I was lost at the previous step, I wonder here what you think
> Thomas wants that's rather specialized. *If you think it's "drink from the
> firehose" and that == rawhide, I agree that that's specialized. *If it's
> semi-rolling updates, then I think that's not so specialized at all.

I want semi-rolling updates

--
LG Thomas

Dubium sapientiae initium
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 05:27 PM
Jesse Keating
 
Default how to make things better(tm)

On Fri, 2010-03-05 at 13:07 -0500, Toshio Kuratomi wrote:
> And since I was lost at the previous step, I wonder here what you think
> Thomas wants that's rather specialized. If you think it's "drink from the
> firehose" and that == rawhide, I agree that that's specialized. If it's
> semi-rolling updates, then I think that's not so specialized at all.

Some of us feel that the current rate of updates on our released
Fedoras /is/ a firehose.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 05:40 PM
Rajeesh K Nambiar
 
Default how to make things better(tm)

On Fri, Mar 5, 2010 at 9:53 PM, Adam Williamson <awilliam@redhat.com> wrote:
> On Fri, 2010-03-05 at 21:47 +0530, Rajeesh K Nambiar wrote:
>
>> > That's because you're misreading Rahul's claims. Rahul was replying to a
>> > post which claimed Fedora has a 'policy' of being 'bleeding edge'.
>>
>> Uh, oh - it wasn't *a *claim*. Its just the popular saying, urban
>> myth, a general feeling - you name it. It wasn't literal, just
>> figurative, I hope you understand the essence.
>
> Uh, what? How does what you said relate to what I said in any way?

Sorry for causing confusion - Rahul made that statement in reply to my
comment. That's how it was related.

>
> Rahul wasn't claiming that Fedora has a strict conservative update
> policy. He was pointing out that Fedora does *not* have a strict
> bleeding-edge policy. Wherein is that 'urban myth', 'popular saying', 'a
> general feeling', or 'figurative'?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



--
Cheers,
Rajeesh
http://rajeeshknambiar.wordpress.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 05:56 PM
Kevin Kofler
 
Default how to make things better(tm)

Bill Nottingham wrote:
> If we are going down the road of providing absolute-latest-versions on
> older releases, perhaps not pushing it to prior releases until it's
> actually been in wide use on the next release? So, you have, for example:
>
> - new version 4.6
> -> push it to rawhide, get testing
> -> get new Fedora release with that version
> --> get *even more testing*, make needed fixes
>
> And only *then* do you push it to the prior releases, once it's actually
> proven that it's not going to break things for the widest group of users.
> It lets you not only use the rawhide adopters, who expect major change,
> but the next-release early adopters, who also expect adjustments on moving
> to a next major release.

The problem is that this translates to a LOT more work for us. By pushing to
both releases at the same time, we can build things together, do the
buildroot overrides together, queue things to testing together, promote them
to stable together. Doing things in the staged way would mean almost twice
the workload (especially in terms of time expense) for us. :-(

In addition, we already got 4.4.0 out only barely before 4.4.1 was released.
If we had staged it as you propose, we'd now be stuck with having to do one
of 2 things:
A. push 4.4.0 into F11 and 4.4.1 into F12. This means:
- we'd be working on 2 different releases at the same time, which would
stretch our resources quite a lot,
- F11 would end up with a KDE "update" which is already obsolete when
pushed, and in particular includes known bugs which are fixed in the bugfix
release that 4.4.1 is.
B. skip 4.4.0 in F11 and go straight to 4.4.1. This means:
- we'd be shipping the same release, but in one case as a big update with
many other related packages to update, and in another case as a bugfix
release. This also means 2 very different updates to prepare at the same
time and would also stretch our resources quite thin.
- the F11 update would either not be staged compared to the F12 4.4.1 one,
or the wait for 4.4 would be even longer than a month.

Support would also get more complicated with the 2 current versions in
circulation simultaneously. Right now, if something's fixed in F12, it's
also fixed in F11 and vice-versa, and we can in general expect our users to
all run the same KDE (unless they just haven't updated yet).

And finally, those F11 users who want 4.4 would feel treated like second-
class citizens for having to wait longer, those who don't want it just don't
want it at all, staged or not.

So I don't think staged updates are a workable solution (there's a reason
almost no maintainer works that way at this time).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 07:18 PM
Toshio Kuratomi
 
Default how to make things better(tm)

On Fri, Mar 05, 2010 at 12:55:23PM -0500, Bill Nottingham wrote:
> Orcan Ogetbil (oget.fedora@gmail.com) said:
> > There is one more thing. Very important thing. We have been pushing
> > KDE releases asap so far, and although it hurt me at times (at school
> > and at work), I like it. I don't blame people who don't. Here is the
> > thing: The bugs need to be reported most of the time to get fixed.
> > Fedora has been a pioneer in KDE development in this sense. If we
> > don't push 4.x.0 releases to stable, the 4.x.1 will be more buggy,
> > since not many distros do kde 4.x.0 updates to their stable releases.
> > Someone has to make some sort of sacrifice but I cannot come up with a
> > good-for-all resolution for this issue.
>
> If we are going down the road of providing absolute-latest-versions on
> older releases, perhaps not pushing it to prior releases until it's
> actually been in wide use on the next release? So, you have, for example:
>
> - new version 4.6
> -> push it to rawhide, get testing
> -> get new Fedora release with that version
> --> get *even more testing*, make needed fixes
>
> And only *then* do you push it to the prior releases, once it's actually
> proven that it's not going to break things for the widest group of users.
> It lets you not only use the rawhide adopters, who expect major change,
> but the next-release early adopters, who also expect adjustments on moving
> to a next major release.
>
There's multiple ways this could look since we have multiple repos. Does
this look like you are imagining?

1) Build for rawhide, F-14, F-13
2) Push to updates-testing on F-14 and F-13
2.1) Testing period. If bugs are found and fixed go back to (1)
3) Push F-14 to updates/release
3.1) Testing period. If bugs are found and fixed go back to (1)
4) Push to F-13 updates.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 07:46 PM
Bill Nottingham
 
Default how to make things better(tm)

Toshio Kuratomi (a.badger@gmail.com) said:
> > If we are going down the road of providing absolute-latest-versions on
> > older releases, perhaps not pushing it to prior releases until it's
> > actually been in wide use on the next release? So, you have, for example:
> >
> > - new version 4.6
> > -> push it to rawhide, get testing
> > -> get new Fedora release with that version
> > --> get *even more testing*, make needed fixes
> >
> > And only *then* do you push it to the prior releases, once it's actually
> > proven that it's not going to break things for the widest group of users.
> > It lets you not only use the rawhide adopters, who expect major change,
> > but the next-release early adopters, who also expect adjustments on moving
> > to a next major release.
> >
> There's multiple ways this could look since we have multiple repos. Does
> this look like you are imagining?
>
> 1) Build for rawhide, F-14, F-13
> 2) Push to updates-testing on F-14 and F-13
> 2.1) Testing period. If bugs are found and fixed go back to (1)
> 3) Push F-14 to updates/release
> 3.1) Testing period. If bugs are found and fixed go back to (1)
> 4) Push to F-13 updates.

Something like that, yes. The idea is that before it goes out to a prior
release, we make sure it's been proven with some level of stability on
a new release first.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 08:24 PM
Toshio Kuratomi
 
Default how to make things better(tm)

On Fri, Mar 05, 2010 at 10:27:53AM -0800, Jesse Keating wrote:
> On Fri, 2010-03-05 at 13:07 -0500, Toshio Kuratomi wrote:
> > And since I was lost at the previous step, I wonder here what you think
> > Thomas wants that's rather specialized. If you think it's "drink from the
> > firehose" and that == rawhide, I agree that that's specialized. If it's
> > semi-rolling updates, then I think that's not so specialized at all.
>
> Some of us feel that the current rate of updates on our released
> Fedoras /is/ a firehose.
>
That's fine for some people to think but also, not what I was asking Andrew
to clarify :-)

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:48 AM
Andrew Haley
 
Default how to make things better(tm)

On 03/05/2010 06:07 PM, Toshio Kuratomi wrote:
> On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
>
>> I suspect that the Fedora policy, as stated, makes the most sense for
>> most people who use Fedora. There is no rule against pushing new
>> package releases to updates, but they're not pushed unless there's a
>> good reason.
>>
> Agreed here as well. Proper emphasis on "reason" -- there should be
> a reason other than upstream has a new release but there's a lot of
> leeway for the maintainer to decide if the reason::risk ratio is
> okay.

OK, so we are on the same page.

>> Fedora is a really good full-featured Linux distro with
>> an aggressive release cycle, even without a continuous
>> drinking-from-a-firehose updates policy.
>
> This is where I'm a bit confused.... AFAICS, no one has pushed for
> a drink-from-the-firehose policy.

Really? Rajeesh K Nambiar wrote about the "latest-and-greatest,
bleeding edge policy of Fedora." Thomas Janseen was arging against
Rahul Sundaram's perfectly reasonable reminder of the current package
update guidelines.

>>> So i (and others who think like me), have no reason to use Fedora
>>> over one of the other mainstream Distros if Fedora is the same. And
>>> we will not get users like me if we dont offer that. Sure, there
>>> might be people who dont give a darn about people like me.
>>
>> Well, that's a rather specialized taste.

> And since I was lost at the previous step, I wonder here what you
> think Thomas wants that's rather specialized. If you think it's
> "drink from the firehose" and that == rawhide, I agree that that's
> specialized. If it's semi-rolling updates, then I think that's not
> so specialized at all.

Perhaps not, but disagreeing with such an eminently sensible message as
Rahul's makes me wonder.

Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 07:39 PM
Thomas Janssen
 
Default how to make things better(tm)

On Sat, Mar 6, 2010 at 12:48 PM, Andrew Haley <aph@redhat.com> wrote:
> On 03/05/2010 06:07 PM, Toshio Kuratomi wrote:
>> On Fri, Mar 05, 2010 at 05:10:41PM +0000, Andrew Haley wrote:
>>> Well, that's a rather specialized taste.
>
>> And since I was lost at the previous step, I wonder here what you
>> think Thomas wants that's rather specialized. *If you think it's
>> "drink from the firehose" and that == rawhide, I agree that that's
>> specialized. *If it's semi-rolling updates, then I think that's not
>> so specialized at all.
>
> Perhaps not, but disagreeing with such an eminently sensible message as
> Rahul's makes me wonder.

Perhaps you got only the half of the message, and perhaps because i
wrote it especially to Rahul

Anyways. I think it's clear now.

--
LG Thomas

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

Thread Tools




All times are GMT. The time now is 01:36 AM.

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