Re: Review of the gtk-gnutella patch
While I agree with the bulk of your points, I think some things need to be
pointed out here. I don't use Gnutella, so I don't have an horse in this
race, but here are my thoughts:
Gnutella (using the word generically -- not referring to gtk-gnutella
specifically) is a corner-case; an exception to the majority of packages.
Why?
1) It's not built on any real network standard, (IETF RFCs like http, or
tcp/ip, or other similar packages might be) and thus is extremely volatile.
2) Wholesale changes (as we can see) occur and when they do, they break
previous versions of the package.. and, most importantly:
3) Normally, previous versions of a package that would be in stable would be
fine; they would continue to function with the old standard. I.e., if
OpenOffice switches from sxw to odt, people both can use the old version to
open their old documents and the new version would retain document backward
compatibility. Because gnutella (and relations) are networked applications
without using stable standards, a non-backward compatible change affects the
entire network.
These are pretty unusual circumstances. An FTP client wouldn't have these
problems (stable protocol so the old version would continue to interoperate
with other FTP servers), and a typical desktop app wouldn't have this problem
(old version would continue to interoperate with the old files.) I think
there are few times when we run into this. Another example might be when a
game completely changes its protocol to fix cheating, but even then the game
is usually playable offline and thus there would be good reason to keep the
old version in stable. (I.e., it still half-works.)
So, this is a strange case and thus not worth getting freaked out about. I
think Volatile should accept the whole new package because of the following
reasons:
1) Upstream didn't split out the changes like (perhaps) they should have
2) The package as it sits is apparently completely useless anyway (because it
depends on a "package dependency" -- the old version of the network protocol
-- that no longer is valid). BTW, why isn't there a gnutella library and
treat gtk-gnutella as a client only? hm.
3) It appears to not have any depends of its own, so accepting the whole
package won't hurt any other packages
4) It's a desktop-quality application that uses an evolving protocol that (by
definition) is not stable... users would rather have an app that works than
one that doesn't, (and volatile is definitely the right place to put it)
and finally (and most importantly)
5) It's a weird, unusual case because of the unusual type of application it
is, so this sort of scenario should be a rare event compared to the majority
of packages..
Hopefully, I didn't miss any key points.. ?
On Wednesday 18 January 2006 12:27, Anand Kumria wrote:
> Hi Martin,
>
> On Sat, Jan 07, 2006 at 06:34:53PM +0100, Martin Zobel-Helas wrote:
> > Hi Anand,
> >
> > based on the patch you send in on 24th of November i tried to review
> > your patch.
>
> Thanks. It can't have been very easy.
>
> > 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.
>
> Yes, upgrading to a new version is required in order to maintain the
> functionality already delivered to our users.
>
> > I would advice you to try to backport the changes of the network stack
> > only and come back with that then.
>
> Basically what you are saying is that you'd like me to divurge from
> upstream and generate a special package that will never exist in either
> stable nor in testing or unstable.
>
> This special package will have a completely different network stack to
> any gtk-gnutella in existence but will interoperate with the (evolving)
> network.
>
> As the kernel maintainers have indicated to you; generating a special
> version of a package merely for volatile is pointless.
>
> Basically it appears that the second item on volatile.debian.net ("
> volatile is ... keep them functional") will cause you to reject most
> packages.
>
> It you are after 'minimal changes', what you are saying is that you
> can't accept a newer gtk-gnutella *despite* the fact that
> this program *no longer functions* for stable users.
>
> > 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.
>
> They aren't but since you aren't able to seperate (and neither am I for
> that matter and nor are upstream) we either have to take them or decide
> wholus-bolus that volatile isn't really necessary.
>
> After I did my analysis of the existing packages in volatile it become
> apparent to me that volatile:
>
> - doesn't have a well-defined consituency
>
> - without a well-defined consituency, by definition, can't meet
> their needs effectively.
>
> It is clear that different users expect different things; I expect
> volatile to do the job that the stable group refuse to do -- ensure that
> Debian stable contains functional software (i.e. I consider volatile a
> hack around the fact that the stable group aren't doing their jobs).
>
> As a user I would expect volatile goals to be:
> - "do no harm"
> - "be usable immediately"
> - "provide updates to ensure Debian stable remains functional"
>
> I'll post something to debian-user-announce explaining to our users how
> they can get a functional version of gtk-gnutella. I was hoping to
> point them to volatile.debian.net but, alas, I can not.
>
> I think that until/unless you define yourself more throughly, volatile
> won't get much traction.
>
> Regards,
> Anand
>
> --
> `When any government, or any church for that matter, undertakes to say to
> its subjects, "This you may not read, this you must not see, this you are
> forbidden to know," the end result is tyranny and oppression no matter
> how holy the motives' -- Robert A Heinlein, "If this goes on --"
Reply to: