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-09-2010, 01:43 AM
Ralf Corsepius
 
Default Proposed udpates policy change

On 03/09/2010 12:53 AM, Jesse Keating wrote:
> On Mon, 2010-03-08 at 18:45 -0500, Steven M. Parrish wrote:
>> As a maintainer I have seen several of my packages sit in updates testing for
>> over 2 weeks with no comments and no karma. In fact they sat so long I got
>> nag mail about not pushing them. Requiring a karma of +3 to push is just not
>> going to work by itself. If anything it should be 'An update cannot be pushed
>> to stable until either it reaches a Karma of +3 or it has been in updates
>> testing for 14 days with no negative karma."
>
> There is a chicken/egg problem here. Karma isn't required, ergo it
> doesn't happen. If karma is required, we might see an increase in karma
> registered, as well as an uptick in tools development to help provide
> karma (we're already seeing this in F13, one could conclude that part of
> that is because karma is required for critpath packages).

=> All you're going to see is further bureaucracy and bureaucratic
overhead, but you'r not going to see better package quality.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 03:41 AM
Jon Masters
 
Default Proposed udpates policy change

Hi Matthew,

Thank you to you, Josh, and others for putting effort into these
discussions. And thanks for bringing this up in the meeting tomorrow.
Some comments inline below that might be useful, or not.

Before I get into what you wrote, can I also suggest asking Fedora users
what they want? We already have an announce list, and we have things
like firstboot, and the fedoraproject start page. It would be *trivial*
to post a survey up on the website that most users are going to see, for
the next few months, and collate actual responses from end Fedora users.
If they want rolling updates, so be it and some of us are "wrong". But
for goodness sake, let's actually ask the users about it.

On Mon, 2010-03-08 at 21:59 +0000, Matthew Garrett wrote:

> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.

Indeed. I believe this is the number one problem right now. The problem
is that a single package update can introduce compound issues with other
packages that were unforeseen and untested, especially the latter. This
is an issue even for the "slow moving" Enterprise distros, and they have
entire teams of people paid to do very thorough testing before pushing
each individual update. Fedora can't quite do that, but I believe that
is therefore even more of a reason to slow down the update pace. After
all, there's a new release in 6 months, not years later (as would be the
case with an enterprise distro). I'd rather wait 6 months for some
feature than have to take time out of the day to fix a stable box.

> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

I believe that this is possibly too limited. Aside from the obvious
abuse potential (which will always exist no matter what happens) -
obviously someone could just hate the process and decide to have a
couple of others sign off on everything no matter what - I think it
should be necessary to have a cooling off period between pushing an
update, it being voted on, and it going out live. It doesn't have to be
weeks, but it should be long enough for the person who actually reported
some bug to test that it is fixed and for others who aren't able to
devote time every day to see the update. I suggest 3-5 days.

I also suggest /considering/ implementing rolling updates rather than
pushing everything to stable. By rolling updates, in this case I mean
implementing a technical means (and this is tricky with mirrors) by
which not every user will receive the update at once. Perhaps PackageKit
already does something with random deltas for non-security updates. I
usually do updates myself manually (I upgrade stable Fedora systems only
when I am certain to have time to reboot, and then I will bite the
bullet and apply many updates at once) so I haven't noticed that.

> Defining the purpose of Fedora updates is outside the scope of Fesco.
> However, we note that updates intended to add new functionality are more
> likely to result in user-visible regressions, and updates that alter ABI
> or API are likely to break local customisations even if all Fedora
> packages are updated to match. We encourage the development of
> mechanisms that ensure that users who wish to obtain the latest version
> of software remain able to do so, while not tending to introduce
> functional, UI or interface bugs for users who wish to be able to
> maintain a stable platform.

It might be worth /considering/ something like "volatile" on other
distros. I know that's mostly for anti-spam type stuff. But perhaps some
parallel stream similar to updates-testing where users can elect to have
new features if they want them, or retain the stable release (in which
case all they get is security fixes). Basically, fedora-updates becomes
literally a separate stream disjoint from the regular fedora stream.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:43 AM
Terry Barnaby
 
Default Proposed udpates policy change

