On 24 May 2012 08:32, Rich Freeman <email@example.com> wrote:
> Sure. The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases the amount of pain
> our end-users run into due to the mistake, which leads to lots of
> flame wars on -dev. That means that the guy who made the mistake is
> subjected to more public ridicule, and is less likely to do it again,
> That improves quality too.
> Since cvs doesn't tie together tree-wide changes in a nice way or
> allow them to be transactionally completed, individual package
> maintainers don't need to be as concerned with the big picture view.
> Now as the maintainer of libfoo the fact that somebody changed my
> ebuild without making a corresponding change in some profile is
> completely hidden from me, and I can go to sleep peacefully without
> realizing that my users are all going to have horribly broken systems
> in the morning. Blissful ignorance of end-user suffering improves
> developer morale, and helps get rid of pesky users at the same time.
> cvs also makes more more aware of what is going on around me. Anytime
> I want to work on something in parallel with the main development
> branch I get to manually merge changes in, which keeps me aware of my
> place in the world. That means that I'm less likely to build nice new
> features, which means fewer bugs, which improves quality, and may even
> drive away users as an added bonus!
> See, cvs is really the wave of the future!
<meta name="sarcasm" value="on" />
This CVS stuff sounds a bit too uppity and unstable to me, sounds like
we should go back to the tried and true code collaboration by
date-stamped tarballs of the tree which are centralised once a week to
a master tarball.
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"