Pokud jste na začátku chtěli něčím přispět (záplata nebo hlášení o chybě), poslali jste to Linusovi. To se vyvinulo v zaslání poštou na seznam (což bylo [email protected] před kernel.org byl vytvořen).
Neexistovala žádná kontrola verzí. Čas od času Linus umístil tarball na FTP server. To byl ekvivalent „tagu“. Dostupné nástroje na začátku byly RCS a CVS a ty Linus nenávidí, takže všichni jen posílali záplaty. (Je tu vysvětlení od Linuse, proč nechtěl použít CVS.)
Existovaly i jiné proprietární systémy pro správu verzí před vydáním Bitkeeperu, ale decentralizovaný vývoj Linuxu založený na dobrovolnících znemožnil jejich použití. Náhodný člověk, který právě našel chybu, nikdy nepošle opravu, pokud musí projít proprietárním systémem správy verzí s licencemi začínajícími v tisících dolarů.
Bitkeeper oba tyto problémy obešel:nebyl centralizovaný jako CVS, a přestože to nebyl svobodný software, přispěvatelé jádra jej mohli používat bez placení. Díky tomu to na chvíli stačilo.
Dokonce i při dnešním vývoji založeném na gitu jsou e-mailové konference stále tam, kde se děje. Když chcete něčím přispět, připravíte to samozřejmě pomocí git, ale než se to sloučí, musíte to prodiskutovat v příslušném mailing listu. Bugzilla je tu od toho, aby vypadala „profesionálně“ a nasávala polovičatá hlášení o chybách od lidí, kteří to skutečně ne chcete se zapojit.
Chcete-li vidět některé ze starých pokynů pro hlášení chyb, stáhněte si historické úložiště Linuxu. (Toto je úložiště git obsahující všechny verze z doby před tím, než git existoval; většinou obsahuje jedno potvrzení na vydání, protože bylo rekonstruováno z tarballů). Soubory zájmu zahrnují README , MAINTAINERS a REPORTING-BUGS .
Jedna ze zajímavých věcí, které tam můžete najít, je toto z Linux-0.99.12 README:
- if you have problems that seem to be due to kernel bugs, please mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup. The mailing-lists are
useful especially for SCSI and NETworking problems, as I can't test
either of those personally anyway.
Procesy využívaly diskusní skupiny (USENET) a (převážně) e-mail. Ve vláknu „existovala“ chyba a vložila „[BUG REPORT] “ nebo „LINUX BUG REPORT " v předmětu byla běžná konvence. Neobsahovala žádná ID chyb. Vzhledem k typické uživatelské základně přicházelo hlášení o chybě často s opravou. Byl použit jeden dávno zapomenutý softwarový nástroj:ibug (viz níže), jiné než diff +patch .
Z Instalace Linuxu a Začínáme (Leden 1994, archivovaná kopie verze 2.0)>
2.6 The Design and Philosophy of Linux When new users encounter Linux, they often have a few misconceptions and false expectations of the system. Linux is a unique operating system, and it is important to understand its philosophy and design in order to use it effectively. Time enough for a soapbox. Even if you are an aged UNIX guru, what follows is probably of interest to you. In commercial UNIX development houses, the entire system is devel- oped with a rigorous policy of quality assurance, source and revision control systems, documentation, and bug reporting and resolution. [...] With Linux, you can throw out the entire concept of organized development, source control systems, structured bug reporting, or sta- tistical analysis. Linux is, and more than likely always will be, a hacker's operating system.(4) [...] For the most part, the Linux community communi- cates via various mailing lists and USENET newsgroups. A number of con- ventions have sprung up around the development effort: for example, any- one wishing to have their code included in the ``official'' kernel should mail it to Linus Torvalds, which he will test and include in the kernel [...]
1992
Zde je hlášení o chybě a oprava z prosince 1992 (0.98.6) na comp.os.linux:https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion
Velmi brzy existoval e-mailový seznam ml-linux-bugs (1992/1993), z tohoto raného FAQ v distribuci Slackware 1.01:
VI.01) Zdá se, že $#@! ported on linux neběží správně, co mám dělat s hlášením chyb?
[...]Všimněte si, že můj "[email protected]" seznam hlášení chyb byl postupně zrušen. Ukázalo se, že Linux má tak málo chyb, z nichž většina je vyřešena na diskusní skupině nebo prostřednictvím Linuse, než je stihnu nashromáždit a odeslat. :) Stručně řečeno:pokud se vyskytne chyba v Linuxu nebo v softwaru portovaném na Linux, bude obvykle opravena v příštím patchlevelu nebo verzi.
Byl tam seznam e-mailů "linux-kernel" (který běžel na původním vger ), diskusní skupiny alt.os.linux, pak comp.os.linux (které se v roce 1993 rychle rozdělily do hierarchie).
Tento časný Linux FAQ (v1.11 Nov 1992) od comp.os.linux také doporučuje poslat e-mail přímo Linusovi.
V roce 1992 Matt Welsh (Running Linux , Linuxová Bible , TLDP) oznámil ibug na pomoc při generování e-mailových zpráv o chybách (ironií je, že jste to v té době nemohli spustit na Linuxu, protože postrádal dostatečnou síť, aby bylo možné odeslat e-mail).
E-mailová šablona hlášení chyby linux.temp byl pravidelně zveřejňován také na comp.os.linux a aktualizace hlášení o chybě měly šablonu aktualizace linux.fix.temp .
Existovalo také úložiště oprav (FTP), pokud mohu říci, bylo to většinou (ne výhradně) pro opravy programů pro portování na Linux.
1993–1994
CVS kopie zdrojového kódu jádra byly běžné, nejdříve jsem našel kopie Dirka Steinberga z éry kernal-0.99.14. První oznámení, které mohu najít, je z ledna 1993 o linuxových aktivistech. Stále můžete najít archivované kopie (1994). Dirk také udržoval binárky cvs a zdroj libc v CVS.
CVS se nepoužívalo ke sledování chyb v současném slova smyslu, někteří vývojáři jej raději používali a záplaty byly často odesílány ve formě rozdílů generovaných cvs.
1995–1996
Přibližně v této době (říjen 1995) začal David S. Miller používat CVS pro port SPARC linuxového jádra (Port Linux/SPARC V únoru 1996 několik dalších vývojářů jádra nezávisle používalo CVS ke sledování záplat, z tohoto vlákna linux-kernel a tohoto vlákna:Alan Cox, Stephen Tweedie, Kai Henningsen. (Druhé vlákno uvádí Russe Nelsona, který z první ruky uvádí Linusovu averzi k CVS.)
1997–1998
V dubnu 1998, krátce po narození Linusova druhého dítěte, se znovu objevila otázka CVS, z linux-kernel viz toto podvlákno (Linus tam přímo opakuje své obavy z CVS).
V prosinci 1997 vydal Andrew Tridgell jitterbug, webový nástroj pro sledování chyb. V červnu 1998 "linux-patches" JitterBug obhajoval na linux-kernel Alan Cox. Toto byl, pokud mohu říci, první skutečný systém sledování chyb, který Linus a další klíčoví vývojáři používali, bohužel instance "linux-patches" již není online.
V září 1998 byl bitkeeper poprvé propagován na linuxovém jádře Larrym McEvoyem.
1999 a novější
V roce 1999/2000 začal lkml FAQ odkazovat (Q 1-16) na strom CVS na (původním) vger. To bylo v té době udržováno Andrewem Tridgellem.
V prosinci 2001 Jitterbug upadl v nemilost, viz toto vlákno s linuxovým jádrem, Linus, Alan Cox a mnozí další se zapojili do diskuse proč.
V lednu 2002 se Linus začal zajímat o bitkeeper (který již používá tým jádra PowerPC Linux).
V únoru 2002 začal Linus používat Bitkeeper pro vývojový strom 2.5.
V listopadu 2002 byl oznámen OSDL hostovaný Linux Bugzilla pro strom 2.5. (Pokud jste si ještě nepřečetli odkaz na bugzillu v otázce, přejděte a přečtěte si ho nyní, obsahuje staré Linusovy chvály).
V dubnu 2005 Linus oznámil odchod od BitKeeper, přibližně v době, kdy poprvé zmínil git podle jména. Krátce poté, co se git stal schopným vlastního hostování, Linus přestal používat BitKeeper a začal používat git pro jádro.
V prosinci 2008 byl oznámen Patchwork patch tracker pro linux-kernel, jedná se o SCCS agnostický webový patch tracker, který se integruje do mailing listů pro sledování patchů a následných aktualizací. Jeho používání pokračuje dodnes, na https://patchwork.kernel.org/ je takto sledováno přibližně 40 seznamů, i když ne všechny jsou aktivní.
Odkazy
Užitečné odkazy:
- Podstata distribuované práce:Případ linuxového jádra (Jae Yun Moon, Lee Sproull)http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (listopad 2000)
- Pokyny pro hlášení chyb Linuxu (červenec 1992)http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
- Archiv důležitých linuxových příspěvků/e-mailů Kennetha R. Saboria:http://www.informatica.co.cr/linux/index.htm (1991–2005)
- archivy linux-kernel ode dneška (listopad 2014) zpět do roku 1995http://lkml.iu.edu/hypermail/linux/kernel/(bohužel, první e-mail je z června 1995, kde administrátor Chris Dent oznámil, že ztratil dřívější archivy ...)archiv LKML sahá až do roku 1996
- Fragmenty z linux-devel 1993-1994 z tsx11http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/ linux-devel/(nedbejte na data v URL a v souborech)
- Nástroje pro správu verzí:CVS až BK v jádře Linux , Sjaikh &Cornford (asi 2003)
- Viz také tyto Zprávy o hackerech vlákno (březen 2015), když se blíží 10. výročí git:https://news.ycombinator.com/item?id=9263336
Dokážu říct, jak se řeší hlášení chyb při vývoji git sám.
Nepoužívají žádný software pro sledování chyb. Chyby jsou hlášeny a diskutovány na vývojářském mailinglistu. Je to možná překvapivé, ale funguje to velmi dobře.
Otázka nebo návrh na použití nějakého softwaru pro sledování chyb se objevuje často, takže se o tom můžete hodně dozvědět z prohledávání archivů gitových konferencí.
Není to o tom, že „ještě jsme nenašli dostatečně dobrý nástroj na sledování chyb“;
Ale také to není o tom, že „máme lepší metodu“.
S touto metodou má správce projektu nebo podprojektu - něco jako hlavní vývojář - důležitou roli jako neformální moderátor vývojového seznamu.
Ošetřování chyb je jeho součástí a nezdá se, že by to byl triviální úkol spravovat chyby tímto způsobem; Určitě to závisí na dovednostech osob v této roli.
Nejformálnější částí metody je týdenní souhrnná zpráva o stavu.
Uvádí věci, které se aktuálně dějí na různých pobočkách, jako krátké položky. Příklad z vývoje git najdete v diskusní skupině gmane.comp.version-control.git zrcadlení mailing listu:Co se vaří v git.git
Co mohu říci s jistotou:Pokud máte správce, který je v tom dobrý, funguje to extrémně dobře.
Například bych byl velmi překvapilo, že zavedení bug trackeru mělo pozitivní vliv na produktivitu na implementované funkce a kvalitu, a to i v dlouhodobém horizontu po amortizaci režijních nákladů na změnu.
Pro linuxové jádro je to podobné, jako se to dělá pro git, až do dneška.
Vývojové e-mailové konference pro vývoj linuxového jádra jsou jistě důležité. Ale není to jeden seznam jako centrální místo jako u git. Existují samostatné seznamy pro podtémata, jako jsou souborové systémy nebo sítě.
Protože existují samostatná témata, která zpracovávají většinou samostatní vývojáři, je možné, že některé skupiny používají nástroje lokálně ve své skupině.