Skip to content

NotesForDevelopers

Jump to bottom
n-soda edited this page Dec 27, 2022 · 4 revisions

Gfarm - Notes for Developers

branches to maintain

gfarm_v2

We are currently maintaining the following 2 branches about gfarm_v2

  • 2.8 (for gfarm-2.8.0 release)
  • 2.7 (for gfarm-2.7.X release)

If you are fixing bugs, all of above branches must be fixed.

The following branches are out of date but will be updated in the future:

  • master (for gfarm-3.0.0 release) - updates are suspended for now
  • 2.9 (for gfarm-2.9.0 release) - updates are suspended for now

All changes on the 2.7 branch should be be incorporated into the 2.8 branch.

things to do before commit

  • check your changes by using checkpatch
  • fix all warnings, except "warning: ignoring #pragma omp"
  • run the regression tests under the regress directory
  • if your change is ....
    • if your change is a new feature, or a bug fix against already released version, please create a new ticket for the change.
    • if your change is a bug fix to a new feature, and the new feature has not included in any released version yet, you don't have to create a ticket for the bug fix, because you can use an existing ticket about the new feature to record the change.
    • if your change is really trivial one (e.g. fixing typo, general indentation fix), you don't have to create a new ticket, but it's recommended to record the change to an existing ticket about the changed part.

The purposes of using tickets are as follows. And a new ticket must be created in case of 1.

  1. to show users new features and bug fixes in the milestone page.
  2. to track changes about a specific intention for development purpose

things to be written in your commit log

  • please write corresponding ticket number in your commit log. (e.g. #453)
    because most important thing for commit logs is to record your intention. your change itself can be known by "svn diff", but your intention often cannot be. the best way to record your intention is to write ticket number, because it's possible to see multiple related commits about the intention by looking at the ticket.
    It's recommended to record ticket summary as well as ticket number in your commit log. although the summary part is somewhat redundant, this is useful for the following reasons:
    • readers of commit logs can understand your intention without looking at the ticket.
    • typo-proof. even if there is a typo in the ticket number, your intention can be understood.
    • even if we switch to another issue tracking system (we don't have such plan for now, though), and ticket numbering is changed due to the switch, we can keep track your intention after the switch.

things to do after commit

  • please record your commit ID (e.g. commit 28f2d5430) in the comment field of the corresponding ticket.

miscellaneous notes

  • DO NOT run autoreconf on a random OS, because some versions of libtool are buggy.
    use same version of autoconf and libtool with already committed version.
    i.e. use the following version, or just use Ubuntu 12.04 to invoke autoreconf:
    • autoconf-2.68
    • automake-1.11.3
    • libtool-2.4.2

obsolete tickets

There are obsolete bug databases which had been used before migrating to the GitHub issues:

Clone this wiki locally