On 08/03/10 23:12, Matthew Garrett wrote:
> On Mon, Mar 08, 2010 at 11:21:45PM +0100, Sven Lankes wrote:
>>
>> If Fesco is aiming at getting rid of all the pesky packagers maintaining low
>> profile packages: You're well on your way.
>
> So, no, that's not the intent and it's realised that this is a problem.
> We need to work on making it easier for users to see that there are
> available testing updates and give feedback on them. This is clearly
> going to take a while, and there'd undoubtedly going to be some
> difficulty in getting updates for more niche packages through as a
> result. If people have further suggestions for how we can increase the
> testing base then that would be awesome, but the status quo really
> doesn't seem sustainable.
>

Can I make a tangential suggestion here ?
I am on the side that quite a few packages need much more testing before
they appear in stable. Fedora, for me, has got less and less stable
and thus less usable. I have been bitten for many years, especially by
the Graphics issues

However, to get testing done it actually requires a good many users to
actually test the packages. This requires it to be easy for the user to do.
This is especially true for the Graphics system where testing is needed
on lots of different hardware.

I wonder if a change to the Fedora package build/release systems could
help here by more closely coupling Bodhi/Others with updates-testing.
Some ideas:

1. All packages in Bodhi automatically appear in updates-testing.
2. The karma (or stability ) value is stored in the RPM.
3. A link to the Bodhi information is also stored in the RPM.
4. yum/rpm is modified to support the idea of a
"karma"/"package stability level".
5. Users can change the "package stability level" they are willing to accept
overall or on a per package or package group basis.
6. Simple GUI package manager extensions could handle the extra info or a simple
to use "package-testing" GUI could be developed to handle this allowing users
to feedback issues in an easy way.
7. There would be an easy way for users to backout the duff packages.
(emails back to the user when an updated package is available ?)
8. A link with upstream would be provided so any user generated feedback
would be sent to the upstream developers or be easily available by
them. Bugzilla would be integrated into this.
9. Bodhi information would include info on particular items to test.

This would mean that all packages are immediately available to end users
in an easy to use way. Users could decide how "frontier" they would like their
system. Links to the Bodhi information would directly available to users
allowing feedback of issues and backout the packages. It would also
be nice to have package groups such as
"Graphics: kernel,libdrm,mesa,xorg-x11-* etc) so that an entire group of
related packages could be karma'ed, installed and reverted in an easy way.
In the background the system can check for package dependency issues and
notify the package managers automatically. Obviously how the "kama"/"package
stability level" is calculated is an issue. In fact updates-testing could
probably go and we would just have updates ...

Any views, anyone got some financial resources

Terry

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:28 AM
Michal Schmidt
 
Default Proposed udpates policy change

On Mon, 08 Mar 2010 23:41:44 -0500 Jon Masters wrote:
> I also suggest /considering/ implementing rolling updates rather than
> pushing everything to stable. By rolling updates, in this case I mean
> implementing a technical means (and this is tricky with mirrors) by
> which not every user will receive the update at once.

Hi Jon,
please do not overload the term 'rolling updates'. That's just
confusing. Perhaps 'staggered' would convey your intended meaning
better.

But what do you mean to accomplish with it?
I guess when an update with an unforseen serious regression gets pushed
to updates you want to give us a chance to react before too many users
download it.

When the broken dbus update fiasco happened it was frustrating to know
that people in one time zone after another upgrade to the broken
build even though the regression was already known. The fixed build may
have been done quickly, but because of the long time it takes from
building a package to have it appear in updates on mirrors there was
not much Fedora could do to limit the damage.

