Andrew Poelstra wrote: > On Mon, Sep 05, 2011 at 03:21:25AM +0200, Kai-Martin Knaak wrote: >> Proposal to tone down the impact of patches breaking important features: >> >> Add a branch "test" to git. This branch would work pretty much like >> sid/unstable repo of debian. It would receive all the new stuff so >> advanced users like me can give them a test run. >> If a patch stands the test by same time, it will be applied to git-head. >> > > My thoughts on this: > > This sounds like a good idea, but depends on developer availability > (who will move features from testing to master?)
If additional filtering is desired: One of the "core developers" Else, whoever commited the patch in the first place. Or someone who takes the job as his/her task in the project. This wouldn't neceessarily have to be a developer. He or she just has to be familiar with git and the build tools in general. The difficult task is to determine, when a patch has seen enough testing. But then again -- Currently, most patches are applied directly to git-head with no intermediate test repo. At worst, a premature application by the "patch-master" would yield the same situation as we have now. > , and would probably end up being of limited usefulness. A transition like debian/testing to debian/stable would remove the necessity to move single patches. There would be a freeze period, during whitch only bug fixes but no new features are applied to the test-repo. Then the test repo is moved wholesale to git-head. This is sort of mini-release. A fixed calendar would help. I'd say two months of patching followed by a month of freeze would be fine. And again, the actual work of moving repo versions around does not necessarily have to be shouldered by devs. > My mil-to-nm changes and Peter C's rendering/cleanup changes have both > been so intrusive that any "minor" changes applied after-the-fact, would > simply not apply without those changes. So they would be stuck in testing > for as long as mil-to-nm is. This seems like no problem to me. It does not delay development in any way compared to the situation now. > So you might want to just checkout your own branch with this reverted, > and rebase any new changes against that: Sure, you can always go back in a git repo. But this needs informed bisection when the critical changes occured. Also, it requires the skill to work with git and build the application locally. A mini-release could be offered as a package ready to install on the servers. This might draw more users into the testing boat. --> More eyes, more bugs spotted, more quality. ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de -----> not happy with moderation of geda-user mailinglist _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
