[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: test repo
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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user