Re: How should we treat the patches (Re: Debian-JP discussions; lets wrap this up)
On Sat, Sep 04, 1999 at 12:22:30PM +0900, Taketoshi Sano wrote:
>
> > Finally I also have a comment on the patches themselves: it seems that a
> > lot of the multibyte-patches contain changes that are not related to
> > multibyte support but do things like add support for DOS and Windows
> > systems or change generated files (like configure, config.h.in,
> > Makefile.in, etc.). This makes it unnecessary hard to merge those
> > patches.
>
> Many of the patches (not only JP (or ja) related) is written and
> distributed outside of the Debian's world. Many patches is not Debian
> specific, and most of authors of patches have no direct relations
> with Debian or Debian JP.
>
> For this reason, I think these patches are "upstream" for us as a unified
> Debian.
Well, there are certainly a lot of different type of patches we have
identified in this discussion:
i18n patches that don't break anything:
Those can be merged in the Debian package and reported upstream for
inclusion. That's the "best type" of patches.
i18n patches that don't integrate well for technical reasons:
Here a fork can be useful. It should be considered to do further
development towards a merge. For example, gettext-ify programs for better
i18n. This work needs to be coordinated with the upstream maintainer, of
course.
i18n patches that don't integrate well because they are "sloppy":
With sloppy I mean that the patch can be done better without breaking
anything, making it possible to merge it in the code and integrate it
upstream. Those patches will become the "best type" later on. For example,
never change "configure" directly but "configure.in". If you don't know how
to improve the patch, ask for volunteers to help you or ask upstream author
for help.
Unrelated patches:
Wichert metioned DOS or Windows support. Those patches are orthogonal to
the main goal of the Debian-JP project. Those patches should be removed
from the i18n patch before submission. If the patch does provide a useful
functionality (new features, bug fixes, etc), they should be mailed in a
seperate bug report or negotiated with the upstream maintainer.
Note that a patch is more easily accepted if it is clean and small and does
only one thing at a time (only i18n, or only DOS support, or only bug fix).
Also, always document what a patch does (if the patch is not yours, at
least try to summarize what the patch is good for).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Reply to: