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 <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
