Code commit and review process

[pbrier]

Would it be a suggestion to implement a "formal" code commit and review process?
e.g. something like this:
https://github.com/energia/Energia/wiki/Bug-fix-and-new-feature-review-process

We could use topic branches, or at least have some staging in the process from feature/bugfix to master branch (e.g. using a "development" branch)

The github wiki pages could be used to document the process (along with coding styles and other considerations)

[bogdanm]

Hi Peter,

On Sun, Oct 20, 2013 at 1:14 PM, Peter Brier [email protected]:

Would it be a suggestion to implement a "formal" code commit and review
process?
e.g. something like this:

https://github.com/energia/Energia/wiki/Bug-fix-and-new-feature-review-process

We could use topic branches, or at least have some staging in the process
from feature/bugfix to master branch (e.g. using a "development" branch)

The github wiki pages could be used to document the process (along with
coding styles and other considerations)

One possible issue with this approach is that we accept pull requests from
two different sources: github.com and mbed.org. Defining a common policy
would probably be difficult due to the differences in the interfaces and
usability of these two sites, while defining two different policies might
be confusing. Is there something in particular that bothers you with our
current process?

Thanks,
Bogdan

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/87
.

[pbrier]

Currently using the HEAD master branch sometimes breaks a build, due to fixes that are pulled in, that are
not sufficiently scrutinized (e.g. see Issue #94 and issue #95, due to pulling in Issue #91).

I would propose that before anything is put in to the master branch, at least:

• The code is build for all compilers, targets and configurations (it should not fail)
• All samples are build (and auto tests performed)
• The code is reviewed by someone else than the author

Does this make sense?

[emilmont]

Hi Peter,
by default we do check the build only with ARMCC and the process is launched manually.

Does this make sense?

Of course, it makes sense.
We are planning to trigger this process automatically, triggered by github pull requests and to add all the compilers. This would have detected the issue introduced for the GCC compiler (#94).

Cheers,
Emilio

[aethaniel]

Hi Emilio,

Sorry to disturb but when this validation process would be available?

Does it also mean that any pull request, for example bringing new devices port, would have to take ARMCC into consideration?
Obviously a patch on code previously validated on ARMCC would have to be working.

My concern is really about providing new devices (and boards) with ARM GCC based projects.

Cheers

[emilmont]

Hi Aethaniel,

when this validation process would be available?

We should have it before the end of the year.

Does it also mean that any pull request, for example bringing new
devices port, would have to take ARMCC into consideration?

No, it will be configurable, similarly to what we are doing for the build releases:
https://github.com/mbedmicro/mbed/blob/master/workspace_tools/build_release.py#L29

It is totally fine to submit a "pull request" adding support for a new target even if it is initially tested only with GCC.

Cheers,
Emilio

[matthewelse]

Hi Everyone (this is probably more useful for Emilio),

Have you considered using something like Travis-CI, which could build all of the code when a push is made, and then provide you with a nice graphic that you could include in the README... The only problem might be that it probably doesn't have all of the embedded compilers. If Travis-CI doesn't include the necessary compilers, you could possibly look at something like Buildbot (used by OpenCV), which might allow more flexibility.

Thanks,

Matthew

[mbednotifications]

It'd be very easy to setup Travis test with GCC and could even run on Qemu
too. I'm more the happy to help! I suppose GCC would be rather enough to
catch most errors, while there might be some compiler-specific cases, we
could still get a green or red light for trivial pull-requests much
quicker. If merging and testing that is done by the maintainers is
currently decoupled, then we could probably make master 80% more stable by
adding Travis... By the way, one can deploy Travis on their site too
(perhaps this could be done to provide ARMCC).

[matthewelse]

Just out of interest, who sent that? It just says mbed notifications...

[matthewelse]

I've just got a travis proof of concept working - see 3da2549. The build succeeded on all of the targets that officially support GCC_ARM, however they use Ubuntu, so there's not much we can do about ARM_CC at the moment.

[matthewelse]

Just done a test pull request as well, just to make sure that Travis is doing its job properly, and so far it seems to be working well... 👍

[aethaniel]

Indeed, Travis-CI seems really interesting.
Why do you have this error: E: Unable to locate package gcc-arm-none-eabi ?
Is it because we can't install external packages?

[matthewelse]

I only had that error on either the first commit, which I had to fix, and when I purposely broke it on a branch to make sure it was working ok

[matthewelse]

The most recent commit on the master branch passed. See this: https://travis-ci.org/matthewelse/mbed/builds/13145173

[aethaniel]

I saw. Great job, Matthew. Thanks for sharing this.

[matthewelse]

No problem... It could be a bit interesting getting ARM_CC to run though. Maybe wine, or something like that would run it?

[aethaniel]

does it have to be installed each time a job is run? I saw the VM is rebuilt every time but maybe I misunderstood this.

[matthewelse]

Yeah it has to be all reinstalled.

[aethaniel]

wouldn't this be a bit heavy at long term?

[matthewelse]

Yes it would, especially if we're having to virtualise windows in order to
run ARM_CC to compile everything... It may be something that requires a custom install of travis-ci or something like it on ARM's own servers to keep compilation times down.

[aethaniel]

is ARM CC part of DS 5? there is a linux distribution for the community edition. Maybe Emilio could have the answer.

[matthewelse]

I think that DS-5 and ARM-CC are separate but I might be wrong... Yeah he probably would, but I have a feeling that the mbed team are over in San Francisco for the week and it'll still be early morning there.

[matthewelse]

Actually, I think you might be right. I'm downloading DS5 onto my ubuntu machine now, but it's a massive download (800MB) so it's still not practical in its raw form to be used on a vm that's rebuilt every time.
Just thought, I reckon the mbed online compiler is probably hosted on a linux server, so there must be a version of ARM-CC for linux.

[matthewelse]

The good news is, ARMCC at least works on wine, though it's a bit of an ugly solution especially with a gui installer. I'm still waiting on the DS5 download.

[aethaniel]

The question of ARM-CC should be also the same for IAR.
Maybe having a build passed using Travis on ARM GCC would be enough for a first validation step before the pull request code review.

[matthewelse]

It would certainly help, but it's by no means as useful as I'm sure Emilio and Bogdan would like it to be...

[matthewelse]

(not having ARM-CC, that is) <- As this is used for the online compiler, this is the most important validation step I suppose

[matthewelse]

There's also the fact that the build.py script tells you which target builds have passed and which have failed. It'd be nice to somehow use that to our advantage.

[mbednotifications]

I can compile with armcc without having to install the whole uvision
package. Just copy the whole armcc folder (with bin/include/lib) somewhere,
and then copy TOOLS.ini to the bin folder and you should be able to compile
from that path.
Not ideal but if you can run that from wine at least you don't have to run
the installer (just inzip). I'm not sure how all this works with licensing,
so please don't get me arrested ARM :)

On Monday, October 28, 2013 6:39:30 AM UTC-7, Matthew Else wrote:

There's also the fact that the build.py script tells you which target
builds have passed and which have failed. It'd be nice to somehow use that
to our advantage.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/87#issuecomment-27211788
.

[errordeveloper]

Looks like github has some issue with comments by email, few usernames including mine show up as mbednotifications instead or is it the way this is setup with the mailing list?

[matthewelse]

Yeah I think we'll pretty much have to get ARM to sort this out for licensing reasons, but I'm sure they'll have no problem sorting it out, seeing as they make the compilers...

[matthewelse]

The problem is that when you reply to the google group, it goes through the google group to github, so goes down in mbed notifications.

[Joey-Ye]

Hi, Matt,

I've just got a travis proof of concept working - see 3da2549. The build succeeded on all of the targets that
officially support GCC_ARM, however they use Ubuntu, so there's not much we can do about ARM_CC at the
moment.

GCC_ARM should run on all linux distribution, windows and Mac OS. It was tested against ubuntu, redhat. People run it on debian successfully. https://launchpad.net/gcc-arm-embedded/+download

Please could you try it and let me know in case it has any problem running on your system.

Joey

[emilmont]

Hi all,
sorry for the delay, this week we are very busy in California for the "mbed connect" conference and TechCon.

Yes, ARMCC is cross-platform and there are also releases for Linux.

Thank you for your suggestions about Travis. This goes exactly along what we are planning to do.

The big picture is that we want to build a bigger farm of mbed devices and we want to provide it as a service through mbed.org for automating these sort of tests: not only the build, but the actual functionalities.

We are actually hiring an engineer that will be responsible for this project:

Cheers,
Emilio

[matthewelse]

That sounds really interesting, so are you planning to have some sort of automated infrastructure of mbeds that test the builds as they come in?