On 22/01/2018 21:11, Sebastian Huber wrote:
> On 22/01/18 01:06, Joel Sherrill wrote:
>>
>>
>> I am open to any ideas that improve how we use and manage the RSB.
>>
>>
>> I don't want to move away from release branches or including the versions
>> in the files.
>>
>> Having the versions in the
On 22/01/18 01:06, Joel Sherrill wrote:
I am open to any ideas that improve how we use and manage the RSB.
I don't want to move away from release branches or including the versions
in the files.
Having the versions in the files makes it easy to upgrade all but one
or two
architectures.
On Sun, Jan 21, 2018 at 4:00 PM, Chris Johns wrote:
> On 19/1/18 5:12 pm, Sebastian Huber wrote:
> > The RSB policy with respect to configuration files is not clear to me. I
> thought
> > these are read-only files that will be never removed?
>
> That policy was established when the RSB was buildi
On 19/1/18 5:12 pm, Sebastian Huber wrote:
> The RSB policy with respect to configuration files is not clear to me. I
> thought
> these are read-only files that will be never removed?
That policy was established when the RSB was building a number of releases from
a single code base. The branching
The RSB policy with respect to configuration files is not clear to me. I
thought these are read-only files that will be never removed? If you
want to keep only the files used by the build sets, then why do they
have file names with a version included?
Are branches in the RSB really practical?
