Re: kaffe-1.1.1 package available for tests
> Yes, maybe this is short. On the other hand, one can take into
> consideration that the last message of Ean about upgrading (at that time
> it was to kaffe 1.1.0) was almost two month ago (see #196867). And there
> has been a mail on this list (which I assume he should read) about
> problems contacting him.
I understand the problem, and the reasons you cite are reasons for
wanting to NMU in the first place, not for doing a highly irregular new
upstream NMU right now. For such a significant change I'd allow Ean
ample time to respond (and perhaps this response will be "yes please, go
ahead"). Recall that NMUs are generally used to fix bugs whilst
minimising unrelated changes. Presumably this is because with a large
software package like kaffe, there may be all sorts of subtleties with
packaging, upgrade paths, etc. that the maintainer is familiar with but
an NMUer might not know about. Bug-fix-only NMUs generally do not fall
prey to such problems. New upstream release NMUs do.
As an example, at times when I've been very busy or offline for a long
time I've invited others to NMU koffice but to please mail me first,
precisely so I can discuss these subtleties with them so we can be sure
that nothing gets broken.
This is not a territoriality thing. It's simply about helping prevent
NMUs from causing more problems than they solve.
> Wouldn't it be more efficient to focus on making ant go into main?
> Assuming that needs fixing free JVMs and/or writing library code, it
> would be work useful to other projects, instead of duplicating work to
> work-around the issue.
Say I maintain package foo. My options are:
(i) Read through the ant XML file for building foo (a package whose
sources I'm quite familiar with), work out what needs to be done and
write a few makefiles;
(ii) Dive into the source code for ant itself (which I'm completely
unfamiliar with), rewrite portions of this source code to eliminate the
need for packages outside main, submit patches and then wait for the
ant maintainer to verify and apply them.
Sure, (ii) is nice in the long run since it helps everybody. But if I
don't have a lot of time then option (i) is more efficient for me, gives
faster results and is more likely to be done correctly.
b.
Reply to: