Re: Let's ROCK

Am Donnerstag, 25. Mai 2006 10:04 schrieb Dave Fancella:
> All,
>
...
> I'm more interested in community merits than technical merits.  Not that I
> ignore technical merits, but for most projects, and definitely one the size
> of rock, the community is all important, since I'm looking to join that
> community.  I'm finding the level of help available and the quality of that
> help to be very good, and I'm very grateful for it.  I've managed to
> achieve most of my goals so far checking out rock, the only one I'm waiting
> for depends on a finished build of target crystal, which is in progress as
> I write this.  And for that I'll have to be on my own, away from the irc
> channel.
>

btw. it's really easy to test ISO images with qemu (and not _that_ slow :) 

...
> I have to say, for something the size of ROCK, having only 3 developers
> with commit access might be a dealbreaker for me.  The whole purpose of
> SCM, svn in particular, is to enable many *many* developers to work
> simultaneously on a project.  I don't know what the goal of this SubMaster
> thing is, it sure looks neat, but from where I'm standing it doesn't look
> like a functional replacement for developers with commit access.  The
> obvious conclusion there is that developers with commit access are a
> bottleneck, and I've been around enough to feel confident in declaring that
> even if I don't see direct evidence.  The size of the project is enough to
> justify that, all 3 developers would have to work on it full-time to keep
> up with the amount of maintenance work needed, to say nothing of developing
> for the future.  Maybe you don't see it that way, that's fine.  Diversity
> is all about disagreeing peacefully, isn't it?  And I can peacefully be on
> my way if it turns out that's the best thing to do, or I can peacefully
> remain if that's the best thing to do.

I totally agree that having only a few developers with commit access can be a 
bottleneck, ROCK Linux has had these problems not long ago. With only one 
person with commit access, we had at peak times almost 200 patches waiting to 
be applied to trunk (this was also because this one person was severly ill at 
that time). What really made this situation difficult was to sort out 
duplicates, dependencies and conflicts between those patches. 

Benjamin (blindcoder) set up a community tree everyone had comit access to, 
which included all pending patches. This allowed to have those patches in a 
consistent state before they were applied to the real trunk. I spent almost a 
week writing a program that can detect duplicates, conflicts and dependencies 
between patches, so this tedious work could be automated.

Why all this hassle if we could also give commit access to every developer? 
Certainly not because we believe in some enlightenend Linux gurus who always 
know better. 

I think the main reason is quality control through peer-review and test 
cycles: for changes to core parts of a software, it is usually a bad idea to 
commit them immediately. Instead you'd like to have them reviewed publicly to 
help find bugs and improvements. You'd also want to do some test builds and 
test runs to help find unforseen negative effects of changes.

AFAIR, when I began using ROCK in 2004, everybody working on ROCK (including 
those with commit access) sent their patches to the rock-devel mailing list 
for peer-review. The stable and devel tree maintainers tested patches, 
against which there were no objections, in their reference builds, and  
applied them  if there were no obvious errors,. 
Note that all patch submitters were (and still are) required to do basic tests 
with their patches (not a full reference build), or clearly mark their 
patches as untested.
A full reference build, including most packages, btw. can easily take a few 
days - esp. when errors (introduced by changes) occur.

So this was indeed a bottle-neck. It was also much work only to collect, 
test-apply and possibly fix all those patches, and keep track of them over a 
mailing list. Clifford eventually wrote SubMaster, which can do several 
things: it's a public, central patch repository that keeps track of all 
patches that have ever been uploaded; it offers public peer-review of and 
voting on patches; and it helps users, developers and maintainers to collect 
and use/test arbitrary sets of patches (called journals in SubMaster).

During the Chemnitzer Linux Tage 2006, the attending ROCK developers 
(including me) agreed to have (for now) three persons with commit access for 
usual patches and one person for instant, security-related patches. We also 
generally agreed that:
- all patches to core parts (like basic tools and packages) undergo public 
review (through SubMaster);
- if there are no objections (contra votes) they are tested (in bootdisk and 
Crystal builds) and eventually applied. Security related patches are applied 
immediately.
- Patches to non-core parts (most targets and packages) are applied if the 
respective maintainer votes pro, or when there are no objections (if that 
part is unmaintained).

Note that the SubMaster server side was completely rewritten following CLT 
2006, and e.g. automated commits for pro-voted, non-core patches don't work 
yet. But we really like to do it to share maintainance work and speed up 
development.

...
> :)  So the extensive use of shell scripting is a bad thing for me if any of
> the following conditions apply:
>
> 1.  The existing rock applications (mine, stone, etc) stay exactly as they
> are, which is the cause of the rough-edged ui and would well prevent the
> kind of customizations I'm wanting to make.

It's relatively easy to replace or extend those applications, and it would 
also be possible (and a good idea) to make the type of package manager and 
installer a Config option.

>
> 2.  You guys want to move to Perl or some other language that drives me
> crazy and makes me have to take medication to deal with.  Python isn't a
> requirement, I can handle other languages and would be happy to learn a new
> one, Perl and C are dealbreakers for me.

The SubMaster server side, e.g. is written in WebSPL. For an introduction, see  
http://www.clifford.at/spl/

>
> 3.  You guys refuse to take Python anyway for core apps, for a reason such
> as "This would cause parallel development of the same features, and we'd
> like to do it this way instead".

If that'd be the case we wouldn't have like 17 window managers in ROCK 
Linux ;-) 
You're very welcome to write replacements for core apps, or extend them. As 
long as I can decide which ones to use in my builds, that's jolly fine with 
me :)

Cheers,
	Stefan Fiedler

...
> Dave
>
> _______________________________________________
> rock-devel mailing list
> [email protected]
> http://www.rocklinux.net/mailman/listinfo/rock-devel