DJ Delorie wrote: > >> If additional filtering is desired: One of the "core developers" > > Again, we just don't have enough "core developers" to add any burden > to them. We need options that *reduce* the load on developers, to > encourage more participation.
See the "if" in my sentence. Core developers are only required if _additional_ filtering is desired. >> 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. > > If they have commit access to the master git, they need to be a > developer. That's kind of our definition of "developer" - you need > to know enough about what's going on, to make smart choices about > which patches to pull. All of them that have been commited by developers to the test repo and have not been seen to break anything for a reasonable amount of testing time. The patch-maintainer does not have to cherry pick anything. He does not have to review code, either. Just read the bug reports and what devs respond. In other words: He automatically commits to git-head unless a patch had been singled out as the cause of trouble. Of course, changes may depend on each other. Then patches will be held back until the blocking feature is ready for prime time. >From the viewpoint of decision making, this is the same situation as now. The developer is responsible for what he commits. Period. Only difference is that he commits to git-test rather than to git-head. > As I said before, that's our procedure - git head *is* our testing > repo. It is "unstable" in the debian sense. What I am asking for, is a repo that is already tested but not as dated as the current releases tend to be. Or more specifically: A repo that contains all patches and features that have been shown to work. >> A fixed calendar would help. I'd say two months of patching followed >> by a month of freeze would be fine. > > A fixed calendar won't work as we don't have dedicated developers. > Our roadmap is to decide on a minimum set of features and bugfixes we > want in the next release, I am not talking about fixed calendar for a release. The calendar is about the internal organization of the testing-to-head-conversion. Note, this is the szenario without the patch-maintainer. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy with moderation of geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
