[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

[Renato Golin via llvm-dev]

On Tue, 17 Nov 2020 at 05:41, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> * I still worry about the bazel files causing merging conflicts when
> backported to the stable branch.  If these are added to tree, could we
> have a rule where commits to utils/bazel/ cannot include changes to
> other files?
>

That's usually the policy for other non-code changes, but I agree that with
build system components, this is specially important.

Expanding on this last point a little bit, this raises some larger
>
questions about what code should be allowed in tree.  Essentially what
> we have here is that a critical part of the LLVM project has been
> re-implemented and is now being asked to be included in tree alongside
> the original implementation (CMake).  There are parts of the codebase
> where this would clearly not be OK (e.g. a re-implementation of one of
> the backends), but for build systems I think you can make a valid case
> to either have it or not to have it.
>

We have examples of competing front-ends (the three different "flang"
projects), middle-end infrastructure (the new pass manager), back-ends (the
two arm64 targets) and build systems (automake/CMake).

But in all examples above, the sub-communities involved agreed on replacing
the flang implementation (twice), concurrently developing the new pass
manager and merging the two arm64 backends. We also have elected to keep
CMake over automake.

Those efforts were always with the intention to replace and not to
co-exist. So none of our priors are close enough.

However, those are all things that we have considered to be "core tier". We
should now consider a "peripheral tier" that would be ok with co-existence,
as long as they follow the support policy.

For your specific point about stable releases, breaking them would be a
major failure to follow the policy, so we need to make sure that doesn't
happen.

And this is why I think it should be a pitch.  In my opinion, these
> kinds of higher-level decisions are better made by review managers than
> by people on the mailing list.
>

There should be an 100% overlap between those two groups. :)

And their views on this subject would be invaluable to the discussion. It'd
be beneficial to all if they could chime in.

The other nice thing about a pitch is that we don't need to spend days
> arguing about this on the mailing list.  You can take my feedback, think
> about it, and if you think there is some validity to what I have said,
> then all you need to do is update your proposal to address my concerns.
> And if not, then you can just move on to the next email.
>

That is true. It would be nice to have a document that reflects the latest
updates on the discussion.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201117/6101f457/attachment.html>