[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI



Hi,

I've given this a lot of thought, sorry about the delay.

On Tue, 2004-11-02 at 11:35 +0100, Thomas Schorpp wrote:
> | This sounds quite interesting, but I wonder if there is enough knowledge
> | about these things in the Debian community to even have a meaningful
> | discussion?
> 
> At least many experienced SW engineers and prooject leads, QMs who have
> worked for the big ones (Siemens, SAP, HEIDELBERG) or automotive (BOSCH,
> JOHNSON, VDO, HARMAN-BECKER, VW, PORSCHE, BMW, DC, HP, NASA) have at
> least basic experience in these practices. I'd like to get assigned some
> webspace on qa-debian.org to publish presentations and guides what
> should convince the current team to be commited to extend QA to QM and
> SPI with (my) help.
> 
> First Readings and base could be the mentioned SPR book, the SEI
> (sei.cmu.edu) publications are more advanced but considered as too
> "academic" in industry.
> 
> A most practical invention was the Rational's Software Unified Process,
> prefered by developers. Even small and middle companies like it.

If I understand you correctly, you would like to take what is currently
known as the "Debian QA team" and let it undergo a metamorphosis, after
which it will have the knowledge and routine to manage "quality" in
Debian. Is my understanding correct?

If we assume that we can actually get the QA team to agree on this, and
implement a plan and a process for quality management, will the rest of
the project members be able and willing to follow it? The obvious answer
is that "it depends on the process" -- but my question is if there can
ever be *any* change in the current Debian process that does not divide
the Debian developers. And if the developers are divided, what means are
there to either rejoin them or expel those who are in opposition? The
volunteer nature of the project, and the terms of joining it, mean that
there are no strong means to do either. The project consists of
autonomous individuals, and the incentive to do or not do something is
on an individual level.

One approach, certainly a tempting one, would be to implement a process
that certain key persons -- the ones who do the implementation work --
and a maximum number of supporters, could agree on. The rest could
decide to stay and comply, or go. At the same time, a lot of software
would be left without maintainers; the burden of quality control would
be eased if support for that software was dropped. This is the
"intrusive quality management process". It doesn't take very much effort
to see why this is not a good idea.

Another approach would be to implement a careful process that could be
embraced by a supermajority in the project, and try to gradually improve
it. This is the "nonintrusive quality management process". It doesn't
take very much imagination to see that it would not differ much from the
current QA work.

> I'm fully aware of that, so we've to invent systems for qualiy circles
> not considerable to take the "typical" free linux developers their
> freedom. A strongest requirement.
> Most of the above models are for "herding" proprietary sw-development in
> large organisations often implemeted in "misuse" of the standards for
> negative additional "stress and power pressure" on hired developers
> maintained by isolated teams of ph-d's of older age.
> It's best practice to get the developers in and commited to the system (
> at my knowlegde only HEIDELBERG has done so) or high risk of failure
> would occur from the start.

OSS could be divided into two categories: software that is essentially
produced and maintained by a single entity (MySQL, the Mono Project,
certain IBM projects such as EVMS, etc) and software that is co-produced
and co-maintained by the community that surrounds it. The former
typically requires copyright assignment to the main entity before code
contributions are accepted, while the latter forms a joint copyright
network.

In the single-entity-copyright case, the entity in question typically
has already implemented some kind of quality management process, if such
a process is desired. It is also the responsibility of such an entity to
do so, if needed, and there is really no other way of doing it since the
code is owned and controlled by that entity alone.

In the joint-copyright-network case, quality management varies. Some
groups have established a more formal process, while some groups have no
process at all. A subset of this group -- most of the popular pieces of
software -- has one characteristic that is worth noting. The quality
management is very much tool-based. Procedures and processes are not
laid out in process documents, they are implemented in the tools, and in
advice of best practise in the usage of these tools. It's a tool
tradition, not a document tradition.

The most important tools in this sense are SCM tools (CVS, Subversion,
Arch, BitKeeper, ...), mailing lists/forums, and real-time chat (IRC,
ICQ, Jabber, ...) and some key software that is specific for each
project. These dictate all kinds of processes to a much higher degree
than one might think at first. Probably the best known example is Linux,
which went from patches-per-email to the BitKeeper system because the
prior was a bottleneck in the process.

In Debian, quality management is as diverse as the tools used. Some
people use CVS. Some use Subversion. Some use Arch. I imagine there must
be someone using darcs as well. There is a multitude of mailing lists.
There have been web fora for some time now. There is IRC, and many
developers use at least Jabber, if not many other means of real-time
chat. The key software is things like apt, dpkg, the build tools, and
the glue tools that link the SCM of your choice to dpkg-buildpackage.
Some people use sbuild, some use pbuilder. Some use debhelper, some use
cdbs and there is still software that is built by a completely
customized debian/rules file. And this is just the start.

In my opinion, a quality management process for Debian must focus on two
things: people, and tools.

People, in the sense that the autonomy of individual developers must be
respected. At the same time, any single developer should not be able
block anyone else's efforts towards improving the quality of Debian. The
work here has already begun, with teams cooperating to maintain sets of
packages instead of having a one-to-many -relationship between
maintainer and package. I also see no reason why the same software could
be distributed in different configurations -- apart from the obvious
downside that it will increase archive size.

People, in the sense that the ways of joining and contributing to Debian
must be developed. There have been many suggestions in this department,
some have been about introducing a hierarchy, while others have followed
the idea of teams. To me, softening the hierarchy and introducing a more
dynamic model seems best, but that is only unfounded opinion.

Tools, in the sense that Debian should focus on improving its most
important tools that were partly described above. Most of all, the art
of packaging should be supported with a simpler and cleaner way that is
clearly superior and makes it less tempting to "roll your own rules".
cdbs -- a step in the right direction, but it needs to come with SCM and
a build environment that catches your mistakes (such as missing
build-deps) early, and allows you to just drop in patches to be applied
at build-time. It has to facilitate working on the software, not
fiddling with the tools.

Tools, in the sense that the tools must be powerful but safe, and they
must come with good documentation on how they fit into the Debian
software development process, not just what happens when you press the
little yellow button. Not that that isn't important.

> First for us theres to be an research project with assessments due to
> the advanced requirements to OSS, if sufficent output, after then the
> implementation.
> 
> 
> | In this sense, I would probably suggest to begin by trying to inform and
> | educate the community in this area, and gradually build a knowledge base
> | to enable this discussion.
> |
> 
> I'm gladly ready to start if i've got the little resources needed to do so.

Could you elaborate? What exactly is needed? How do you envision this
effort to go forward from here?

Cheers,
-- 
Fabian Fagerholm <fabbe@paniq.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: