Re: [linux-sh:02047] Re: [linuxsh-dev] Drop-In tree updates

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

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

>=20
> I don't say, we should encourage incompatibility or divergent tree.  I
> said, we have to think about maintaining the divergence.  Although we
> should do our best to minimize the divergence, there _is_ always
> divergence and it is quite important to maintain the divergence and
> merging.
>=20

Yes, today there is divergence.  But it doesn't have to always be this way.
I'm proposing that we become much more agressive in sending patches against
mainline to their respective maintainters, and Marcelo and Linus.  We don't
have any excuse not to.  If a patch is desperately needed (I can hear Greg
and Stuart talking about a PCMCIA patch) and the maintainer of that code
remains unresponsive, then send it to Marcelo or Linus CC'd to the
maintainer and lkml.  This way everyone gets to see it, and even if it
still doesn't go in people can fix it on their own.

We have to up the ante, we shouldn't just blindly accept breakage from up
high.

> It takes time to do the merging, and since the band width (of human
> being) is limited resource, we should be careful to do the merging.
>=20

Not if we stay in sync on a regular basis.  Even still, there's now
incremental pre- patches on kernel.org, so syncing from older versions
should be much easier.  As far as limited resource, you've just been
offered help to do the merging work.  What's wrong with Robert doing a
merge and posting it here before it gets sent to Linus?  Being the
maintainer, you can easily review and approve/decline the patch as
necessary .. do you have any objections to that?

>=20
> Yes.  You did good job towards this goal.  Don't you think that part
> of mm/memory.c is maintained by me?
>=20
[...]
> Because I maintain this divergence of mm/memory.c.  Obviously, it's
> ugly hack, but it's important for performance wise for SuperH or other
> relevant architecture.  We need API change for cache handling routines
> for merge, but for a while it's good.  It's definitely _not_
> CONFIG_SUPERH thing.  For me, it looks quite selfish and bad code for
> generic part of kernel to have CONFIG_SUPERH if it's not really
> needed.
>=20

If it only applies to SuperH then it is a CONFIG_SUPERH thing.  CONFIG_*
options are specific to what they define, if they weren't, would we have
CONFIG_SH_DREAMCAST sprinkled all over drivers/net/8139too.c ?

If something needs to be changed in mainline for our port to work, then we
need to change it, just as you've been sending patches to fix gcc, this is
the same idea.

>=20
> It's good tools.  But unfortunately, it's not perfect.  If some part
> is not going in, then, he has divergence in his working tree, isn't
> it?
>=20

Yes, for awhile.  I'm saying we should cut that time short, and *not* have
stale code that could've went into mainline (or been fixed) sitting around
for a year or so.

>=20
> I have been doing that.  I don't think other person sending patches
> help things here.  Say, do you believe RedHat users who find
> divergence between mainline and the kernel distributed by RedHat
> sending the difference to Linus?  I don't think so.
>=20

We're not just users, we're developers.  Red Hat users don't submit kernel
patches to Red Hat, Red Hat has it's own kernel development team that
maintains its patches, just as you and I and Paul and Jeremy maintain parts
of the LinuxSH tree.  So your analogy doesn't hold here.  And yeah, if
someone has a problem in our area of code, then we should be the ones to
respond, just like Red Hat is responsible for tracking support for it's
code.

Oh, and you haven't been regularly sending patches to Linus, else we
wouldn't be having this discussion!

>=20
> For me, 2.5 thing is better to follow.  2.4 is difficult.

I don't want to go back and forth (and I'm sure you don't), so I'll just
say this - help is being offered to ease your workload.  The communication
lines are open, and you have some experienced kernel hackers that are
willing to give you assistance.  If the situation occurs where it takes too
long for changes to be accepted and/or passed back to Linus, then you'll
eventually end up with the same sort of "fork" that happened with SGI OSS
and linux-mips.  Ask those developers why they chose to open another tree.

M. R.