-----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 <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Fabian Fagerholm <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ~ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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-----
