[Fwd: Re: [RFC] Software Process Improvement in Free Software, Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -------- Original Message --------
Subject: Re: [RFC] Software Process Improvement in Free Software,
Closing the Quality Cycle, Inventing Non-Developer-Demotivating QA/QM/SPI
Date: Fri, 05 Nov 2004 19:01:57 +0100
From: Thomas Schorpp <t.schorpp@gmx.de>
Reply-To: t.schorpp@gmx.de
To: Fabian Fagerholm <fabbe@paniq.net>
References: <4185D3BA.8050000@gmx.de> <1099379943.4022.22.camel@kernel>
~ <41876309.70501@gmx.de> <1099664702.4025.80.camel@kernel>
Hello Fabian,
I'll answer first in short comments,
Fabian Fagerholm wrote:
| Hi,
|
| I've given this a lot of thought, sorry about the delay.
Thank You, me too.
|
| 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?
No, You are able to manage quality yet. I dont want to be a new
"manager" or some of these consultants or something like.
What I could do for (with) You is to start with QA Process Assessments
to determine capability leaks. Such data and scores could be used then
to optimize the debian-qa processes in steps of years.
|
| 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?
Strong requirement on implementing every QM-System.
| 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.
Developers shouldn't have to "join", either they should not be
discriminated. Interesting research how to do this.
|
| 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.
Full agree.
|
| 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 fear, You are thinking to far, lets start with analysises,
implementation stages in the Quality Circle are far away, under the
mentioned circumstances.
|
|>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)
They've got organisation internal QA/QM and SPI systems. Shouldn't need
~ us. Nevertheless there should be "interfaces" beetween both systems.
| 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.
They do that by themselves (if they've got enough resources) or we could
help them doing it by providing our QM resources to them, e.g.
|
| 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.
Learned.
|
| 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.
Yes, in my opinion tools are a good solution for rationalising QM for
production practioneers. Let me make it clear, ISO 9000- like
QM-Handbooks and paper nobody will ever read IS OUT, for sure.
|
| 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.
Interesting, how the community has brought in this process improvement...
|
| 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.
There's more needed, but is it applicable and if it is, how? Thats the
question. Cases to research.
|
| People, in the sense that the autonomy of individual developers must be
| respected.
A must.
| 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.
Learned - Welcome to production.
|
| 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.
No, that's scored modern best industry practice. Congratulations.
|
| 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,
I prefer high automation grades and ergonomics for such tools.
How much good text documentation does lie around unread and ununderstood?
| not just what happens when you press the
| little yellow button. Not that that isn't important.
|
Again, we're far from implementation, You're far too big-stepping here
;) . Need more analysis on higher process abstraction here...
|
|>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?
Appreciated, please give me some weeks time to work it out, there're
many adaptions to OSS needed.
|
| Cheers,
Y
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.90 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iQCVAwUBQYvA1Wqsze5HSzyoAQKGmgP9EJZfIPP12GMU/j1wHSNVPGmFpUnd5Z3h
CT5jAbi4kFuGOeoWYyjcYc9+xNRVz23ZelRAxHh0/IiQ7VLFdD+lAe/ttzbAFXtw
kV7OCY3Wy6VZCus+kItXBxm8OEsyaFM8pGM1I92Ik7UJOblHe2SI1cEPiFZHNBPt
h9rbk+MuxYs=
=aB4k
-----END PGP SIGNATURE-----
Reply to: