Review of the gtk-gnutella patch
Hi Anand,
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.
On Thursday, 24 Nov 2005, you wrote:
> On Wed, Nov 23, 2005 at 11:58:47PM +0100, Martin Zobel-Helas wrote:
>
> <http://www.progsoc.org/~wildfire/debian/gtk-gnutella/gtk-gnutella-0.95to0.96b.diff>
As Andi already said a few days ago, i try to even review a patch that
Andi would not let into volatile.
Here is what i found:
* No packageing changes (good)
* Messy debian/changelog (you already told you fixed that in the upload
which got rejected accidently).
* There are a couple of files that seem to have moved by upstream
* Adding 3 more PO langauges
+ el
+ zh_CN
+ uk
* massive changes to existing po-files (~4MB)
* massive UI changes (~9MB), and i did not look into them, as i don't
think UI chnages are necessary to keep this program functional.
* in src/core and src/lib i found quite a lot of ABI changes
It looks to me that nearly every file in this programm has changed.
Having not my volatile hat on i hearby would recomment to the rest of
the volatile team to not accept this package into volatile with the
current patch. It couldn't figure out why all of this changes are
necessary to keep this package functional, so i could understand that
the network protocol seem to have changed upstream.
I am still not sure if this package could even be recommended to
volatile-sloppy, as it looks to me that the changes are to massive to
accept it there. Given that there have not been any serious bugs found
since the release of sarge the package itself seems to be in good shape.
Also the package maintainer seems to be quite active and responsive on
bugs.
Anand, if you really want an updated package of gtk-gnutella in
volatile, keep the patch as small as neccessary. Reviewing 18MB of patch
is quite painful.
I would advice you to try to backport the changes of the network stack
only and come back with that then. I agree with you that a change of the
network stack is a valid candidate for volatile but this is much more
then just the change of the network stack; eg. i don't understand why
the changes of the UI are necessary to keep this program functional.
Greetings
Martin
Reply to: