FESCo wants a more sane updates policy (feedback requested)
 

I'm putting my thoughts here... but this is again one of those threads
that has about 500 forks and people nit picking back and forth, so I am
never sure where to do a general reply. ;)

First some background:

a. There is no policy to discuss here, as we don't yet have a proposal.
I would expect after a draft is constructed it would be posted here for
feedback and more input.

b. Given a, I would say people should stop posting to this thread. If
you have a better updates policy in mind, perhaps you could draft up a
proposal for what you think it should be? Or wait for a real proposal
to comment on?

My thoughts (not speaking for fesco or anyone else):

- I think we are breaking our "stable" releases too much, and also
pushing them too many bits that they don't need/want. I've seen this
feedback a number of times from the various support channels, (irc,
forums, mailing list).

- I think educating our maintainers to be more carefull or get more
testing feedback has not worked so far, nor is it likely to moving
forward. We simply seem to lack the communications channel to do so.

- I think perhaps a more lifecycle like thing could help our users know
what to expect. Currently, they don't. They could get a major version
bump at any time, in a older "stable" release. I have talked to users
who are are f11 still because they think it will be "most stable" but
then are dismayed with how many updates they get.

- Perhaps we could look at ways to make rawhide more day to day
friendly. I think the autoqa stuff might help here. If those people
that needed the very newest version of everything could use rawhide,
perhaps we could target the stable releases more to those that want
them.

- From some of the comments here I am getting the idea that people
would like for us to move to a "2 tree" setup. Ie, "rawhide" and
"release". Things get tested in a cursory manner in rawhide, then get
pushed to release? Is that right? Perhaps someone could write up a
proposal for how such a flow could work? Do you think we would have
any users left in such a world?

- If stable pushes were more restricted, perhaps that would get us more
testing? If someone required a newer version and could easier
install/test from updates-testing and provide feedback, don't we all
win? Perhaps we could have PackageKit/yum say "you have the latest
stable version of foo, but foo-2.0 is in updates-testing, would you
like to test it and provide feedback?

- For those things that don't have many users, we could allow a time
based approach. keep the update in testing for a few weeks and then
it can go to stable with no -karma. I admit I run with
updates-testing enabled here, but usually only find time to provide -
karma. I have however done that a fair bit.

- This is a balancing act i think, we don't on the one hand want
everything always updated like rawhide in a stable release. On the
other hand we don't want to only provide security updates and nothing
else. What do our users expect here? I would argue that given the
decline in downloads and such they are clearly saying the status quo
is not what they want.

Anyhow I think this thread is mostly hot air unless there are specific
proposals or concrete feedback. Please write up a detailed proposal, or
wait and provide feedback when we have such? Or at least post new
ideas... not 'he said, she said' back and forths.

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

FESCo wants a more sane updates policy (feedback requested)
 

On Fri, Feb 26, 2010 at 03:54:02PM -0700, Kevin Fenzi wrote:

> b. Given a, I would say people should stop posting to this thread. If
> you have a better updates policy in mind, perhaps you could draft up a
> proposal for what you think it should be? Or wait for a real proposal
> to comment on?

Since AutoQA is supposed to to behaviour testing of packages eventually,
how about a policy that says:

A stable update to Fedora must pass all AutoQA tests.

Then the granularity of stability can be adjusted by adding tests to
AutoQA. And I hope that only reasonable tests will be added to AutoQA,
e.g. a test that just ensures that a packages stays at version X would
not be one. But if it ensures that e.g. "yum-builddep foo.src.rpm"
installs all build deps of foo, it would be a useful test.

> - I think educating our maintainers to be more carefull or get more
> testing feedback has not worked so far, nor is it likely to moving
> forward. We simply seem to lack the communications channel to do so.

If the maintainer receive more testing feedback, they probably won't
ignore it.

