Breaking master [Was: [PATCH] Chase Newlib sys/select.h changes]

[Gedare Bloom]

I think it is quite common to need tool updates on the master for
either a change in newlib or a change in RTEMS. At least I can think
of about 6 times during 4.11, so I guess at least yearly it happens.
Maybe that isn't common...

On Thu, Dec 10, 2015 at 8:08 AM, Joel Sherrill <joel.sherrill at gmail.com> wrote:
>
> On Dec 10, 2015 6:50 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>>
>> Nick,
>>
>> We occasionally "break master" by updating newlib or gcc. This is
>> fine, but yes it deserves a shout-out.
>
> After each release branch is cut, there is a period where the frozen tools
> continue to work. But usually this doesn't last long as backed up newlib or
> gcc changes force a tool update.
>
> On top of that, it is the development master and the tools will evolve and
> update. Sometimes causing breakage.
>
> One thing that would help is in the 4.11 branch only accepted rtems4.11 and
> the master rtems4.12. That helps a little but it doesn't stop the 4.12 tools
> from sometimes needing an update.
>
> I suppose the minimum is a big red announcement when tool updates are known
> to break the master and require you to build new ones.
>
> FWIW I do not expect autoconf or automake to upgrade again. We will move to
> waf build system and side-step dealing with them.
>
>> On Thu, Dec 10, 2015 at 4:40 AM, Nick Withers <nick.withers at anu.edu.au>
>> wrote:
>> > Hullo again,
>> >
>> > On Thu, 2015-12-10 at 20:04 +1100, Nick Withers wrote:
>> >> Hi all,
>> >>
>> >> Attached is a patch for master similar to that I posted to the Newlib
>> >> mailing list in https://sourceware.org/ml/newlib/2015/msg00888.html *
>> >> .
>> >>
>> >> It chases Newlib changes to sys/types.h / sys/select.h and allows us
>> >> to use Newlib's sys/select.h directly rather than rolling our own.
>> >
>> > This patch would break building master with pre-08184b3 Newlib.
>> >
>> > Is this a problem? Should it be?
>> >
>> >
>> > How would folk feel about declaring that the master branch, like
>> > FreeBSD -CURRENT [1], is "unstable" and subject to changes like this
>> > that require the end-user to be on their game?
>> >
>> > Could we then just have an UPDATING-equivalent and/or mailing list post
>> > for changes like this that says "hey, you need to recompile your
>> > tools"?
>> >
>> > ...Or should we invest the time and effort to ensure that maintain
>> > backwards-compatibility whereever possible across all branches?
>> >
>> >
>> > I suppose there'd probably need to be releases more regularly to avoid
>> > people being somewhat-forced onto master. Other thoughts?
>> >
>> >
>> > [1] https://www.freebsd.org/doc/handbook/current-stable.html
>> > --
>> > Nick "definitely not trying desperately to avoid having to touch
>> > autotools" Withers
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel