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-08-2010, 10:05 PM
Matthias Clasen
 
Default Proposed udpates policy change

On Mon, 2010-03-08 at 23:45 +0100, Michael Schwendt wrote:

> Also important, Matthew even fills a FESCo seat. Proposals like that are not
> what I expect from FESCo members. I'm severely disappointing.

Just to even things out: I am very happy with this proposal, and it is
exactly what I expect from FESCo members.

One thing that could perhaps be added is a hint that maintainers which
have trouble getting sufficient karma for their updates could seek the
help of our QA team on fedora-test-list. Or not ?


Matthias

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:12 PM
Matthew Garrett
 
Default Proposed udpates policy change

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.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:17 PM
Matthew Garrett
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 11:27:04PM +0100, Michael Schwendt wrote:
> On Mon, 8 Mar 2010 21:59:29 +0000, Matthew wrote:
> > 1) Updates to stable that result in any reduction of functionality to
> > the user are unacceptable.
>
> Unless the fixes contained within an update are _more important_ than a
> dropped feature.
>
> E.g. if upstream has removed some "functionality" deliberately, and
> upgrading to upstream's code is the only way to move forward.

In that kind of situation, I think the maintainer would need a very good
reason to push this to a stable release. We've arguably been there with
Thunderbird, and we saw how much trouble that caused.

> > 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.
>
> Your wording or FESCo's?

My wording, to be voted on by Fesco.

> In either case, I disapprove this strongly. I have failed to get bodhi
> karma from bug reporters multiple times before. It is beyond my time
> to pester bug reporters, so they would vote inside bodhi instead of
> simply adding a comment in bugzilla. In many cases (ABRT generated
> tickets), I cannot even get them to reply in bugzilla. I release
> updates in return to
> - problem reports found in non-Fedora places,
> - crap I see in daily diffs I create for upstream projects,
> - problems I find myself, which haven't reported by anyone else but
> likely affect other users.
> I don't want such updates to be held up by artificial hurdles.

As I've said elsewhere, this is a problem that needs solving. But I
don't believe that it's a problem that's best solved by allowing people
to push directly to stable.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:25 PM
Todd Zullinger
 
Default Proposed udpates policy change

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

Perhaps as a data-point, before Till's recent easy-karma script, I'm
not sure any update of the git package ever received enough karma to
be automatically moved to stable. It's not like git is a package no
one around here uses.

That said, I don't disagree with the goal of pushing packages through
updates-testing. I'm just unsure if lesser used packages will ever
get out of updates-testing. Maybe >= 3 karma or 2-3 weeks would
suffice?

--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
Some people are like Slinkies... not really good for anything, but you
still can't help but smile when you see one tumble down the stairs.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:26 PM
Sven Lankes
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 11:12:11PM +0000, Matthew Garrett 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 even if that would be in place (for example by counting
non-fas-account bodhi feedback - it isn't counted currently) we would
still have the case where a maintainer cannot fix something that is
obviously broken without a) pestering others to 'vote for it' or b)
claiming that it is a security fix.

> and there'd undoubtedly going to be some difficulty in getting updates
> for more niche packages through as a result.

All I can say is that if your proposal is accepted, that will mean that
I can no longer do my job as a packager (of a few low-profile packages).

If others can live with only ever updating things in rawhide then that's
fine - that's not something I feel I can do and neither can I be
bothered to lobby others to +1 my updates (or create 2 or 3 fake fas
accounts to push the updates through on my own).

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

First of all: Make sure a FAS account isn't required to give feedback
and second: don't try to punish the 98% of the packagers that are doing
the right thing to make sure the 2% screwing up are stopped.

--
sven === jabber/xmpp: sven@lankes.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:28 PM
Martin Langhoff
 
Default Proposed udpates policy change

On Mon, Mar 8, 2010 at 4:59 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> The future
> ----------
>
> 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.

Thanks to you, Fesco and all developers working on this. There is
something that everyone seems to be missing on this track, and I'd
like to bring some attention to it.

Distros do integration work, and the main thrust of the QA work around
a release is that all the packages work nicely _together_, that all
the subtle interactions interact the right way.

