Hello,
here I am proposing some items for removing from the source code, to keep it cleaner:
- $Id$ or the other SVN expandable tokens - they are svn specific, some of them even included expanded. Typical location is at the beginning of the file. They are useless now or very old (when expanded)
- the 'history' section in source code - typical location is after license at the beginning of the source code files. Used mainly during CVS times, the content is very old (even more than 10 years) and in many cases misleading now. If there is something relevant, we can discuss and eventually move as comments to functions or parts of the code. We have no proper commit logs and git blame is helping to track what is current in the code
- git branches that were merged or very old (no longer suitable for merging)
If there is something else that should be part of this process, just name it here.
This is not going to happen quickly (although it would be good) and it is addressed here to make the developed aware, when they work on a file or have spare time ( :-) ), to consider removing those parts.
I would prefer to be a dedicated commit (can be for many files at once, but not across components -- e.g., one commit for a module, not mixing for many modules or modules+core+libs ...), to be easy to check it doesn't break the code.
Cheers, Daniel
On 02/01/15 14:20, Daniel-Constantin Mierla wrote:
Hello,
here I am proposing some items for removing from the source code, to keep it cleaner:
- $Id$ or the other SVN expandable tokens - they are svn specific, some
of them even included expanded. Typical location is at the beginning of the file. They are useless now or very old (when expanded)
- the 'history' section in source code - typical location is after
license at the beginning of the source code files. Used mainly during CVS times, the content is very old (even more than 10 years) and in many cases misleading now. If there is something relevant, we can discuss and eventually move as comments to functions or parts of the code. We have no proper commit logs and git blame is helping to track what is current
ERRATA ^^^ : We have __NOW__ proper commits logs ...
in the code
- git branches that were merged or very old (no longer suitable for merging)
If there is something else that should be part of this process, just name it here.
This is not going to happen quickly (although it would be good) and it is addressed here to make the developed aware, when they work on a file or have spare time ( :-) ), to consider removing those parts.
I would prefer to be a dedicated commit (can be for many files at once, but not across components -- e.g., one commit for a module, not mixing for many modules or modules+core+libs ...), to be easy to check it doesn't break the code.
Cheers, Daniel
On 02 Jan 2015, at 14:20, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
here I am proposing some items for removing from the source code, to keep it cleaner:
- $Id$ or the other SVN expandable tokens - they are svn specific, some
of them even included expanded. Typical location is at the beginning of the file. They are useless now or very old (when expanded)
Yes.
- the 'history' section in source code - typical location is after
license at the beginning of the source code files. Used mainly during CVS times, the content is very old (even more than 10 years) and in many cases misleading now. If there is something relevant, we can discuss and eventually move as comments to functions or parts of the code. We have no proper commit logs and git blame is helping to track what is current in the code
Yes.
- git branches that were merged or very old (no longer suitable for merging)
Can't really say anything about this personally.
Any developer can do this while watching boring TV shows or participating in a poorly managed teleconference... :-)
/O
If there is something else that should be part of this process, just name it here.
This is not going to happen quickly (although it would be good) and it is addressed here to make the developed aware, when they work on a file or have spare time ( :-) ), to consider removing those parts.
I would prefer to be a dedicated commit (can be for many files at once, but not across components -- e.g., one commit for a module, not mixing for many modules or modules+core+libs ...), to be easy to check it doesn't break the code.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
On 05 Jan 2015, at 09:55, Alex Hermann alex@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. Personally I don't see a problem with the diffs and haven't myself seen any merge conflicts - how does this happen to you?
/O
On Monday 05 January 2015, Olle E. Johansson wrote:
On 05 Jan 2015, at 09:55, Alex Hermann alex@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.
On 05 Jan 2015, at 10:36, Alex Hermann alex@speakup.nl wrote:
On Monday 05 January 2015, Olle E. Johansson wrote:
On 05 Jan 2015, at 09:55, Alex Hermann alex@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.
Sign "Documentation lover"
On 05/01/15 10:49, Olle E. Johansson wrote:
On 05 Jan 2015, at 10:36, Alex Hermann alex@speakup.nl wrote:
On Monday 05 January 2015, Olle E. Johansson wrote:
On 05 Jan 2015, at 09:55, Alex Hermann alex@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
On 01/05/15 04:09, Olle E. Johansson wrote:
I use them quite a lot both myself and in trainings. They definitely need to be part of the .tar.gz. Personally I don't see a problem with the diffs and haven't myself seen any merge conflicts - how does this happen to you?
I've seen it happen due to different locales, or some people building them on UTF-8 enabled platforms while others don't, etc. You end up getting a different output (different characters or encodings for special characters, quotation marks, etc) even though the content hasn't changed. At least this part should be standardized IMO.
cheers
On 01/02/2015 02:20 PM, Daniel-Constantin Mierla wrote:
- git branches that were merged or very old (no longer suitable for merging)
Now that we are officially in github, from my POW there is no need to have personal/temporal branches. Anyone can fork and pull-request when needed.
I would suggest to remove all but master, 3.X, 4.X
Cheers, Victor
-
Alex Hermann -
Daniel-Constantin Mierla -
Olle E. Johansson -
Richard Fuchs -
Victor Seva