If it is not possible to shorten the minimal from-Koji-to-mirrors delay
to something on the order of one hour (wouldn't that be awesome?), then
perhaps there should be a way to blacklist known brown-paper-bag
updates in the metalinks (which are not affected by the delay). I
believe this would be more useful than staggered updates.

Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:41 AM
Alexander Kahl
 
Default Proposed udpates policy change

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/09/2010 12:12 AM, Matthew Garrett wrote:
> ...
> We need to work on making it easier for users to see that there are
> available testing updates and give feedback on them. This is clearly
> going to take a while

.. but should happen before the actual policy change takes place. I'm
afraid the impact without proper arrangements won't only be frustrated
maintainers realizing how many weaknesses from parliamentarism (does
your acting reflect the grass roots' desires?) Fedora has to bear but
also loss of distribution superiority with many packages gone or
forsaken by never or far too late being pushed to stable.

QA enforcement works well for businesses were people get actually paid
for reviewing and testing stuff before going out to customers but since
Fedora is (mainly) a community-driven distribution this mechanism should
be provided opt-in / opt-out and enforced only where major system
breakage may occur, coincidentally this is where many users are actually
in place to give Karma (e.g. who doesn't use glibc?).

Why not provide a mechanism to count the approximate number of users for
a package first, coupling this with the minimum Karma automatism - where
low-profile packages are excluded from this by not reaching a minimum
threshold? This approach would be sophisticated, sensible and IMO easily
accepted by the majority of users and maintainers.

- --
Alexander Kahl
GNU/Linux Software Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuWCcQACgkQVTRddCFHw10KGgCglDxJA4U7hw 0Q6LN39JT+Hv4C
TkoAoIwIKawBDPnXeFZr0eSkcl500z9C
=W34l
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 07:52 AM
Dan Horák
 
Default Proposed udpates policy change

Matthew Garrett p*še v Po 08. 03. 2010 v 21:59 +0000:
> This is the policy that I expect to be discussed during the Fesco
> meeting tomorrow. This is entirely orthogonal to the ongoing discussions
> regarding whether updates in stable releases should be expected to
> provide features or purely bugfixes, and I don't see any conflict in
> introducing it before those discussions have concluded.
>
> Introduction
> ------------
>
> We assume the following axioms:

I think first should come the answer on "what problem is this proposal
trying to solve?". Is it the plain number of updates? Is it the quality
of updates? What updates failed?

> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.
>
> 2) It is impossible to ensure that functionality will not be reduced
> without sufficient testing.
>
> 3) Sufficient testing of software inherently requires manual
> intervention by more than one individual.
>
> Proposal
> --------
>
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

Unfortunately this tries to use the "one size fits all" method, but this
can't work in the recent Fedora with the number of source packages
attacking the 10000 mark. And for sure there are packages with many
users (millions?) and on other side packages with few users (dozens or
even less). And as others said, sometimes it's hard to get even a
response from the reporter on his own bug ...

> It should be noted that this does not require that packages pass through
> updates-testing. The package will appear in Bodhi as soon as the update
> is available. If sufficient karma is added before a push occurs, and the
> update is flagged for automatic pushing when the karma threshold is
> reached, the update will be pushed directly to updates.
>
> It is the expectation of Fesco that the majority of updates should
> easily be able to garner the necessary karma in a minimal space of time.
> Updates in response to functional regressions should be coordinated with
> those who have observed these regressions in order to confirm that the
> update fixes them correctly.

Yes, this can again work for the mainstream packages and not for the
rest. And as result the only way to get a newer version of a
non-mainstream package will be only to upgrade the whole distro with a
waiting time up to 6 months. The new release contains both bugfixes and
new features, because the author can't maintain multiple branches at a
time and is doing releases every few months - one of the open source
principles was release early, release often.

So what are the options if the situation is so serious that something
must be done:
- start automated testing of updates - let the machine work, it can do a
lot
- divide packages into more tiers - add one(?) level between critpatch
and the rest that would require better testing (for example containing
libraries used by another package), some statistics how much are
packages installed would be needed
- start creating personal repos with updated stuff - and I always
thought this is the wrong way that is used by other distros and their
users ...
- improve the updates delivery mechanism so the user can easily consume
the regular updates and also test and comment the non-stable ones, this
would also require educating the users that there can be a newer version
in updates-testing when they are not satisfied with the stable one
- every package must have a QA person, well at least 3 ...

And yes, there are some not very nice options too ...


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 08:04 AM
Thomas Janssen
 
Default Proposed udpates policy change

On Mon, Mar 8, 2010 at 11:21 PM, Sven Lankes <sven@lank.es> wrote:
> On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
>
>> Before being added to updates, the package must receive a net karma of
>> +3 in Bodhi.
>
> [...]
>
>> It is the expectation of Fesco that the majority of updates should
>> easily be able to garner the necessary karma in a minimal space of time.
>
> I don't know what to say.
>
> If Fesco is aiming at getting rid of all the pesky packagers maintaining low
> profile packages: You're well on your way.

Very well said.

What i clearly miss is the Boards vision given to FESCo. Or am i wrong
here and it's FESCo who decides what will happen and the Board says,
well yeah, lets try that. We can always clean up and change it after
the train wreck? Or does the Board have nothing to do with it at all?

Well, a clean up isn't needed if it becomes a train wreck, it will be
already cleaned out.

Or with other words, is there a statement of the Board, officially
making clear what *they* want, with a link to it?
What FESCo want is clear meanwhile. By the way, is there some
documentation on how to vote out particular FESCo members and who can
do it? Just in case one thinks that a particular member of FESCo is
wrongly voted in. Or is that like with politicians, once elcected you
lost.
Same question for Board members.

Thanks in advance.

P.s. I hope it's clear that this is not trolling, but searching for
some clarity on the hierarchy and what the small developer can do if
he feels something is wrong.

--
LG Thomas

Dubium sapientiae initium
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 08:19 AM
Christof Damian
 
Default Proposed udpates policy change

On Tue, Mar 9, 2010 at 00:53, Jesse Keating <jkeating@redhat.com> wrote:
> On Mon, 2010-03-08 at 18:45 -0500, Steven M. Parrish wrote:
>> As a maintainer I have seen several of my packages sit in updates testing for
>> over 2 weeks with no comments and no karma. *In fact they sat so long I got
>> nag mail about not pushing them. *Requiring a karma of +3 to push is just not
>> going to work by itself. *If anything it should be 'An update cannot be pushed
>> to stable until either it reaches a Karma of +3 or it has been in updates
>> testing for 14 days with no negative karma."
>
> There is a chicken/egg problem here. *Karma isn't required, ergo it
> doesn't happen. *If karma is required, we might see an increase in karma
> registered, as well as an uptick in tools development to help provide
> karma (we're already seeing this in F13, one could conclude that part of
> that is because karma is required for critpath packages).

I think the 14 days with no negative karma is a good solution. At
least for the packages I maintain. That is the way I use it manually
at the moment, I push packages to stable once I get the nag mail. I
also started to do mayor updates only to rawhide, enhancements to F-12
and security/mayor bug-fix updates to F-11.

I maintain mainly php-qa packages. I never received any karma for
those. So far I haven't received a single bug report. I might be the
only person using those packages (I hope not - is there any way to
find out?).

I like the idea of easy karma scripts, but these will only help for
packages which are used every day by a number of persons which are
prepared to use update-testing.

This could mean that I will only add new versions to rawhide and
simply ignore any F-XX. This would save me a lot of time, but is
probably not what users are looking for.

Cheers,
Christof
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 08:48 AM
Jon Masters
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 09:28 +0100, Michal Schmidt wrote:
> On Mon, 08 Mar 2010 23:41:44 -0500 Jon Masters wrote:
> > I also suggest /considering/ implementing rolling updates rather than
> > pushing everything to stable. By rolling updates, in this case I mean
> > implementing a technical means (and this is tricky with mirrors) by
> > which not every user will receive the update at once.

> please do not overload the term 'rolling updates'. That's just
> confusing. Perhaps 'staggered' would convey your intended meaning
> better.

Agreed. Henceforth corrected because I didn't really want to go there.

> If it is not possible to shorten the minimal from-Koji-to-mirrors delay
> to something on the order of one hour (wouldn't that be awesome?), then
> perhaps there should be a way to blacklist known brown-paper-bag
> updates in the metalinks (which are not affected by the delay). I
> believe this would be more useful than staggered updates.

You got exactly what I meant. I also think Terry's suggestion of
stability levels can easily be encoded in metadata in the yum repo, if
anyone wanted to do that. Then it could dynamically change as people
voted in Bodhi, and I could set a threshold of something awesomely high
for applying updates, or say "wait until it's a week old first"

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 08:51 AM
Joe Orton
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> It is the expectation of Fesco that the majority of updates should
> easily be able to garner the necessary karma in a minimal space of time.

This seems naive to me. My experience is that there are few people
willing to provide testing karma, even for relatively high-profile
packages. It took about three months to get as many people to submit
positive testing results for an httpd F-11 update in updates-testing
recently.

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

Thread Tools




All times are GMT. The time now is 07:06 AM.

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