> - I think perhaps a more lifecycle like thing could help our users know
> what to expect. Currently, they don't. They could get a major version
> bump at any time, in a older "stable" release. I have talked to users
> who are are f11 still because they think it will be "most stable" but
> then are dismayed with how many updates they get.

Pushing less updates to F(current-1) is probably something many
maintainers can live with. But I have also heard of people using
F(current-1) and feeling like secondary users, because they did not get
the updates that F(current) got.

> - Perhaps we could look at ways to make rawhide more day to day
> friendly. I think the autoqa stuff might help here. If those people
> that needed the very newest version of everything could use rawhide,
> perhaps we could target the stable releases more to those that want
> them.

There will always be updates in Rawhide that are not meant to be
consumed directly or without manual intervention.

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

FESCo wants a more sane updates policy (feedback requested)
 

Till Maas wrote:
> Pushing less updates to F(current-1) is probably something many
> maintainers can live with. But I have also heard of people using
> F(current-1) and feeling like secondary users, because they did not get
> the updates that F(current) got.

Yes. IMHO the old stable release deserves the same level of support as the
current one. As long as it's supported, it should get updates. People may
not be ready for the disruptive changes in the current stable release, that
doesn't mean they don't want to continue receiving the non-disruptive
updates!

(So I'm also not a fan of the suggestion to only push KDE upgrades to the
current stable release and not the previous stable one.)

Kevin Kofler

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

FESCo wants a more sane updates policy (feedback requested)
 

On 26 February 2010 22:54, Kevin Fenzi <kevin@scrye.com> wrote:
> - If stable pushes were more restricted, perhaps that would get us more
> *testing? If someone required a newer version and could easier
> *install/test from updates-testing and provide feedback, don't we all
> *win? Perhaps we could have PackageKit/yum say "you have the latest
> *stable version of foo, but foo-2.0 is in updates-testing, would you
> *like to test it and provide feedback?

I had PK code to do that, but the check for updates took way too long,
as the updates-testing repo had to be enabled, the primaries
downloaded (and maybe the file lists too), updates resolved and then
disabled again, in ADDITION to the normal updates check. The package
manager is just too slow to get PackageKit data to make such a thing
work without making the user wait an extra 30 seconds.

If we could speed up the dep checking and downloading, I agree it
would be better for usability, and the exposure of updates-testing
generally.

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

FESCo wants a more sane updates policy (feedback requested)
 

On Fri, Feb 26, 2010 at 11:54 PM, Kevin Fenzi <kevin@scrye.com> wrote:
> I'm putting my thoughts here... but this is again one of those threads
> that has about 500 forks and people nit picking back and forth, so I am
> never sure where to do a general reply. ;)

There has been a draft a while ago which did not result into much discussion ..

http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience

Which looks pretty sane to me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

FESCo wants a more sane updates policy (feedback requested)
 

On 02/27/2010 04:21 PM, Richard Hughes wrote:
> On 26 February 2010 22:54, Kevin Fenzi <kevin@scrye.com> wrote:
>> - If stable pushes were more restricted, perhaps that would get us more
>> testing? If someone required a newer version and could easier
>> install/test from updates-testing and provide feedback, don't we all
>> win? Perhaps we could have PackageKit/yum say "you have the latest
>> stable version of foo, but foo-2.0 is in updates-testing, would you
>> like to test it and provide feedback?
>
> I had PK code to do that, but the check for updates took way too long,
> as the updates-testing repo had to be enabled, the primaries
> downloaded (and maybe the file lists too), updates resolved and then
> disabled again, in ADDITION to the normal updates check. The package
> manager is just too slow to get PackageKit data to make such a thing
> work without making the user wait an extra 30 seconds.
>
> If we could speed up the dep checking and downloading, I agree it
> would be better for usability, and the exposure of updates-testing
> generally.
>

This sounds interesting, was this a plugin or configuration setting?
Could this be something people can opt-in to at first?

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

FESCo wants a more sane updates policy (feedback requested)
 

