Re: [RFC PATCH v3 0/7] Introduce clar testing framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 12, 2024 at 03:13:39PM -0700, Junio C Hamano wrote:
> <rsbecker@xxxxxxxxxxxxx> writes:
> 
> >>For something as small as "clar", I think it is fine to start with the currently proposed
> >>layout and see what happens.  If we can keep going without touching the imported
> >>part of the sources at all, and the system proves to be useful and stable, that is a
> >>good time to suggest moving it out and binding the selected version of the
> >>upstream as a submodule.
> >
> > I think we already have a copy customized for git's use. The main clar repo on its own
> > has portability issues. I have contributed a few fixes, but they need work.
> 
> Yup, but as long as the changes we make are all upstreamable, the
> story does not change all that much.  Changes like "#ifdef TANDEM"
> would be totally uncontroversial thing for them to accept and we
> should be able to upstream them fairly easily, and once we thin our
> local customization down to zero, we'd reach the state I outlined.
> 
> Starting out with a local copy helps us making these portability and
> other changes without much friction, regardless of how responsive
> the upstream is, and the request upstream would see is "here are the
> changes to make it available on more platforms and/or making it
> generally more useful. all of these changes have been used and
> battle-tested in the context of the Git project for N months, please
> apply."

Yeah, agreed. My intention certainly is to upstream all required
changes. Right now, it's only two minor fixes that we need, one for
NonStop and one for whitespace fixes.

While I'm still one of the maintainers of the clar, I first want to
connect with Ed before merging any of these fixes. I would otherwise
consider it a bit overreaching to just go in and merge things after
having been absent from that project for such a long time. But when
things are sorted out I think the upstreaming process should be easy
enough.

Meanwhile, I think keeping this in the tree is fine. We can then
optionally convert the code to a submodule once the necessary changes
are upstream.

Patrick




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux