Re: removal of submaster

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas V. Meier wrote:
> Hi,
> 
> as discussed on irc, I want to ask to replace submaster.
> 
> Reasons:
>  - Patches get applied only rarely, like half-year-wise. They are updated two or
>  more times while lingering in the web-frontend, sometimes don't apply anymore
>  or just with manual fixes, and more negative implications of aged patches.
>  - devs that use submaster and have applied patches locally regularly get into
>  synchronization troubles when the master trunk applied patches after a long
>  time, due to the fixes that the application procedure made necessary.
> [add your reasons here]
> 
> 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
>  2. git (blindcoder?)
>  [add other suggestions here]
> 
> Background:
> I am a quite calm and lazy person. I continued using submaster, although it
> imposed usability regressions. It had made many ROCK developers already leave
> the project in favour of a fork. My reason for not switching was mainly the
> uncomfortable explosive ego of the fork's leader. From what I hear, I am not the
> only one that feels that way.
> We should change something, in a way that it pleases the _majority_ of the
> remaining dev's. Otherwise I fear ROCK will continue to peter out and die due
> to lack of vital ressources - developers.

I wholeheartedly agree that the current approach to patch tracking - SubMaster -
is hindering ROCK development more than helping to advance it. Especially since
patch applications seem to become a monthly occurance at best.

ROCK development for me has stalled quite a bit due to the slow patch
application process. Also, if I take myself as any kind of reference, people
tend to try out patches only when they appear in ROCK, not when they appear in
SubMaster.

Clifford: If you are overworked, more interested in other projects or simply too
lazy right now or anything else that prevents you from spending as much time on
ROCK as you used to... PLEASE accept that we are here to HELP you.
Noone here wants to break ROCK by submitting updates to glibc, kernel, binutils
or similiarly important packages the minute they appear.
But this seems to be your primary concern if I understood you correctly at 22C3.
That "wild submission of code to subversion" would break the now really usable
trunk.
Even if this would happen, what's the worst that'll happen as a result?
The one submitting the change will get a slap on his wrist and the change
reverted by a 'trick' you taught me some time ago:

	svn merge -r $(($n-1)):$n . && svn ci .


Besides... there are so few ROCK developers right now that it's by far not like
herding a bag of fleas.

Greetings,
	Benjamin
- --
Go away, or I will replace you with a very small shellscript!
	http://shellscripts.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFD7JvTr0OTeImXvg8RAjeRAJ9U/PgxT+rzcZUSzigRVI4nBsV7bACg0/cs
IOmTwLjFBIROLSt5VVp/YCU=
=8EH3
-----END PGP SIGNATURE-----