On 27 February 2010 19:31, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:
> This sounds interesting, was this a plugin or configuration setting?
> Could this be something people can opt-in to at first?

in /etc/PackageKit/PackageKit.conf, the idea was to set
CheckTestingRepos to true. I'm not sure the code is actually reading
this config setting yet, so if you want it to work you might have to
contribute some python. :-)

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

FESCo wants a more sane updates policy (feedback requested)
 

On Sat, 2010-02-27 at 15:21 +0000, Richard Hughes wrote:
> On 26 February 2010 22:54, Kevin Fenzi <kevin@scrye.com> wrote:
> > - If stable pushes were more restricted, perhaps that would get us more
> > testing? If someone required a newer version and could easier
> > install/test from updates-testing and provide feedback, don't we all
> > win? Perhaps we could have PackageKit/yum say "you have the latest
> > stable version of foo, but foo-2.0 is in updates-testing, would you
> > like to test it and provide feedback?
>
> I had PK code to do that, but the check for updates took way too long,
> as the updates-testing repo had to be enabled, the primaries
> downloaded (and maybe the file lists too), updates resolved and then
> disabled again, in ADDITION to the normal updates check. The package
> manager is just too slow to get PackageKit data to make such a thing
> work without making the user wait an extra 30 seconds.

I can't think of any reason why you'd need, or want, to have
updates-testing checks block any other GUI operation.

> If we could speed up the dep checking and downloading, I agree it
> would be better for usability, and the exposure of updates-testing
> generally.

Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300
packages here and lsuT is like 2.5 seconds. I guess maybe that's worth
caring about if you block everything else behind it, but...

As to the downloads, if you know of a way to speed up a users internet
connection ... feel free to spread your wisdom.


¹ We also have an optimisation for large updates, that we can probably
turn on for F13.

--
James Antill - james@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

FESCo wants a more sane updates policy (feedback requested)
 

drago01 wrote:
> There has been a draft a while ago which did not result into much
> discussion ..
>
> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>
> Which looks pretty sane to me.

It looks very insane to me:
* only critical bugfixes, security fixes and hardware enablement for an
arbitrary class of "system" packages which isn't defined anywhere. Not even
general bugfixes! IMHO that's not at all what Fedora is or should be about.
* only weekly pushes. We should target daily pushes. Our current pushes are
too rare, not too frequent. People who only want to update once a week
should just only update once a week. I don't see how us pushing once a day
would be a problem for them! It's important to push updates as frequently as
possibles so users get to decide when to update. We shouldn't decide for
them. Some users may want to update on Tuesdays, others on Sundays, others
(like me) as often as possible. Daily (or more frequent, but our
infrastructure would probably not like that) updates make that possible.
Weekly pushes force an arbitrary weekday onto everybody.
* application enhancement updates "at the discretion of the upstream brand"?
Why should it be upstream's business what updates we push in our
distribution?

Sorry, but as I already said back when this was originally proposed, that
proposal makes no sense whatsoever to me.

Kevin Kofler

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

FESCo wants a more sane updates policy (feedback requested)
 

On 02/28/2010 06:25 PM, Kevin Kofler wrote:
> drago01 wrote:
>> There has been a draft a while ago which did not result into much
>> discussion ..
>>
>> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>>
>> Which looks pretty sane to me.
>
> It looks very insane to me:
> * only critical bugfixes, security fixes and hardware enablement for an
> arbitrary class of "system" packages which isn't defined anywhere. Not even
> general bugfixes! IMHO that's not at all what Fedora is or should be about.
> * only weekly pushes. We should target daily pushes. Our current pushes are


Frankly for system packages we have

1) kernel (+perf, dracut grubby)
2) core daemons(e.g. dns, sendmail, nfs)

3) application daemons (e.g. apache, pulseaudio).

Kernel should follow mainline stable - as reasonably soon after
release and our testing as possible.

Core daemons - ditto.

Application Daemons - i have no strong feeling on ..
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel