Plans about homebrew-avr

[larsimmisch]

The general question is: how do we want to work on this together? Do we want a dev branch and a master branch? Do we want code reviews? Is there a good way to do code reviews on github?

In general, it is really not quite clear to me how to do useful QA with something like this (the stress is on useful, i.e. QA that solves more problems than it creates)

Basically, for every change, I tested the recipes on my local machine and verified it produced the executables, and then tested that the ave-gcc could still produce a binary, but I didn't necessarily test that the binary ran on any of possible targets.

My experience was that most reported issues were from people that had newer OS X versions than me or people with slightly borked setups, and I don't think there is any meaningful defense against these.

[ladislas]

As for the testing, I do the same.

I always have the most up to date version of OS X on one of my machines, so I can do the testing if needed.

we could also set up a travis ci build to control new pull requests and so on, should not be too hard.

as for the branches, I like to have a master branch people can just rely on, a dev branch for testing that might need some tweaking and feature branches to add brand new stuffs.

[leojrfs]

@larsimmisch , yes, thank you.
Well, @jpommerening was talking about the possibility of integrating travis.
If we can get there, some problems you talked about would disappear.

@jpommerening had to delete the other repo like we agreed on, by doing so your comment and the issues where deleted. Can you extend on what precisely could we solve with travis?

[leojrfs]

@ladislas , we posted almost at the same time 😆, anyways, that sounds good dev for some explosions and feature for some bleeding edge 😄

[ladislas]

👍

[jpommerening]

Yeah so, about that Travis thing: The easiest setup would be to just install all the things in this repo. That would at least make sure that everything compiles. Also, with Travis we get a clean slate for each new build, so no more forgetting to uninstall every package before testing. Of course this does not solve all QA problems, but it's something.

This also helps with the code review. Every pull request will be tested and we can see if some proposed change breaks the build without even looking at the code.

@larsimmisch: Regarding code review – GitHub has "pull requests", which are basically just issues with source code attached. You can have a look at the changes, add comments to diffs, you can even fetch them to your local working copy. Here's an example: jpommerening/homebrew-avr#7 – you can click on the "Commits" and "Files Changed" tabs to inspect the Git log and diffs.

As for me I'd much prefer to submit my changes that way (instead of pushing directly to the repo). That way one (or more) of you can have a look at what has changed and merge the changes if they don't see any problem. Also, Travis will do a brew install to make sure that at least that part works.

@leojrfs: Let me give a shot at adding gdb and simulavr. I have some changes in want to do before submitting these :)

[larsimmisch]

@jpommerening

Settings up Travis is probably a good idea. Does Travis understand pull requests?

I know what pull requests are. And they might work ok for a code review tool here. (My experience with them in larger projects is a bit mixed: I very rarely wanted to pull the requests wholesale, most often, I wanted to rework them slightly, and then they look like they aren't accepted when in essence they are)

But let's try it. Send your additions for simulavr and gdb as a pull request, and @leojrfs or @ladislas or me can test them locally and then accept them.

[leojrfs]

lets keep this close, and use the "osx-cross" repo for planning