This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: Questions on the submission of new patch in the binutils


Hi Virendra,

 Thanks very much for your interest in contributing your work.

Could you kindly help us by answering below questions. Or point me to
the appropriate links/documentation where such information is present.

 Before you start you need to be aware of the FSF Copyright assignment
 policy.  Patches submitted to FSF projects, including the binutils,
 need to be covered by an FSF Copyright assignment:

http://www.fsf.org/licensing/assigning.html

If you do not have a copyright assignment in place already then you can apply for one by filling out the attached form and sending it off
 to the FSF.


1. What would be the appropriate branch to upstream this new patch? I
see there are three major active branches:  master, gdb-7.11-branch
and binutils-2_26-branch.

 master.

 The 2_26 branch is for the current 2.26 release.  It is meant to be
 a stable branch and so it is not suitable for the addition of new
 features.  The gdb-7_11 branch is for the GDB project, so you would
 need to have permission from the GDB branch manager to commit changes
 there.

 (The binutils git repository is shared between the binutils and gdb
 projects).


2. What are the formal tests that needs to be done before proposing a
   patch to binutils?

 You should make sure that the patched sources build.  Also you should
 make sure that the gas, ld, binutils (and possibly gold) testsuites do
 not show any regressions for the appropriate target(s).  If you are adding
 a new feature then you should also, if possible, contribute one or more
 additions to the testsuite(s) that check that the new feature works.

 The targets to test depend upon the patch.  If it only affects ARM specific
 files, for example, then you would only need to test a set of ARM targets.
 But if it affects some generic code, then you would need to test a larger
range of targets, including at least the x86 and x86_64 targets. (I currently test ~ 130 targets each day, just looking for regressions).

 With regard to ARM specific changes you should make sure that you check
 an arm-eabi target, plus arm-wince-pe, arm-nto and arm-nacl.



3. Due to active development in binutils, the development branches
move very fast.
    What if the branch, over which my patch is based, moves forward
after the submission of my patch for the review?
    Do I need to rebase it again?

 No and yes. :-)  If the patch is reviewed in a timely manor, then it
 will probably still apply.  Sometimes however patches are not reviewed
 quickly - were are working on this project on a volunteer basis after
 all - so you may find that you want to resubmit a patch, or maybe ping
 the maintainers asking for a review.  In cases like this, where some
 time has elapsed, it is helpful if you can regenerate the patch when
 asking/prompting for a review.

 Also, if you are asking for someone to apply the patch on your behalf,
 because you may not have write permission on the repository, then they
 may ask you to regenerate the patch, if they encounter problems when
 they try to apply it.


I hope that this information helps and we look forward to your future contributions.

Cheers
 Nick

Attachment: request-assign.future
Description: Text document


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