Early backports to reduce post-release fixes
 

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

When I was a motu-sru member, I realized the great majority of SRU
candidates to be processed were related to visible bugs (crashes when
doing normal tasks, uninstallable packages, and so on). This kind of
issues could have been addressed in time for the release if widespread
testing was conducted on the affected packages.

We cannot enforce people to upgrade to current development release just
to have more testers, many people believe development release is
completely unusable until release day. I was moderator of Italian
forums, I have several examples of these "isterisms", where people was
scared to see "development branch" in MOTD!

How can we help motu-sru to avoid some SRU requests for trivial tasks,
allowing a greater audience to test packages without the need to
upgrade? My proposal is to prepare early backports of the most commonly
used packages in Universe. Starting from Feature Freeze, we could
identify some packages with high popcon and determine if it's worth to
prepare a backport for current stable release (new upstream releases,
new features to be tested, and so on), so the main part of the Ubuntu
users can effectively test packages and report issues, so they can be
fixed in time for the release.

What do you think?

- --
. '`. Luca Falavigna
: :' : Ubuntu MOTU Developer
`. `'` Debian Maintainer
`- GPG Key: 0x86BC2A50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl+7asACgkQnXjXEYa8KlCy7QCeKKfPkgIeZW JFaCKFGypqL/8Q
oDUAoJe53+L8qyfSlkanp9ZIb9ea1Agq
=JT8A
-----END PGP SIGNATURE-----

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

Luca Falavigna <dktrkranz@ubuntu.com> writes:

> How can we help motu-sru to avoid some SRU requests for trivial tasks,
> allowing a greater audience to test packages without the need to
> upgrade? My proposal is to prepare early backports of the most commonly
> used packages in Universe. Starting from Feature Freeze, we could
> identify some packages with high popcon and determine if it's worth to
> prepare a backport for current stable release (new upstream releases,
> new features to be tested, and so on), so the main part of the Ubuntu
> users can effectively test packages and report issues, so they can be
> fixed in time for the release.

Short: I like the idea.

I could imagine a lightweight approach: Activate the ~ubuntu-dev (or
~motu) PPA, and use it as "backports-staging" archive. Proposed policy:

- proposed package backports should be tracked via a malone bug
- any motu may upload there if he feels that a package should be
backported, mentioning the LP bug number
- the backport teams tracks these bugs and approves backports if
"enough" positive feedback from users has been given in the LP bug


--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

On 27 Jan 2009, at 12:28, Reinhard Tartler wrote:

> - the backport teams tracks these bugs and approves backports if
> "enough" positive feedback from users has been given in the LP bug

I thought the intent wasn't to use this as staging for backports, but
to allow users of stable releases to test packages from the current
development release without having to upgrade their system wholesale.
This will help weed out more bugs in the new version before it becomes
harder to fix them post-release.

I am a bit concerned that the PPA would suffer from the same problem
that -backports and -proposed suffer from now - that there's no easy
way for end-users to selectively enable it. Once enabled, they will
receive updates for all packages that a MOTU cares to upload that they
have installed. Given that this will carry an image of being
officially sanctioned in some way, it won't look good if this becomes
a sort of "development-release-lite", upgrading end-user applications
and potentially destabilising systems.

Also, I worry that this will become a short-cut to backporting too. I
can see people requesting new upstreams be released to this new PPA,
ostensibly "for testing purposes", but really to negate the often-
protracted backporting process

Just thoughts. The basic premise is good, and I think it would be nice
to see some movement in this direction.

Iain

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

On Tue, 27 Jan 2009 12:19:07 +0100 Luca Falavigna <dktrkranz@ubuntu.com>
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>When I was a motu-sru member, I realized the great majority of SRU
>candidates to be processed were related to visible bugs (crashes when
>doing normal tasks, uninstallable packages, and so on). This kind of
>issues could have been addressed in time for the release if widespread
>testing was conducted on the affected packages.

For basic issues like installability and builability I think we're better
of relying on automated tools meant to be used archive wide like puiparts
and rebuildd.

>We cannot enforce people to upgrade to current development release just
>to have more testers, many people believe development release is
>completely unusable until release day. I was moderator of Italian
>forums, I have several examples of these "isterisms", where people was
>scared to see "development branch" in MOTD!

These aren't random fears. People without sufficient experience to dig themselves out of a
sudden and deep whole should not be running the development release.

>How can we help motu-sru to avoid some SRU requests for trivial tasks,
>allowing a greater audience to test packages without the need to
>upgrade? My proposal is to prepare early backports of the most commonly
>used packages in Universe. Starting from Feature Freeze, we could
>identify some packages with high popcon and determine if it's worth to
>prepare a backport for current stable release (new upstream releases,
>new features to be tested, and so on), so the main part of the Ubuntu
>users can effectively test packages and report issues, so they can be
>fixed in time for the release.
>
>What do you think?

I've certainly done this for packages I'm interested in. It works. Mostly
what it needs is interested parties to test backports so we can approve
them.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

On Tue, 27 Jan 2009 13:28:20 +0100 Reinhard Tartler <siretart@ubuntu.com>
wrote:
>Luca Falavigna <dktrkranz@ubuntu.com> writes:
>
>> How can we help motu-sru to avoid some SRU requests for trivial tasks,
>> allowing a greater audience to test packages without the need to
>> upgrade? My proposal is to prepare early backports of the most commonly
>> used packages in Universe. Starting from Feature Freeze, we could
>> identify some packages with high popcon and determine if it's worth to
>> prepare a backport for current stable release (new upstream releases,
>> new features to be tested, and so on), so the main part of the Ubuntu
>> users can effectively test packages and report issues, so they can be
>> fixed in time for the release.
>
>Short: I like the idea.
>
>I could imagine a lightweight approach: Activate the ~ubuntu-dev (or
>~motu) PPA, and use it as "backports-staging" archive. Proposed policy:
>
>- proposed package backports should be tracked via a malone bug
>- any motu may upload there if he feels that a package should be
> backported, mentioning the LP bug number
>- the backport teams tracks these bugs and approves backports if
> "enough" positive feedback from users has been given in the LP bug
>
The general standard has been one user reporting it builds, installs, runs.
For packages with rdepends, they need to be tested too.

This probably seems like a very low standard, but in virtually all cases it
proves sufficient.

In some cases we ask for more testing if it seems prudent.

In short, I don't think we need the PPA step.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

On Tue, 27 Jan 2009 16:25:35 +0000 Iain Lane <laney@ubuntu.com> wrote:
...
> Once enabled, they will
>receive updates for all packages that a MOTU cares to upload that they
>have installed.
...

We have a pending spec about improving this situation.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Early backports to reduce post-release fixes
 

Reinhard Tartler wrote:
> Luca Falavigna writes:
>
>> How can we help motu-sru to avoid some SRU requests for trivial tasks,
>> allowing a greater audience to test packages without the need to
>> upgrade? My proposal is to prepare early backports of the most commonly
>> used packages in Universe. Starting from Feature Freeze, we could
>> identify some packages with high popcon and determine if it's worth to
>> prepare a backport for current stable release (new upstream releases,
>> new features to be tested, and so on), so the main part of the Ubuntu
>> users can effectively test packages and report issues, so they can be
>> fixed in time for the release.
>
> Short: I like the idea.
>
> I could imagine a lightweight approach: Activate the ~ubuntu-dev (or
> ~motu) PPA, and use it as "backports-staging" archive. Proposed policy:
>
> - proposed package backports should be tracked via a malone bug
> - any motu may upload there if he feels that a package should be
> backported, mentioning the LP bug number
> - the backport teams tracks these bugs and approves backports if
> "enough" positive feedback from users has been given in the LP bug

After reviewing the backports process (1), I don't think we need an
even lighter-weight process to handle these. From my reading, it only
takes a few people to say it works to be backported. If these initial
reports are negative, then the package ought be fixed in the development
release anyway.

Despite the process, I don't think this will actually help with the
problem at hand. In my experience, the majority of packages that fail
to work at all (or perhaps even install) suffer from one of three
problems: 1) they missed a library transition (perhaps even an informal
one), 2) they need to be built against a newer version of the build
tools because they failed to include some change that was done at a
lower level, or 3) they have some incompatibility with some other change
in the distribution that went untested during the cycle.

Since backports (or PPA builds) are rebuilds, they will mask issues
of the first two types, and since they would be targeted at the previous
release, will not be affected by the third. With the current situation,
some packages fail, are trivial to fix, and are fixed (albeit perhaps
with some delay for various reasons). With such a change, we may
instead have a perception of regressions: where a package that is known
to work as a backport suddenly doesn't work in a release users are
likely to be significantly more annoyed than in the case where they
upgraded to something that didn't work.

We would do better to try to close outstanding dependency issues by
reviewing the debcheck output (2), and revitalise the work on automated
installation tests using piuparts, to get that running on some shared
infrastructure with viewable output. This ought resolve most
installation issues, and with appropriate piuparts scripting, may even
be able to handle many of the cases where a package completely fails to run.

For more comprehensive work towards ensuring that packages work as
expected, it may be sensible to write test cases for the automated
testing framework (3). This would probably benefit from extensions to
cover a wider variety of software than is currently tested.

1: https://help.ubuntu.com/community/UbuntuBackports
2: http://qa.ubuntuwire.com/debcheck/
3: https://wiki.ubuntu.com/Testing/Automation/Desktop/

--
Emmet HIKORY

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu