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, 09:09 PM
"Richard W.M. Jones"
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> We assume the following axioms:
[..]
> 2) It is impossible to ensure that functionality will not be reduced
> without sufficient testing.

Your axioms are obviously wrong. An update which simply bumped a
release number would have the same functionality. Since you claim
these are axioms -- self-evident truths that form the basis for
further argument, anything else you wrote is unsound. Sorry :-!

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:14 PM
Bruno Wolff III
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 22:09:25 +0000,
"Richard W.M. Jones" <rjones@redhat.com> wrote:
>
> Your axioms are obviously wrong. An update which simply bumped a
> release number would have the same functionality. Since you claim
> these are axioms -- self-evident truths that form the basis for
> further argument, anything else you wrote is unsound. Sorry :-!

It could cause a conflict or a problem with obsoletes even without getting
rebuilt.
The rebuilt version of the package could break if other packages it uses
for the build have changed since it was last built.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:17 PM
Matthew Garrett
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 10:09:25PM +0000, Richard W.M. Jones wrote:
> On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> > We assume the following axioms:
> [..]
> > 2) It is impossible to ensure that functionality will not be reduced
> > without sufficient testing.
>
> Your axioms are obviously wrong. An update which simply bumped a
> release number would have the same functionality. Since you claim
> these are axioms -- self-evident truths that form the basis for
> further argument, anything else you wrote is unsound. Sorry :-!

What guards you against changes in the buildroot, non-deterministic
compiler bugs, cosmic rays and the like? The point is to test the
binaries that are being pushed into the hands of the users.

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

Matthew Garrett wrote:
> 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.

Would that apply also to new packages being pushed as updates to stable
releases, or only to updates to existing packages?

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:20 PM
Matthew Miller
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 10:17:01PM +0000, Matthew Garrett wrote:
> > > 2) It is impossible to ensure that functionality will not be reduced
> > > without sufficient testing.
> > Your axioms are obviously wrong. An update which simply bumped a
> > release number would have the same functionality. Since you claim
> > these are axioms -- self-evident truths that form the basis for
> > further argument, anything else you wrote is unsound. Sorry :-!
> What guards you against changes in the buildroot, non-deterministic
> compiler bugs, cosmic rays and the like? The point is to test the
> binaries that are being pushed into the hands of the users.

And note that the point says _sufficient_ testing. If the change is just a
rebuild with bumped version number, sufficient testing may simply mean
verifying that nothing _actually_ changed.


--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:21 PM
Adam Williamson
 
Default Proposed udpates policy change

On Mon, 2010-03-08 at 22:09 +0000, Richard W.M. Jones wrote:
> On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> > We assume the following axioms:
> [..]
> > 2) It is impossible to ensure that functionality will not be reduced
> > without sufficient testing.
>
> Your axioms are obviously wrong. An update which simply bumped a
> release number would have the same functionality. Since you claim

It would be rebuilt from source, as all updates are. The build would not
be performed in the exact same circumstances as the original build. We'd
certainly hope that wouldn't change anything, but it's impossible to be
certain.

Your post is clearly nitpicking, but this is an important point; I've
certainly seen cases when I was at Mandriva where a rebuild didn't work,
whereas the initial build still did; various odd issues, such as build
environment changes, can cause this.

Actually, it happened to me once, if I recall correctly, with Kompozer.
The initial build I'd done a few months previously for a given Mandriva
release worked in Cooker (Rawhide equivalent). If you took the exact
same SRPM and rebuilt it with the then-current Cooker environment - even
though the old binary package still worked in that environment! - the
resulting binary package did not work at all.

Which only goes to illustrate that updates are tricky and *really,
really* anything can go wrong.
--
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
 
Old 03-08-2010, 09:21 PM
Sven Lankes
 
Default Proposed udpates policy change

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.

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

On Mon, 2010-03-08 at 22:09 +0000, Richard W.M. Jones wrote:
> On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> > We assume the following axioms:
> [..]
> > 2) It is impossible to ensure that functionality will not be reduced
> > without sufficient testing.
>
> Your axioms are obviously wrong. An update which simply bumped a
> release number would have the same functionality. Since you claim
> these are axioms -- self-evident truths that form the basis for
> further argument, anything else you wrote is unsound. Sorry :-!

Richard: I'm afraid, from bitter experience, I can dispute that
argument

The essence of my counterargument is that in the meantime an update
might have been pushed to the build root tag that affects the rebuild,
and you might "silently" lose functionality.

The most common example I can think of is when a test in a configure
script starts failing for some reason beyond the control of the person
building the update: a package can be rebuilt without changing its
source, but all functionality relating to the configuration test will
"silently" go away. (youch!)

Or if you want a more direct but hopefully less common example, what
happens if a bug has been introduced into the compiler since you last
rebuilt? All you're doing is bumping a release number, without changing
your sources, but you could end up in a world of (new) pain.

Hope this is helpful; FWIW I think we need better automated testing
around our updates process.

Dave

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:25 PM
Julian Sikorski
 
Default Proposed udpates policy change

W dniu 08.03.2010 22:59, Matthew Garrett pisze:
> 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.
>
> 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.
>
> 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.
>
> At present, this policy will not apply to updates that are flagged as
> security updates.
>
> 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. 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.
>
How about packages that have few people use? I almost never got any
karma on the updates I prepare.

Julian

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-08-2010, 09:27 PM
Michael Schwendt
 
Default Proposed udpates policy change

On Mon, 8 Mar 2010 21:59:29 +0000, Matthew 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.

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.

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

-1 silly
-1 ridiculuous
-1 bad
===
-3 total

I would be very unhappy with FESCo (and I was one who voted during the
election), if something like that were approved.

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

Your wording or FESCo's? 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:33 PM.

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