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

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 20:41, NIIBE Yutaka wrote:

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

Sorry, but I can't see any rational reason for putting an if 0 in code
such that it disables perfectly working code under other arches.

If you have a superior solution, go for it.

Regardless, you are the maintainer and I respect that.  Your call.

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

I disagree.  I think in an ideal world, we would not diverge at all. 
But we can't honestly expect to develop in sync with Linus and the x86
arch so we have to work separately.  Having a CVS repository exists to
make the job easier; nothing else.

Maintaining a divergent tree makes things harder on everyone.  It makes
syncing on our end harder.  It causes changes to the kernel with no
regard to what we are doing (since no one knows). Etc etc ...

What sort of problem does someone sending a diff off to Linus and
Marcelo cause?  It makes our "drop in" tree smaller and our resyncing
easy.

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

Well, I am here offering to help you -- but again, its you call.

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

What do you mean by this?

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

No, I don't intend to ever divert anything from your control.  A fork is
not going to get us anywhere here.  I just want to _help you_.

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

Completely understandable.

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

Understandable; your gcc work is _very_ appreciated.

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

I made a patch of SH drop-in (and my pending patches) vs 2.4.17-pre5. 
The non-SH stuff is trivial.  In other words, not much syncing needs to
be done on our side.  It is their side that needs to catch up to us.  Of
course, what did need to be done would be posted to this list for all to
see.

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

Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
specifically says SH is out of sync -- and is the only thing out of sync
-- at the maintainers request that he do it himself.  We won't work in
2.5 until this is fixed.

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

	Robert Love