Marco, > Well, given the current state of the code, it's hard to plan changes to > give activity authors a few days to update their code. This particular > change happened because of some refactoring I needed to be able to keep > working on the journal UI.
For what Bert asked, a little help from the framework *might* speed up the entire development process overall. > I think this kind of breakage (etoys not starting) in the daily builds > is acceptable. I'm doing what I can to avoid but I don't want to slow > down development because of it. Sugar is in alpha state, it's not yet > the time to pretend fully stable builds everyday. Such a change doesn't necessarily have to be noticed in advance, but I wish if there were a better mean to communicate with people outside Massachusetts on the kinds of changes to the system. Each sub-system is depending on bunch of libraries and other components, so some seemingly innocent changes by somebody may affect somebody else's component through the dependency chain. You said that people in community should test their stuff daily, but testing without knowning what has changed can lose the focus. (As a starter), what if I ask you to generate the output from "ls -lR" and put them in the build<nnn> directories on the server so that I can just get the diff between them? In this way I will be able to see what kind of problems I should be cautious (for some extent). Removing libGL.so would have been spotted easier, for example with this mechanism. > Clearly if there will be major changes, this will be done more > carefully. But this was only a one liner, trivial change. That was a one liner was Bert's point, too^^; Thank you! -- Yoshiki _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
