micro-libgcj merge reconsidered

Tue Jan 17 09:55:00 GMT 2006

On 2006年1月16日, David Daney wrote:
> Joel Dice wrote:
>> In light of both of these concerns, I think the advice of Steph 
>> Meslin-Weber and others is most appropriate - create a branch for 
>> micro-libgcj as proposed, but without intending to merge it into the trunk. 
>> Others may then use that branch as a basis for their own branches and take 
>> them in whatever directions they care to. Elements from any of these 
>> branches may then be merged back into the trunk if and when there is demand 
>> for them.
>>>> How does that sound?
>> That would not be my preference.
>> While creating a branch is likely the right thing to do, starting with the 
> assumption that it would not be merged back is not at all appealing to me.

Then I would advise creating a branch of your own that supports your 
intentions.
> I thought we were close to a consensus that Per Brothner's preprocessor idea 
> was close, if not identical, to the preferred approach. It seems to me that 
> most people would not object to this and we would have a very good chance to 
> merge it back to the mainline.

I did not get that impression. From what I read, neither of the libgcj 
maintainers sounded convinced that this was the right approach.
> I think preprocessing is the only way to make a u-libgcj useful to enough 
> different people to make the entire project worthwhile. In case you could 
> not tell, I am strongly in favor of the preprocessor approach.

I already consider micro-libgcj worthwhile regardless of what happens 
next. I do agree that the preprocessor approach is best for micro-libgcj. 
Whether it's best for the libgcj trunk or for GNU Classpath is another 
question, and one which I'm content to let the maintainers of those 
libraries decide.
 - Joel