Updates are always risky. There is no doubt that the updated package
worked fine for the maintainer, and yet we see updates bombing out
spectacularly relatively often. This is because pushing out a single
package update is what a maintainer does, but this "package focus"
undermines what the distro does -- _integration_.

Small, low-risk bugfix updates respect that distro-wide goal. Major
risky updates disregard that goal -- yes, a specific package is new!
improved! but the implicit social contrct with your end users ("a
nicely integrated OS") is broken because the time and effort to shake
out the subtle integration issues were skipped.

>From an OLPC PoV, major updates are rather troubling. We put together
two OSs based on Fedora (XO and XS OSs). We test the integrated OS
quite a bit ("we" being an outstanding team of volunteers around the
world), and we override a few packages, some of them very tightly
coupled to the platform (that is -- likely victims of subtle
interactions that may go haywire on a major update).

Given that, wearing my "XS lead dev" hat, I hope that Fedora focuses
its "update" policy on the safe, sane, low-risk bugfixes. Otherwise,
downstream projects that do careful QA are between a rock and a hard
place -- between taking potentially exploding updates or ignoring
updates altogether... and missing out on important bugfixes.

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:31 PM
Toshio Kuratomi
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> 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:
>
> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.
>
I disagree with this as an axiom with this phrasing. Most updates are
supposed to increase functionality for the user. However, any change in
code can lead to different bugs showing up which reduces functionality in
a different area. There is a tradeoff that needs to be made here; labeling
all reductions in functionality as unacceptable as an axiom is unworkable.

If you s/unacceptable/undesirable/ you have a better axiom. That
acknowledges that the fix in one piece of functionality may be more
important than the regression in another. However, that makes
for a weaker case for a stringent policy.

> 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.
>
This isn't entirely true either. One person can manually evaluate the
impact of certain changes to certain pieces of software. But this is less
of an issue than the first axiom as the number of packages that fit this
category is likely to be small.

> Proposal
> --------
>
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled.
>
This is the foundation of the new policy. It provides the means to enforce
any other changes. Sufficient or insufficient justification for this should
down below so I'll discuss that there.

> Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.
>
This I do not agree with on several fronts.

1) Net karma is really less interesting than whether any people have used
the package and any negative karma that was given has comments that can be
used to evaluate whether a package should still go into the repos. (for
instance, negative karma may be given for things that don't work, but didn't
work with the previous update. Or negative karma may be given for something
that is less important than the bugs that are being fixed by the update).

2) There needs to either be a method besides karma for updates which
haven't received positive or negative karma or there needs to be
a commitment of time from FESCo or a group that FESCo delegates to test
updates that haven't received feedback so that karma can be acquired when
none of the consumers of the update use bodhi to leave karma.


>
> 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.
>
This is a good note to have in the policy. Thanks.


> 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.
>
Could you clarify why FESCo expects this given past usage of karma in bodhi?
Other people have given counter examples of updates that have not received
any feedback. We can have lmacken run a query for percentage of updates
have had +3 karma statistics if the anecdotes are insufficently convincing.
Or you can explain what you think will change (for instance, FESCo will
allocate time to testing and giving karma to all packages which do not have
negative karma) to make this expectation true.

> 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.
>
This is a good idea -- one snag is that a regression often affects multiple
Fedora releases. Currently karma is often only given to a single release
out of the multiple where the bug needs to be fixed.

If you decide that the regressions are so severe that known bugs should not
be fixed unless positive karma is applied on each branch separately then
this is what the policy is supporting. However, I think that's an
unreasonable weighting of regression risk. The fact that the package works
successfully on F-n reduces the number of potential places that a regression
could be present in the F-(n-1) update. This should be taken into
consideration as part of evaluating whether the update should be pushed to
other releases than the one the bug reported explicitly tested on.

> At present, this policy will not apply to updates that are flagged as
> security updates.
>
The security team operates outside of the normal policy currently so this is
expected but there should also be a method for getting critical bug fixes
out the door. Perhaps something like "if a maintainer requests a package be
pushed sooner because it is a critical bugfix, fesco members will test the
package and add positive or negative karma before the next push to satisfy
the karma requirement".

