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

[Joel Sherrill]

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 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151210/37c211ac/attachment-0002.html>