[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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).


`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

Reply to: