On Mon, Dec 4, 2017 at 11:16 PM, Georg Zotti <georg.zo...@univie.ac.at>
wrote:
> 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.
>
Definitely, what we would need is maybe an HTML version of the PDF. I don't
think first time users will bother downloading 25Mb pdf guide, just to see
the quick start..
> 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.
>
I think we can just drop these. Same thing for the wiki, a quick look at
other languages show that it's really outdated / not consistent with the
english version.
> The wiki should IMHO contain dev documentation, short guidelines how to
> build on various platforms, but not program usage.
>
I agree. Every information which is already in the guide should just point
to the guide (ideally as HTML). No duplication. Maybe it's also a good
place for users to advertise their extensions (textures, plugins etc..)
> Maybe extended release notes and FAQ can be kept/placed into the wiki to
> replace (most of the) FAQ from LP.
>
The release notes would be better in github releases I think, but the FAQ
could be fine there yes.
> 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?
>
There is someone who created a script to transfer bugs from launchpad to
github. But I'm not sure we want to migrate everything at once without
filtering..
Fabien
>
> 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
>
------------------------------------------------------------------------------
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
