Re: kaffe-1.1.1 package available for tests
--- Ben Burton <bab@debian.org> wrote:
> 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.
Being a kaffe developer, I'd recommed that the NMU includes Ben's fix for the
/usr/lib/jni lookup thing. We won't fix that in kaffe, as it's debian specific.
Other than that, I believe that all other rc bugs are fixed in 1.1.1
> > 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.
the trouble is that you, and everybody else does (i) over and over again
whenever a package is released that needs ant to build itself. in the long run,
(ii) is the rational choice. while (i) may seem to be more efficient, it's just
a distributed waste of time ;)
if you want to do a massive distributed waste of time project, i believe that
time would be better spent persuading the FSF and ASF to get together on their
licenses and make either the GPL ASL compatible or the other way round. who
kknows, maybe you won't waste the time and they get their ideals/egos out of
the way and work out a compromise.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: