Re: Review of the gtk-gnutella patch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/07/2006 04:54 PM, Peter J. Holzer wrote:
> On 2006-01-07 18:34:53 +0100, Martin Zobel-Helas wrote:
>
>>based on the patch you send in on 24th of November i tried to review
>>your patch. This 18MB patch seem to only consist of changes upstream
>>made. This are _not_ only changes to a stable program that are
>>necessary to keep it functional but a complete backport of a package.
>
> Correct me if I'm wrong, but wasn't debian-volatile created to keep
> programs functional where upstream changes too frequently (or too
> massively) to make just fixing bugs infeasible?
Yes... but there is a "small tiny line" that splits what packages
are suitable for inclusion in volatile (and sloppy) and the packages that
we recommend a backport instead of volatile.
In fact it still a litle bit fuzzy for me, but AFAICT, and please,
somebody correct if I'm wrong here, you should consider something like
this (and it is my personal point of view, MHO):
* Sarge Security Updates and Point realeases
- Security fixes
- Special cases for some packages (very rare cases)
* Volatile
- Packages that relays on very often updates but do not have a
big change in its structure (clamav as the best reference)
* Volatile Sloppy
- Packages that get big chagens and also relays on very often
updates. SpamAssassin is one good example of a package that
jumps from volatile to sloppy.
* Backport
- New releases braking of the actual configuration
In fact, a good way to measure where the package is recommended is
how great are the chances that the package break stuff, userland and the
user/admin setup. If you check closer, it is not the size of the diff that
defines that, it is an important variable in the equation, but it is not
_the_ variable.
Volatile tries to "above all, do no harm", which means that we are
more open than "stable" but we are not "sid" or "backports". As I see it,
we are trying to fill the space of more frequent updates before the
backport.
> I know zilch about the gnutella protocol and how much it changed since
> the release of sarge, so I'll try to ask the question generally:
>
> If stable contains version X of a program, and that version turns out to
> be unusable because of massive changes in the environment it is supposed
> to be used in, and there is a current version Y of the program, would
> not the correct way to include the program in volatile to package
> version Y instead of creating a huge patch with all the changes between
> X and Y?
The decision is made with a case by case approach. In the above
example, we really need to check with the new package mess with the user
setup. But looks like a good candidate for at least sloppy. The real
point is the fact that if the package is totally new and break actual
stable stuff, it should be backported instead of added in volatile.
The diff brings to Volatile Team the change to "point check"
what really changes, we need to test the package, do some upgrade to
see what happens and try to identify if it fits our [1]acceptance rules.
1.http://volatile.debian.net
Using your example, if the package is a P2P client or a IM
client, and the network changes its protocol breaking the clients,
probably a new version to get the package working again with the new
network model looks like a good candidate to volatile. But if the
upstream take the chance to add "a lot of new stuff" it brings us
to a "gray area", where maybe the package should added to backports.
Hope it helps, kind regards,
- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFDyXEKCjAO0JDlykYRAkGuAJ4gtIHO9tpqUsTKMjNPNdz83H2z5gCfTBzB
A9+yHWlpD0RmZB2FRnwzWBc=
=f6Ab
-----END PGP SIGNATURE-----
Reply to: