Re: [Simulavr-devel] [bug #33148] Modifications needed in to compile last simulavr

[Petr Hluzín]

Hi folks

On 1 May 2011 17:26, ThomasK <address@hidden> wrote:
> Hi list,
>
> I'm back after a long time ... ;-) (hopefully) It's a question of free time,
> of course.
>
> About nightly build service:
>
> At all, it's a good idea. In my work I see many such solutions. Some build
> quick and dirty - just for this project only, some with professional
> software. And there are also open source for such tasks. (for example
> hudson)
>
> But for our work it's not ideal at all!
>
> At first, we need a server for such. And we have to pay for it! As I know, I
> don't know a "free" build service, which we could use.
>
> The second is, that we need a build service for different platforms: linux
> with ubuntu or debian, windows with mingw/cygwin, windows with VS and - as I
> assume - also for Apple/Mac.

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.

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

> And at last, our change frequence isn't so high, that we really need a
> nightly build service.
>
> I had some discussions about master branch with Onno a long time ago. :-) I
> think, he's right, that master branch should be stable in every case. Stable
> means at least, that it will compile and build on every platform and that
> "make check" will run successfully.

Yes, this is the usual convention. (And I try to keep it buildable on Linux.)
But build failures happen and can be solved by programmer/commiter by
reverting the offending changes. Users cannot (or should not) revert
and thus can tolerate less breakage. Depends how much effort should
programmers put into preventing the build-breakage.

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

> So my suggestions about this:
>
> - not to use master branch for development, instead create a devel-...
> branch. You can decide for self, if you want to publish this branch or not
>
> - after a change or a bunch of changes is done, commit or merge it to a
> branch called "master-staging" and push a comment to mailing list to check
> and review this on the different platforms
>
> - if it's ok and nobody gets a problem with this change, it can be merged to
> master branch
>
> So we have too a small review process. The task to check this changes on
> "master-staging" isn't so big. It means "bootstrap; configure ...; make;
> make check". And if this is successfull a post to mailing list.

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
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.

And my work consist of cleanups of code and user interface.
Open-source programmers in general do not care about a user interface
and if merging from my branch would require an effort on their side
then I fear they will rather spend arguing why should users learn how
to make the tool work.

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.

Reviews:

Yes, I would definitely prefer some feedback. In fact I am always
nervous about possibility of changing someone's pet code - some
constructs in the code look really weird but I understand that author
may especially like them. I would rather leave such ugly code
construct alone then endure arguing. So far I have been working in
vacuum.

> Just my suggestions for solving problems with instable master.

Reminder: So far it was reported only once. A problem, not problems.
(Of course we do not know how many users were affected. On the other
hand they were not using released software anyway, they should have
expected various ugly things.)

> And, of course, we should commit us about a release!

Maybe we should. Certainly a solution.

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

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.

In order to make release we should decide what things we want to
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".

-- 
Petr Hluzin