[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnuastro-commits] (no subject)
From: |
Mohammad Akhlaghi |
Subject: |
[gnuastro-commits] (no subject) |
Date: |
Fri, 27 May 2016 09:31:58 +0000 (UTC) |
branch: master
commit 3607c5701754706e6e8edc19425145b89a965184
Author: Mohammad Akhlaghi <address@hidden>
Date: Fri May 27 18:19:50 2016 +0900
New "Forking tutorial" name for section, more clarity
The old "Branching workflow tutorial" was renamed to "Forking tutorial" to
be more clear. Also following some questions asked by Navid Mousavi, some
further clarifications were added to the "Developing" chapter:
- That interested people don't need to become a Savannah member to be
able to clone and develop in Gnuastro.
- That the repository hosting services will need to know your public SSH
key in order for the `git push' command in the "Forking tutorial"
section to work.
Besides these, in some places, it was found that "let's" was mistakenly
written as "lets". This was also corrected.
---
doc/gnuastro.texi | 94 +++++++++++++++++++++++++++++++++--------------------
1 file changed, 59 insertions(+), 35 deletions(-)
diff --git a/doc/gnuastro.texi b/doc/gnuastro.texi
index dab17b4..3651219 100644
--- a/doc/gnuastro.texi
+++ b/doc/gnuastro.texi
@@ -513,7 +513,7 @@ Contributing to Gnuastro
* Copyright assignment:: Copyright has to be assigned to the FSF.
* Commit guidelines:: Guidelines for commit messages.
* Production workflow:: Submitting your commits (work) for inclusion.
-* Branching workflow tutorial:: Tutorial on workflow steps with Git.
+* Forking tutorial:: Tutorial on workflow steps with Git.
Other useful software
@@ -7073,7 +7073,7 @@ Wikipedia}. We see that
@mymath{\lim_{m\rightarrow\infty}a(\pi)=-1}, while
interpretted as an angle in units of radians and therefore how
@mymath{a(v)=cos(v)} and @mymath{b(v)=sin(v)}.
-Since @mymath{e^{iv}} is periodic (lets assume with a period of
+Since @mymath{e^{iv}} is periodic (let's assume with a period of
@mymath{T}), it is more clear to write it as @mymath{v\equiv{2{\pi}n\over
T}t} (where @mymath{n} is an integer), so @mymath{e^{iv}=e^{i{2{\pi}n\over
T}t}}. The advantage is of this notation is that the period (@mymath{T}) is
@@ -7374,7 +7374,7 @@ convolution (@mymath{C(\omega)}) can be written as:
}
@noindent
-To solve the inner integral, lets define @mymath{s{\equiv}l-\tau}, so
+To solve the inner integral, let's define @mymath{s{\equiv}l-\tau}, so
that @mymath{ds=dl} and @mymath{l=s+\tau} then the inner integral
becomes:
@@ -7687,7 +7687,7 @@ understood in one dimension, it is very easy to
generalize them to two
or even more dimentions since each dimension is by definition
independent. Previously we defined @mymath{l} as the continuous
variable in 1D and the inverse of the period in its direction to be
address@hidden Lets show the second spatial direction with
address@hidden Let's show the second spatial direction with
@mymath{m} the the inverse of the period in the second dimension with
@mymath{\nu}. The Fourier transform in 2D (see @ref{Fourier
transform}) can be written as:
@@ -7724,7 +7724,7 @@ since most imagers have square pixels, we assume so here
too}:
Finally, let's represent the pixel counter on the second dimension in
the spatial and frequency domains with @mymath{y} and @mymath{v}
-respectively. Also lets assume that the input image has @mymath{Y}
+respectively. Also let's assume that the input image has @mymath{Y}
pixels on the second dimension. Then the two dimensional discrete
Fourier transform and its inverse (see @ref{Discrete Fourier
transform}) can be written as:
@@ -13239,7 +13239,7 @@ steps and conventions as our 2D friend, we arrive at:
@address@hidden(z)=[ \Omega_{\Lambda,0} + \Omega_{C,0}(1+z)^2 +
@c\Omega_{m,0}(1+z)^3 + \Omega_{r,0}(1+z)^4 ]^{1/2}}
address@hidden Lets take @mymath{r} to be the radial coordinate of the emitting
address@hidden Let's take @mymath{r} to be the radial coordinate of the emitting
@c source, which emitted its light at redshift $z$. Then the comoving
@c distance of this object would be:
@@ -13680,6 +13680,22 @@ the development discussions. Therefore, it is not
recommended to directly
post an email to this mailing list, but do all the activities (for example
add new issues, or comment on existing ones) on Savannah.
+
address@hidden
address@hidden
address@hidden I need to be a member in Savannah to contribute to Gnuastro?}
+No.
+
+The full version controlled history of Gnuastro is available for anonymous
+download or cloning. See @ref{Production workflow} for a description of
+Gnuastro's Integration-Manager Workflow. In short, you can either send in
+patches, or make your own fork. If you choose the latter, you can push your
+changes to your own fork and inform us. We will then pull your changes and
+merge them into the main project. Please see @ref{Forking tutorial} for a
+tutorial.
address@hidden cartouche
+
+
@node Developing mailing lists, Internal libraries, Gnuastro project webpage,
Developing
@section Developing mailing lists
@@ -14430,7 +14446,7 @@ ensure that Gnuastro can remain free in the future, see
@ref{Copyright
assignment}. From the technical point of view, in this section we also
discuss commit guidelines (@ref{Commit guidelines}) and the general version
control workflow of Gnuastro in @ref{Production workflow}, along with a
-tutorial in @ref{Branching workflow tutorial}.
+tutorial in @ref{Forking tutorial}.
Recall that before starting the work on your idea, be sure to checkout the
bugs and tasks trackers in @ref{Gnuastro project webpage} and announce your
@@ -14442,7 +14458,7 @@ help you.
* Copyright assignment:: Copyright has to be assigned to the FSF.
* Commit guidelines:: Guidelines for commit messages.
* Production workflow:: Submitting your commits (work) for inclusion.
-* Branching workflow tutorial:: Tutorial on workflow steps with Git.
+* Forking tutorial:: Tutorial on workflow steps with Git.
@end menu
@node Copyright assignment, Commit guidelines, Contributing to Gnuastro,
Contributing to Gnuastro
@@ -14543,7 +14559,7 @@ org''.
To be able to cleanly integrate your work with the other developers,
@strong{never commit on the @file{master} branch} (see @ref{Production
-workflow} for a complete discussion and @ref{Branching workflow tutorial} for a
+workflow} for a complete discussion and @ref{Forking tutorial} for a
cookbook example). In short, leave @file{master} only for changes you
fetch, or pull from the official repository (see
@ref{Synchronizing}).
@@ -14636,7 +14652,7 @@ introduction too.
address@hidden Production workflow, Branching workflow tutorial, Commit
guidelines, Contributing to Gnuastro
address@hidden Production workflow, Forking tutorial, Commit guidelines,
Contributing to Gnuastro
@subsection Production workflow
Fortunately `Pro Git' has done a wonderful job in explaining the different
@@ -14646,7 +14662,7 @@ and in particular the ``Integration-Manager Workflow''
explained there. The
implementation of this workflow is nicely explained in Section
address@hidden@url{http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project}}
under ``Forked-Public-Project''. We have also prepared a short tutorial in
address@hidden workflow tutorial}. Anything on the master branch should always
be
address@hidden tutorial}. Anything on the master branch should always be
tested and ready to be built and used. As described in `Pro Git', there are
two methods for you to contribute to Gnuastro in the Integration-Manager
Workflow:
@@ -14663,7 +14679,7 @@ solution.
You can have your own forked copy of Gnuastro on any hosting site you like
(GitHub, GitLab, BitBucket, or etc) and inform us when your changes are
ready so we merge them in Gnuastro. This is more suited for people who
-commonly contribute to the code (see @ref{Branching workflow tutorial}).
+commonly contribute to the code (see @ref{Forking tutorial}).
@end enumerate
@@ -14685,18 +14701,21 @@ might change and evolve to better suite our needs.
address@hidden Branching workflow tutorial, , Production workflow,
Contributing to Gnuastro
address@hidden Branching workflow tutorial
address@hidden Forking tutorial, , Production workflow, Contributing to
Gnuastro
address@hidden Forking tutorial
This is a tutorial on the second suggested method that you can submit your
-modifications in Gnuastro (see @ref{Production workflow}). Let's assume you
-want to start contributing to Gnuastro and you would like to use
address@hidden
+modifications in Gnuastro (see @ref{Production workflow}), which is
+commonly known as forking. Let's assume you want to start contributing to
+Gnuastro and you would like to use address@hidden
@url{https://www.gnu.org/software/repo-criteria-evaluation.html} for an
-evaluation of the major existing repositories.} to keep your work remotely
+evaluation of the major existing repositories.} to host your work remotely
and share it with other Gnuastro developers once you are ready. You can
-create an empty repository on the GitLab webpage (this applies to any
-service, not just Gitlab!). Here we'll assume you use the name
+create an empty repository on your hosting service webpage. If this is your
+first hosted repository on the webpage, you also have to upload your public
+SSH address@hidden example see this explanation provided by GitLab:
address@hidden://docs.gitlab.com/ce/ssh/README.html}.} for the @command{git
+push} command below to work. Here we'll assume you use the name
@file{janedoe} to refer to yourself everywhere and that you choose
@file{gnuastro-janedoe} as the name of your Gnuastro fork. Any online
hosting service will give you an address (similar to
@@ -14710,22 +14729,26 @@ $ git remote add janedoe
git@@gitlab.com:janedoe/gnuastro-janedoe.git
$ git push janedoe master
@end example
-The full Gnuastro history is now pushed onto your GitLab account and the
+The full Gnuastro history is now pushed onto your hosting service and the
@file{janedoe} remote is now also following your @file{master} branch. If
you run @command{git remote show REMOTENAME} for the @file{origin} and
@file{janedoe} remotes, you will see their difference: the first has pull
access and the second doesn't. This nicely summarizes the main idea behind
this workflow: you push to your remote repository, we pull from it and
merge it into @file{master}, then you finalize it by pulling from the main
-repository. The process above is only necessary for your first time setup,
-you don't need to repeat it. However, please repeat the process below for
+repository.
+
+To test (compile) your changes during your work, you will need to bootstrap
+the version controlled source, see @ref{Bootstrapping} for a full
+description. The process above is only necessary for your first time setup,
+you don't need to repeat it. However, please repeat the steps below for
each independent issue you intend to work on.
Let's assume you have found a bug in one of the functions of
@file{lib/statistics.c} and after announcing it (see @ref{Report a bug}),
you are in charge of fixing it. You make a branch, checkout to it, correct
the bug, check if it is indeed fixed, add it to the staging area, commit it
-to the new branch and push it to your GitLab account. But before all of
+to the new branch and push it to your hosting service. But before all of
them, make sure that your @file{master} branch is up to date with the main
Gnuastro @file{master} branch.
@@ -14740,15 +14763,16 @@ $ git commit
$ git push janedoe bug-123456-stats
@end example
-Your new branch is now on your GitLab repository. You can then let the
-other developers know that your @file{bug-123456-stats} branch is ready,
-and they will pull your change, test it themselves and if it is ready to be
-merged into the main Gnuastro history, they will merge it into the
+Your new branch is now on your hosted repository. Through the respective
+tacker on Savannah (see @ref{Gnuastro project webpage}) you can then let
+the other developers know that your @file{bug-123456-stats} branch is
+ready. They will pull your work, test it themselves and if it is ready to
+be merged into the main Gnuastro history, they will merge it into the
@file{master} branch. After that is done, you can simply checkout your
local @file{master} branch and pull all the changes from the main
-repo. After the pull you run address@hidden log}' as shown below, to see
-that your separate @file{bug-123456-stats} is merged with master. So you
-can push all the changes to your GitLab account and delete the branches
+repo. After the pull you can run address@hidden log}' as shown below, to see
+how @file{bug-123456-stats} is merged with master. So you can push all the
+changes to your hosted repository and delete the branches:
@example
$ git checkout master
@@ -14764,8 +14788,8 @@ and remote branch so work can progress on them
independently. After you
make your announcement, other people might contribute to the branch before
merging it in to @file{master}, so this is very important. Also before
starting each issue branch from @file{master}, be sure to run @command{git
-pull} in @file{master} as shown above, to simplify the merging process
-later.
+pull} in @file{master} as shown above, to start your branch (work) from the
+most recent history point and thus simply the final merging of your work.
@@ -14792,7 +14816,7 @@ changes, see @ref{Documentation}.
@item
Commit your change to your issue branch (see @ref{Production workflow} and
address@hidden workflow tutorial}) Afterwards, run Autoreconf to generate the
address@hidden tutorial}) Afterwards, run Autoreconf to generate the
appropriate version number:
@example
@@ -14814,7 +14838,7 @@ and try to compile it in the most general cases, then
it will run the tests
on what it has built in its own mini-environment. If @command{$ make
distcheck} finishes successfully, then you are safe to send your changes to
us to implement or for your own purposes. See @ref{Production workflow} and
address@hidden workflow tutorial}.
address@hidden tutorial}.
@end enumerate