> The future
> ----------
>
> Defining the purpose of Fedora updates is outside the scope of Fesco.
>
Note that the purpose of updates is not a Board issue or an FPC issue so
it's either a FESCo issue or something for the individual packagers to
decide.

> However, we note that updates intended to add new functionality are more
> likely to result in user-visible regressions,

This is untrue. An invasive bugfix can cause user-visible regressions more
easily than new functionality that only touches on existing code in one
place (for instance, adding a menu entry). Perhaps you could phrase it as:

"In many cases, adding functionality increases the complexity of code more
than fixing a simple bug. More complexity is more likely to result in
a user-visible regression."

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

On this note, kparal has been working on an updates policy as well since the
QA team needs to understand the workflow to understand where AutoQA and
other pieces fit into the picture. I think he should bring that up for
further discussion at this point as another take on this.

kparal, care to post a link to your proposal?
-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:45 PM
"Steven M. Parrish"
 
Default Proposed udpates policy change

On Monday 08 March 2010 05:32:01 pm Kevin Fenzi wrote:
> ...snip...
>
> Thanks for working on this Matthew!
>
> A small issue:
>
> - If the policy states +3 is needed, does that mean we are locking all
> updates to require this amount, no more no less? This could be bad
> for packages where the maintainer might want more testing. Perhaps it
> should be 'no less than +3' ? or 'at least +3' ?
>
> I personally like this idea (at least to try out and see how well it
> works). I do think we should continue to address longer term update or
> pace issues.
>
> I would suggest people with feedback write up their feedback clearly
> for this thread and avoid back and forth filibustering.
>
> kevin

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

Steven
--
================================================== ===
Steven M. Parrish
-------------------------------------------------------------------------------------------------
gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0
http://tuxbrewr.fedorapeople.org/
irc.freenode.net:
Nickname: SMParrish
Channels: #fedora-kde, #fedora-olpc, #fedora-edu, #sugar, #packagekit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:45 PM
Martin Langhoff
 
Default Proposed udpates policy change

On Mon, Mar 8, 2010 at 6:31 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
>> 3) Sufficient testing of software inherently requires manual
>> intervention by more than one individual.
>>
> This isn't entirely true either.

#3 is so true that is central to what distros are about. Upstream
probably released a good updated version, but the distro role is to do
the integration, and shake out all the bugs in those subtle
interactions between components.

Otherwise, distros could provide the installer + @base and for the
rest we could all grab RPMs from upstreams' websites.

The QA of the integrated set of packages at particular release is hard
and complex. That's what Fedora does, as a distro, and is central to
what Fedora is, and the implicit social contract -- these components
perform together in tune like a well-rehearsed orchestra.

If the trombonist buys a new and shiny trombone, great, but for the
piece he's playing tonight he'll have to play with the old trombone.
The new trombone may be slightly out of tune, or louder, or tinnier;
none of those things are bad per se, but it will ruin the combined
effort.

> One person can manually evaluate

That's the "it works for me" attitude. Works for small software
projects with a couple users. Not for a hugely complex OS, one that
others use as the base for their own work.

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 10:50 PM
Toshio Kuratomi
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 11:12:11PM +0000, 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.
>
Sustainable doesn't really seem like the correct word.... We've been doing
it this way for many years now and it's not as if updates skipping directly
to stable and thereby introducing more regressions is a bigger problem than
it has been in the past.

Really, the goal of this policy is to reduce the number of regressions as
the problem exists and we want to cut down on it.

The places where the policy fails are:
1) it doesn't address how to actually get more testing done
2) it doesn't balance risk of regression against the factors that are
prompting the update in the first place (bugfixes, user requested features).

Without those two pieces, this policy just outlines how to enforce that
a package does not get into the repositories without a trail of testing
having occurred. That doesn't provide any benefits to the packagers so it's
not going to get buyin.

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

Thread Tools




All times are GMT. The time now is 03:19 AM.

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