[sr-dev] source code clean up

[Daniel-Constantin Mierla]

On 05/01/15 10:49, Olle E. Johansson wrote:
> On 05 Jan 2015, at 10:36, Alex Hermann <alex at speakup.nl> wrote:
>
>> On Monday 05 January 2015, Olle E. Johansson wrote:
>>> On 05 Jan 2015, at 09:55, Alex Hermann <alex at speakup.nl> wrote:
>>>> On Friday 02 January 2015 14:20:00 Daniel-Constantin Mierla wrote:
>>>>> If there is something else that should be part of this process, just
>>>>> name it here.
>>>> I think we should remove all the generated README's. They contribute a
>>>> lot to merge conflicts due to paragraph numbering and the fact that the
>>>> Makefile for them is too limited regarding the build environment,
>>>> resulting in large diffs depending on local settings like the system
>>>> locale.
>>>>
>>>> Generating the README's can be made part of the normal build process
>>>> instead. Maybe also a separate top-level target.
>>> I use them quite a lot both myself and in trainings. They definitely need
>>> to be part of the .tar.gz.
>> I didn't mean them to be removed completely, just from the repository. 
>> Generated files don't belong there. They can still be shipped in the tarball. 
>> Git users should be able to just run 'make docs' or something similar in the 
>> root to get the README's generated.
>>
>>
>>> Personally I don't see a problem with the diffs
>>> and haven't myself seen any merge conflicts - how does this happen to you?
>> The reasons are mentioned above. Mainly paragraph numbering and the makefile 
>> not setting up a consistent environment.
> I don't class them as "merge conflicts", but maybe I'm thinking to much SVN where
> I have a lot of merge conflicts...
>
> I do vote for keeping them. It's not a huge problem and keeping docs available
> helps a lot of people.
>
We should keep them, they are very useful and handy on installations,
considering many do it from sources and installing all docbook xml suite
makes no sense (or hard to do it) on all systems (e.g., embedded).

While it is an exposure to conflicts, the regeneration of readme can be
done as separate commit -- it's what I do to avoid conflicts on
backporting, cherry-picking only the commit to xml file and
re-generating the readme in the branch. Same should be done with
branches, just update the xml doc there and the readme after merging.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda