Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Tue, Mar 07, 2006 at 03:51:42PM -0600, Jeremy Blosser (emrys) wrote:
[...]
> In connection with this vote I move that the QA and Security Teams be
> dissolved, with their respective responsibilities falling to the relevant
> areas.  ie, the Grimoire Team would be responsible for their own security
> updates and releases, same with the ISO and Sorcery Teams, etc.  We don't
> have the people to keep up on all of these teams, and at least until we do
> I think it's more appropriate for each "product" team to handle their own
> security patches and releases.  If someone agrees I'd ask them to second
> this motion, and then I'd ask the PL to judge how best to make a decision
> inside the timeframe of the Grimoire Lead vote.

I do think we should merge security and QA concerns into the grimoire team.
While the security and qa teams did a good job, there wasn't really a
clear distinction between those teams. As a grimoire lead I approved and
integrated several fixes to stable/stable-rc grimoires, which are
technically the QA team responsibility, mostly because - as Seth said in
his mail - the teams were not big enough to delegate such changes all
the time. The same also happened with security fixes, those have always
been handled both by the security team and the grimoire team, as often
normal version updates also include security fixes.
So what I'm saying is that the three have always overlapped quite a bit.
If they get merged into one grimoire team, I would set up informal
sub-teams for them inside the grimoire team. Informal as in not having
some hierarchy inside either the grimoire team or those sub-teams, but
instead just having a group of developers for those sub-tasks that are
interested in them and consider them their pet-projects. This would
mostly be experienced developers that have been with us for a while as
it obviously requires access to the stable grimoire. I imagine other
developers who take an interest in those areas to work through bugzilla,
with a defined way to notify the developers who currently have access to
stable to those issue (probably a little more specific than the current
'integrate to stable' flag).

Now to the point of further development of the grimoires, I want to
encourage more standardization and code reuse in our grimoire. We have
worked towards this for quite a while now, starting with grimoire and
section FUNCTIONS that helped remove a lot of duplicate code parts. We
need to continue this, including reorganizing parts of the grimoire for
easier code reuse, like it was done with php-pear, perl-cpan and
python-devel. One of the most important requirements for this to happen
is to have the currently existing infrastructure for code reuse and the
current standards better documented. While I am not a particularly avid
doc writer myself, I hope to encourage others to take up that task and
will help anyone who does so with everything he or she needs.

As the question of switching away from perforce has just come up again,
here are my thoughts on that, though they mostly coincide with what Seth
has already said. Yes, I'm in favor of seeking for perforce
replacements. I have tested several SCMs in the past for exactly that
purpose and came to the conclusion that none of them offered all the
features I expected and still offered enough stability to be used.
Looking at this pragmatically, I won't push a Free alternative that
doesn't meet our needs just because it's Free. As Seth mentioned, this
is not the least a matter of people volunteering to gather the exact
requirements we have and make detailed tests with various systems. I'll
happily work together with anyone who wants to take on that task.

I've always believed that the best type of leadership in Free Software
development teams is to lead by example, so that's what I have done and
will continue to do. It's one of the reasons I like to tackle the hard
spells like the split gcc compilers or glibc.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org