Misplaced Directories?

[Chris Johns]

On 03/05/2018 15:21, Sebastian Huber wrote:
> On 03/05/18 03:55, Chris Johns wrote:
>> On 02/05/2018 21:25, Sebastian Huber wrote:
>>> On 02/05/18 13:18, Joel Sherrill wrote:
>>>> On Wed, May 2, 2018, 12:13 AM Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de
>>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>>      > I think that's it from my notes. Any comments or thoughts?
>>>>
>>>>      I would leave the source files in cpukit where they are. A proper
>>>>      file
>>>>      history is more important than a fancy directory layout from my
>>>>      point of
>>>>      view
>>>>
>>>> Doesn't got keep history with moves and renames?
>>> It works to some extent. You usually need a --follow command line option. It is
>>> not completely transparent.
>>>
>> I think not allowing code movement in the cpukit as a rule is too restrictive. I
>> do not support such a restriction. I think code can be moved in the cpukit tree.
>>
>> I would have questioned the 'dev' tree being added if I knew this restriction
>> existed. I think adding 'dev' is a good change and we should look to move parts
>> that existed before it was created into it. I think a sensible layout is worth
>> more than the linear history for _those_ pieces of code.
>>
>> The RTEMS code base is old and if we had not moved files we would be in a tragic
>> place. The moving of the headers and BSP code is a good example of why we need
>> to move source and the threshold for those files to move was higher than the
>> need for a clean history. We need to be smart about what we move, why we want to
>> move things and when. The threshold to move files in rtems, sapi and score is
>> very high. This does not rule out moving files in those directories, it just
>> means we need to balance the cost/benefit ratio when deciding. A clean history
>> for those directories and files is important and highly rated.
>>
>> Give the extent of code moved for RTEMS 5 I am OK with the directories Joel has
>> listed moving. I welcome the cpukit being cleaned up.
>>
>> Chris
>>
>> ps Please reconsider using terms like "fancy directory layout", it is not
>> helpful in a discussion about moving files after you have moved most of the
>> c/src (which is a fantastic thing to have happened).
> 
> The header file movements were driven by the need to get rid of the preinstall
> step. This is a clear benefit. The movements of the BSP source files are a
> consequence of this.

Agreed.

> If you really want to clean up the cpukit source files, then please create a
> ticket and make a plan.

This is Joel's to manage.

> I am strongly opposed to move files in rtems, sapi and score.

Noted.

I do not see any movement in those directories for the foreseeable future. 15
years ago I thought the BSPs would never move. My open response is about the
time frame we are talking about, 10, 15 or even more years?

I can still type 'c/src/lib/libbsp' without thinking about it. At least at my
age it will not take long to forget.

> It should be carried out before the 5.1 release. 

Agreed.

Chris