The policy of creating vendor/users branches in binutils

[Joel Brobecker]

> On Mon, Apr 26, 2021 at 7:53 PM Nick Clifton <nickc@redhat.com> wrote:
> >
> >    [Sorry for the delay in responding]
> 
> Thanks for helping to clarify the policy!
> 
> > > Are there any policies to create the vendor
> > > branches in binutils?
> >
> > Yes.  See the "Creating Branches" section in the binutils/MAINTAINERS
> > document for details.
> >
> > (Unfortunately this section does not address the subject of creating a
> > group of related branches).
> 
> Yeah, the problem has bothered us for a while.
> 
> > > I see that ARM has their own vendor branches in
> > > /users/ARM/, and so as others.  But in GCC, vendor branches are used
> > > to be placed in /vendors/<vendor name>/...  Therefore, could we create
> > > branches in /vendors/RISC-V/ rather than in /users/RISC-V for
> > > binutils?  It would be great if we can keep the consistency with GCC,
> > > and also follow the policy of binutils.
> >
> > I have no objections to your using /vendor/RISC-V/...  and if it helps
> > to keep things simple, then please do go for it.
> 
> Thanks for the approval.  We will try the /vendor/RISC-V/ for some
> time.  I think changing the naming should be fine, if most people
> think the /users/RISC-V would be better in the future.

Sorry to come in a bit late in the discussions, but from the Git
hooks's perspective (the hooks that are installed on the server
side), the conversion that we have established is for branches
to be users/xxx.

What the configuration does is two-fold: It avoids commit emails
being sent for branches in that namespace, and also gives
non-fast-forward permissions.

If the only reason for using vendor/xxx was to follow what GCC does,
I don't think it's a strong-enough reason to duplicate the configuration
we already have for users/* to vendors/*. Just my 2 cents, of course.

-- 
Joel