Am 04.12.2017 22:25, schrieb Fabien Chéreau:
Hi Georg,
Here is a simple wiki page about the branches:
https://github.com/Stellarium/stellarium/wiki/Branching-Strategy
I also created a draft main wiki page:
https://github.com/Stellarium/stellarium/wiki/
Good!
The content obviously must be migrated from the old wiki. One issue is
that a large part of the up-to-date content is actually in the (really
great) user guide, and I don't think it would be wise to duplicated it
again in the new wiki. Did you find a way to render the User guide as
a clean HTML page, so that we can simply put link to refer directly to
it?
Alexander and I have re-assembled the user guide from the wiki back into
LaTeX. I think the PDF version should be the definite user guide (and
kept up-to-date in the master, or maybe separated into another git?) The
program is so complex and demanded by various user groups (beginning
stargazers, advanced observers, historians, cultural astronomers, ...)
that good and exhaustive documentation is an essential component, and a
hyperlinked PDF is my favourite format. For me, the online HTML manual
could be dropped, or it should be recreated (for every release?) from
the same LaTeX sources and placed on the main website (stellarium.org).
Else for me there is no point in manually keeping LaTeX and HTML in
parallel.
I don't know about the translated guides. There seem to be fragments (or
even complete versions?) of Matthew's guide in a handful of languages,
but nothing past the 0.12 series, I think. Keep it, or drop it?
Translating the 300 pages and semi-automatically keeping it current
looks like huge work, not sure if anybody would volunteer.
The wiki should IMHO contain dev documentation, short guidelines how to
build on various platforms, but not program usage.
Maybe extended release notes and FAQ can be kept/placed into the wiki to
replace (most of the) FAQ from LP.
Of course, historically important content could be kept somewhere, but
who decides if hints e.g. about OpenGL1.2 cards are relevant enough to
keep?
Kind regards,
Georg
Fabien
On Mon, Dec 4, 2017 at 7:44 PM, Fabien Chéreau
<fabien.cher...@gmail.com> wrote:
Yes, I will do that, even though I don't want to fix everything into
marble ;)
For me the most important goal is that when looking at the history
of the master branch, we see only one linear list of commits most of
the time.
For example, in the last days there was a few merges of branches
containing just a few small commit. It's much better for these to
appear as standard commit on master rather than branch merge. For
this, a rebase is needed before pushing to master
Fabien
On Mon, Dec 4, 2017 at 11:44 AM, Georg Zotti
<georg.zo...@univie.ac.at> wrote:
Dear Fabien,
I have started reading the progit book, and it describes a lot of
strategies for development. However, how they best apply to
Stellarium is still not fully clear to me.
It might even be good to have a "master" (from which the numbered
releases are created) and "dev" or "next" branches (for the weekly
betas?)
The progit book has a warning section about when not to use rebase.
(esp. after branching from public non-master branches)
I usually just merged BZRs trunk to my branches before merge
requests, or after large updates on trunk. Maybe this can be better
replaced by a rebase with git? And of course we merged branches into
trunk when they were ready.
Maybe you can develop&clarify such "collaboration guidelines" on our
github wiki?
Kind regards,
Georg
Am 04.12.2017 11 [1]:06, schrieb Fabien Chéreau:
Hi,
after migrating the git, I noticed that the history of stellarium is
full of merge commits, and this is a real mess to understand.
We should really avoid merge commits unless they are really
necessary
(I would say only for stable branch -> master synchronizations), and
try to keep the history linear. I already changed the settings on
github so that pull requests are only allowed when rebased.
In general, if someone has a branch to merge in the tree, he should
always rebase the branch first (git rebase origin/master), and then
simply push the branch on master (git push origin HEAD:master). At
the
end the commits will just add on the top of the current master's
head
and the history will remain linear.
Fabien
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stellarium-pubdevel mailing list
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
