[debian-devel:10270] How should we treat the patches (Re: Debian-JP discussions; lets wrap this up)

[Taketoshi Sano <xlj06203@xxxxxxxxxxx>]

Hello.

wichert@xxxxxxxxxxxxxxxx (Wichert Akkerman) writes:

> Okay, we've been discussing this for a while now and I think it's time
> to wrap this one up. All arguments have been made by now and it's been a
> very informative discussions for both sides.

I think so.

> We (Debian) are very happy with the hard work that Debian JP has done
> and is still doing. 

Thanks for your estimation for our (Debian JP's) work.
We (our member) sometimes feel that JP Project is neglected or ignored
or regarded with hostility by Debian Project, but your comment clear
those fear.

> Needless to say I disagree with both reasons. Maintainers not responding
> in time is a problem and unfortunately there is not much to be done
> about that, except reminding them occasionally, and trying to work
> directly with the upstream maintainer. On the second reason: it has
> long been a motto of the Free Software community to `release fast,
> release often'. Holding on to a patch could work counter-productive.
> Only if for some reason merging is not an option, only then proceed
> with posting an intent-to-package and creating a new package.
> 
> This will indeed slow things down a bit, but I feel that the final
> result will be a much more integrated system and a lot less tension.

I see. I personally encourage to use BTS for our "merge" work on our
mailing list (debian-devel@debian.or.jp) for the rest (which are not
yet uploaded to Debian) of our JP packages.

And, I try to explain something on following your comment:

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

I think you would not say:

 We (as a unified Debian) should order the autor of xemacs to merge 
 his code base into the code base of GNU's emacs.

If the forking is entirely evil, then we should do the effort to merge
the egcs into gcc, and we should not provide the package of egcs.

Do you really think that ?

I think that the forking in upstream is not our responsibility.

Some (or many) JP related patch is written without relation to Debian or
Debian JP Project entirely. They are distributed from some place widely 
in Japan. So authors of those patch is our "upstream" and their patch
should not be included in ***.diff.gz in our source package because
they are not Debian specific change.

We can ask or advice the author of these patches to contribute his code
into "their" upstreams, but I think we can not order them to contribute
his code to our official maintainer for Debian specific purpose.

What we can do is respect the upstream, and promote this idea. Isn't it ?

-- 
  Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@xxxxxxxxxxx>