Hi folks On 1 May 2011 17:26, ThomasK <[email protected]> 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 _______________________________________________ Simulavr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/simulavr-devel
