This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Branch creation policy?


Jeff Johnston wrote:

> I do not wish to start a collection of permanent branches for various
> groups out there.

The GCC, GDB, and Binutils repositories have all adopted this policy,
and the result is that code that would otherwise be maintained in
private repositories is now available in public, albeit on a branch.
For example, Red Hat and CodeSourcery both maintain productized versions
of GCC on branches in the FSF repository.  These contain various
backports and patches which might not be appropriate in all contexts,
but which make sense for the context in which the branch is being used.

> My concern is this leads to checking in of
> questionable changes, and a lack of effort in properly submitting
> changes back into the mainline. 

Frankly, I don't think restricting our ability to create branches will
have any affect on CodeSourcery's level of contribution.  We will simply
use our own repository instead of the FSF's repository to maintain the
branches we need.  It's slightly harder to merge things back and forth,
but not terribly much so.

We will continue to contribute patches to the mainline because that's
certainly in our best interest as well as being the right thing to do.
I suppose that because merging back and forth is a bit harder, we might
contribute a bit less, or a bit less frequently, and we might merge from
mainline to our branches a bit less often.  So, the merge friction will
probably have some effect, but I don't think it will cause us to stay
closer to the FSF mainline.

I'm not trying to sound belligerent; I don't mean it that way at all!  I
think it's entirely your call what policy to use (even though I wish
there were a src-wide policy, for simplicity).

> I am not sure why you feel this
> is necessary considering the fact that newlib is fairly liberal in patch
> acceptance.  Is there a patch submitted by you that you felt was
> unfairly reviewed?

No, not at all!  I'm perfectly happy with the newlib review process, but
for commercial purposes, we clearly need to be able to create stable
release branches and branches for particular customer developments, and
we need to control what patches are committed to those branches.

Thank you for maintaining newlib,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]