Re: removal of submaster

Hi,

first of all: sorry for the two weeks backout. I've been knocked down by a
heavy acute fibrinous bronchitis..

On Fri, Feb 10, 2006 at 02:05:34PM +0100, Andreas V. Meier wrote:
> Reasons:
>  - Patches get applied only rarely, like half-year-wise.

Usually it is 1-2 weeks. I need about one week for doing a ref. build on my
test machine. Sometimes there are serious troubles with one patch or
another and I need some days to fix it. Sometimes I even need to do a 2nd
reference build when the first one was to broken because of a dangerous
patch.

btw: you, avm, are pretty good in sending patches which do then delay this
process for a week or more because they are broken.

> Replacement:
>  1. experimental subversion branch, that is accessible for (web-)registered
>  users. This almost the same as the submaster webinterface, but much more
>  comfortable to use. 
>  Patches are merged to the stabilization-trunk after a  regression test. 
>  Votes can be stored in subversion properties

Obviously you did not try to do such a thing already. We (linbit) are doing
that for merging features from the commercial DRBD branch to the public
(GPLed) tree.

This is a hell of a work for just some patches. I can't imagine doing that
for the patchload we have in ROCK..

It is especially important that one patch (e.g. a simple package update) can
overtake another patch (e.g. an experimental redesign of Build-Target). And
it must be possible to write patches independent of other patches, e.g.
because one patch is an alternative to another one. All that is not or not
easily possible with something like a world-writeable branch..

>  2. git (blindcoder?)
>  [add other suggestions here]

with git you wouldn't have a list of patches waiting to go to the official
tree. (there also wouldn't be an official tree ;-)

You would need to send all your patches (sha1 checksums) upstream to someone
else who is higher in the hiarchy, etc.

This is great for dealing a huge project like the linux kernel, but it adds
a lot of overhead. Much more than one has with SubMaster. So the problems
you are talking about would be much harder with git..

The reason why git works great for the linux kernel is that one usually
does not need 1-2 weeks for testing a change.

you want to improve the patch cycles? then _please_ provide the help I have
asked for already two years ago when we started using SubMaster:

	Create smap journals. Make test builds with them and send me the
	results. Then I can apply the patches sooner.

	I have just one test machine and it often is a bad idea to make to
	big journals with to many breaking changes. So I have limited
	resources for testing the changes. And without testing them I can
	not apply them.

yours,
 - clifford

-- 
L I N : B I T           ___
 _______ __ _____  ____|_  |  The OSS cluster synchronization tool for
/ __(_-</ // / _ \/ __/ __/   configuration files an application images
\__/___/\_, /_//_/\__/____/   --- [ http://oss.linbit.com/csync2/ ] ---
       /___/
 
Hoffnung ist der erste Schritt auf der Strasse der Enttaeuschung.