Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Robert Love wrote:
 > Exactly.  That is one reason.  Another is that the #if 0 makes the tree
 > instantly incompatible with any arch other than SH.  The SH tree should
 > be fully compatible with all arches, so that we can resync with each
 > other.

Sorry, I don't share your view.  No, I don't say you're wrong.  I
think that it's a sort of matter of taste or discipline (work style).

Ideal stuation would be like that (fully compatible and fully
synchronized), but there are some parts which is not, _always_.
Sometimes, we have to maintain the differences, say, a year or so to
get merged.  It's unwise, well, quite impractical to ignore the
existence of diversion.  If it's really being synched, there is no
sence to have SH repository, in the first place.

And it has been _me_ (and I think still _is_) who work for the
synchronization.  And I ask you and others to leave it as #if 0,
because it is good for me to do the synchronization work.

Having SH repository, people only commit to the repository, not try to
send the patch to main line.  That's quite bad thing, because it may
result more diversion and bad quality.  I had spent much time for the
work of synchronization, and my experience says "don't hide the issue
if there is work remained for merge".

If you really want (looks like) sane version, you can have your own
version.

Yes, it depends who does that.

 > Which brings me to the next point ... the trees are way out of sync. 

I agree I have things to be done.

 > When was the last time someone pushed an SH merge off to the official
 > kernel?

It is me, because I am a maintainer.  It was late 2.4.13.  Since that
time, because of the priority of GCC synchronization, I have been
spent most of time to have GCC patches to gather, send to upstream,
evaluate, generate local patches, etc. 

 > I would be happy to put together a diff against the latest 2.4 and 2.5
 > and send it off to Marcelo and Linus for merging into their tree.  I
 > suspect it will take some work to make sure we keep the code correct
 > (ie, nothing like the #if 0 stuff).  I would want the maintainer's
 > permission before I do this.

Thanks for offering help, but no thank you for this work.  It
complicate things in a bad way, if I can't see how things are going.

It is, say, "serialization".  In many cases, this style works well,
although sometimes it's the bottle neck.  To avoid confusion of
diversion, it is known to best to serialize merge of the work.

 > Second, with 2.5 starting, we need conversion to both CML2 and
 > kbuild-2.5.

Yes.  I think that I notified people some time last year, and Greg
also mentioned last month.

 > Both are non-trivial changes.  The SH port is the _only_
 > piece of the kernel non-synced with CML2, supposedly at the maintainer's
 > request that he do it?

No.  I don't request.  It's simple, I asked, but none does that.

 > Also, SH items in Configure.help are very lacking.  CML2 will _not_
 > allow an item to be selected if in non-expert mode if it has no
 > configure help!  And kbuild-2.5 will require a rewrite of our
 > makefiles...

Why don't you contribute this part?  I think that there's no objection
for 2.5 tree to do that job.  If you don't have write access to the
repository, please ask.
--