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

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Dec 07, 2001:

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

I can't buy that.  Aren't one of the LinuxSH goals to make the SH arch
backend available to everyone?  What's the purpose of purposely maintaining
a divergent tree, if doing so increases workload and has the potential to
break things on our end?  We should be much more active in fixing mainline
as well as our port, see the post the last couple of days about removing
segment.h from all source files (we needed that), etc.  We shouldn't be
isolationists, and encourage incompatibility.  Especially when huge (and
not so huge) companies have an invested interest in what we produce.

IMHO, we have an SH repository so that each maintainer can work on her
own areas of code in a semi-controlled fasion.  Not so that we can just be
"different".

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

Why?

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

No, that's what peer patch review is for.  Everyone can see what patches
are proposed and object to them before they go in.  Nothing is being
hidden.

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

Are you proposing a fork?

> Yes, it depends who does that.
>=20
[...]
>=20
> I agree I have things to be done.
>=20

I can understand you having limited time to work on things, I've often
delayed submissions for months because I didn't have the time to finish
them.  But that's the benefit of our style of development, anyone else
who's willing can step up and help you out.  Why refuse that help?

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

I understand you've been busy with other tasks.  But it's time that the SH
tree catches up with the real world, and it's difficult to do that if we
aren't regularly syncing back to Linus.

How about this?  Would you have a problem remaining the 2.4 maintainer,
while someone else stepped up to become the 2.5 maintainer?  Since we're
talking about divergance anyway, the linux-2_4-branch and HEAD will soon
become (think directory restructuring) as divergent as the gcc 3.0 branch
and gcc HEAD.  It's going to be a ton of more work than what exists for the
2.4 series today.

Is there anyone else who'd even want the maintainers chair?

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

That's why we're all on this mailing list.  We already submit to patch
review ... how can you not see how things are going?

IMO, we need to become much more organized for the 2.5 line of development.
What I mean by organization is that we need to know when to send patches to
mainline, notify each other what breaks and why and who's responsible for
what areas of code.  I'm currently the Dreamcast maintainer, but I have
some non-DC code I'd like to submit which I would of course maintain if it
got in.

M. R.