Re: gEDA-user: test repo

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

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: kmk@xxxxxxxxxxxxxxx
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user