On Mar 24, 2015, at 9:26 AM, Steven Ross wrote:

On Tue, Mar 24, 2015, 12:00 PM Marshall Clow wrote:

...

Just a reminder that we’re coming up on a release; and if you have changes that you want to see in the release (I know *I* do), you should get them in ASAP.

Check them into develop, and then, once the tests have cycled successfully, merge them to master.

Please do not merge anything to master w/o permission from the release managers after the start of April (11:59 PM next Tuesday PDT).

Also, if you know of problems with the current state of the master branch that would preclude releasing it, please let us know (preferably *before* next Wednesday).

Is there a way to verify which version of my library (sort) will be in the release? I fixed a bad doc link a couple weeks ago in the sort library master, and would like to verify that it will make it into the release.

If it’s in the master branch at 00:00 1-April, then it will make it into the release. — Marshall

On 24/03/2015 17:46, Andrey Semashev wrote:

On Tuesday 24 March 2015 09:00:32 Marshall Clow wrote:

...

Also, if you know of problems with the current state of the master branch that would preclude releasing it, please let us know (preferably *before* next Wednesday). What about the changes to Config, Build, Context and Log with respect to architecture checks? Will these changes be merged to master before release?

I'm happy to merge the Config changes if that's the right thing to do. Do those merges need to be coordinated? John.

If I'm not mistaken, Config only adds the checks, so it should be safe to merge it first. The rest can go after that, preferably synchronized.

Ah yes, the changes aren't used by anything else as yet, so shouldn't effect anything. On that basis config is merged, feel free to merge the others when you're ready. John.

On 03/24/2015 09:40 PM, Oliver Kowalke wrote:

2015-03-24 19:29 GMT+01:00 John Maddock :

...

If I'm not mistaken, Config only adds the checks, so it should be safe to

...

merge it first. The rest can go after that, preferably synchronized.

Ah yes, the changes aren't used by anything else as yet, so shouldn't effect anything. On that basis config is merged, feel free to merge the others when you're ready.

better one release manager merges the required changes (config, context etc...) at his local branches and then pushes the commits to remote

I mean to do that - along with suppressing extra elements in path - but won't be able to work on that until weekend. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com