[Simulavr-devel] Nightly build service, was: [bug #33148] Modifications needed in to compile last simulavr

[ThomasK]

Hi Petr,

> We do not have to cover all combinations (myriad). I believe there are
> are POSIX-based systems - whose look identical for our purposes. And
> there is a Visual Studio build. If someone breaks buildability on VS I
> do not mind fixing that. So buildability on any Linux would cover most
> bases.

Yes, agree! ALL combinations are simply impossible. And for me I just
use it on Linux (Ubuntu). I have too made some changes on MinGw/Cygwin,
because I had this time and a windows box. In the moment I could provide
MinGW on a win7 box. But, for example not an Mac system. And I don't
want to install VS2008 (or VS2010). So I couldn't test it. But we
provide it in our repo and we should try to hold it running.

And I agree too, that Linux and MinGW - to provide windows - are the two
main systems. (btw. do we have Mac user on the list?)

> Why do you think nightly build service is not usable for us?
> Is it difficult to setup? If yes, isn't that a bug?

Not really difficult if you don't want to test special cases. But the
main point is, that in my opinion, you'll find only services, which you
have to pay for! And we havn't changes every day, where a nightly build
service is necessary.

For my opinion it's necessary to make such "nightly build" after a
change was commited and pushed to public repo. Just to know, that it's
running or if not, to get a hint, that there is something broken.

For example, a hudson server can be configured this way. The results are
the build output (and of course test results, if configured) and the
build products, all accessible on a http server. And it sends mails to
all developers in case of failure, which have made changes since last
sucessfull build. Such is really usefull for projects, which have a
dedicated platform or hardware. (for example control units, where code
is cross-compiled and there is a hardware-in-the-loop test equipment for
testing)

I our case it would be enough, if we have a few developers, which fetch
code after a change (and a post on the list), run make and make test and
push results back to list. Results mean: sucessfull or not and maybe a
errormessage. Just a little bit effort, but not really much.

> ... and thus can tolerate less breakage. Depends how much effort should
> programmers put into preventing the build-breakage.

That's the point. Ok, a final "bootstrap, configure, make, make check"
after a change or finishing a task on a clean local repo clone should be
at least possible. (our build needs only a few minutes, not hours ... I
know such projects, build about 1,5 hours, test some days ...)

But, for example, I couldn't check it on Mac or Win with VS!

> This also creates pressure to make release for users, or maybe
> "technology preview" release.

:-))

> The problem is that I am afraid it will be difficult to merge the
> branches with Git. I too scared to even try that. I have bad

If you merge from master-staging to master and master isn't changes
since last merge (or initial branch), then it's simply a fast-forward
merge! Sure, you have to think about, what you're doing. But nobody
prevents you to clone your working repo before you start such
"dangerous" operations and do that on the clone, not your originally
working repo. If it fails, then you havn't broke you origin and you can
start over.

I have learned to handle with git in this way. Or tried something out,
where I'm not sure, if this works in this way. That's in my opinion one
of the great advantages of git, it's the same, if you try local or push
to a remote repo, just change the URL! (not, for example, like svn,
where you need a server to work!)

> experience working with Git/TortoiseGit (and F/OSS in general). It is
> like filling tax forms - being required to fill fields I (and most
> people) do not care for in order to achieve something which is
> principally simple.

:-))

> So I would prefer if other programmers do not have to do anything with
> my patches. They will say "meh, another stupid diagnostic added" and
> move along. Except when I accidentally break the build.

I know, what you mean. And we are all hobbists, not hired for a
professional work on this. But some rules are necessary and user
interfaces are also important. And a clean and well designed user
interface isn't bad.

> In general I believe in: release early, release often, get stuck.

Maybe not to often. ;-) But in fact more often than now! :-)

> For example current Tcl/Python (SWIG) binding reveals all of the
> internals. It is technically almost impossible to not break that in a
> next release. (Please let's not solve that by another abstraction.)
> And AvrDevice::SetClockFreq() requires script users to set period, not
> frequency.

Agree in both cases. But there I'm also in "a vacuum", means, there is
to less response, to decide, what's needed and what not.

> promise to not break. I prefer to promise nothing and call such
> release "technology preview release" or "look what has been cooked in
> grandma's pot".

Sounds good for me. Just to provide a precompiled package for users,
which don't want to handle with repos and make and compiler and such.
Just to get more response, what's good and what's wrong, what's
unneccessary and what's needed.

cu, Thomas