Climbexion revision control voor softwarewerkplaatsen Henk Pietersma

Transcriptie

1 Climbexion revision control voor softwarewerkplaatsen Henk Pietersma

2 Inhoudsopgave 1 Inleiding Achtergrond De organisatie Inleiding Projects en Products De teams Het werk Enige slotopmerkingen De televisie als bedrijf Televisie, de software Architectuur en component modellen Robuuste overgangen Folder structuur en builds Afbakening NXP Diversity Koala / Horcom Power modes en hardware die geen deel uitmaakt van het audio/video platform Pumps en pump engines MIPS recovery Test binaries Tools Version control Instrumentation Slot opmerkingen Televisie, de hardware De testplek De basis Begrippen Basisstructuur De organisatie van het geheel aan drawers De organisatie van pools De organisatie van snapshots Other-focused files Envelopes Baseline supplements, external envelopes Resources Metadata Inleiding Attributes, soorten en maten Templates, wizards, pretty printing, macro's, en zo File-type Entity type Restricties op kins Classifications ten behoeve van export limitations Original en neighbor Base en labored Kin references Attributes van drawer, package, pool, machine Tenslotte...99

3 2.4 Werkwijzen Merging Synchronisatie Synchronisaties tussen satellite en working-tree Het werken met team-drawer, transfer-drawer en satellite Een geabonneerd package inlijven Het overnemen (adopt) van envelopes uit een sister-project Undo envelope synchroniseren van eigen packages met die van een sister-project (adopt merge) Gemeenschappelijk beheerde packages Baseline samenstellen Project dependencies Informatie, werkelijkheid, gedistribueerd systeem Planning & Tracking en Repositories Introductie Relaties met envelopes Composite Activities Builds en Repositories De invloed van builds op Climbexion First class citizens of tarballs Build Forest Build bij NXP Versnipperingen Other-focused build results Conclusies Build extra's. DianPush Build Security Security entiteiten Security doelen en middelen Gentlemen agreements Overige aspecten Status en Progressie Het top package Locks Notifications Pool operaties Importeren, Exporteren Virtualisatie Begrenzen? Gebruikersvriendelijke? id's Losse eindjes Slotopmerkingen Methodische probleem beschrijving Inleiding ORM Problem frames Pagina: 3 / 230

4 3.1.3 JSP HCI Context diagram Repository Database Envelopes Het administrator subprobleem (zeer voorlopig) Interface Administrator machine / SCM machine Interface Administrator / Machine Licentie Pagina: 4 / 230

5 1 Inleiding 1 Inleiding 1 Inleiding 1.1 Achtergrond Sinds 1 oktober 2008 ben ik met pensioen gegaan. Voordien werkte ik bij het softwarehuis TASS Software professionals in Eindhoven, en was gedetacheerd bij NXP en droeg bij aan software voor digitale televisies. Dus maar wat hobbyen. In mijn jonge jaren heb ik me weleens bezig gehouden met programma beheer op IBM mainframes. Dit was gebaseerd op partitioned datasets en overdrachten van de afdeling programma-ontwikkeling naar de afdeling productie. Bij het openen van een programma in de ontwikkel-omgeving werd het programma eerst gezocht in de development dataset, en dan in de production dataset. In de productie-omgeving werd uitsluitend in de production dataset gezocht. Sindsdien heeft dergelijk beheer altijd mijn belangstelling gehad. Vandaar deze poging om een revision control system te definiëren. Trouwens, ik vindt het leuk om dingen opnieuw uit te vinden. Er zijn behoorlijk wat systemen om software op te bergen. Ik verwacht dan ook dat, als ik mijn gedachtespinsels op een website zet, dat de dingen dan niet ogenblikkelijk uit mijn handen gerukt zullen worden omdat iedereen erom zit te springen. Anderzijds hoop ik toch ook dat anderen mijn studie belangwekkend vinden. Voor mijn analyses heb ik mijn kennis van de NXP afdeling gebruikt waar ik het laatst gewerkt heb. Hierop kun je echter niet blindvaren. Ik heb geen documenten of software mee naar huis genomen, geen interviews gehouden, of mensen gebeld als ik iets niet wist, kortom als ik iets niet wist heb ik mijn duim gebruikt. Als ik dacht dat precisie schadelijk kon zijn voor NXP of een klant, dan ben ik vaag gebleven, of heb maar wat verzonnen. Als het al geleerd is wat ik beschrijf dan is het in ieder geval kamergeleerdheid. Wees gewaarschuwd. Voor de domein beschrijving en het eisen pakket probeer ik Niam (tegenwoordig ORM) en Problem frames te gebruiken. Dergelijke specificaties heb ik tot nu toe nooit hoeven te maken, dus ik ben benieuwd of het lukt. Het systeem dat ik beschrijf heeft als belangrijkste kenmerk dat het niet triviaal is. Hopelijk is het niet een zuivere kopie van een bestaand systeem. Te hanteren methoden zijn beschreven in: 1. "Information Modeling and Relational Databases. second edition" van Terry Halpin en Tony Morgan (Morgan Kaufmann Publishers ISBN: ) 2. "Problem Frames, Analyzing and structuring software development problems" van Michael Jackson. (Addison-Wesley ISBN X) De taal waarin ik schrijf is Nederlands hoop ik. Als het mij lukt om mijn ideeën in redelijk Nederlands en begrijpelijk op papier te krijgen, kan ik ze altijd nog vertalen in slecht Engels. Voor de termen die te maken hebben met het revision control system, trouwens voor veel vaktermen, gebruik ik Engels, die zijn dus reeds vertaald. Pagina: 5 / 230

6 1 Inleiding 1.2 De organisatie 1.2 De organisatie Inleiding In de jaren heb ik onder meer deelgenomen aan diverse projecten voor Philips Semiconductors. Een van de dingen die toen opviel is de toewijzing van ontwikkelingen aan de diverse laboratoria. Ieder laboratorium kreeg een aandeel in een nieuw te ontwikkelen chips-set. Daar zullen best allerlei rationele argumenten voor geweest zijn, maar toch, ik denk dat de belangrijkste reden was dat ze verslaafd waren aan internationale samenwerking. En sindsdien heb ik eigenlijk nooit anders ervaren. Voor wat betreft de TV ontwikkeling bij de eeuw overgang: Phiiips SC (Semiconductors, later NXP) en Philips CE (Consumer Electronics) waarmee werd samengewerkt waren strikt georganiseerd in markt segmenten. Er waren teams die de low-end markt bedienden, teams voor de mid-range, en teams voor de high-end markt. Ik werkte in het high-end segment. Traditioneel wordt daar het maken van een televisie gezien als een edel handwerk, met nauwelijks concessies: goed is niet goed genoeg. Features ontstonden in het high-end segment, en vonden vandaar uit hun weg naar mid-range en low-end. Dit werd down-draining genoemd, en besloeg een aantal jaar. Ieder team had zijn eigen software stack en hardware range waarin de nieuwe functionaliteit werd aangebracht. In de periode dat ik er werkte vond feitelijk een integratie plaats van mid-range en high-end. Down-draining hield op te bestaan. Mid-range werd uitgekleed high-end, in ieder geval in mijn vakgebied: de software. De afdeling bij NXP in Eindhoven waarvoor ik werkte van 2002 tot in 2008 ontwikkelde software voor hybride analoge/digitale televisies. Technisch zijn het digitale televisies want analoge signalen worden zo snel mogelijk omgezet naar digitale stromen. Alle bewerkingen van decoderen tot het schrijven op een LCD of plasma scherm vinden plaats door de stroom te converteren van het ene digitale formaat in het andere (decoding), of door de digitale informatie te wijzigen (bewerking). Hybride zijn ze omdat ze zowel analoge video en audio input kunnen weergeven op beeldscherm en speaker, als ook digitale. Ook kunnen ze analoge output maken, door een digitale stroom om te zetten in een analoge, net voor hij de tv verlaat. Toen ik in 2002 door NXP werd ingehuurd, werd een belangrijk deel van de software ontwikkeld in Eindhoven, en een ander deel in Sunnyvale. In 2008 vindt het grootste deel van de ontwikkeling plaats in Bangalore en een klein deel in Eindhoven, en nog enige drivers in Hamburg. De software die NXP levert is bestemd voor hun one-chip TV. Deze ene chip bevat een aantal AD en DA converters, Micro-controllers zijn in gebruik als digitale signaal processors (DSP's) en er zijn enige computers. De computers zijn: een Intel 8051 : standby processor, een MIPS: besturingscomputer enige (één of meer) TriMedia's: signaal bewerkingen. De software van NXP op deze computers moet samenwerken met de software van TV fabrikanten, de set-makers. Ook gespecialiseerde softwarehuizen leveren software voor gepatenteerde of gestandaardiseerde functies. Het geheel komt uiteindelijk in uw TV thuis, tenminste als uw TV een NXP chip bevat. Volgens één of andere rare conventie wordt het programmeren van micro controllers gerekend tot hardware en het programmeren van de drie typen computers tot Pagina: 6 / 230

7 1 Inleiding 1.2 De organisatie software. Dit stuk gaat dan ook over het programmeren van die drie computers, en dan vooral programmeren op de computer waarbij ik betrokken was: de MIPS. NXP koopt het benodigde operating system voor de MIPS (Linux), en de real-time kernel voor de TriMedia's. Ook (cross) compilers, debuggers, en development systems worden gekocht. Zelf maakt ze de software voor de standby processor, het merendeel van de software op de TriMedia's, en het grootste deel van de drivers en hun aansturing op de MIPS. Als een nieuwe chip wordt ontwikkeld wordt ook het NXP aandeel van de software ontwikkeld. De software is deels gebaseerd op de software van de chip die daarvóór ontwikkeld werd. Dit gebeurt hoofdzakelijk in Bangalore. Nieuwe ontwikkelingen op het gebied van signaal bewerking vinden plaats in Eindhoven. Sommige drivers worden ontwikkeld in Hamburg. De TV waarop deze software wordt getest heet reference design Zo'n televisie komt vrij snel na de start van de software ontwikkeling beschikbaar voor testen, dus de chip is al eerder ontwikkeld. De ontwikkeling van chip en software vindt plaats in samenwerking met een belangrijke klant, meestal Consumer Electronics van Philips. Omdat de televisie standaards in de Verenigde Staten van Noord Amerika nogal afwijken van die in Europa worden er vaak 2 reference design televisies gemaakt. Schematische voorstelling van de werkwijze In de eerdere projecten werd veel aandacht besteed aan design documenten en de design fase, in de latere projects werd hieraan minder aandacht besteed: er is immers reeds een framework, de nieuwe software en de wijzigingen hoeven er alleen maar in te passen Projects en Products NXP zoekt een tv fabrikant om samen een nieuwe generatie televisies te ontwikkelen. NXP ontwikkelt de chip, en de set-maker (de klant) ontwikkelt de televisie. Waar NXP begint met een reference design, daar begint de klant met een standaard design. Hierin Pagina: 7 / 230

8 1 Inleiding 1.2 De organisatie ontwikkelt de klant zijn noviteiten. De software die door de klant ontwikkeld wordt is (deels) gebaseerd is op de software van zijn vorige televisies. Datzelfde geldt voor het reference design: het is voor een deel gebaseerd op voorgaande software en hardware. Om deze designs te maken vindt er uitwisseling van kennis, hardware en software plaats, in het design project. NXP houdt er een reference board met software aan over, dat uitgangspunt is voor de verkoop aan andere klanten. De klant houdt er een standaard board en software aan over, die het uitgangspunt is voor zijn uit te brengen televisies. Zodra een verkoopbare televisie is gespecificeerd en een prototype beschikbaar komt, start een design-in project. In dit project wordt de software van NXP en klant passend gemaakt voor een TV van de klant. De NXP software is gebaseerd op het reference design, maar bevat wijzigingen die noodzakelijk zijn voor de TV of de stijl van de klant. Als het reference design klaar is, en de klant, waarmee is ontwikkeld, een afgesproken voorsprong heeft op zijn concurrenten, dan worden ook andere TV fabrikanten bediend met design-in projects. Dit vindt plaats in zowel Bangalore als Eindhoven, maar gaat naar Bangalore. In feite was ik in Eindhoven bijna de laatste die het licht uitdeed. Sommige TV fabrikanten ontwikkelen helemaal geen software. Tot voor kort bediende NXP ze met een complete software stack. Tegenwoordig worden de applicatie en middleware delen uitbesteed aan gespecialiseerde softwarehuizen. Een aantal projects zijn tegelijk aan de gang. Tussen deze projects vindt uitwisseling plaats van verbeteringen en nieuwe ontwikkelingen in de software. Meestal gebruikt de klant de chip in meerdere TV sets. Er komt dan een design-in project voor elk groepje TV sets dat erg op elkaar lijkt. Een groepje dat te sterk afwijkt is reden voor een ander design-in project. De software is dan gebaseerd op die van van een vorige design-in, of op een standaard design. Deze projects vonden aan de NXP kant plaats in Eindhoven maar gaan ook naar Bangalore. Deze keuze voor design-in projects en de keuze van NXP om zijn reference designs te baseren op voorgangers laat ons terecht vermoeden dat we te maken hebben met product familie structuren, compleet met huwelijken en kinderen en zo. Op een willekeurig tijdstip zijn van zo'n televisie familie enkele modellen in ontwikkeling, enkele modellen worden gefabriceerd, en enkele modellen staan in de schappen in de winkels. Voor de chip familie geldt iets soortgelijks: in een tijdsvenster zijn er slechts een paar typen in ontwikkeling, en worden slechts enkele typen gefabriceerd. Vaak zijn er enige varianten die ongeveer samen ontwikkeld worden, bijvoorbeeld een power-chip en een compatible eco-chip. Sommige klanten hanteren een fictief project: het backbone project. Dit is een voortzetting van het design project. Wijzigingen in een project worden, als ze algemeen bruikbaar zijn, ook gebruikt om de backbone software te verbeteren. Nieuwe design-in projects worden gebaseerd op de laatste versie van het backbone project. NXP gebruikt design-in projects om zijn reference design te verbeteren. Voor NXP is het reference model de backbone. Een tv project wordt geregeerd door deadlines, zoals een expositie op een beurs, een sport Pagina: 8 / 230

9 1 Inleiding 1.2 De organisatie evenement, een seizoen, en de aanvraag van een certificaat. Met een certificaat geeft een onafhankelijke commissie aan dat ze heeft vastgesteld dat de televisie aan een standaard voldoet. Vaak moet een aanvraag ruim van tevoren worden ingediend, en uitstel is afstel, dan moet opnieuw ruim van te voren een aanvraag worden ingediend. Elk certificaat is een stikker met logo op de televisie en/of de doos waar hij in zit. Na de aanvraag is er dus een deadline. De software fasen development en verification/integration zijn geen echte fasen maar lopen in elkaar over: op een gegeven moment werkt men niet meer aan ontwikkeling maar nog uitsluitend aan problemen, of aan tussentijdse wijzigingen. Dit komt omdat een nieuw project gebaseerd is op software van een voorgaand project. Daardoor beschikt men al zeer vroeg over een werkbaar geheel, en kan vanaf het begin reeds gewerkt worden aan de verification/integration fase, en wat betreft de verification beginnen de testers dan ook onmiddellijk met het genereren van problem reports. Voor design-in projects geldt dit meer dan voor (reference) design projects, waarin veel innovaties zitten, en waarin voor NXP naast een nieuwe TV chip ook overgangen kunnen zitten naar andere microcomputers, andere operating systems, andere compilers, andere debuggers enzovoort. De mijlpaal wordt dus niet bereikt als groen licht wordt gegeven voor de start van de integratie/verificatie fase, maar als de development fase uitgedoofd is. Deze mijlpaal wordt niet langer beschouwd als een go/no-go beslispunt. Zelfs is het zo dat vaak pas met een ontwikkeling van een nieuw feature begonnen wordt als de integratie op orde is, en dan zodra een specialist beschikbaar komt. In televisie projects zie je dat veel mijlpalen worden gedefinieerd door het overall project, dat gaat van idee tot de televisie bij de mensen thuis. De go / no-go mijlpalen en audits worden bepaald door interactie tussen markt analyse, research, hardware ontwikkeling, software ontwikkeling, ontwikkeling en het opzetten van (proef) fabricage lijnen, distributie, certificering, aankondiging en demonstratie, en dergelijke. De risico's voor een volgend traject in één of enkele van de disciplines zijn in principe voor een belangrijk deel afhankelijk van de opgeleverde kwaliteit van voorgaande trajecten in alle disciplines. De risico's worden definitief bepaald aan de vooravond van zo'n traject. De resultaten van audits en externe analyses moeten aangeven dat een traject gestart mag worden, en mogelijk ook op welke punten opleveringen in voorgaande trajecten moeten worden verbeterd. Uiteraard werkt men in projects het liefst met strikt opeenvolgende fasen, zodat dezelfde vooravond ook een stop going / don't stop going beslissing oplevert voor de organisatie die de voorgaande fase realiseerde, en voor het wel of niet vrijgeven van de mensen en middelen die daarbij gebruikt werden. De projects om een televisie te maken horen te worden gekenmerkt door een grote mate van beheersing van het hele proces. Op elk moment moet duidelijk zijn wat er bereikt is en wat er nog moet gebeuren. Onduidelijkheden in het ontwerp mogen eigenlijk niet voorkomen, daar zijn de research projects voor. Tegenvallers kunnen gemakkelijk uitgroeien tot een ramp. Vooraf moet er al een gedetailleerd inzicht zijn, wat het product behelst dat men maakt, welke resources er nodig zijn om het project te realiseren, en welke resources voorhanden zijn. Gedurende het project wordt dagelijks de voortgang gecontroleerd van alle werkopdrachten: hoe staat het met de analyse, de programmering, de verificatie? Er wordt bijgehouden welke tests gepasseerd zijn, welke nog niet kunnen worden gedaan, en welke een fout resultaat opleveren. In een project worden geregeld audits gehouden met lange checklists, om te bepalen of een mijlpaal is bereikt. Hiermee alleen lukt het niet om tijdig een goede kwaliteit televisie af te leveren. De ene keer is er sprake van een Jantje van Leiden in de eerdere stadia van het project, de andere keer moet de Pagina: 9 / 230

10 1 Inleiding 1.2 De organisatie televisie in de schappen staan voor een wereldkampioenschap, en zo is er altijd wel wat. Een project wordt dan ook vaak gerealiseerd door de tomeloze inzet en het overwerk van de medewerkers De teams De teams die deze projects bemannen zijn gestructureerd volgens specialismen. Binnen NXP kennen we zoal: Operating System en standby processor. Frontend Decoding Video bewerking. Audio Performance Al naar gelang de behoefte, of de smaak van de teamleider zijn er veel subteams met weinig specialismen per subteam, of een weinig gestructureerd team met veel specialismen binnen het team. Ook zijn er design-in teams die werken voor een enkele klant (account gericht), en teams die (successievelijk) werken voor meerdere klanten. Van oudsher was er in televisies de hardware die het werk deed, en de software die de user interface bediende en de hardware aanstuurde. Met de digitale TV ontstaat er ook software die het werk doet: Video en audio bewerking. De specialisten die deze software maken zitten in een ander team dan de andere specialisten die zich bezighouden met besturing en drivers. Ze worden meer ingezet in ontwikkeling en reference design projects en minder in design-in. schematic matrix organization Iemand die nieuw in het televisie vak begint krijgt verantwoordelijkheid voor een deel van de software, bijvoorbeeld de tuner software. Hij of zij wordt dan al snel specialist. Werknemers van NXP volgen een ontwikkelingsplan, waarbij ze ook op andere delen en in andere teams worden ingezet zodat ze na een tijdje generalist worden. Inhuurkrachten volgen geen plan maar worden al naar gelang de behoefte na een tijdje ingezet op andere delen van de software. Sommigen worden zo generalist, anderen beheersen na een tijdje één of meerdere specialismen. Beide, medewerker en inhuurkracht, wordt een TV cursus aangeboden om meer algemeen inzetbaar te zijn. Teams met specialisten zijn van nature wat groter dan teams met generalisten, omdat er voldoende Pagina: 10 / 230

11 1 Inleiding 1.2 De organisatie dekking in TV kennis moet zijn in een project. De wat grotere teams worden ingezet op design projects of op veel design-in projects tegelijk. Kleinere teams worden ingezet op enkele projects tegelijk, bijvoorbeeld op OEM design-in projects, waarin ze in een rap tempo het éne na het andere project realiseren. Indien het design of design-in project veel moet vernieuwen, dan structureert men het team meestal volgens specialisme. Sommige generalisten worden factotum, en zijn niet vast aan een team verbonden, maar worden ingezet daar waar de druk het hoogst is. Sommige specialisten worden goeroe en worden daar ingezet waar hun kennis het meest nodig is. Vaak is een team in een project geografisch gescheiden van de anderen. Soms worden teams bij elkaar gebracht in één gebouw, we spreken dan van een one-roof project. De teams van de klant en die van NXP blijven vaak gescheiden, maar er vinden wel detacheringen plaats, ter bevordering van de communicatie. Soms maar niet vaak is er een one-roof team van een klant en NXP. De spreiding van teams van NXP en klant over de wereld leiden verder tot veel telefonisch vergaderen, zowel reguliere meetings, als ad hoc vergaderingen vinden telefonisch plaats Het werk Gedurende de development activiteiten van de software werken de ontwikkelaars, testers en integrators planmatig. Software wordt (her)ontwikkeld en geverifieerd met reviews en tests volgens plan door testers en ontwikkelaars. De nadruk bij het testen ligt bij component en package tests. Reviews worden gehouden voor documenten, c files, test scripts en zo. Tijdens de verificatie en integratie fase worden de ontwikkelaars gestuurd door problem reports, testers volgen deels een integratie test plan, waarbij de nadruk komt te liggen bij product tests en tests van lagen. Verder verifiëren ze opgeloste problems, met name in baseline tests. Integrators brengen een nieuwe baseline uit per vastgestelde periode en incorporeren baseline van andere teams liefst éénmaal in dezelfde periode. In de laatste fase van het integratie traject, de maturing phase, worden de software wijzigingen van NXP per opgelost problem doorgegeven aan andere teams. Regelmatig worden nieuwe baselines van de eigen software verstuurd naar andere design groepen: werk van de build manager, uiteraard na een forse baseline test: werk van een tester, en voorzien van een baseline report: werk voor de integrator. Regelmatig worden nieuwe baselines van de software van andere teams in het project in ontvangst genomen. Ook dit is werk van de build manager. Zo'n nieuwe baseline moet ook in gebruik worden genomen: werk voor de integrator. Meestal worden baselines eens per twee weken uitgegeven, soms wekelijks of maandelijks, afhankelijk van de project-fase en de afspraken. Meestal duurt het enkele dagen voordat een nieuwe baseline door een team in gebruik wordt genomen, soms duurt het langer, en soms wordt een baseline overgeslagen. Binnen NXP sprak men over releases waar ik spreek over baselines. In software configuration management wordt een snapshot dat een naam heeft gekregen, en waarvoor kwaliteitseisen zijn gerealiseerd, over het algemeen baseline genoemd. Releases zijn,vind ik, gerelateerd aan eindproducten, die voor gebruik beschikbaar zijn gesteld aan eindgebruikers, en soms voor testen door eindgebruikers zoals alfa en bèta releases. Pagina: 11 / 230

12 1 Inleiding 1.2 De organisatie Baseline schema In het plaatje van het baseline schema is te zien dat er nog patches moeten worden ontwikkeld nadat een baseline is uitgebracht. Dat is eigenlijk een zwakte bod, het had voorkomen moeten worden. Zo'n baseline schema eist wel een zekere robuustheid van de software. Baseline D van package Cup Pagina: 12 / 230

13 1 Inleiding 1.2 De organisatie moet compatibel zijn met baseline T-1 en T van package Saucer, en met de ontwikkeling van package Saucer tot baseline T+1 en verder. Baseline T van package Saucer moet compatibel zijn met baseline D-1 en D van package Cup en met de ontwikkeling van package Cup tot baseline D+1 en verder. Eventueel kunnen in de nadagen van een baseline baseline supplements (patches) gebruikt worden om compatibel te blijven. Het getoonde baseline schema is echt een schematische voorstelling van zaken, in de praktijk komt het voor dat een team wel eens een baseline overslaat van een geabonneerd package. Bij parallel lopende projects worden vaak wijzigingen uitgewisseld. Soms gebeurt dit periodiek. Hierbij is de integrator betrokken, vaak samen met ontwikkelaars. In ieder geval is er uitwisseling tussen backbone en design-in projects, dit geldt voor de backbone van de klant, en die van NXP. Naast het werken aan de voortgang is er nog het terugkerende routinewerk: dagelijks ('s nachts vooral) wordt vrijgegeven software van de ontwikkelaars ingelijfd in de team software. Voordat dat gebeurt vindt eerst een build en een regressie test plaats. Dit is natuurlijk alleen routinewerk als de build en de test goed verlopen, anders moet er ook uitgezocht worden welke software fout is, dat gebeurt vooral de volgende morgen. Betrokken hierbij zijn de build manager en een tester, eventueel bijgestaan door een software engineer. Software moet vaak geanalyseerd en getest worden. Hiervoor is veel hardware nodig in de vorm van televisies, audio/video generators, dvd players, antenne pluggen met daarachter een netwerk aan tv zenders, meet apparatuur, en dergelijke. Het onderhoud van dit alles is het werk van de hardware specialisten. Voor planning en tracking van alle voorgaande activiteiten zorgt de change manager. Zij/hij werkt nauw samen met de change managers van de andere teams, en met die van het overall project Enige slotopmerkingen Een design project heeft een relatief lange software development fase en een design-in project een relatief korte, tenminste wat betreft de NXP bijdrage. Marktontwikkelingen die niet voorzien zijn, tijdens het ontwerp van de chip, worden meestal opgelost door de klant die de elektronica uitbreidt met extra chips. Aan de voorkant van het signaal pad is dit in 2002 een HDMI chip geweest en in 2007 een MPEG4 chip. Aan de achterkant waar het beeldscherm aangestuurd wordt zijn dit in 2003 chips geweest voor scaling en natural motion bij grote plasma schermen, of grote LCD schermen. Recent (2008) heeft NXP een nieuwe ontwikkeling op het gebied van video nabewerking gestart op een afzonderlijke chip met een drietal TriMedia processors. Deze chip kan met de TV chip samenwerken, maar de TV chip kan ook standalone werken. De nieuw ontwikkelde chip kan ook zonder TV chip geleverd worden als backend van concurrerende oplossingen. In de tijd dat ik bij NXP werkte bleek dat een chip zeer snel veroudert Na een jaar design-in is er niemand meer die de chip nog wil. HDTV ready is opgevolgd door Full HDTV, één HDMI ingang moeten er vier zijn, internet aansluiting en DLNA zijn een vereiste, de beeldbewerking lijkt primitief vergeleken met de nieuwe algoritmen, de punt die over een LCD scherm raast moet niet Pagina: 13 / 230

14 1 Inleiding 1.2 De organisatie alleen het kristal openen dat hij passeert, maar ook het backlight regelen (dit is een vereenvoudigde voorstelling van zaken), enzovoort. Men zoekt naar een kortere doorlooptijd van design projects. Want nu zorgt de tijd die nodig is voor software ontwikkeling ervoor dat de omzet van de chip beperkt is. Ook zoekt men naar verkorting en capaciteit vermindering van design-in projects, zodat meer klanten in korte tijd geholpen kunnen worden. Toch gaan de herstructureringen van de software die hiertoe moeten leiden traag, omdat de focus ligt op het verkopen van wat men heeft. De investering in de software aan het begin van de eeuw, die de basis vormt van de huidige (2008) software stack is misschien nog niet genoeg terugverdiend. De eerste digitale televisies waren een succes waarmee Philips een voorsprong nam op de concurrentie: de televisies van de concurrentie bleven in de schappen. Bij de overgang van HDTV ready naar Full HDTV liet Philips zich verrassen door de concurrentie. We hadden geen onmiddellijk antwoord en onze televisies bleven onverkocht. Veel DSP's zijn specialistische digitale signaal processors die werken met een ingebakken programma. Ze delen geen geheugen met de andere processors, en voor een nieuw programma is een speciale loader nodig. Ze gebruiken specialistische i/o devices, bijvoorbeeld speciale AD of DA converters. Na het inbakken is er feitelijk sprake van hardware. In de tv's waarbij ik betrokken was werden ze bijvoorbeeld gebruikt bij het digitaliseren en decoderen van de oude analoge audio en video signalen naar het interne formaat. Ze zijn wel onderdeel van de éne televisie chip. TriMedia's zijn general purpose signaal processors met geheugen waarin steeds opnieuw software geladen kan worden vanuit de MIPS. Deze flexibiliteit maakt het volgende mogelijk: Het bewerken van tv signalen behoort tot het competentie gebied van zowel set-makers als chipmakers. Allebei willen ze software ontwikkelen voor signaal bewerking. Dit is software in de TriMedia laag, achter de API (application interface). De samenhang die voor deze software nodig is wordt bereikt met een gemeenschappelijk project van NXP en een belangrijke tv fabrikant: het design project. Er is een tendens om de development fase te verwaarlozen en alle wijzigingen te realiseren middels problem reports. Persoonlijk ben ik daartegen. In mijn beschrijvingen ga ik dan ook uit van development activiteiten. Halstead gaf een definities voor complexiteit, zoals lenght, volume, difficulty effort en dergelijke. Mijns inziens kun je de complexiteit in een development inspanning terugdringen, en kan die alleen maar toenemen in de verificatie manier van werken. Zelf ben ik er voorstander van dat systematisch in nieuwe projects een onderdeel van de software opnieuw wordt gestructureerd. Natuurlijk moet dat wel met design en development activiteiten gebeuren. Je zou dit kunnen verwoorden door te stellen dat geen line of code ouder mag zijn dan 6 tot 10 jaar. Overigens, voor nieuwe features is development nodig, je kunt doorgaans niet uitgaan van een hello world programma om vandaar uit met problem reports het feature te realiseren. Waardoor wordt deze tendens om meteen vol de integratie/verificatie fase in te gaan gevoed? Met problem reports kunnen programmeurs in paren of alleen, onafhankelijk van de anderen werken, bij grotere wijzigingen moet er meer worden samengewerkt. Bij grote wijzigingen bijvoorbeeld, kan de software verdeeld worden over de programmeurs, die dus ieder hun eigen onderdeel bijhouden. Wijzigingen moeten gesplitst worden, zodat meerdere specialisten een deel krijgen, die wijzigingen zijn niet zonder meer onafhankelijk te integreren. Daarentegen bij kleine wijzigingen kunnen de wijzigingen uitgedeeld worden Pagina: 14 / 230

15 1 Inleiding 1.2 De organisatie aan de programmeurs, die ieder voor zich dan alle benodigde software wijzigen, en onafhankelijk integreren. Test-items in de integratie fase testen of software voldoet aan de requirements voor het eindresultaat. Test-items in de development fase testen of een development stadium bereikt is. Deze test-items kunnen zeer omvangrijk worden, en zijn afhankelijk van voortschrijdende wijzigingen in het eisen pakket. Testers vinden dat ze wegwerp tests maken, die verder nooit meer bruikbaar zijn. Als je een ontwikkelingsgang wilt volgen zodanig dat de software in elk stadium getest kan worden met tests die een uittreksel zijn van tests uit de verificatie fase, dan vergt dat nogal wat van die ontwikkelingsgang: de software uit het begin moet compatibel zijn met de uiteindelijke software. Met een test-plan in de integratie fase is een overzichtelijke voortgang zichtbaar van items die nog niet kunnen worden getest, items die fout zijn, en items die correct zijn. Fout en correct is ten opzichte van de requirements voor het eindproduct. Testers maken in de integratie fase gebruik van herbruikbare tests, want alle televisies lijken op elkaar. Een voorbeeld uit begin jaren negentig van een ontwikkelingsgang die waarschijnlijk niet volledig de compatibele reeks stadia oplevert die testers waarderen: In een MS-DOS applicatie gebruik je eerst een interface die gebaseerd is op een tweedimensionale tekst omgeving (de voorlopige, geïmproviseerde oplossing), en later als de functionaliteit bereikt is ga je over op een grafische interface. Ooit heb ik geleerd wat een Pert network is, en hoe een Gantt chart eruitziet. Bij de ene staan de activiteiten in de knooppunten en bij de andere in horizontale balken langs een tijdlijn. Bij beiden zijn de afhankelijkheden van de activiteiten weergegeven met pijlen. Ik meen mij te herinneren dat er ooit ook nog een soort geïnverteerde Pert chart was, met de activiteiten in de pijlen en de afhankelijkheden in de knooppunten, maar in Wikipedia vond ik slechts de opmerking dat dit een AOA (activity on arrow) schema was. In de vele kleine projects waaraan ik heb deelgenomen (één tot vier mensen voor de software) heb ik serieus geprobeerd volgens zo'n plan te werken, en altijd bleek weer dat de vooraf bedachte afhankelijkheid eigenlijk helemaal niet gold. Het was misschien handig als module A klaar was voor B, maar als dat niet zo uitpakte, dan improviseerde je wat, en kon je B gebruiken of testen zonder A. Hierin lijkt software werkelijk soft te zijn, harde volgorde doet er eigenlijk niet zoveel toe. Ik dacht dat het aan mij lag, dat de afhankelijkheden en werk indeling constant veranderden, als het ging om ontwikkelafhankelijkheden van onderdelen. Ik dacht dat ik mij teveel liet leiden door de inspiratie en de waan van de dag, in plaats van te werken volgens het plan. Ik dacht dat anderen er geen last van hadden. Het testen van televisie software, en zelfs het ontwikkelen ervan is voor een groot deel (in ieder geval het aandeel van NXP op de MIPS) afhankelijk van de hardware (of van de software in de TriMedia). Ieder die betrokken is bij embedded software ontwikkeling weet dat en voelt dat: je kunt een driver misschien wel testen zonder hardware, maar dat is niet echt, en heeft niet veel waarde. Je moet de software testen op de hardware, punt! In de software-werkplaats werken vakmensen die specificaties leuk vinden, maar liefst zo snel mogelijk willen werken aan de hand van waarnemingen. Trouwens een GUI applicatie maak en test je ook niet zonder grafische kaart en window manager, dus zuiver op specificaties. Toen we de software voor de digitale televisies ontwikkelden, hebben we het serieus geprobeerd. We Pagina: 15 / 230

16 1 Inleiding 1.2 De organisatie creëerden voor een driver een test skeleton waarin we de driver testen op de aangestuurde hardware. Iedere driver kreeg zijn eigen skeleton. De hardware, wat die doet is afhankelijk van de manier waarop hij wordt aangestuurd door de driver, en van het signaal dat hij verwerkt. Als je software test, kijk of luister je onder anderen naar wat de hardware component met het signaal doet, gegeven de manier waarop je hem aanstuurt. Het signaal komt van een input bijvoorbeeld een antenne en eindigt in een output, bijvoorbeeld een scherm, en passeert een aantal hardware en TriMedia componenten. De manier waarop de belendende componenten moesten worden ingesteld, dat bleek niet erg stabiel te zijn. Voordat je een bestaand skeleton kon gebruiken moest je het eerst aanpassen aan de laatste toestand van de software. Naarmate de tijd vorderde kon je meer verfijnd testen van meer input pluggen, naar meer outputs, en met meer nuances in de signalen, en moest je je test-doelen bijstellen. Skeletons bevatten gedurende langere tijd geïmproviseerde software van belendende componenten. Later zijn deze skeletons afgeschaft. Nu wordt uitsluitend getest met het product of met een platform harness. Dit harness wordt ook gebruikt als een specifieke driver moet worden getest. Maar dat van die verfijning en uitbreiding, naarmate de tijd voortschrijdt, dat is gebleven, en beïnvloedt de testscripts. Ik merkte dat ik niet alleen was. Het is dus niet: Ik dacht dat anderen er geen last van hadden maar: Wij denken dat de anderen er geen last van hebben. Waarom zijn design-in projects nodig? Kan dit niet opgelost worden met configuratie bestanden en hardware herkenning? Nu in de eerste plaats is een televisie van zo'n design-in project een unieke gelegenheid om de combinatie van software met de bijbehorende configuratie file en de bijbehorende hardware te testen. Deze gelegenheid was er niet eerder, want de televisie was nog niet ontworpen of gemaakt. Het testen van de software van een TV heeft al een doorlooptijd van een aantal weken. De fouten die er uit komen moeten dan nog opgelost worden, waarna de tests opnieuw moeten worden uitgevoerd. Het is bekend dat de introductie van software in en nieuwe gebruikersgroep begint met de ontdekking van een aantal problemen en fouten. Dit geldt blijkbaar ook voor de introductie van software in een nieuwe televisie. Ik meen dat dit wel eens verwoord is als volgt: hoe meer gebruikers er zijn hoe meer fouten er worden gevonden. Waarschijnlijk geldt dit meer algemeen voor omgevingen waarin software moet functioneren, en hoeven meer omgevingen niet per se meer gebruikers te zijn. In de tweede plaats is het ontwerpen van een televisie of een televisie lijn een creatief proces waarmee men vriend en vijand probeert te verrassen. Als er alleen een configuratie bestand moet worden gemaakt, omdat de diversity adequaat is dan is in feite het verrassen mislukt: de configuratie was min of meer voorzien. Dat is niet de bedoeling. Tenslotte is het zo, dat de 'universele one chip TV die door NXP gemaakt is niet altijd rekening houdt met de specifieke eisen van een door een klant te maken TV set, ook al was bekend dat de specifieke eisen er waren. Integratie van de chip in zo'n set is dan niet triviaal, maar mogelijk wel de beste manier om de set te maken. Dus een design-in project is nodig. Het projectmatig samenwerken betekent dat het ideaal van component software, zoals aangegeven door Clemens Szyperski in het boek Component Software niet bereikt is: er is geen volledig Independent Deployment. In de tijd dat ik bij NXP werkte was het geen usance om eindgebruikers een upgrade van de Pagina: 16 / 230

17 1 Inleiding 1.2 De organisatie software te sturen. Als de televisie op de markt kwam dan moest de software klaar en goed zijn. Een upgrade was in feite een nederlaag. Naarmate independent deployment zijn intrede doet zal een eindgebruiker merken dat upgrades normaal worden: het op de markt komen van een tv betekent niet langer dat deze uit ontwikkeld is, althans op software niveau kunnen componenten worden opgevolgd door andere. Voor set makers betekent dit dat nieuwe software ontwikkelingen niet langer alles bepalend zijn voor de time to market van een televisie: men kan de tv leveren met bestaande software, en later upgrades sturen. Voor de software ontwikkeling betekent dit dat men rekening moet houden met adaptive maintenance van alle software in alle design-in (inmiddels maintenance) projects. Het aantal design-in projects dat tegelijk onderhanden is zal in zo'n situatie drastisch toenemen. Om een en ander met dezelfde mensen te realiseren zal de software die ontwikkeld en getest wordt aan de hand van algemeen geldende specificaties moeten toenemen, en de software die specifiek is voor een bepaalde hardware en daarop getest moet worden, die software en de tests ervan zullen beter afgebakend moeten worden. Een subproject dat een package ontwikkelt moet dit dus kunnen doen voor meerdere televisies dus voor meerdere master projects. Voor NXP geldt bovendien dat zijn software ontdaan moet worden van klant specifieke oplossingen. Met digitale televisie werd begonnen, samen met Philips CE, nog voordat al die afbakeningen definitief en hard waren gespecificeerd. Waarschijnlijk maakt dat de samenwerkingsprojecten uit die tijd toch wat uniek. Voor tv software programmeurs bij set-makers is het toch een beetje een cultuur omslag als er bijna uitsluitend tegen specificaties getest en ontwikkeld moet worden, zonder de hardware zeg maar, want die leidt dan maar af. Maar voor het NXP aandeel geldt dat NXP zich juist terugtrekt op de hardware software interface. Component Software. Beyond Object-Oriented Programming Clemens Szyperski (ACM / Addison Wesley: ISBN ). Televisie mensen zijn gewend aan systemen met een kloppend hart. Een televisie is onderworpen aan het strenge regime van 50 of 60 beelden per seconde. Een beeld moet volmaakt op het scherm staan voordat het volgende beeld aan de beurt is, anders krijg je macro blokken of andere storingen. Zo richten ze ook hun projects in: dagelijks wordt de software bijgehouden, periodiek (wekelijks, 2 wekelijks, maandelijks afhankelijk van de project-fase en het project) komt er een nieuwe baseline. Hun projects kenmerken zich door een kloppend hart. Dit creëert dagelijkse en periodieke deadlines waarin de dingen moeten gebeuren. Veel handelingen zijn tijdrovend, en worden onder tijdsdruk wel eens achterwege gelaten, hierin zijn televisie mensen minder strikt in hun projects dan in hun tv's. Waarom wordt er eigenlijk zoveel voortgang gecontroleerd? Blijkbaar gaat men er van uit dat je als manager kunt ingrijpen bij vertragingen, maar kan dat wel? Er geldt toch de regel dat meer mensen op een te laat project de zaak alleen maar meer vertragen? De meeste voortgangsproblemen hebben geen crisisachtig karakter en worden opgelost doordat teamleden elkaar helpen, onderling het werk herverdelen, en (nog) wat meer uren maken. Ook kan men binnen een team vrij probleemloos met capaciteiten schuiven van het éne project naar het andere. Behalve dat hij wel heel erg een eigen leven is gaan leiden, en iedereen er meteen naar wijst als het management ingrijpt, is er nog iets grappigs aan die oude wet (in 1975 gepubliceerd geloof ik). Om hem te controleren zou het project zich moeten splitsen in een project dat op de oude manier doormoddert, en een project waar nieuw bloed leidt tot herbezinning (dat kost tijd) en misschien tot Pagina: 17 / 230

18 1 Inleiding 1.2 De organisatie nieuw elan (dat spaart tijd, mits het lukt). Het enige wat je kunt meten is één van de voortgangen, want andere hebben zich niet voorgedaan. Of de wet in een specifieke situatie mag worden overtreden is mogelijk een kwestie van geloof, inzicht en ervaring. In ieder geval zijn de eerder genoemde factotums en goeroes enkele malen met succes ingezet in crisisachtige situaties. Het motto van de leiding was: be prepared. Ze waren erop voorbereid dat plannen kunnen mislukken, en dat bleek sterker dan de wet van Brooks. Eigenlijk is het natuurlijk ook de aard van het bedrijf en het product waardoor de wet niet per se geldt, en mensen gemakkelijk kunnen verhuizen van het éne project naar het andere, en van het ene team naar het andere, al is het nooit helemaal naadloos. Let wel: bij het toevoegen van een factotum aan een project gaat het primair om de extra man-months, dus het is een echte lange neus tegen de wet. Er lopen dan extra mensen in paren of individueel in de tredmolen: problem report van de stapel halen, fout analyseren en verbeteren, testen, regressie test uitvoeren, inchecken, problem report van de stapel halen,... Je helpt elkaar waar nodig, maar dat neemt niet excessief toe met nog meer mensen. Behalve de eerste paar dagen, waarin de ervaren nieuwkomers worden bijgepraat, gaat alles zijn gewone gang. Zelfs minder ervaren mensen zijn wel eens ingezet, onder leiding van de project architect, en met de afspraak dat ze vooral steun zouden zoeken bij elkaar, en dat ze vooral werk van de stapel zouden halen dat tot hun specialiteiten behoort. Of ze de project-duur significant hebben verkort is mij niet bekend, hoogstwaarschijnlijk hebben ze de duur niet verlengd. Qua methode: baat het niet, het schaadt ook niet. Dat geldt in ieder geval voor de doorlooptijd. Er zijn veel boeken over team building, en ook over crisis management, en ik heb ooit heel vroeger een enkele gelezen. Eigenlijk weet ik niet echt hoe je een team bemant en de menselijke samenstelling onderhoudt, of hoe je professioneel ingrijpt als zich een crisis voordoet. De boeken waarvan ik mij nog maar nauwelijks de details herinner: The Mythical Man-Month. Frederick P. Brooks, Jr. (Addison-Wesley: ISBN )) The Psychology of Computer Programming. Gerald M. Weinberg (Dorset House Publishing: ISBN: ) Soms moet je als manager wel ingrijpen. Zelf ben ik samen met een collega medio jaren tachtig wel eens ingezet in een klein te laat project, als software reviewer van software die geschreven was in een mij onbekende script taal. Het ging meen ik om een implementatie van een EDI systeem betreffende de goederen stroom (orders, leveringen, facturen en dergelijke). Het betrof een in-house project van TASS voor het rekencentrum van Philips in Eindhoven. Het IBM mainframe waarop getest moest worden was pas laat beschikbaar gekomen, waardoor er een soort big bang situatie was ontstaan: alle software werd geïntegreerd getest. Toen mijn collega en ik begonnen was testen zelfs compleet onmogelijk. Vandaar dat we werden ingezet als reviewer en vandaar dat het team er nogal moedeloos uitzag. Eén fout is ontdekt door iemand die zijn software nakeek om een vraag van mij te beantwoorden toen ik mij inwerkte, sommige fouten vond men zonder onze inbreng, andere met een van ons als praatpaal, en een enkele fout vonden we zelfstandig als reviewers. Na een week of twee hadden we met elkaar de spook-verschijnselen in de software verklaard en verbeterd, en toen was het project ook zo goed als klaar. Uitspraak achteraf van de staf: Brook's vuistregel is er om overtreden te worden, maar liefst wel Pagina: 18 / 230

19 1 Inleiding 1.2 De organisatie intelligent. OK, ik zal wat meer details geven. De meeste fouten waren peanuts. Er was maar één systematische fout verantwoordelijk voor de spook-effecten die testen onmogelijk maakten. Deze fout kon woekeren omdat er tijdenlang geen mainframe beschikbaar was voor testen, en misschien ook omdat het team bij TASS zat, en niemand van de klant over een schouder meekeek. De teamleden hadden het taaltje geleerd van voorbeelden, van elkaar, en van iemand bij de klant, waar de taal inmiddels een beetje ingeburgerd was. De scripttaal en de interpreter waren nogal in elkaar geflanst. Een procedure call was geïmplementeerd zonder call stack: er werd maar één return adres onthouden. Bij elke call opdracht, en alleen bij elke call opdracht, werd het returnadres register bijgewerkt en bij elke return opdracht vond een goto plaats naar het onthouden adres. Wie denkt nou aan zoiets als je van huis uit C of Pascal programmeur bent op een VAX/VMS systeem of op een Unix mini: de Philips P800. De systeembeheerders, werkvoorbereiders en operators in het rekencentrum waren gewend aan JCL, aan allerlei hen opgedrongen configuratie files, en aan de ongein die applicatie programmeurs op de laatste project dag nog even voor ze uitvinden, zoals de beruchte datum ponskaart. (Nou ben ik behoorlijk aan het chargeren, dat gebeurt lang niet altijd.) Ze vonden zo'n regel of interpreter niets bijzonders, en het ontbreken van validatie heel normaal. Deze catastrofe had de klant niet kunnen voorzien. Ik moest of wilde mij inwerken zonder het team teveel te belasten, dus ik leerde het taaltje uit een boekje en geloofde mijn ogen niet toen ik las dat je binnen een subprocedure geen procedure call mocht uitvoeren. Zo was ik, denk ik, de eerste die de fout-oorzaak ontdekte. Dus ik wist: je moet wel wat geluk hebben, een ander was je zomaar vóór geweest. Achteraf gezien was het misschien niet zo rationeel, om je in te werken zonder het team te belasten. Iemand inwerken heeft immers op zich al een hoog review gehalte. Ook hiermee hebben we mogelijk geluk gehad, al had ik mij laten ringeloren door de wet van Brooks. In onze presentatie als reviewer toonden we aan dat de verschijnselen bij het testen het gevolg waren van de diepte structuur en de call beperking. Spokerij werd vervangen door logica, en het gedrag van de software kon tenslotte door iedereen worden nagespeeld en begrepen. Maar ook was onontkoombaar duidelijk dat de fundamentele structuur van de software vervangen moest worden. Dat bleek voor ieder bijzonder moeilijk te accepteren: het was verder een goed doordacht concept. De volgende dag, nadat ze een vlak gestructureerd framework hadden geadopteerd, en de taken om het frame in te vullen waren verdeeld, zaten ze weer neuriënd achter hun CRT scherm. Alleen de teamleider, die de oorspronkelijke opzet had bedacht, was nog lange tijd van slag, maar hij heeft zich, als ik het mij goed herinner, niet ziek gemeld. Vanwege dat acceptatie probleem en vanwege hun moedeloosheid geldt mogelijk: Misschien waren ze er niet uitgekomen zonder nieuwe medewerkers in het team, en had ik helemaal geen geluk gehad. Misschien maar goed dat de staf niet naar de wet had geluisterd. Pagina: 19 / 230

20 1 Inleiding 1.3 De televisie als bedrijf 1.3 De televisie als bedrijf Als je de televisie ontleedt, hetzij hardware hetzij software, dan vind je een componenten structuur. Toch herken je vaak nog een bedrijfsmodel. Er is een transformatie laag, een besturing en planning laag, en een laag waarin doelen geformuleerd worden (door de zapper). Het is natuurlijk wel een simpel model zonder een strategische component, zonder verander processen, zonder projects, en zonder informele gegevens. In de hardware zie je de TriMedia, en de DSP's die zich bezig houden met het transformatie proces, en de MIPS die vooral gebruikt wordt voor besturing en planning, en met een beetje goede wil zou je de stand-by processor, die onder meer belast is met het ontvangen van de signalen van de afstandsbediening, kunnen zien als de component die zich bezighoudt met de doelen. Dit laatste is een grapje, de stand-by processor heeft nog enkele simpele ad converters, beheert een aantal aan/uit poorten, (sommige van deze poorten worden gebruikt als input andere als output, soms als input/output), en bevat een wekker, hij is voornamelijk een ondersteunende afdeling, Het ontvangen opslaan en bijhouden van de bedoelingen van de zapper is een taak van de MIPS software. In de software is herkenbaar de software die zich bezig houdt met het transformatie proces. Dit is altijd TriMedia software, De besturing en planning software zelf is gesplitst in middleware en de drivers (AV platform laag). De driver laag draait deels op de MIPS, maar sommige hardware componenten worden bestuurd vanuit de TriMedia. Er is nog ondersteunende software: os (operating system), een API laag tussen TV software en het onderliggende operating kernel. En er zijn de applicaties. Op de MIPS was de kernel vroeger een gespecialiseerde real time kernel, maar tegenwoordig is dit Linux. De TriMedia gebruikt nog wel een specifieke real time kernel. Planning en besturing maakt gebruik van gegevens die door de zapper of door applicaties zijn verstrekt, van configuratie gegevens, van gegevens die door dealers wordt verstrekt (bijvoorbeeld geografische informatie) en van gegevens die afkomstig zijn van de te verwerken signalen. Deze laatste categorie gegevens kunnen een real time probleem geven als ze afgehandeld moeten worden door de MIPS software. Een voorbeeld hiervan is de aanwezig/afwezigheid detectie van een signaal. Bij afwezigheid moet meestal geen ruis maar een blanco scherm gepresenteerd worden. Als de bestuurder moet beslissen dan zie je even ruis op het scherm, en als dit autonoom wordt afgehandeld dan zie je geen ruis. Er is een enkel geval waarin het tonen van ruis functioneel wordt geacht, dan wordt niet gedelegeerd, in alle andere gevallen wordt wel gedelegeerd. Een ander voorbeeld is fast blanking Een video recorder stuurt via een scart plug een CVBS signaal naar de TV, maar als de gebruiker de video recorder instelt dan wordt gebruik gemaakt van de TV voor de menu's van de video recorder (OSD: on screen display), en wordt niet alleen het CVBS signaal gestuurd maar ook een RGB signaal met het menu. Beide signalen beslaan in principe het hele scherm. Er wordt een aan/uit signaal fast blanking genaamd meegestuurd om aan te geven waar in het RGB signaal het menu staat. De besturing software is te traag om de overgang te realiseren, terwijl de transformatie laag enkele pixels nodig heeft om te schakelen, nadat de recorder de wenselijkheid van de overgang heeft gerapporteerd. Daarom kan de transformatie laag deze CVBS/RGB v.v. overgang autonoom afhandelen. Er is echter ook hardware waarin deze faciliteit ontbreekt, en dan wordt de overgang alsnog door de besturingssoftware beslist. Maar nu kost een dergelijke overgang enkele frames, in plaats van één pixel. Als de zapper Pagina: 20 / 230

21 1 Inleiding 1.3 De televisie als bedrijf een tv station kiest dan wordt fast blanking niet toegestaan, maar als naar de scart van een video recorder of dvd speler wordt gezapt dan wordt fast blanking gedelegeerd. Bij nieuwe hardware (of TriMedia software) kan de software engineer verrast worden door faciliteiten die opeens autonoom kunnen worden afgehandeld, of door faciliteiten die dat opeens niet meer kunnen. Iemand die UHAPI bestudeert zal zich soms misschien wel eens afvragen waarom bepaalde dingen autonoom afgehandeld kunnen worden door de transformatie laag. Meestal is er een goede reden. Daarna kun je je dan afvragen waarom er een mogelijkheid geboden wordt om dingen niet autonoom te laten afhandelen, en waarom zo'n functie soms ontbreekt in de transformatie laag. UHAPI: Universal Home API. Dit is een interface verzameling die gedefinieerd wordt door het UHAPI forum. Meer details zijn te vinden via Wikipedia (Engels) UHAPI. Met de komst van de digitale televisie komt er meer nadruk op te liggen op de tv als een verzameling applicaties. We hadden reeds een menu structuur, teletekst, een automatische programmagids, misschien een faciliteit voor automatisch opnemen, en dergelijke. Met de komst van digitale tv komt er ook interactieve tv: MHEG en MHP. Daarnaast zijn er multimedia en internet toepassingen, variërend van fotoalbum, tot beeldtelefoon, al dan niet volgens de DLNA standaards. Er zijn nieuwe methoden van copyright bescherming zoals DHCP, er zijn Fast blanking methoden van pay-tv met behulp van een CI (common interface). PIP, menu's en teletekst zijn uitgegroeid en behoeven een volwaardige window manager, gefaciliteerd door een sophisticated scaler/mixer. Het pure streaming transformatie systeem wordt een steeds kleiner deel van de televisie. Naast het bedrijf bevat de televisie zo ook een aantal klanten van het bedrijf: de applicaties. De besturing van het audio video platform vindt uiteindelijk plaats door registers te zetten, en registers te lezen. Er is een centrale database waarin voor veel situaties de register standen staan. De beheer software gaat uit van een aantal standaard instellingen,en weet wat de afwijking is van de standaard en bepaalt daarmee de register inhoud. Bijvoorbeeld, stel er zijn 2 ingangen voor analoog geluid. Via enige analoge elektronica bereikt dit signaal de omzetter naar een digitaal signaal. De analoge componenten hebben eigenschappen binnen toleranties. Als een tv gemaakt wordt, en mogelijk naderhand tijdens onderhoud, wordt door metingen vastgesteld wat de afwijking is van Pagina: 21 / 230

22 1 Inleiding 1.3 De televisie als bedrijf een norm. Dat wordt gecompenseerd met afwijkende register waarden. Een gebruiker die het geluidsvolume bijstelt vindt dat dat lineair gebeurt, maar de expert weet hoe de register settings moeten worden bijgesteld, gegeven de afwijkingen van de elektronica. Tuning is ook nodig om ontwerp karakteristieken te compenseren, zodat een analoog of digitaal signaal hetzelfde overkomt, of het nu van de tuner, MPEG speler, HDMI of scart afkomt, en hoe het bewerkingstraject er ook uitziet. Het vindt plaats op alle ins en outs. Tuning vindt plaats door berekening, meten in de test en integratie fase en voor de toleranties tijdens de fabricage of tijdens onderhoud. Om optimale beeld kwaliteit te waarborgen moet er regelmatig bijgestuurd worden. De stuurmanskunst is onderdeel van de platform besturing. Het bijsturen hoeft niet slechts te zijn gebaseerd op metingen van de signalen. Temperatuur metingen in de televisie, en het meten van licht en geluid in de omgeving is ook mogelijk. Het connection management, dat reageert op zappen en signalen die wegvallen, of die juist beginnen, regelt het opzetten van signaal routes. Een deel van het power management: het planmatig aanschakelen en uitschakelen van een televisie is voor een deel de platform besturing. Schematisch overzicht van het transformatie proces: een typisch Europese televisie Opmerkingen bij Schematisch overzicht van het transformatie proces: Europese televisie : Pagina: 22 / 230 De switches zijn gemerkt met een X het zijn source selection switches. Een output pin is altijd verbonden met hoogstens één input pin, een input pin kan verbonden zijn met meerdere output pinnen. De kolommen met een

23 1 Inleiding 1.3 De televisie als bedrijf X representeren in feite een groep matrices, waarin afzonderlijk schakelbare output pinnen zitten. In één matrix kan iedere output pin worden verbonden met iedere input pin, maar niet met twee input pinnen tegelijk. From file: de file is geselecteerd in het connectivity system en komt van het internet/intranet, van een USB-stick soms zelfs van een interne harddisk. Sources die verbonden zijn middels scart zijn statisch geclusterd, maar sommige AV sources zijn dynamisch geclusterd (verbonden met diverse pluggen aan de achterkant van de tv).het betreft dan soms een combinatie van YPbPr (3 pluggen type RCA), CVBS (1 plug type RCA), YC (1 plug type S-Video) LR (2 pluggen RCA), SPDIF (1 plug type FOSLINK ), maar ook combinaties met DVI en HDMI zijn mogelijk. Een source is bijvoorbeeld een DVD speler. De verzameling tv pluggen waarmee de dvd speler is verbonden vormen een input cluster die gezamenlijk de DVD speler representeren. Dit is vaak een dynamisch cluster, de samenstelling van de pluggen is niet voorgeprogrammeerd. Een enkele source kan inbreken als het betreffende apparaat gaat spelen, en interrumpeert de main source. Het daarvoor benodigde signaal wordt door de tv gemonitord. Als het apparaat aanstaat dan toont de source een logo als je er naar zapt. Dit is meestal geen reden voor break-in. Het apparaat moet echt gaan spelen. Sommige source clusters kunnen meerdere versies van een signaal tegelijkertijd aanbieden. Vaak wordt in zo'n situatie automatisch het digitale signaal of het signaal met de grootste bandbreedte (het minst gecomprimeerde signaal) geselecteerd. De niet geselecteerde signaal routes moeten dan vanaf source tot aan signal selection intact zijn zodat de aanwezigheid van het signaal gemonitord kan worden, dit moet in ieder geval gebeuren voor de route van het voorkeur signaal. Sommige sources kunnen successievelijk (achtereenvolgend) meerdere soorten signaal aanbieden, op dezelfde pluggen. Dan wordt automatisch het juiste pad gekozen na een verandering. Een club is in feite een groepje destinations die gezamenlijk naar dezelfde source kijkt en luistert. Het is geen gangbaar begrip in televisieland, maar het is evident dat clubs bestaan. Encrypted canal plus club. Het encrypted canal plus signaal komt uit de tuner, en gaat naar Scart1 (destination) en zo naar de canal plus decrypt box. De main club kijkt en luistert ondertussen naar Scart1 (source) naar de audio en video signalen die uit de decrypt box komen. In feite is de encrypted canal plus route open als de tuner staat ingesteld op een analoog station, dus ook bij niet versleutelde signalen. Subwoofer club. Het Spdif output signaal komt uit de main club en gaat naar de homecinema audio set. Het subwoofer signaal komt uit de home-cinema audio set. De speakers van de tv vormen in deze schakeling de subwoofer van het surround audio systeem. Het lipsynchroon probleem van digitale tv's wordt door de tv opgelost: het Spdif output signaal is lipsynchroon met de video. Van de home cinema set en de subwoofer club wordt verder geen significante doorlooptijd verwacht. De encrypted canal plus club, en de subwoofer club hoeven feitelijk geen source te kiezen. Voor die clubs ligt de source vast. Naar de main club kunnen schakelen: Main window, Speakers, Headphones, Scart, Spdif, LR sound. Naar de PIP club kunnen schakelen: PIP window, Speakers, Headphones, Scart, Spdif, LR sound. Wat ik PIP (picture in picture) genoemd heb kan ook een gelijkwaardig second Pagina: 23 / 230

24 1 Inleiding 1.3 De televisie als bedrijf window in een dual window televisie zijn. PIP window en Main window kunnen niet echt schakelen naar een club, het zijn vaste clubleden van hun eigen club. Naar Sound only kunnen schakelen: Speakers, Headphones, Spdif, LR sound. Sound kan in principe uit elk der sources komen. Merk op: scart output doet niet mee, maar produceert geluid, dat hoort bij de betreffende video (uit de main, pip, of canal plus club). Video route selecties zijn chip en software afhankelijk. Een voorbeeld van signalen die ieder een eigen route volgen: gewone video (1FH in het jargon) HD ready (2FH) Full HD (3FH) PC monitor, Game: deze moeten zonder vertraging, dus nogal onbewerkt getoond worden. Een van de vele voorbeelden waar het schema niet exact opgaat: Voor Scart output kun je kiezen of een CVBS signaal wordt geleverd of een Y/C signaal. Maar deze keuze is er niet als het signaal afkomstig is uit de encrypted canal plus club, dan wordt altijd het CVBS signaal geleverd: Met nog meer details ziet het schema er nog weer anders uit. Pin 19 van de scart ontvangt of het CVBS of het Y (luminance) signaal. Het C (chrominance) signaal komt wel of niet op pin 15: dat werkt niet met een input selection switch, maar een open/close switch. Toen er uitsluitend zwart/wit tv's waren was er slechts het luminance signaal. Met de komst van kleuren tv's werd CVBS geconstrueerd zodanig dat CVBS onbewerkt te gebruiken is als luminance signaal in zwart/wit tv's. Het verschil tussen CVBS en Y/C output is vaak uitsluitend het bij schakelen van het aparte chrominance signaal, omdat CVBS gebruikt kan worden als het luminance signaal. Het bandbreedte voordeel van het Y/C signaal wordt natuurlijk niet geëffectueerd, als de source een CVBS bron is: het signaal wordt niet beter dan het is. Mixing voor speakers en headphones: per afzonderlijke speaker kan er sprake zijn van equalizing en mixing van de oorspronkelijke (mono, stereo, surround) audio-stromen. Featuring en encoding gaan daarbij hand in hand. We beschouwen de DAC (digital to analog conversion) als encoding, de rest als featuring. Pagina: 24 / 230

25 1 Inleiding 1.4 Televisie, de software 1.4 Televisie, de software Ik heb voornamelijk met Philips Consumer Electronics samengewerkt. Zowel NXP als Philips CE gebruiken de taal C als programmeertaal. Toen ze samen een digitale TV gingen maken bleek dat wel zo ongeveer de enige overeenkomst Architectuur en component modellen Toen Philips Consumer Electronics en Philips Semiconductors gingen samenwerken om een digitale televisie te maken was de situatie als volgt: De software architectuur van CE wordt MG-R genoemd. Deze naam is afgeleid van het MG98 project waarin voor het eerst een component model werd gebruikt in een Philips televisie. MG-R betekent MG-Revised. De Software stack van CE gebruikt al sinds MG98 uit de vorige eeuw Koala voor de indeling van software in compile time componenten, die met elkaar communiceren middels Koala interfaces. (documentatie is te vinden met Google: trefwoord Koala Component ). Recente documentatie over Koala vond ik niet. Er is: The Koala Component Model for Consumer Electronics Software, Rob van Ommering, Frank van der Linden, Jeff Kramer, Jeff Magee; IEEE Computer, March 2000, p Er is een website waar een opensource versie wordt aangeboden. XT / Koala compiler. Zelf heb ik thuis stiekem het manual "The Koala Yellow pages", waarin de volgende zin staat: "The Koala pages have been written in July They have been updated in October 2000, October 2001 and September 2002." Koala compileert cd, dd, id, en pd files, en genereert een h file per Koala module. Soms genereert Koala ook c files, namelijk als voor de betreffende Koala module niet met de hand een c file is gemaakt waarin interface functies worden geïmplementeerd. Koala gebruikt een database waarin wijzigingen kunnen worden aangebracht. In een clean build wordt een nieuwe database gemaakt. In vervolg builds worden wijzigingen in de source files gebruikt om de database te wijzigen Gewijzigde input files resulteren in een gewijzigde database en van daaruit in gewijzigde h files en c files. De betreffende folder bevat na afloop van een Koala build niets anders dan de huidige h en c files. Hierdoor is duidelijk welke object files kunnen vervallen, welke blijven welke nieuw of opnieuw gemaakt moeten worden. Wijzigingen in een c file in de source tree, die ongeveer dezelfde naam heeft als de overeenkomstige h files, en die deze inlijft, bepaalt mede welke object files wegens wijzigingen opnieuw moeten worden gemaakt. De lijst met objects in de object folder bepaalt de nieuwe inhoud van de executable. Het merendeel van build: controle op gewijzigde cd, dd, id, en pd files, worden behandeld door Koala. Wat overblijft voor make is redelijk simpel en recht toe recht aan. NXP noemde haar architectuur DVP (digital video processing). De software van NXP (voorheen Philips Semiconductors) voor de TriMedia gebruikt voornamelijk IDL interfaces en COM methoden voor de RPC communicatie met de MIPS. De COM methode voorziet niet in het genereren van make files. Er werd gebruik gemaakt van recursive make. De COM methode maakt gebruik van de midl compiler. Deze compiler compileert idl files. Hij maakt er proxy/stub programmatuur en h files van. Proxy is het marshaling deel aan de client zijde en stub het marshaling deel aan de server zijde. Ik herinner mij dat de bij een interfaces of een component benodigde GUID (global unique identifier) in een c file wordt geplaatst. Dit laatste Pagina: 25 / 230

26 1 Inleiding 1.4 Televisie, de software dient om te controleren of de versies van componenten en interfaces die verondersteld worden in client software, of die versies aanwezig zijn, of bediend worden in de server software. Ook wordt de midl compiler gebruikt om een registry samen te stellen. UHAPI interfaces worden met behulp van RPC doorgegeven aan de TriMedia, en aan de drivers van de DSP's. COM wordt gebruikt zonder ActiveX of tekst interfaces voor script talen. Zie Wikipedia, en Google. Trefwoorden Microsoft COM, midl compiler en zo. De architectuur van de geïntegreerde MG-R/DVP software wordt NHSW genoemd: Nexperia Home SoftWare. He betreffende gedachtegoed wordt beheerd door NXP. Sindsdien begint CE meer en meer een eigen koers te varen met haar deel van de software stack. De NHSW architectuur ligt vast in een architectural notes document vol met regels en regeltjes voor ontwerpen, coderen, opslaan, structureren, gebruikte tools enzovoort. Toen ze gingen samenwerken is afgesproken dat de software voor de MIPS zou worden gebaseerd op Koala, en de software voor de TriMedia zou worden gebaseerd op COM, maar met een Koala sausje. Verder zou men op weg gaan om de interfaces naar de driver laag te gaan baseren op COM (IDL) interfaces. Voor Philips Semiconductors was dit een must, omdat veel van zijn klanten geen Koala gebruiken. Dit heeft geresulteerd in de Philips standaard NHAPI die inmiddels is opgevolgd door de algemene standaard UHAPI. Omdat de drivers gedeeltelijk op de MIPS zijn geïmplementeerd, is de COM methode ook in gebruik genomen tussen software componenten op de MIPS. Inmiddels is KOALA uitgebreid zodat met een mix van Koala interfaces en IDL interfaces kan worden gewerkt. Van UHAPI is een beschrijving te vinden in Wikipedia (Engels). Communicatie tussen TriMedia componenten en MIPS componenten en componenten van de standby processor gebeurt altijd op basis van idl interfaces proxy/stub programmatuur, en runtime binding. Proxy en stub communiceren met elkaar middels remote procedure call's (RPC). Er is afgesproken om Koala integraal te gebruiken, hoewel het gebruik voor TriMedia software minimaal is: de h files die door de idl compiler worden gegenereerd worden niet rechtstreeks ingelijfd in de betreffende c files, maar vermeld in de cd file van de betreffende Koala component zodat Koala deze inlijft in de h file die hoort bij de overeenkomstige c file. Koala is hier vooral bedoeld om de de eigen build methode te vervangen door Koala met recht toe recht aan make. Deze de overgang is overigens niet van de ene op de andere dag gerealiseerd, en misschien niet eens volledig Robuuste overgangen Met de keuze voor een component model is er ook gekozen voor struise overgangen. Infrastructurele wijzigingen dat zijn ze, de wijzigingen van interfaces. Afgesproken is dat interfaces niet wijzigen, als ze eenmaal zijn uitgegeven. Ze kunnen wel worden opgevolgd door een andere interface. Een component in zijn rol van server, kan een reeks opeenvolgende interfaces implementeren. Een component in de rol van client kan op een geschikt moment gewijzigd worden zodat die daarna de meest recente interface gebruikt. Pas als de laatste client over is wordt een oude interface beëindigd, en zijn implementatie uit de server verwijderd. Dit is de standaard methode. De methode kan ook omgekeerd werken. Als er diverse servers zijn kan een client een server ondervragen, en zich bedienen van één van de interfaces die de server aanbied. Pas als de laatste server en de laatste client over zijn naar de nieuwere interfaces worden de clients en servers vereenvoudigd door oude interfaces te verwijderen. Afhankelijk van de scope van de interface kan Pagina: 26 / 230

27 1 Inleiding 1.4 Televisie, de software de methode gebruikt worden om overgangen binnen een subproject, of binnen een master project te realiseren. Soms, als er sprake is van een interface tussen slechts twee componenten of tussen modules die onderhouden worden door één team, worden software en interface wel eens gelijktijdig gewijzigd. In een enkel geval waarin de twee componenten beheerd worden door verschillende teams, sturen ze elkaar wel eens baseline supplements (patches) om de gelijktijdige wijziging te realiseren. Dan moeten ze er wel zeker van zijn dat de interface niet elders in gebruik is. Vaak is er enige tolerantie voor gemaakte fouten. Maar als er iets mis gaat met de invoering van een interface wijziging dan krijg je de wind van voren: Waarom heb je de standaard niet gevolgd? Je weet toch dat je een interface niet mag wijzigen. In een enkel geval wordt gebruik gemaakt van configuratie files, versie-nummers, of creatievere methoden (hardware herkenning bijvoorbeeld) om de situaties te herkennen, waarvoor software in een overgang bruikbaar moet blijven. Ook is er de mogelijkheid om al dan niet met dezelfde interfaces een opvolger van een component te maken, en de oude pas weg te gooien als de nieuwe in gebruik genomen is. Zonder robuuste overgangen is teamwork en inter teamwork bij het maken van software waarschijnlijk zeer veel minder productief, en in ieder geval veel lastiger te organiseren. Van belang blijft het opruimen van oude oplossingen, als nieuwe volledig zijn geïmplementeerd. Tussen NXP en CE was er een procedure afgesproken. Bij de creatie van een nieuwe interface werd afgesproken op welk tijdstip de oude mocht vervallen. De nieuwe interface komt te staan in de folder..\interfaces, de oude komt in..\interfaces\obsolete, en verdwijnt daar op of na de afgesproken datum. Logisch, want het liefst hebben we de software simpel en toegespitst op bestaande situaties. Voor de andere oplossingen om overgangen met redundancy op te lossen, zijn geen afspraken gemaakt over opruimen en staat er niets in de architectural notes. Pagina: 27 / 230

28 1 Inleiding 1.4 Televisie, de software Folder structuur en builds Toen Philips Semiconductors (nu NXP) en Philips CE gingen samenwerken om een hybride TV te maken, was er een standaard folder-indeling van CE en één van SC. Er is toen een nieuwe folderindeling afgesproken door de architecten van beide industrie groepen. Normaal is de path-name van een folder de name-pace van zijn inhoud. Voor de NHSW tree gold echter dan componenten binnen de tree een unieke naam moesten hebben. Toen dat niet meer was vol te houden is besloten dat componenten een unieke naam moeten hebben binnen een package, dus in Koala wordt wordt een component nu aangeduid met een package name en een component name. De package naam wordt in de nieuwe pd file als name-space gezet. Ieder package heeft een pd file in zijn top folder waarin de namen worden vermeld van de packages waarvan componenten worden gebruikt. Als meerdere componenten dezelfde naam hebben dan wordt ze in de pd files een alias toegewezen. Vereenvoudigde NHSW structuur Toen ik NXP verliet werd de builds folder niet gearchiveerd in een revision control system, en ik heb niet meegemaakt dat de project folder enige inhoud had. Een folder als connmgr heeft typisch een package structuur, terwijl de subfolders in private en public typisch een opsomming zijn van componenten die een component structuur hebben, hoewel daarin ook een folder voorkomt met de naam interface. Deze folder-structuur is momenteel één enkele boom, voor alles wat er geproduceerd wordt aan program libraries, en executables en dergelijke. In de eerste fase van een build ontleedt Koala alle Koala files in de boom, ook als ze niet nodig blijken te zijn voor het target van de build procedure. Gezien de omvang inmiddels (tientallen gigabytes) zal in de toekomst waarschijnlijk gezocht worden naar een manier om van een boom over te gaan op een bos van kleine bomen, die zoveel mogelijk onafhankelijk van elkaar kunnen worden bijgehouden, en ieder een eigen executable Pagina: 28 / 230

29 1 Inleiding 1.4 Televisie, de software binary levert, met misschien een dynamische library. Als de TV start moet dus van elke tree uit het bos een binary worden geladen, want deze binaries moeten samenwerken. Ontwikkelaars zouden dan mogelijk minder tijd kwijt zijn aan het uitvoeren van build procedures. Deze weg is ingeslagen door CE die, ik meen in een SPACE folder, een aantal van de applicatie, product en tool packages heeft geplaatst buiten de NHSW tree (in een super tree), en daarop eigen build procedures gebruikt. Binnen de NHSW tree bleven: Tools, Middleware, Operating system, Audio/Video. Ik neem maar aan dat dit een trend is die doorzet. Iets dergelijks bestond reeds, Er is een MIPS executable, voor iedere TriMedia is er één, voor de stand-by processor is er één, (voor de DSP's natuurlijk ook, maar die staan niet in de folder structuur). Maar op de dag dat ik gepensioneerd werd was dit niet gerealiseerd in de folder structuur. Source code voor de één kan in principe zelfs staan in dezelfde folder als die voor een ander. De folder structuur herbergt packages (subsystems). Packages bevatten private en public onderdelen. Het is de bedoeling dat software in andere packages slechts refereert aan public onderdelen, zodat er voor de beheerders van het package nog enige implementatie vrijheid blijft bestaan. Met de nodige mitsen en maren kan gesteld worden dat een wijziging in een package die het publieke deel daarvan intact laat, slechts regressie kan veroorzaken in het eigen package. De mitsen en maren worden ook wel semantisch genoemd: het publieke deel moet ook semantisch intact blijven. Tot nu toe is het de gebruikers van een package altijd weer gelukt om aan te tonen dat het semantisch inzicht van de beheerders onvolkomen is. Het standpunt van de beheerders is evenwel dat gebruikers zich moeten beperken tot gebruik van het package binnen de semantische begrenzingen, hoe onvolkomen die ook zijn beschreven: je kunt het toch wel aanvoelen. Tot de publieke onderdelen behoren de public components, public interfaces, en public data definitions. De folder structuur is niet van de éne dag op de andere tot stand gekomen, hij is ontwikkeld, en dat heeft geleid tot verhuizingen van de source code. Zelfs de package indeling is aan wijzigingen onderhevig. Het systeem dat ik ga beschrijven zou dat moeten faciliteren, maar ik denk momenteel dat dat gedeeltelijk lukt voor herstructureren binnen een package, maar dat het me niet lukt voor herstructureren over packages. Niet dat het niet kan, maar het revision control system levert geen support: er kan geen verwantschap vastgelegd worden tussen twee programma's die in verschillende packages voorkomen Afbakening NXP De eerste Digitale TV die werd ontwikkeld was voor wat betreft de MIPS software gebaseerd op een bestaande software stack van CE. Het MIPS gedeelte dat NXP voor zijn rekening nam bevatte nog een ruim aandeel applicatieachtige functionaliteit, Bijvoorbeeld het bijhouden van de frequenties en eigenschappen van TV stations, of het kiezen van het beeld-formaat. De API (verzameling interfaces van de NXP laag) bevatte daarvoor veel functies. Momenteel trekt NXP zich terug op een driver layer die aangestuurd wordt via een glue layer. Dit in de hoop op kleinere en snellere design-in projects. Het package UHAPI bevat de interfaces, die de samenwerking van middleware met de driver laag Pagina: 29 / 230

30 1 Inleiding 1.4 Televisie, de software definiëren. Gegevens hierover zijn te vinden in Wikipedia. Ik heb eerst gewerkt met de interfaces van Philips CE, en heb daarna voornamelijk gewerkt aan de overgang naar voorganger NHAPI. De interfaces van NHAPI werden gebruikt als basis applicatie interface. In design-in en reference projects wordt NHAPI vaak uitgebreid met interfaces die de noviteiten in de chip aansturen. Ditzelfde gold indertijd voor UHAPI, ook die biedt een basis set. Er zijn klanten die bediend worden met een volledige software stack, en zelf bijvoorbeeld een logo toevoegen. Dit zijn OEM leveranciers. Voorheen had NXP een eigen software afdeling voor de top lagen, maar momenteel wordt deze software bijdrage uitbesteed Diversity Sinds jaar en dag prefereren de tv fabrikanten één enkele productlijn in hun fabriek, met één enkel software programma voor alle regio's en alle variëteiten. Dit betekent: diversity wordt vastgesteld bij het aanzetten van de TV: runtime oplossing. Maar geheugen was duur en dus schaars in televisies, en de microprocessoren hadden hun beperkingen, en dus soms moest er toch gewerkt worden met meerdere software varianten en werden sommige variabelen in de runtime omgeving constanten in de compilatie omgeving. Welke variabelen? Dat varieerde natuurlijk. In de ene serie waren het vooral regio gerelateerde codes, in een andere vooral model en functionaliteit gerelateerde codes. Koala wordt gebruikt om diversity efficiënt te verwerken. Soms weet je voor een TV waarvoor je software ontwikkeld al van te voren (op compilatie tijd) wat de diversity optie is, Voor een andere TV set moet je dit op run tijd detecteren. KOALA zorgt dat je de diversity in beide gevallen met dezelfde source code kunt bevragen. De object code die gegenereerd wordt door de compiler is compacter, als reeds op compilatie tijd bekend is welke optie geldt. Een van de technieken die de compiler gebruikt heet dead code elimination : de source code voor condities die niet gelden wordt verwijderd. Vaak wordt deze techniek gebruikt samen met een techniek die constant propagation wordt genoemd. Methoden die code optimaliseren zijn reeds in de jaren zestig en zeventig ontwikkeld. De diversity parameters die of op runtime of op compilatie tijd een waarde kunnen krijgen waren er in ieder geval al in de jaren tachtig. Toen besloten is om over te gaan op een componenten structuur, is er veel aandacht aan besteed om dit te behouden, en zelfs te verbeteren. Vandaar dat de componenten van KOALA geen binaries zijn, maar folders met source code. Het Koala engine zorgt ervoor dat bij een start module in een component (vergelijk het maar met de main procedure in C) de componenten en modules worden gezocht die samen een executable vormen. Dit gebeurt via de interface instances. Ook dit engine wordt gestuurd door diversity, en voert dead code elimination uit op het niveau van componenten en modules, die wel of niet meegenomen worden. Voor de herbruikbare C source code betekent dit ook wel iets. Soms geldt: #define a b soms int a = diversity_a(); met alle consequenties van dien voor wat betreft het gebruik van parenthesis (), switch statements enzovoort, bij een referentie naar a of b. Het streven is ooit geweest om de laatste software versie van NXP te kunnen gebruiken in alle vorige projects en dit te realiseren met diversity. Maar zodra gewijzigde software niet meer getest Pagina: 30 / 230

31 1 Inleiding 1.4 Televisie, de software wordt op een vorige televisie, dan is ze daar niet meer betrouwbaar. (Het is zelfs zo dat in de allerlaatste fase van een project, als tests nog haast uitsluitend plaatsvinden op builds van het product, dat dan een build voor het testen met een test harness vaak mislukt. Dit is een algemene regel: als verificatie ontbreekt, dan is regressie het gevolg. De standaard diversity is belangrijk voor een snelle aftrap van een project. De diversity tussen de modellen binnen een project moet zich vaak ontwikkelen binnen het project. Binnen de NXP packages werd diversity als volgt geïmplementeerd. Basis is een aantal parameters die de variant van de televisie beschrijven. Iemand gaat werken aan een component (delta processing of zo) en komt er achter dat de component varianten en instellingen niet rechtstreeks afhankelijk zijn van de basis, maar daar door logica en berekening uit zijn af te leiden. De varianten van de component hebben hun eigen parameter set. Er is in het begin is er een diversity component gemaakt die middels een diversity interface bevraagd kon worden om de diversity van een component te leveren. Nu maken de componenten deel uit van componenten die een platform deel representeren, platform delen zijn componenten binnen de platform component en naast de platform component staat de diversity component. De diversity interfaces van de kleine componenten werden in het platform deel verenigd tot een grotere interface, en in het platform tot één geheel. Nu kwam het voor dat sommige componenten om dezelfde diversity parameter vroegen. In de samengestelde interface kwamen dus functies in enkelvoud voor die in de platform cd file tot een return waarde in meerdere interfaces moest leiden, en zo ook in de deel platform cd file. Toen dit systeem bedacht en geïmplementeerd werd door mensen voor wie Koala nieuw was, (en misschien kon Koala toen nog niet wat nu mogelijk is) is dit zo gebeurt dat in de diversity module van een (deel) platform component ieder functie call vanuit een component afzonderlijk opgeloste met een functie call via de samengestelde interface. Dit bleek zeer onderhoudsgevoelig. Voor diversity interfaces maakten we trouwens een uitzondering, geen enkele wijziging leidde tot een nieuwe interface, deze interface mocht gewoon wijzigen. Ondanks de onhandigheid, is er in geen van de projects erna besloten tot herontwikkeling. Als er in product family een tv voorkomt waarvan een eigenschap op compile time bekend is dan is die eigenschap een diversity parameter. Voor diversity geldt als ze in één van de andere televisies geen compile time diversity is dat ze moet zijn te determineren door automatische detectie van hardware karakteristieken, of dat ze moet worden opgegeven door een fabrieksmedewerker, of door een dealer, of door een eindgebruiker. Normaal worden de run time diversity parameters vastgesteld tijdens initialisatie van het systeem. Als de diversity wordt ingesteld door dealer of fabricage medewerker, dan moet opnieuw worden gestart om de wijziging te activeren. Maar van een eindgebruiker wordt dit doorgaans niet verwacht. Wat tussen sommige televisies diversity is, kan in een andere een gebruikers optie zijn. Ik heb nog niet gezien dat dit met diversity is geregeld. Het binden van parameters aan waarden mag dan gebeuren tijdens initialisatie, maar dat betekent niet dat de diversity alleen dan geraadpleegd wordt. Raadplegen gebeurt voortdurend. Tuner karakteristieken maken deel uit van de diversity. Proactief worden van tuners de eigenschappen vastgelegd. Iets soortgelijks geldt voor onderdelen als beeldschermen. Tuners en beeldschermen zijn in ieder geval voor een deel op compile time bekend. Soms wordt in de fabriek gekozen uit enkele typen, dan is op compile time de selectie bekend. Andere zaken die mogelijk proactief bijgehouden worden, maar vaak ook het gevolg zijn van field calls, of field tests. Soms wordt van een bepaald invoer apparaat geconstateerd dat zijn signalen beter afwijkend kunnen worden behandeld. Soms geldt dit voor de signalen van kabel exploitanten, Pagina: 31 / 230

32 1 Inleiding 1.4 Televisie, de software en tv stations. De dealer kan soms informatie geven over de signaal leveranciers ter plekke. Maar toch, de eigenschappen van invoer-apparaten en kabel exploitanten en dergelijke kunnen momenteel beter uit een database van het internet opgehaald worden. Die van kabel exploitanten veranderen, tv stations komen en gaan en apparaten komen er steeds meer. Er wordt steeds meer gestandaardiseerd, en certificering kan groeien in kwaliteit. Soms kan iets dat eerst mogelijk met diversity geregeld was, eruit verdwijnen Koala / Horcom Koala is gemaakt voor resource restricted systems. Dit zijn kleine micro computers met weinig geheugen en processing power. Ook is Koala gemaakt voor product families, en implementeert ze efficiënt diversity. De bijdrage aan de diversiteitsafhandeling wordt nog steeds gewaardeerd. De processoren in de TV chip kun je niet meer zo heel erg resource restricted noemen, maar daarvoor geldt baat het niet het schaadt ook niet, en uiteindelijk is Koala enigszins uitgebouwd voor COM. Diversiteit wordt gebruikt om bij elk source programma een toegespitste h file te maken, nou ja niet bij allemaal, alleen degenen die van belang zijn voor een bepaalde televisie. De compile time oplossingen van Koala profiteren van het feit dat er in een televisie veel singleton componenten voorkomen, of enkele met name te noemen instances. Zo is er slecht één tuner, en slechts enkele decoders (een decoder kan slechts enkele signaal-soorten decoderen), enzovoort. In veel televisies kan men werken met een Dual Window of met Picture in Picture Dan moeten er voldoende component instances zijn voor de verschillende video-stromen. Bij deze componenten hoort ook slechts één driver. De component instances hoeven meestal niet dynamisch gecreëerd te worden en de interfaces behoeven meestal niet dynamisch te worden gelegd. Koala is in deze situatie goed op zijn plaats. De componenten staan in een statische structuur, en de interfaces zijn vaste verbindingen tussen de componenten, die tijdens compilatie gedeeltelijk met behulp van inline code worden gerealiseerd. Een component die 2 instances realiseert implementeert soms twee sets instances van dezelfde interfaces. De ene set kan verbonden zijn met client component A, en de andere met B. De compile time binding van Koala werkt samen met een optimizing c compiler en zo wordt door Koala en compiler geoptimaliseerde code geproduceerd. Een verstoring van dit beeld treedt op omdat er in tv's gezapt en geschakeld wordt. Als je zapt van een analoge tuner naar een digitale dan moet het signaal een andere route gaan volgen; als je naar een dvd speler kijkt moet het signaal een andere route volgen dan wanneer je kijkt naar een uitzending: de componenten moeten zich steeds anders aaneenrijgen om een route te maken. Voor hardware componenten wordt dit geregeld met hardware switches en blijft het statische beeld feitelijk intact, maar voor TriMedia (software) componenten wordt het signaal pad geformeerd, door de betreffende component instances dynamisch te creëren en dynamisch te linken aan voorganger en opvolger. Ook dan blijft het vaak singleton werk, want er kunnen slechts enkele signaal-stromen tegelijk door een televisie lopen. Een en ander heeft ertoe geleid dat de hardware routes worden geregeld met Horcom, terwijl TriMedia routes worden geregeld door een Connection Manager. Een ontwikkeling die nog altijd door mij wordt betreurd, het had met één methode gekund: Horcom vernieuwd. Horizontal communication: a style to compose control software, Rob van Ommering Software Practice & Experience Volume 33, Issue 12 (October 2003). Pagina: 32 / 230

33 1 Inleiding 1.4 Televisie, de software Horcom discussies, gesprekken bij de koffie automaat Sommigen binnen NXP wil eigenlijk af van Koala, omdat Philips CE de enige klant is die ermee werkt. Voor NXP zelfstandig werd nam PS het onderhoud over van CE als ik mij goed herinner, maar ik geloof niet dan het beheer meegenomen is toen PS NXP werd. Binnen PS was het misschien wel stiekem de bedoeling om het te killen. Maar tot nu toe is de berg eigen NXP software waarin het gebruikt wordt te groot om het weg te gooien, bovendien heeft men met Koala ook beheerders en gebruikers overgenomen, en die willen van geen wijken weten. Koala is typisch zo'n methode waarvan je denkt dat je hem beheerst, terwijl je er eigenlijk gewoon aan verslaafd bent. Wat voor Koala geldt geldt ook voor Horcom: CE is de enige klant die ermee werkt, en eigenlijk willen sommigen er daarom van af in de hoop beter aan te sluiten bij de rest van de markt. Veel klanten gebruiken geen NXP tuner, en geen NXP channel decoder, of vullen de chip aan met eigen chips of bolt-on boards, en komen daarvoor dan met eigen software: de platform software werkt dan slechts ten dele met Horcom, of via omwegen of gedeeltelijk imiteren worden de componenten van de klant opgenomen in Horcom. Daar staat tegenover dat NXP zeer veel heeft geïnvesteerd in de platform besturingssoftware die er nu is, met een project van tussen de veertig en zestig mensen gedurende meer dan een jaar. In feite was het project de allerlaatste poging om een digitale tv op de markt te zetten. Koala en Horcom maken deel uit van, of misschien wel zijn, de infrastructuur van de platform besturingssoftware. Als je ze vervangt moet je feitelijk overnieuw beginnen. Vandaar misschien de methode: reuse en langzaam terugdringen. Horcom als architectuur principe. Het idee is duidelijk. De componenten structuur van de hardware wordt nagevolgd door de software. In principe is dit een anti reuse bepaling: je volgt niet de structuur van de vorige software generatie, maar de structuur van de huidige hardware (en TriMedia) componenten, dus reuse is komt hoogstens voort uit reuse van onderliggende componenten. Dit volgen van de structuur betreft overigens niet de hiërarchische structuur maar uitsluitend de netwerk structuur: het transformatie model zeg maar. Ondanks dat dit eigenlijk heel duidelijk is, is er toch altijd wel tegen gezondigd. Het is gewoon te verleidelijk om software opnieuw te gebruiken, en wat te knutselen om het werkend te maken. Het capability model van Horcom is te simpel. Oorspronkelijk zou een Horcom node de volledige verzameling capabilities van de onderliggende transformatie component vermelden, maar uiteindelijk werden slechts de signaaleigenschappen geregistreerd die de component kon vaststellen. Voor deze data is een simpele methode gekozen, zonder zaken als information hiding. Dit alles was gerechtvaardigd op de vroegere kleine micro computers met weinig geheugen, maar nu is er behoefte aan betere methoden, zoals uit de twee volgende paragrafen blijkt. De taken van Horcom: connection management en het verzorgen van de (bidirectionele: upstream en downstream) communicatie tussen de componenten in de transformatie laag. Connection management is op te delen in verschillende taken, zoals het bepalen van de blanking en muting periode tijdens een zap, het afbreken van de oude routes en het instellen van de nieuwe, Het beëindigen en opnieuw bemiddelen tussen de transformatie componenten die gegevens produceren en degenen die informatie behoeven. Met de introductie van de com component methode zou daar een deeltaak bij moeten komen: het dynamisch koppelen en ontkoppelen van de bestuurlijke interfaces (van UHAPI) aan de componenten in de transformatie laag. Het bedienen van zo'n interface is natuurlijk ook een capability van de component. Ook het binden van interfaces tussen de laagste besturings-componenten ontbreekt. Veel van deze componenten zijn één op één vast gerelateerd met drivers, en daarmee vast gerelateerd aan een Pagina: 33 / 230

34 1 Inleiding 1.4 Televisie, de software Horcom node. Met name de engineers van het audio gedeelte implementeerden een Horcom node met besturingsinterfaces zonder onderliggende transformatie component, en vandaar uit een complex geheel aan route begeleidende (KOALA) interfaces naar nodes die wel een onderliggende transformatie component bedienen, zo omslachtig zelfs dat het plug en play karakter verloren is gegaan. Het stromen model van de eerste chip die we programmeerden kon daardoor nog steeds herkend worden in de software voor de laatste chip die ik heb meegemaakt. Via deze interfaces vindt zowel gegevens uitwisseling plaats als ook besturing. Die route begeleidende interfaces hebben duidelijk een work-around karakter. Ze zijn er omdat Horcom ze niet biedt. Toen MG-R en DVP geïntegreerd werden ontdekte men van elkaar aan de ene kant Horcom, en aan de andere kant TSSA (TriMedia Streaming Software Architecture) Men startte de discussie met ze als alternatieven te zien. De volgende twee paragrafen zijn het resultaat van de discussies toen. Een deel van de Horcom discussies zijn analoog aan de delegeren of besturen discussies in verticale organisaties. Er is de vaststelling dat veel van de horizontale communicatie met de stroom meegaat, en dus als metadata met de stroom meegestuurd kan worden, zoals je in een fabriek halffabricaten kunt transporteren in een bak met een kaart met streepjescodes. De informatie-stroom in tegengestelde richting zou te gering zijn voor een algemene oplossing, en zou dus maar met incidentele oplossingen moeten worden bewerkstelligd. Dus waarom dan nog Horcom? Eigenlijk was dit een opvatting gebaseerd op het gegroeide idee dat er slechts data uitgewisseld wordt tussen transformatie componenten. In de praktijk wordt er ook data van of voor het management horizontaal uitgewisseld, en worden opdrachten in stukjes geknipt en doorgegeven aan de transformatie-laag. Dit komt omdat Horcom het enige horizontale management platform is in de TV. Zo zijn er zelfs enige Horcom nodes zonder een bijbehorende transformatie component. Zonder deze nodes zou mogelijk een verzuilde besturingslaag zijn ontstaan, terwijl nu de verzuiling alleen bestaat voor de Horcom nodes, de drivers en hun onderliggende transformatie componenten (in het audio gedeelte is het wel wat complexer geworden, dan kleine zuiltjes). Zuivere verzuiling zou de toenemende rol van applicaties hinderen. Het verdelen van applicatie informatie naar transformatie componenten, het verzamelen van informatie t.b.v. applicatie componenten en het verdelen of herindelen van opdrachten komt deels omdat er op transformatie niveau creativiteit toegestaan wordt met de component indeling. Daardoor past een UHAPI interface niet altijd precies op één hardware component, of één TriMedia component. Voor een ander deel omdat er altijd wel enige redundancy bestaat in de transformatie laag waardoor er keus is waar een bewerking of een waarneming moet plaatsvinden. Die keus wordt doorgaans gerealiseerd in de management laag, dus in het horcom netwerk. Die redundantie is er bijna zeker, als de NXP chip wordt begeleid door elektronica die niet van NXP afkomstig is, en soms ook als additionele elektronica wel is geleverd door NXP, en af en toe is ze er zelfs binnen de one-chip televisie. Het andere deel van de discussies is een plug en play discussie. Horcom heeft een typisch plug en play aspect: plaats een Horcom node in het model en de onderliggende transformatie component kan worden bestuurd en doet mee met connection management. Al moet je naar de hardware nog wel een driver maken, en vaak de driver aansturen vanuit een functionele module. Dit heeft natuurlijk een prijs: bij elke zap, en bij sommige signaal veranderingen, wordt voor elke output (speakers, window, connectoren) een route gezocht naar de gewenste input. Iets zoeken is natuurlijk minder snel dan iets pakken. Het vaststellen van de blanking periode (drop/restore logica) gebeurt door meerdere malen Pagina: 34 / 230

35 1 Inleiding 1.4 Televisie, de software sequentieel routes in het netwerk te doorlopen. De daadwerkelijke gegevens uitwisseling werkt eveneens, door sequentieel routes langs te gaan om componenten te notificeren. De routes worden doorlopen doordat iedere node op zijn beurt de betreffende functie aanroept in een naastgelegen node. Dit betekent dat een zeer grote call-stack moet worden bijgehouden. De tegenstanders van Horcom bepleiten als oplossing: houdt het model buiten de TV software (desnoods op een schoolbord), doe daar een model zap, registreer wat er dan gebeurt, en breng het geregistreerde aan in de TV software. Daartoe gebruiken ze dan in de TV de connection manager voor het koppelen van interfaces aan platform componenten, en het kennis systeem voor de register waarden (inclusief switches). In wezen betreft deze discussie dus het wel of niet verplaatsen van acties in de runtime omgeving naar het ontwerp stadium. Om reeds in de design fase (van de chip of de set) een Horcom model te maken is natuurlijk een goed idee. Je kunt ermee testen of alle signaal paden altijd over voldoende resources kunnen beschikken, en misschien ook of elkaar storende onderdelen tegelijk actief kunnen zijn. De keuze om het audio / video netwerk te modelleren met KOALA interfaces tussen Horcom nodes is niet helemaal gelukkig. Er zijn inmiddels veel nodes in dit netwerk, dus Horcom nodes zijn geen singletons (er zijn er aanzienlijk veel meer dan één of twee). Met KOALA interfaces is er is een aanzienlijke hoeveelheid node specifieke code. Dank zij uitgekiende Horcom macro's is de hoeveelheid primaire source code beperkt, maar na macro expansie is er relatief veel c code: Horcom is een geheugen vretertje. We zouden misschien beter over kunnen gaan op een netwerk structuur opgebouwd uit objecten met vtables, die met elkaar verbonden zijn middels pointers. De meeste horcom nodes hebben meer dan één ingang en meer dan één uitgang. Nodes tot nu toe zijn: source, destination, one-to-one, fork (die zorgt voor een vertakking van een input signaal in meerdere output signalen), switch (dit is altijd een source selectie switch: de output pinnen worden erdoor gegroepeerd in clubs die naar dezelfde input pin kijken of luisteren, of mogelijk één output pin die afwisselend kan kijken naar steeds één input pin tegelijk). Als je twee forks bekijkt dan kan de éne het volledige signaal splitsen in 2 volledige signalen, terwijl de ander het signaal ontleedt in onderdelen die ieder een eigen route volgen. Bijvoorbeeld audio/video wordt gescheiden, of een video signaal splitst in een Y route en een BlueRed route. Er zijn ook hybride forks waarin een gedeelte van het signaal voorkomt in meerdere teeth. Forks in het Horcom model hoeven niet altijd te bestaan in de hardware: in een scart plug bijvoorbeeld heeft ieder signaal zijn eigen poort, maar in het horcom model zijn die gebundeld in één route bij de source node, en wordt de route met een fork gesplitst in een audiogroep, een CVBS/YC groep en een RGB groep. We missen nog één type, een tegenhanger van de fork, waar signalen bijeen komen, zoals in de video mixer, waar dual windows en menu's kunnen samenkomen in het screen, en de video decoder van de oorspronkelijk analoge signalen, waar sync signalen binnenkomen die een andere route hebben afgelegd dan de RGB signalen, en waar het luminance signaal via een andere route binnenkomt dan de chrominance signalen. De trajecten achter de mixer en vóór de decoder zijn inmiddels significant. De tegenhanger van de signaal ontledende fork, bijvoorbeeld de analoge video decoder zou composer genoemd kunnen worden of counter-fork. Mogelijk wordt de mixer geïmplementeerd met twee half autonome horcom netten, immers zijn Pagina: 35 / 230

36 1 Inleiding 1.4 Televisie, de software output is een source voor het net dat er op volgt, terwijl zijn inputs een destination zijn van het net dat eraan voorafgaat. Achter de mixer is er bijvoorbeeld een netwerkje met een route voor de onmiddellijke ongebufferde presentatie van de video van spelcomputers en de route met frame buffers die dienen voor het plausibel presenteren in de beeld frequentie en resolutie van het scherm. (Tijdens de nationale voetbal gekte hebben de huizen in de straat waaruit het eerst een gejuich opstijgt nog een ouderwetse analoge tv, met een analoge provider en de huizen waaruit het gejuich een aantal seconden later komt een digitale met veel (frame) buffers tussen camera en scherm). Er is een idee om switch en fork te combineren zodat in de ene tv een input en een output pad hard coded of middels diversity gekoppeld kunnen zijn, terwijl in een andere dynamisch middels switchen gekoppeld wordt. Die diversity bijvoorbeeld geeft hardware ontwerpers de mogelijkheid om een plug de ene keer aan te sluiten op poort A van de chip, en de volgende keer op poort B. De huidige implementatie met macro's mist die mogelijkheid, waardoor de diversity methode die nu in gebruik is erg omslachtig is. Het is typisch een work-around oplossing. Er lijkt soms een tegenstrijdigheid te bestaan: om switches consequent met Horcom te regelen is er een verfijnd netwerk nodig, waarin ieder subsignal zijn eigen route krijgt. Voor het communiceren met drivers is er een minder verfijnde structuur nodig waarbij één enkele horcom signaal route een driver aandoet. (Mogelijk zal er wel altijd een grijs gebied zijn waarin een setting kan worden beschouwd als een switch, of als een gewone setting.) Er is ook een idee om input selectie switches te implementeren in de software als open/close switches aan de input zijde, waarvan er tegelijkertijd slechts één open mag staan. Zo'n switch kan dan soms reduceren tot een output die slechts verbonden is met één switch. De combinatie connection manager / horcom is niet bepaald gelukkig. De huidige connection management component ziet eruit als een kind met een waterhoofd. Ook dat is een reden om het hele concept te herzien. Inmiddels is de connection-search-method behoorlijk geoptimaliseerd, zijn computers snel, en zijn er design patterns beschikbaar voor gegevens uitwisseling (bijvoorbeeld observer en callback). Ook zouden iteratieve methoden kunnen worden gebruikt, in plaats van call stacks. dus ik zou zeggen gebruik het Horcom model in de TV voor connection management, het opzetten van upstream directed communication die afkomstig is van transformatie componenten, en upstream en downstream directed information die afkomstig is van management componenten, of die ervoor bestemd is. Ook, als je data meestuurt met het signaal naar de volgende component, zou je een oplossing kunnen kiezen die verbergt of er horizontaal of verticaal, stroom opwaarts, of met de stroom mee gecommuniceerd wordt. Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison-Wesly, ISBN Voordat de Horcom macro's gemaakt waren, programmeerde ieder zijn eigen horcom nodes, daarna was het een kwestie van een paar regels macro's. Dit had een eigenaardig effect. Voor veel programmeurs werd het horcom netwerk een geheimzinnige black-box die op magische wijze zijn nuttige werk deed. Het was niet langer een gemeenschappelijk concept. Dank zij de macro's was ook nog eens knap lastig geworden om bijvoorbeeld breakpoints te zetten, en ook adequaat loggen om een fout te ontdekken was een kunst geworden. Toch was horcom vaak belangrijk bij het Pagina: 36 / 230

37 1 Inleiding 1.4 Televisie, de software analyseren van fouten. Bij voorkeur werd daarvoor een deskundige ingeschakeld. Ook werden vaak toch maar alternatieve foutanalyse methoden gebruikt. Mocht het ooit komen tot een redesign van horcom dat zouden debug en logging faciliteiten op toegankelijke wijze geïmplementeerd moeten worden. Bij Philips-CE in Brugge was horcom een gedeeld concept. In het gezamenlijke CE/SC project TvDoc, werden de horcom macro's ontwikkeld, die daarna in het gezamenlijke Jaguar project gebruikt werden in de eerste volledig digitale TV (op de meeste inputs en outputs na). In het Jaguar project werd horcom een black-box voor het SC team, maar was het nog steeds een transparant concept voor het CE team, ondanks de macro's. Momenteel is NXP verantwoordelijk voor deze connection management onderdelen. Mogelijk in de toekomst laat hij dit over aan zijn klanten. Maar zoals het er bijstaat (anno 2008) draagt NXP niet bepaald een gespreid bed over aan die klanten Power modes en hardware die geen deel uitmaakt van het audio/video platform Als je erover nadenkt besef je dat het netwerk model van Horcom onvoldoende is om alle hardware te besturen. Een analogie: het licht knopje van de fabriekshal is niet te vinden in een productielijn. Het blijkt dat hardware vaak hiërarchisch is opgebouwd, en niet alleen maar een netwerk structuur heeft. Een component die zowel de DAC's (digital to analog converter) als de ADC's bevat bevindt zich zowel aan de voorzijde als aan de achterzijde van het transformatie netwerk, en heeft een eigen power management, waaraan mogelijk geen recht wordt gedaan als uitsluitend actie wordt genomen als een ADC of DAC benaderd wordt in het netwerk. Er is software die bestaat uit meerdere componenten: de Power componenten, die ervoor zorgen dat precies die hardware en software opgestart is als nodig is voor de onderhanden taken. Hierbij kunnen typische Horcom drivers en hardware aangestuurd worden, maar ook kunnen hardware en drivers worden aangestuurd die niet met Horcom bediend worden. Er zijn diverse power modes, waarbij hardware wel of niet is opgestart. Als 's nachts het elektronisch programmablad wordt opgehaald, hoeft het scherm niet aan te staan. In standby mode is bijvoorbeeld de stroom afgehaald van MIPS en TriMedia. Je kunt de TV gebruiken als radio, zonder video. Als je een TV uit standby mode haalt wordt de audio/video mode bereikt via een serie fasen om te zorgen dat niet in één klap alles aanstaat, want dat geeft werkelijk een klap, waarbij elektronica kan beschadigen. Ook uitzetten loopt om dezelfde reden bij voorkeur via fasen. Ook deze fasen worden power modes genoemd. Goed planmatig opstarten is waarschijnlijk ook nuttig om te garanderen dat de elk elektronisch onderdeel na het opstarten in de gewenste start toestand staat. Enige voorbeelden van hardware buiten het A/V platform: afstandbediening lezen, de wekker, de stroom voorziening, het file system, alle communicatie met internet, USB, harde schijven zonder dat daar streaming bij betrokken is. Ook deze hardware wordt bedient met drivers, en valt buiten het competentie gebied van Horcom. Pagina: 37 / 230

38 1 Inleiding 1.4 Televisie, de software Pumps en pump engines Van ouds her werkt embedded software met een "main loop" waarin events (messages) worden gelezen en afgehandeld. State variables en message types worden gebruikt om de procedure te determineren die de message verwerkt. Messages ontstaan door interrupts, en door het gebruik van de remote control, en ze worden gegenereerd door procedures in de main-loop. De messages komen meestal in een first-in first-out lijst. Soms is er geen lijst, dan mag in een doorgang van de mainloop hoogstens één message gegenereerd worden, en wel als laatste actie. Momenteel, nu de processors krachtig zijn en geheugen geen probleem, is één van de belangrijkste onderdelen van de ondersteunende component os het message systeem. In de message queues van de televisie kun je messages sturen die naast enige data het adres bevatten van de procedure waaraan de message is gericht. Per thread is er een main loop die de messages uit één queue afhandelt. Als zo'n message aan de beurt is dan wordt de betreffende procedure aangeroepen, met de parameters die in de message staan. Dit is meen ik afgekeken van MS Windows 3.1. Een message van een bepaald type wordt een pump genoemd. De message queue en de thread die de message afhandelt wordt pump-engine genoemd. De pump en pump-engine definitie stamt uit de MG-R poot. De software componenten communiceren met elkaar door procedure calls via hun interfaces. Methods in de koala interface worden rechtstreeks aangeroepen en niet via dit message mechanisme. Calls naar COM componenten, bijvoorbeeld remote procedure calls (RPC), worden in proxy/stub modules opgelost met behulp van synchronisatie middelen. Ik weet niet of dit is opgelost met de pump implementatie van de component os, maar ik vermoed van niet. Messages worden meestal gestuurd en ontvangen door procedures die tot dezelfde component, en liefst dezelfde source module, behoren. Zo wordt de uitvoering van een langdurig karwei opgesplitst in een serie kortstondige brokken, die door dezelfde pump-engine worden uitgevoerd. De afhandeling van een functie uit een koala of com interface wordt op deze manier in stukjes geknipt. Meestal worden meerdere karweien tegelijkertijd door dezelfde pump-engine afgehandeld: meerdere interface functies, van meerdere interfaces worden in stukjes geknipt. Het effect van een pump-engine is daarom voor een groot deel: non pre-emptive multitasking. Non pre-emptive multitasking met messages doet denken aan non-determinisme. Dat zou in overeenstemming zijn met de ontwikkelmethoden voor embedded software: met de DFD's (data flow diagrams) die sommige methoden gebruiken die het non-determinisme min of meer maximaliseren en het in ieder geval in kaart brengen. Embedded software engineers houden vooral daarom van non-determinisme omdat ze het om zeep kunnen brengen: het geeft je keuze mogelijkheden voor prioriteiten en daarmee voor volgorden, zodat real time doelen kunnen worden gehaald. Prioriteiten worden gerealiseerd door pump-engines te koppelen aan componenten, en prioriteiten aan pump-engines. Maar door de enorme hoeveelheid componentjes en message types in Tv's blijft er nog zeer veel volgorde ongedetermineerd. "Structured Development for Real-Time Systems Volume 1" van Paul T. Ward & Stephen J. Mellor. (1985 Prentice Hall ISBN ) (volume 2 en 3 zijn er ook). "Strategies for Real-Time System Specification" van D.J. Hatley & I.A. Pirbhai (Dorset House Publishing; New Ed edition (1 Jan 1988) ISBN: ) Naast non determinisme zijn er in embedded software ook constructies waarbij de prioriteiten bijdragen aan de logica, in het ene geval werkt het programma logisch correct, in het andere geval Pagina: 38 / 230

39 1 Inleiding 1.4 Televisie, de software fout. Het is de kunst om in de mix van keuzevrijheid en volgorde voorschrift, de brokjes programma-doorloop te voorzien van optimaal werkende prioriteiten: als de afhandeling van een message logisch moet vooraf gaan aan die van een andere, dan mag zijn prioriteit zeker niet lager of gelijk zijn. Een elementair voorbeeld: een implementatie van a=2*(b+1) a = b; (1)... a = a + 1; (2)... a = a * 2; (3) Na uitvoering van statement (1) wordt statement (2) uitgevoerd door afhandeling van message (m1) en statement (3) door afhandeling van message (m2). Als iedere message afgehandeld wordt in zijn eigen message queue, dan moet message (m1) afgehandeld worden met een grotere prioriteit dan message (m2), en message (m2) liefst met een lagere (of gelijke) prioriteit, dan de procedure die de messages verstuurde. Er zijn twee soorten messages: de timed message: de afhandelende procedure moet worden aangeroepen zodra de tijd verstreken is. De untimed message: de afhandelende procedure moet aangeroepen worden zodra de gelegenheid zich voordoet. Timed messages gaan vóór untimed messages. Overige prioriteiten worden geregeld met thread priorities. Een belangrijke toepassing van timed messages is het polsen waarmee hardware registers in de gaten worden gehouden. Er lijkt momenteel een tendens te zijn om dit te regelen met interrupts, maar de embedded software engineers staan enigszins wantrouwend tegenover interrupts: we houden meer registers in de gaten dan waarvoor interrupts bestaan, en bovendien, in elke chipset zijn er weer andere. Polsen: Eigenlijk gebruikten we de term pollen. Het Engelse to poll is in feite, althans volgens mijn woordenboek, periodiek een steekproef nemen (periodiek een deelverzameling doormeten). Wij gebruikten het dus om periodiek een register te testen op verandering, dus zonder een deelverzameling te trekken. Daarnaast zijn er twee opties voor een message type Het meest gebruikt is de optie dat een message van een bepaald type een eventuele voorgaande message van hetzelfde type overschrijft. En er is de andere optie: alle messages van een bepaald type moeten worden afgehandeld. Er worden zeer veel replacing message types gedefinieerd, in plaats van weinig queuing message types, om de inschatting van de grootte van de message queue zo nauwkeurig mogelijk te kunnen doen. Een message kan door de procedure die de message verstuurd, worden geplaatst in de message queue van een bepaalde thread. In het jargon wordt de message queue van een thread een pump engine genoemd. Met een dergelijke resource begint de thread nog niet op een task te lijken. De component os spreekt echter over tasks, en niet over threads. Meestal gebruikt een component één (hoofd) task met message queue, zodat andere synchronisatie mechanismen, zoals semaphores, critical regions en dergelijke zoveel mogelijk vermeden worden. Pagina: 39 / 230

40 1 Inleiding 1.4 Televisie, de software Als een (koala) component een procedure aanroept in een component die een andere task gebruikt, dan maakt de caller gebruik van een synchronisatie waarbij de task van de called component wordt stilgelegd nadat de lopende message is afgehandeld, de task van de caller wacht hierop. Dan wordt de call gepleegd, en daarna wordt de task van de called component weer geactiveerd. Remote Control signalen, signalen van knoppen die op de TV ingedrukt worden, audio en video veranderingen, enzovoort. Al deze signalen veroorzaken een message op een pump engine. Al het pollen (periodiek controleren van een register) wordt geregeld met timed messages. Komt uit dat pollen een signalering voort, dan is ook dat ook weer een message. Je hoeft niet altijd te pollen, vaak kun je of soms moet je gebruik maken van hardware interrupts. Dan stuurt de interrupt routine een message. De invloed op de interfaces van de componenten: Bij de meeste requests van een client component aan een server component wordt er geen waarde als antwoord geretourneerd, maar wordt later een callback procedure in de client aangeroepen door de server, met de afloop van het request. Soms biedt een interface een hybride oplossing. Dan wordt er een direct een antwoord geretourneerd als dat mogelijk is, maar anders wordt er een callback procedure aangeroepen. Dit is vaak nodig omdat de afhandeling van een request vaak in stukjes wordt geknipt met behulp van messsages. Soms is dat nodig omdat het tijd kost om iets te meten, soms is het wenselijk omdat gecommuniceerd wordt met een functie in een andere thread. Koala interfaces bieden geen rechtstreekse faciliteiten voor callback. Er is de mogelijkheid om naast een interface die nodig is voor de client en waarin de functie aanroepen staan naar de server, een notify interface te gebruiken die nodig is voor de server, waarin de functie aanroepen staan naar de client. In Koala is dit volkomen symmetrisch opgelost. Callback is een functie aanroep via de notify interface. Merk op dat callback iets anders is dan een notificatie, want het initiatief van de notificatie ligt bij de server, de server notificeert spontaan, en niet als uitgesteld antwoord op een request MIPS recovery Als de MIPS crasht blijkt dat de transformatie laag gewoon autonoom doorwerkt, onder het motto managers, waarvoor heb je ze nodig. Er is een reboot methode bedacht om de MIPS weer op te starten, zonder onderbreking van de transformatie laag. Daartoe wordt regelmatig de status weggeschreven naar NVM (Non Volatile Memory). Bij het opstarten voor recovery wordt het schrijven naar hardware registers of het commanderen van de TriMedia componenten tegengehouden, zodat de transformatie laag blijft werken. De status opvragen van de transformatie laag blijft wel mogelijk, dat moet zelfs. Deze modus wordt aangehouden totdat de MIPS weer bij de tijd is. Zo'n situatie zou zich niet voor moeten doen, maar helaas is er een een TV in de markt geweest die dit in het begin regelmatig deed. Tijdens de crash reageerde de TV niet op opdrachten met de afstandsbediening, of op de toetsen op televisie. Dit werd doorgaans gemerkt door de gebruiker, want de crash was meestal een verkeerde reactie op een signaal van de afstandsbediening, waarna de gebruiker extra hard en vaak, maar wel te vergeefs, op knoppen drukte om te TV te laten doen wat hij wou. Tegen de tijd dat de TV weer reageerde drukte de gebruiker vaak op willekeurige toetsen, waarna de TV ook niet deed wat hij wilde. Pagina: 40 / 230

41 1 Inleiding 1.4 Televisie, de software Test binaries Tijdens ontwikkeling worden niet alleen binaries gemaakt voor het product zoals dat uiteindelijk in de tv komt, er is een binary voor het audio/video platform, veel componenten in het platform worden getest met het platform harness, omdat hiermee de interfaces naar en van het platform kunnen worden gekoppeld aan een script, of kunnen worden gebruikt via een menu op de tv. Veel interfaces zijn vast verbonden met een component, daarom kun je er vrij eenvoudig een component mee testen. Dan zijn er nog binaries die een test-harnas zijn van een enkele component of een enkele source module, en die mogelijk op een desktop of laptop getest kunnen worden: de unit tests. Er zijn in principe twee methoden om software te laden en op te starten in een TV. Je kunt software uploaden naar het flash geheugen van de TV en dan voortaan van daaruit starten. Upload gebeurt met met het installatie tool. Er is ook een methode om software van een externe source rechtstreeks te laden in het main memory van de TV. Beide methoden worden gebruikt. De laatste methode wordt bijvoorbeeld gebruikt door remote debuggers. Zolang software getest wordt zijn er dus twee methoden om de TV te starten: wel of niet uit flash memory. Zoals eerder vermeld, is er een tijd geweest dat we werkten met component tests op de televisie, waarbij iedere component was ingebed in zijn eigen executable: het test-skeleton. Deze methode bleek dermate onderhoudsgevoelig dat we ermee zijn gestopt. Een belangrijk deel van onze component tests worden uitgevoerd in één executable: het platform test-harness. Slechts enkele tests worden uitgevoerd op de PC, in een eigen test-harness, voor tests die uitgevoerd kunnen worden zonder TV hardware Tools Behalve de software die moet worden uitgevoerd in een televisie, zijn er nog allerlei tools. Koala en de MIDL zijn reeds genoemd. Voor elk van de 3 soorten processors is er een C cross compiler/linker, in ieder geval voor voor de MIPS is er een debugger. Ook wordt gebruik gemaakt van een native compiler op de desktop of laptop, om componenten te testen en voor de tools die lokaal draaien. Verder wordt er gebruik gemaakt van een aantal script talen zoals perl. Er is software gebruikt om C files te controleren op foute constructies, en overtredingen van coderingsregels. De static analyser die ik heb meegemaakt was QA-C. Er is een flow-charter voor het tekenen van structuur diagrammen (Microsoft visio) Er is software om vanaf een PC de registers in de TV te lezen en te schrijven. Er is een installatie tool om de software op de tv te installeren en te onderhouden, en een script op de PC om deze software te verzamelen. De software op de TriMedia's wordt uitgevlooid en getest met hulp van softwareinstrumentatie. Om het realtime ritme te handhaven print men niet méér dan voor de analyse noodzakelijk is, en past men een compressie techniek toe op de gegevens die gelogd worden. Hiervoor wordt gebruik gemaakt van een pre-compiler op de PC, en een tool dat binaire nummers in de log-file vervangt door tekststrings, en het resultaat converteert naar een excel file. Er is capture software om gegevens uit de audio en video stromen zichtbaar te maken Er is een tool om een test-harness te genereren bij een Koala component. Vanaf een PC kan men dank zij RPC toegang krijgen tot een component die draait op de MIPS via Pagina: 41 / 230

42 1 Inleiding 1.4 Televisie, de software een koala of com interface. Het generatie tool genereert stubs voor de MIPS software, en symbol files voor een programma op de PC dat test-scripts kan uitvoeren, en een testrapport genereert. Het generatie tool genereert ook menu's om interface functies aan te roepen met behulp van de afstandsbediening. Er is een programma op de PC dat het NVM (non volatile memory) kan lezen en schrijven Time-doctor wordt gebruikt. Er is software voor het specificeren van gebruikers menu's. Er is software om remote controls aan te sturen vanaf een PC. Er is software om vanaf een PC pattern generators aan te sturen e.d. Waarschijnlijk ben ik niet volledig. Veel van deze programmatuur wordt verstrekt door derden, sommige tools zijn home-made van NXP, en sommige zijn home-made van onze klant. Vaak is er een overlap van programma's die gemaakt waren voor persoonlijk gebruik, en later tot handig tool voor allen werden verordend. Ook is er overlap omdat een klant een eigen programma hanteert en NXP ook een tool beschikbaar stelt. Soms gebruiken de hardware ontwerpers andere gereedschappen dan de software ontwerpers. In de praktijk kan men zich niet altijd houden aan zijn eigen methode en gereedschappen. Bijvoorbeeld bij een probleembeschrijving hoort een beschrijving van het scenario dat leidt tot het probleem, en een beschrijving van het waargenomen fenomeen. Deze beschrijvingen refereren aan de gebruikte gereedschappen, hun invoer en hun uitvoer. De ontdekker van het probleem en de oplosser moeten allebei het gebruikte gereedschap kennen Version control Momenteel ( ) wordt binnen NXP een Version Control system (Continuous / Synergy ) ter beschikking gesteld, waarin voldoende software is opgenomen voor een platform build. Software voor een product build wordt beschikbaar gesteld in een folder op een shared disk. Hier worden door de build manager recente generaties bijgehouden, compleet met product binaries (executables). Dit betreft zowel optimized binaries als ook debug binaries, en een tussenvorm waarin slechts ingebouwde asserts worden getest. In deze product info-trees mag je niet wijzigen, als je wilt wijzigen dan moet je een lokale kopie maken. Met deze constructie hoopt men de synchronisatie-tijd en de build tijd voor ontwikkelaars enigszins te reduceren. Koala doorzoekt de gehele folder tree tijdens een build, hoe kleiner de tree hoe sneller de build, vandaar dat de folder structuur in het revision control system getrimd is voor platform (test harness) builds. Ieder team heeft zijn eigen centrale revision control systeem, Daarin komen alle benodigde packages, ook die van andere teams. In ieder package is ieder project een branch. Zo is er ook in iedere folder en iedere file een branch per project. De baselines van packages van andere teams worden overgenomen met behulp van DCM (distributed configuration management), en het eigen package wordt verstuurd met behulp van DCM. Iedere branch kan subbranches hebben die later weer met elkaar vergroeien tot main-branch, als de versions van de tips gemixt worden tot een resulterende version. Package versions en folder versions bevatten een set elementen. Als de set veranderd wordt een nieuwe version gemaakt van de folder. Pagina: 42 / 230

43 1 Inleiding 1.4 Televisie, de software Instrumentation main.c sub1.c #include <stdio.h> #include <stdlib.h> extern void fsub1(void); extern void fsub2(void); int main(int argc, char *argv[]) { int i; /* normally an endless loop */ for (i=0; i<3; i++) { fsub1(); fsub2(); system("pause"); } return 0; } #include <stdio.h> #ifdef ENABLE_PRINT #define PRINT(p) printf p #else #define PRINT(p) #endif void fsub1(void) { static int a=0; static int b=1; /* incredibly complex way to determine the currrent value of a: */ a++; PRINT (("a = %d\n",a)); /* the same for b */ b++; PRINT (("b = %d\n",b)); } sub2.c #include <stdio.h> #ifdef ENABLE_PRINT #define PRINT(p) printf p #else #define PRINT(p) #endif void fsub2(void) { static int c=2; static int d=3; /* obtain c */ c++; PRINT (("c = %d\n",c)); /* obtain d */ d++; PRINT (("d = %d\n",d)); } Een simpel project C:> build product,optimize successfully C:> touch sub1.c successfully C:> build product,optimize,enable_print successfully C:> Een manier om sub1.c te laten loggen. main.c sub1.c #include <stdio.h> #include <stdlib.h> extern void fsub1(void); extern void fsub2(void); int main(int argc, char *argv[]) { int i; /* normally an endless loop */ for (i=0; i<3; i++) { fsub1(); fsub2(); system("pause"); } return 0; } #include <stdio.h> #ifdef ENABLE_PRINT #define PRINT(p) printf p #else #define PRINT(p) #endif void fsub1(void) { static int a=0; static int b=1; /* incredibly complex way to determine the currrent value of a: */ a++; PRINT (("a = %d\n",a)); /* the same for b */ b++; PRINT (("b = %d\n",b)); } sub2.c #include <stdio.h> #ifdef ENABLE_PRINT #define PRINT(p) printf p #else #define D_PRINT(p) printf p #define PRINT(p) #endif void fsub2(void) { static int c=2; static int d=3; /* obtain c */ c++; PRINT (("c = %d\n",c)); /* obtain d */ d++; D_PRINT (("d = %d\n",d)); } Tijdelijke wijziging om variable d te loggen. Vlak voor ik met pensioen ging werd een ontwikkel-omgeving gepresenteerd voor MIPS software, Pagina: 43 / 230

44 1 Inleiding 1.4 Televisie, de software waarin een debugger ontbrak. Later werd GDB gepresenteerd als debugger. Deze debugger is beschreven in een erg dik handboek, en er was een half A4-tje waarin werd uitgelegd hoe je vanaf een PC software in een televisie kon debuggen. Inmiddels werd op grote schaal gebruik gemaakt van logging (instrumentatie), dat voor de TriMedia software reeds standaard was. Ondertussen waren de voordelen ontdekt: test-werkplekken kunnen beter gedeeld worden met kort lopende sessies waarin gegevens in een log-file geplaatst worden. Sessies met een debugger houden een testwerkplek langdurig bezet. De debugger werd slechts zelden gebruikt. Er zijn wel regels voor het wel of niet gebruiken van instrumentation. Nadat je het hebt gebruikt voor debugging moet je de logging uitschakelen, en verifiëren of de software zonder logging correct is. De software moet worden overgedragen, zonder werkende logging. Dit laatste is niet helemaal waar. Sommige boodschappen werden geacht nuttig te zijn voor allen, of in ieder geval velen. Er is daarom een categorie console messages die getoond worden in assert mode, maar de gewone console messages worden adhoc ingebouwd of naar behoefte geactiveerd. Instrumentatie wordt gebruikt voor een aantal redenen. Zonder garantie dat de redenen uitputtend zijn opgesomd geef ik de volgende: controle op volledigheid bij het testen (coverage) frequentie meting en doorlooptijd-tijd meting ten behoeve van tijd optimalisatie loggen ten behoeve van debugging en testen (white-box tests) signaleren van overtreding van preconditions, postconditions en invariants, met behulp van assert Alleen om de laatste twee redenen wordt instrumentatie gebruikt in de MIPS software. Logging en assert zijn rechttoe rechtaan met de hand ingebouwd, zonder generator, of aspect oriented programming Slot opmerkingen Alles stroomt Wat opvalt is dat er veel verhuisd en geherstructureerd kan worden: Er wordt verhuisd tussen besturingsniveau en transformatie niveau (wel/niet delegeren) Oplossingen verhuizen van Koala componenten naar COM componenten Het binden van diversity parameters worden verhuisd van compilatie-tijd naar uitvoerings-tijd visa versa Er wordt verhuisd in de folder en package structuur Executie wordt verhuisd van de éne prioriteit naar de andere Een oplossing kan zelfs worden verhuisd van uitvoerings-tijd naar ontwerp-tijd of omgekeerd. Er wordt waarschijnlijk veel tijd aan herstructureren en verhuizen besteed, ik weet niet goed hoe je het kunt vermijden, maar ik weet wel dat dit werk is dat niet direct leidt tot vooruitgang. Waarschijnlijk is het werk dat bijdraagt aan de perioden waarin niets lijkt te gebeuren in Weinberg's Law of Twins. Echte voortgang, dat zijn de krenten in de pap, maar de krenten kunnen de pap niet missen. Wil je dat meer progressie zich manifesteert, dan zou je dat misschien kunnen bereiken door het verhuizen en herstructureren te beperken of te verbieden. Maar de structuren die er zijn worden dan misschien een keurslijf, waar nogal wat work-around overheen puilt, zoals bijvoorbeeld met Horcom is gebeurd. Let wel, vaak is er eerst de work-around, en dan pas het inzicht dat herstructureren misschien beter zou zijn geweest. Daarna kan er pas geïnventariseerd en beslist worden over opnieuw doen. In actuele situaties geldt vaak: het zit er al in en het werkt. Pagina: 44 / 230

45 1 Inleiding 1.4 Televisie, de software Maar bij een nieuw project zou je elke keer kunnen beginnen met het opruimen van enkele uit de hand gelopen constructies. Door te herstructureren ben je bezig met de stuff en blijf of ga je de problematiek beheersen. Net als koffie drinken, kletsen met een collega, en opruimen, kun je het doen, als je het even niet ziet zitten of een beslissing wilt uitstellen. Sommige mensen zeggen dat mensen herstructureren om een stukje van zichzelf vast te leggen in hun omgeving, of in ieder geval om de omgeving naar hun hand te zetten, zodat ze zich er thuis voelen. Als de law of twins geldt, dan heb je herstructureren nodig om op een gegeven moment door te stoten, en is het te vergelijken met (lang) mikken voordat je schiet. Weinberg's Law of Twins : eigenlijk geldt hier: Wie een parel wil zien moet er zelf maar naar duiken. Maar ik zal toch maar een referentie geven. Ik vond de wet in Wikipedia (Engels). De verwijzing die daar bij staat: Weinberg, Gerald M. The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Dorset House Publishing Company, ISBN " Grenzen van een revision control system Versies van files, die direct of indirect uit elkaar voorkomen vormen in een klassiek RCS een DAG (Directed Acyclic Graph) Er is de aanname dat de versies ervan op een gestandaardiseerde manier elkaars wijzigingen kunnen overnemen (met een merge programma), en dat zo wijzigingen in de éne branch gemakkelijk kunnen worden overgenomen in een andere. NXP rekt dit idee op en veronderstel dat wijzigingen in het ene lid van een product familie op gestandaardiseerde manier kunnen worden overgenomen in een ander. Maar het zou kunnen dat er zoveel is gewijzigd tussen producten (zie ook het voorgaande: alles stroomt ) dat dit niet meer volledig opgaat. De praktijk moet uitwijzen of er nog een zinvol deel overblijft voor de gestandaardiseerde gegevensuitwisseling. In het verleden bleek vaak dat dergelijke uitwisseling zinvol is tussen redelijk verwante leden, en dat uitwisseling zinvol is tussen dat deel van de code dat nauwelijks gewijzigd is. In het voorgaande: alles stroomt worden ontwikkelingen geschetst waarvan de herstructurering niet vastligt in de structuur van een version of revision control system. Al zijn de resultaten van dergelijke ontwikkelingen wel over te dragen met standaard merge, copy en delete, toch herken je de herstructureringen meestal niet door puur naar de ontwikkeling van een branch te kijken. Alleen naamswijzigingen en verplaatsingen in de folder structuur worden immers geregistreerd als herstructureringen. Ontwikkel methoden Bij NXP waren ontwikkelmethoden een beetje een verwaarloosd. Voor je met coderen begint moeten de interfaces beschreven zijn en moet er een component description zijn. Deze beschrijvingen zijn echter meer implementatie en gebruikers handleidingen dan ontwerp documenten. In het begin moest er een Visio plaatje (schema) gemaakt worden van een component, later werd het plaatje gegenereerd uit de cd file. Er is geen voorschrift om een ontwikkel traject te doorlopen dat eindigt met de juiste componenten en interface structuur. Het enige dat er is is een plaatje met blokken: applicaties, middleware, operating, platform en dergelijke en heel misschien een aanduiding waar de clients zitten waar de servers ervan. Niet echt refutable stuff, meer een hoofdstuk indeling. Dit haalde het niet bij de stappen (acht of zo) in ORM, die allen een model opleveren. En ook niet bij de UML schema's waarmee fasen en facetten van het object georiënteerd ontwerpen worden beschreven. Al evenmin bij de tweedeling probleem beschrijving en probleem oplossing bij de Pagina: 45 / 230

46 1 Inleiding 1.4 Televisie, de software "problem frames"van Michael Jackson. Nu we leven in een tijdperk van hergebruik en onderhoud van het bestaande is het mogelijk lastig om te spreken over ontwikkelfasen, en beter om te spreken over een aantal modellen die je bijhoudt. Misschien doe je dat per project toch ongeveer in een bepaalde volgorde. Zonder echte ontwikkel methoden, begin je misschien al te snel te programmeren als je een idee hebt of de weg ziet naar een oplossing. Methodiek zou het idee moeten vervolmaken, integreren, mogelijk weerleggen, herstructureren, of weer ideeën uitlokken. Een methode is de transpiratie na de inspiratie. Aangezien de werkwijze van NXP leidend is bij mijn ontwerp van een revision control systeem is de invloed van het volgen van een ontwikkelmethode minimaal. Toch stel ik mij voor dat hergebruik in product families leidt tot kleine reeksen bewerkingen van model onderdelen. Op zijn simpelst: eerst wijzig je een schema, dan een document, dan een testscript, en dan een source module. Op enig moment is een deel van zo'n ontwikkelreeksje klaar, en is er een rest deel te gaan. Omdat oplossingen ontstaan in wisselwerking tussen kennis intern in het hoofd en extern in de modellen, is de volgorde waarin de (extern buiten het hoofd) modellen worden bijgewerkt boterzacht. Bovendien zijn er allerlei confrontaties (in gebruik nemen, reviews, tests) die tot volgorde afwijkingen kunnen leiden. De toestand van zo'n reeks wordt bepaald door wat is afgevinkt als klaar, en dat is niet altijd aaneengesloten, en startend met de eerste volgens de formele volgorde. De toestand van het product wordt dan bepaald door de toestanden van de reeksjes. Alleen al door te spreken over de toestand van het product lijkt dit een onderdeel van configuration management, en zou je na moeten gaan wat de bijdrage van een version control system zou kunnen zijn. Maar niet in dit schrijfsel dus: mijn werk bij NXP leverde onvoldoende use-cases. Vaak werden document, source code en testscript gezamenlijk gewijzigd en overgedragen. Alleen bij echte nieuwbouw was sprake van acceptatie procedures met min of meer harde volgorden. Het idee van de wisselwerking tussen kennis in het hoofd en kennis in de wereld vond ik in de Nederlandse versie van: Donald Norman, The Psychology of Everyday Things, vertaling: Prof. dr. A.J.W.M Thomassen, Dictatuur van het design, A.W. Bruna Uitgevers B.V. Utrecht, 1990 ISBN Een voorbeeld. Een uiterst simpel fictief ontwikkelingsmodel. Er moet een flow diagram ontwikkeld worden. De drie ontwikkel fasen zijn: eerst bepaal je de blokken, dan de verbindingslijnen, en tenslotte de teksten. Tijdens een nieuwe ontwikkeling wordt strikt volgens deze methode gewerkt. In de repository zie je dan ook eerst versies met alleen blokken, dan is er een mijlpaal, (een hoera snapshot zeg maar), en daarna komen er versies met blokken en lijnen, en tenslotte komen er versies waarin ook teksten staan. De diagram versies die gemarkeerd zijn met een mijlpaal worden als waardevolle modellen beschouwd, met bestaansrecht vanwege de informatie die ze benadrukken. Reeds in de tweede fase, als er lijnen getrokken worden zie je dat soms blokken verschijnen, verdwijnen, of verplaatst worden, en in de derde fase kunnen er ook correcties optreden op blokken en lijnen. En tenslotte wordt er onderhoud gepleegd op het uiteindelijke resultaat, met wijzigingen op alle ingrediënten. Een reversed engineering tool zorgt ervoor dat uit een volledige versie een model met uitsluitend blokken, en een model met blokken en lijnen gemaakt wordt. De modellen die Pagina: 46 / 230

47 1 Inleiding 1.4 Televisie, de software gemaakt worden met het reversed engineering tool zijn geen source code. In een source code revision control systeem horen ze strikt genomen niet voor te komen. Up-to-date zijn daarin dus op een gegeven moment uitsluitend volledige schema's, en verouderd zijn daarin de schema's met alleen blokken, en de schema's met blokken en lijnen. Zelfs als je de reversed engineering modellen opneemt in de repository dan zijn het versies van een andere file dan de source file. Eigenlijk zijn de blokken modellen ook geen versies van elkaar, omdat ze niet door update uit elkaar voortkomen. Je zou ze in de repository willen plaatsen zodat ze beschikbaar zijn voor mensen die niet over het tool beschikken, bijvoorbeeld omdat ze in een ander team werken. Conclusie: voor een volledige verzameling use-cases voor een repository zou je een aantal ontwikkel- en onderhouds- methoden moeten beschouwen. Use-cases die voortkomen uit ontwikkel methoden zullen soms leiden tot een regel voor het gebruik van een repository, soms tot een requirement voor de repository, en soms tot een verzoek tot aanpassing van de tools van de ontwikkel methode. Het bovenstaande leidt bijvoorbeeld tot de regel: Zodra een mijlpaal is gepasseerd pas je reversed engineering toe en plaatst het resultaat in een nieuwe file in de repository. Het wordt van die file de eerste versie. Een requirement voor de repository: files die geen source file zijn moeten gefaciliteerd worden. Een voorstel om details van een ontwikkelmethode aan te passen: zie het volgende voorbeeld. Een tweede voorbeeld. In de jaren negentig heb ik gewerkt met een IDE voor het maken van C code. Deze IDE bevatte een wizard voor het generen van initiële C source code voor een aantal soorten applicaties. Er zijn bijvoorbeeld DOS command line applicaties, ActiveX applicaties, MFC applicaties COM applicaties en dergelijke. De wizard leidt je door een menu en genereert dan een aantal files met initiële code. Deze files bevatten vaak een comment regel waarin iets staat als insert here your code:. Het hele gegenereerde kun je beschouwen als source code. Op een gegeven moment ontdekte ik dat je het process kunt herhalen, zelfs als je eigen code al hebt ingevuld, en je de applicatie hebt uitgebreid met allerhande eigen files. Bij dit herhalen kun je andere opties en waarden opgeven: je kunt ze onderhouden. Blijkbaar worden de oorspronkelijke menu keuzen en velden in de wizard met reversed engineering gereconstrueerd uit de gegenereerde code, zodat je het menu kunt aanpassen, waarna opnieuw initiële code wordt gegenereerd, die daarna in het geheel de oorspronkelijk gegenereerde code vervangt. Bij bepaalde soorten applicaties was het genereren ook nog eens modulair, en complex: bijvoorbeeld voor elk menu kon je de wizard aanroepen, of voor elk window. Als je daar met mijn ogen naar kijkt, en misschien ook als je ernaar kijkt met de ogen van een configuration manager, dan kom je tot het volgende: de keuzen en de ingevulde velden in de menu's van de wizard zijn samen de source code. Deze code zou je liefst sec willen opslaan in de repository in één of meer files, en eventueel terug halen in de wizard voor bewerking. Door ze in source files op te nemen zijn de opgegeven keuzen en waarden identificeerbaar geworden. De gegenereerde files zijn geen source en moeten liefst niet gemengd worden met source code. Dus geen comment: /* plaats hier uw code: */ maar in plaats daarvan #include <uw-code>. Dit zijn typisch aanpassingen in de details van deze minimale? ontwikkelmethode. Onder omstandigheden wil je misschien het genereren uitstellen en daar een build procedure voor gebruiken, in plaats van de instant generatie van de wizard. Het zal voorstelbaar zijn dat het wijzigingen van de parameters en opties dikwijls geen standalone wijzigingen zijn, vaak moet ook de eigen code aangepast worden. Pagina: 47 / 230

48 1 Inleiding 1.5 Televisie, de hardware 1.5 Televisie, de hardware Voor ons bestaat een televisie uit een kabinet, met daarin een LCD of plasma scherm met toebehoren, een voeding, een infrarood oog, en een paar luidsprekers, en uit een PCB (printed circuit board), soms twee PCB-'s, en een enkele keer drie. Het main-board bevat de tv chip van NXP, een tuner, een channel decoder, flash memory, (onverslijtbaar) NVM, chips van klanten, in en uitvoer pluggen, een houder voor een CI-card enzovoort. Het tweede board bevat pluggen voor de zijkant of de voorkant van de TV. Zelden wordt er door een klant gebruik gemaakt van een bolton board, met extra hardware. Het kan gebeuren dat een main-board combineerbaar is met meerdere side-boards, of een side-board met meerdere main-boards. Bij een boardset horen uiteraard connectors en kabels om de boards onderling te verbinden, en om ze te verbinden met het kabinet. Zo'n board of boardset is een reference boardset als het gemaakt is door NXP of een design-in boardset als het gemaakt is door een klant. De boardset is vaak combineerbaar met meer dan één type kabinet, en een kabinet is vaak combineerbaar met meer dan één type boardset. Soms moet er geïmproviseerd worden: dan wordt er bijvoorbeeld een externe voeding gebruikt om de boardset van stroom te voorzien, of de uarts moeten elektrisch compatibel gemaakt worden met de com poorten van de PC. Sommige boards zijn niet volledig uitgevoerd, er missen pluggen, of sommige verbindingen staan niet op het board. Zo'n board is dan slechts bruikbaar voor een deel van de software tests. Af en toe kan het hardware team de functionaliteit van zo'n board uitbreiden. De chips op de boards hebben een versie nummer. Tijdens de duur van een project kan worden overgegaan naar een boardset met verbeterde chips, of naar een verbeterde boardset. Software Diversity wordt gebruikt om de overgang mogelijk te maken. De workarounds voor de oude versie kun je dan met diversity uitschakelen voor de nieuwe versie van de boardset. Soms als een project net is opgestart, en er nog geen eigen design-in boardset beschikbaar is, behelpt men zich met een boardset die er op lijkt. Het is zo dat adequate hardware niet altijd beschikbaar is op het moment dat software ontwikkeld wordt. Vaak worden tests dan uitgesteld tot een later stadium. Dan bestaat het team vaak uit minder software ontwikkelaars (vaak ook anderen), en meer testers. Invoer en uitvoer pluggen van een boardset: Antenne (invoer) Scart (invoer/uitvoer analoog video en audio, meestal 2 of drie, op een Europese tv) Cvbs cinch (één voor invoer, één voor uitvoer analoog video) Yc S-VHS connector (één voor invoer en één uitvoer analoog video) sound left/right cinches (enkele voor invoer, één voor uitvoer analoog audio) analoog mono sound input Pagina: 48 / 230

49 1 Inleiding 1.5 Televisie, de hardware headphone plug (uitvoer analoog audio voor koptelefoon) YpbPr of RGB cinches (één of twee sets invoer analoog video YPbPr: 3 cinches, RGB 5 cinches) VGA (invoer analoog RGB signaal, PC monitor signaal) Spdif (één of twee invoer één uitvoer digitaal audio niet gecomprimeerd, soms extra een optische invoer of uitvoer) Hdmi (meerdere invoer digitaal audio en video niet gecomprimeerd) Dvi (invoer digitaal video niet gecomprimeerd, PC monitor signaal) Usb (invoer digitaal audio, foto, video, gecomprimeerd. Ook wordt usb gebruikt voor programmatuur die door installatie tool wordt geïnstalleerd op flash memory) Ethernet (Interactieve communicatie, mail, digitaal audio, foto, video, gecomprimeerd, enzovoort) Houder voor een CI (common interface) cartridge waarmee een abonnement op pay-tv stations kan worden gerealiseerd. UART (een van de uarts wordt gebruikt om de standby processor te programmeren, de andere om een console verbinding met de MIPS te realiseren) JTAG (deze invoer/uitvoer is verbonden met een probe die via het local area netwerk is verbonden met een PC. Via JTAG kan logging informatie van MIPS en TriMedia naar een PC worden gestuurd, kan programmatuur worden geladen in MIPS of TriMedia, worden registers gelezen of geschreven, wordt geheugen bekeken of gewijzigd, breakpoints gezet of verwijderd, en dergelijke. Connector infrarood sensor (afstandsbediening) Connector voor aansturen scherm Connector voor aansturen speakers Connector voor voeding Optionele overige aansluitingen bijvoorbeeld: microfoon voor speech-control, zendertje om de remote control te laten piepen, en dergelijke Pagina: 49 / 230

50 1 Inleiding 1.6 De testplek 1.6 De testplek In een laboratorium staan lab-tafels. Dat zijn tafels met een extra schap, een transformator als elektrische isolatie, een zekering, een hoofdschakelaar, een aard-lek schakelaar, veel stopcontacten, en een aard-strip. Deze zijn ingericht als test-plekken. Meestal is een lab-tafel groot genoeg voor twee plekken. Zo'n test-plek bevat een televisie voor het testen van software. Bij iedere televisie hoort een probe, die bedoeld is om van buiten af geheugens en registers in de televisie te lezen en te wijzigen. Behalve de tv is er een desktopcomputer, die met zijn com poorten is verbonden met de uarts en met de probe, en mogelijk nog met een signaal generator die te bedienen is met behulp van een (test) script vanaf de desktop. Ik zal de computers op de testplek "desktop" noemen om ze te onderscheiden van "personal" computers, wat dan weer laptops of desktops kunnen zijn. Testplek desktops zijn allemansvriendjes, waar Ms-Windows op draait. Desktop en probe zijn ook verbonden via het intranet; het IP adres van de probe kan worden gelezen via een com poort. De probe is verbonden met de JTAG plug van de tv. De test desktop bevat veel gespecialiseerde tools die normaal niet op een bureau PC aanwezig zijn: een debugger, een tool om het NVM te lezen of te schrijven, om registers te lezen of te schrijven, om test scripts uit te voeren, om programma's en configuratie files over te brengen naar de tv, drivers voor afstandsbediening en voor patroon generators die aangestuurd worden via com poorten of USB en dergelijke. Er staan DVD spelers, die verbonden zijn met invoer pluggen, en een kleine analoge tv die verbonden is met een analoge uitvoer-plug van de tv. Op sommige tafels staat een home cinema set, die verbonden is met de spdif uitvoer. De antenne plug is verbonden met één van de interne televisie-netwerken van het laboratorium, met een patroon-generator, of met een mobiel tv stationnetje, dat analoog of digitaal uitzendt. Andere invoer pluggen zijn mogelijk ook verbonden met patroon-generators. Meestal is er een koptelefoon. Er zijn afstandsbedieningen voor de tv en de dvd spelers. Af en toe wordt een video recorder gebruikt, of is een canal-plus decoder verbonden met een scart. Er is een afstandsbediening op een voetstuk, die aangestuurd wordt via een com-poort van de desktop, en software die zo'n afstandsbediening aanstuurt. Incidenteel wordt een spelcomputer aangesloten, en soms is er een set met een settopbox. Vaak is er enige afscherming om te zorgen dat je elkaar niet stoort met een remote control. Kern van een werkplek zijn altijd de tv, de desktop, de probe, een dvd speler, een monitor, en twee afstandsbedieningen (één voor de tv en de monitor, en één voor de dvd speler). De andere apparatuur blijft korter of langer, al naar gelang de behoefte. Werkplekken die in gebruik zijn voor dagelijkse testen en overdrachtstesten, hebben een grotere kern van randapparaten. Ook werkplekken die specifiek zijn opgezet voor audio tests hebben een grotere kern. Een werkplek blijft meestal voor langere tijd ingericht met dezelfde televisie. Vaak zijn test-werkplekken niet persoonsgebonden en vaak zijn ze ook niet taak gebonden. Ze worden gedeeld door testers en ontwikkelaars. Dikwijls werkt een persoon of een team voor meer dan één project, en heeft dan zeker te maken met meer dan één test-werkplek. Meestal zijn er diverse tv's nodig binnen één project, bijvoorbeeld om te testen met verschillende kabinetten, of verschillende boardsets. Soms is het niet nodig om beeld of geluid waarnemingen te doen, of om pluggen in en uit te Pagina: 50 / 230

51 1 Inleiding 1.6 De testplek trekken, of apparaten aan en uit te zetten, een keuze menu te volgen op een dvd speler enzovoort. Dan wordt een tool als VNC gebruikt om vanaf je bureau de test desktop over te nemen en een test uit te voeren. Ook wordt dit tool dikwijls gebruikt als iemand aan zijn bureau uitzicht heeft op de testplek, zodat beeld en geluid gewoon kunnen woeden waargenomen. Af en toe wordt er een opstelling gemaakt met een webcam zodat iemand werkelijk remote tests kan uitvoeren. Veel van de hulp-apparaten zijn signaal generators. Dit geldt bijvoorbeeld al voor de DVD spelers. Bij een signaal generator horen signalen, voor de DVD speler zijn die afkomstig van dvd's. Voor patroon generatoren zijn dit patronen. De eenvoudige patroon generatoren bevatten een ingebakken hoeveelheid patronen, maar de meeste zijn programmeerbaar. Tv zendertjes moeten iets uitzenden. Er is dan ook een uitgebreide collectie aan patroon bestanden en multimedia bestanden beschikbaar op enkele file servers, en er zwerft een uitgebreide collectie dvd's door de lab ruimtes. Toen ik er wegging was blu-ray sterk in opkomst en werd er nog nauwelijks met video recorders getest. Alleen als specifieke video recorder problemen moesten worden opgelost, zoals variabele lijn en beeld frequentie, werd de recorder uit de kast gehaald. Pagina: 51 / 230

52 2.1 De basis In de zeventiger en tachtiger jaren had ik toegang tot de ICT bibliotheek van Philips Eindhoven. Hier hadden ze een kopie-service, waarbij ze maandelijks een blad met uittreksels distribueerden van tijdschrift-artikelen. De artikelen die je interessant vond kon je aankruisen, waarna ze een kopie van het artikel toestuurden. Zo heb ik in die tijd een klein persoonlijk archief opgebouwd van tijdschrift artikelen. Eén van die artikelen was Update Reconsidered van Ben-Michael Schueler. (Gepubliceerd in Architecture and Models in Database Management Systems G.M. Nijssen, (ed.), North Holland Publishing Company, 1977). Hierin wordt een lans gebroken voor opslag methoden waarbij niets wordt weggegooid. De methode om een oude waarheid te vernietigen door deze te overschrijven door een nieuwe wordt Aton update genoemd, de methode om diskruimte opnieuw te gebruiken omdat de file die er stond niet meer interessant is wordt Palimpsest genoemd, en het per ongeluk kwijtraken van informatie Alexandria update. Wie niet beschikt over het artikel kan de oorsprong van deze benamingen toch wel achterhalen, denk ik. Al deze updates zijn fout, we zouden geen informatie mogen weggooien, of kwijtraken. Voor mij was dit artikel een eye opener. Maar het was ook een intellectuele uitdaging, die ik met een voorbeeld niet tot een goed einde bracht. Dit schrijfsel is dus een herkansing. Recente artikelen over temporele databases zijn gemakkelijk te vinden dank zij Google; enkele gevonden namen: Christian S. Jensen", "Richard T. Snodgrass", artikelen die ik ooit van hen las: 2 Semantics of Time-Varying Information, Introduction to temporal database research. Hierin wordt onderscheid gemaakt tussen valid time en transaction time. Stel bijvoorbeeld dat ene Jansen leefde van 1933 tot 2003, dan is de periode de valid time, die begrensd wordt door twee gebeurtenissen (events), één in 1933 en één in Zelf ben ik geboren in Stel nu dat ik in 1983 hoorde dat hij in 1930 geboren was, en in 1995 hoorde ik dat hij in 1933 geboren was, en in 2007 dat hij in 2003 overleden was. Nu is er een transaction time over de periode , één gedurende , en één gedurende , en één van 2007 tot heden, met gebeurtenissen in 1944,1983, 1995 en Dank zij het feit dat ik de hele situatie zelf bedacht heb, hebben we een totaal overzicht dat leidt tot het volgende: gedurende was mijn kennis nihil, in de periode fout, daarna correct, dan in verouderd, en tenslotte correct. Zonder totaal overzicht hebben we alleen de transacties: in plaats van 'fout' kunnen we achteraf zeggen 'vermoedelijk fout', en in plaats van 'correct' kunnen we slechts zeggen 'vermoedelijk correct'. Er kan altijd een transactie plaatsvinden die onze kennis omtrent het valid zijn aanpast. Onzekerheid of het revision control systeem actueel is, is er meestal niet, een transactie wijzigt zowel het revision control system (de werkelijkheid) als ook de kennis die het revision control system over zichzelf heeft. Die kennis over zichzelf is dus best wel actueel. Tenminste, als de revision control software geen fouten bevat, de hardware betrouwbaar is, het geheel goed is Pagina: 52 / 230

53 2.1 De basis beveiligd, de administrator foutloos werkt enzovoort. Wat verwacht ik van een revision control systeem? Het revision control system is vooral nodig om gestructureerd samenwerken mogelijk te maken Als iemand iets beschikbaar stelt voor gebruik door een ander, dan moet een bepaalde kwaliteit gegarandeerd zijn. Er is dus software die voldoet aan een kwaliteitseis, en software die niet voldoet maar daar naar op weg is. In ieder stadium is er een gebruikersclub. Voor iedere club is er een reden om de software te gebruiken, en kunnen er regels zijn voor het gebruik. Voor al die software is er het revision control system. Dan is het revision control system er ten behoeve van review, reconstructie van wat er is gebeurd, analyse en debugging: om de software op peil te houden of te verbeteren dus. Verder voor (project) evaluaties en dergelijke. Om de werkwijzen te verbeteren dus, en misschien ook om verantwoording af te leggen betreffende werkwijze en product. Tenslotte is er het opportunistische argument: je weet nooit waar het goed voor is. In ieder geval voor de laatste 3 items van de verwachting geldt dat het revision control system antwoord moet kunnen geven op wie wat waar wanneer vragen over de inhoud van de repository. Zo nauwgezet mogelijk moet alles vastgelegd worden. Gestructureerd samenwerken wat is dat? De belangrijkste voorwaarde is dat er een taakverdeling mogelijk is, waarbij de taken min of meer onafhankelijk van elkaar worden uitgevoerd. Iemand maakt iets, draagt het over, en pas daarna kan een ander er kennis van nemen of het gebruiken, of er verder aan werken. Dit hoeft niet per se één persoon te zijn: een groepje personen maakt iets, Voor zaken als overleg, brainstormen, over de schouder meekijken, met zijn drieën samen en tegelijk aan een document werken, biedt deze repository geen faciliteiten, en moet je zoeken naar andere middelen. Moderne web applicaties en elektronische hulpmiddelen kunnen helpen, als dit soort samenwerken nodig is tussen mensen die geografisch gescheiden zijn. Maar de bijdrage van het software archief is hier praktisch nihil. Veel version control of revision control systems zijn source code revision control systems. Ik zal proberen te komen tot een software revision control system, Het liefst een beetje in de richting van een software project revision control system. Allereerst is er een naam nodig voor de software die ik beschrijf. Zeker als ik toekom aan importeren en exporteren is het nodig om export naar een ander systeem te onderscheiden van export naar een systeem dat dezelfde software gebruikt. Software ontwikkelen is als het gezamenlijk beklimmen van een berg, je klimt een eindje en dan kan een ander de aangebrachte voorzieningen gebruiken, Zelf gebruik je de voorzieningen die anderen aanbrengen om weer een nieuw stukje te klimmen. Dit geldt voor medewerkers binnen een team en ook tussen de teams. Ik vond geen woord voor klimmen in een bepaald verband, en dus zal het voorlopige codewoord voor de SCM software zijn: Klimverband. Maar de termen die ik hanteer zijn Engels. Dan wordt dit Climb-Connexion of kortweg : Climbexion. Pagina: 53 / 230

54 2.2 Begrippen 2.2 Begrippen Basisstructuur Allereerst definiëren we een timestamp. In C en C++ is er een standaard functie time_t time(time_t *tp) Deze retourneert een datum/tijd variabele met een resolutie van één seconde. Dit is enigszins grof voor een event. We zullen deze functie inbedden in de functie climbexion_timestamp() die bij een aanroep een combinatie van een time en een sequence number retourneert, en die garandeert dat ofwel de time is verhoogd sinds de vorige aanroep en het en sequence number geïnitialiseerd, ofwel de time is (nog) steeds hetzelfde, maar het sequence number is verhoogd. In de voorbeelden in dit hoofdstuk laat ik het sequence number weg. Soms zullen timestamps echter slechts bestaan zonder sequence number, bijvoorbeeld, de datum/tijd van de laatste wijziging van een file die door desktop software is gewijzigd. Bij gebruik van zo'n timestamp kan Climbexion een sequence number toevoegen, voor zover nodig om een unieke identifier te vormen. De transacties die het revision control system wijzigen zijn vaak complex. De starttijd van een transactie is een timestamp, maar items binnen de transactie kunnen een volgnummer behoeven. Waarschijnlijk kan ook hiervoor het sequence nummer gebruikt worden, mits dit niet ten koste gaat van het gebruik van de temporele uitbreidingen van de database. Software bestaat uit files, die in een drawer zijn verzameld. Drawers hebben een folder structuur, de files staan in de folders. Een file staat op een willekeurig moment slechts in één folder. Een drawer is gealloceerd in een location. Bijvoorbeeld op een server, of op een PC. De keuze voor files en folders als identificeerbare elementen in een revision control system is redelijk traditioneel. Toch impliceert dit enige regels voor de software die erin is opgeborgen. Een software entiteit, bijvoorbeeld een class, een component, een variabele, een procedure, een namespace wordt alleen dan geregistreerd en geïdentificeerd in Climbexion als die één op één correspondeert met een file, een folder, of een ander Climbexion element. Van te voren dien je te bedenken wat je wel en niet samen in een file (of een folder) stopt. Het revision control system bevat files. Mutaties wijzigen die files. Deze mutaties wijzigen zowel de werkelijkheid (de files), alsook de kennis (van het revision control system) omtrent die werkelijkheid, dus kunnen we het ons gemakkelijk maken: transaction time = valid time. We hoeven alleen maar de valid time te implementeren. Kortom de repository is zijn eigen universe of discourse. Een file kan stadia doorlopen: er is een course of development of kortweg een course. Er is een course van zijn name, van de folder waarin hij voorkomt: de folder reference, en van zijn contents. Het bestaan van een file in een drawer: zijn existence kan eindigen, en misschien later weer beginnen: er is een existence course. Samengevat: er is een course van de file. De events die de course van een file vormen zijn voorzien van een timestamp: de transaction time. Zo'n event is bijvoorbeeld een naamswijziging, of een move naar een andere folder, of een gewijzigde inhoud of een combinatie ervan. De events van een course zijn bijna altijd Aton-achtige updates die een Pagina: 54 / 230

55 2.2 Begrippen oude waarheid, een oude realiteit, vervangen door een nieuwe, alleen vergeten we de oude waarheid niet met de komst van de nieuwe, we overschrijven niets meer. Het is de transaction time die maakt dat een course een adequate data structuur is, waarvoor geldt: de enige manier om de course te wijzigen is een toevoeging aan zijn tip. Een dergelijke toestandswijziging, is ook typisch een valid time overgang. Iedere toevoeging wijzigt de repository en daarmee ook de werkelijkheid. Ik zal ze successions noemen. Omdat hier geldt: transaction time = valid time, en we aannemen dat de implementatie van de climbexion betrouwbaar is, daarom is een succession onbetwistbaar en behoeft nooit gewijzigd te worden, en ook de timestamp waarmee de overgang ingaat wijzigt nooit meer. File met course Het revision control system legt verwantschappen vast tussen versies van files, zolang ze uit elkaar voortkomen. Het legt geen bloedlijnen vast, zodat je in één oogopslag kunt zien: hé die eigenschap ven de versie komt van zijn betovergrootmoeder. Ook ontleedt het geen chimaera: als functionaliteit verhuist van de ene file naar de andere, dan wordt er geen relatie gelegd tussen de file die de functie levert, en de file die de functie ontvangt: een functie is geen geregistreerde een entiteit. Het wijzigen van names en folder references, zoals dat hier geschetst wordt, lijkt op vrijheid, blijheid en anarchie. Je moet hier natuurlijk bedachtzaam, en liefst spaarzaam mee omgaan. In de aanloopfase van een programma kan het best wenselijk zijn om namen te wijzigen, en ook tijdens fasen van heroverweging, zoals die gelden als je van het ene project overgaat naar het volgende, of van de ene chip naar de volgende. Een doel van architectuur is immers om een omgeving te creëren waarin mensen zich kunnen oriënteren, en een goede naamgeving en een goede indeling lijken dan ook onontbeerlijk, ook al dragen ze niet bij aan een oplossing van het probleem. Om het goede te bereiken, moet je soms het minder goede kunnen veranderen. (Nou ja soms? Je kunt aan verbeteren een heel leven wijden.) Pagina: 55 / 230

56 2.2 Begrippen Een overeenkomstige file in een andere drawer heeft meestal dezelfde name en staat over het algemeen in dezelfde folder, maar hij kan een andere name hebben, en in een andere folder staan, en een andere inhoud hebben. Toch zijn deze files verwant. Ik denk dit te realiseren door te stellen dat ze tot dezelfde kin behoren. Een kin heeft een identificatie. Een file kan niet verhuizen van de ene drawer naar het andere. De file vertegenwoordigt de kin in de drawer. Ik denk dat in andere revision control systems het begrip trunk het meeste overeenkomt met een kin. Maar een trunk heeft een course en een kin niet. Een kin wordt hooguit door één file vertegenwoordigd in een drawer. Deze file heeft binnen de drawer een niet wijzigbare identificatie: die van de kin. Een stadium in de ontwikkeling van een file is een snapshot van de file. De inhoud van dit snapshot staat in een worm (write once read many-times) file. Traditioneel heet zo'n wormfile een version. Zo'n version kan kan worden hergebruikt. Meestal in een file in een andere drawer, die tot dezelfde kin behoort. Een version mag meer dan eens voorkomen in de content course van een file: bijvoorbeeld ten gevolge van een undo operatie. In de content course van de file staat een reeks referenties naar versions, die zelf in een pool zijn opgeslagen. In plaats van content course kunnen we ook spreken van een version course. De huidige toestand, of de toestand die een file of een folder had tussen twee events heet een snapshot. De course van een element kan worden gezien als een reeks snapshots, of als een reeks events die zijn gesorteerd op transaction time. Snapshots Een transaction kan meerdere files en folders wijzigen. De mutaties van de transaction die slechts één file wijzigen noemen we een event. Eén enkele wijziging die een event teweeg brengt noemen we een event item, of een course item. Een event item breidt slechts één elementaire course (name, folder reference of version, e.d.) uit. De wijziging die een transaction teweegbrengt, de verzameling mutaties, noemen we een changeset. (Ik vond ook het woord patch voor changeset. Binnen Climbexion wordt het woord patch soms gebruikt voor changesets die gestuurd worden naar andere teams). Transactions mogen niet tegelijkertijd door elkaar heen worden aangebracht: er is een course van changesets. Het effect van een changeset is een nieuw snapshot in de drawer en wordt wel een Pagina: 56 / 230

57 2.2 Begrippen revision genoemd. De event items die een file wijzigen worden toegevoegd aan een course van de file, die daardoor in een nieuwe toestand komt. Nieuwe toestanden van folders worden veroorzaakt door wijziging van hun name of één van hun andere eigenschappen, en toegevoegd aan hun eigen courses. Transactions, events, event items, kins, files, en versions kunnen attributes bezitten die geen succession zijn: Bijvoorbeeld de mededeling: deze transaction lost probleem X op, of Deze version is gekopieerd uit Project Y. Ze vervangen geen oude werkelijkheid door een nieuwe. Soms is er geen garantie dat de informatie correct is. Dan geldt niet valid time = transaction time. Er is geen course of development, maar hoogstens een course of metadata corrections, die hopelijk eindigt zodra de informatie correct is. De timestamps in een course of metadata corrections zijn transaction times, maar geen valid times: ze erven de valid time van het object waarop ze slaan. Voor een folder geldt wat voor een file geldt: er is een kin die hij vertegenwoordigt. Een folder is net als een file een element. Voor een element in zijn algemeenheid geldt: er is een kin van het element. Op een zeker tijdstip geldt: In een folder staan files en folders. Dit is de memberset van de folder. De inner-reach van een folder is een verzameling elements. Ze bestaat uit de folder zelf, zijn memberset, en de inner-reach van de folders die tot zijn memberset behoren. Shallow en deep zijn de termen die ik elders vond. Veel queries in het revision control system selecteren de inner-reach van van een folder op een zeker tijdstip. In feite wordt nu van ieder element een snapshot geselecteerd uit zijn course. We zullen meestal het begrip snapshot gebruiken als snapshot van de inner-reach van een drawer of een folder. De begrippen event en event item zullen we echter specifiek gebruiken voor een toevoeging aan een specifieke course. Een snapshot is een willekeurig tijdstip, maar vanwege het feit dat transactions atomair zijn, en hun changeset helemaal wel of helemaal niet is geïmplementeerd, kunnen we slechts snapshots gebruiken die een changeset volledig insluiten of uitsluiten. Snapshot timestamps zullen eventueel worden afgerond zodat de toestand die ze duiden jonger is dan de changeset die ingelijfd werd op die tijd, maar ouder dan de volgende changeset. Het lijkt erop dat we een aantal (bijna) synoniemen hebben geïntroduceerd: transaction, changeset, revision, snapshot, waarmee we zienswijzen of effecten van hetzelfde fenomeen aanduiden. Sommige folders worden package of subsystem genoemd. Als ik het heb over een package dan bedoel ik de inner-reach van de folder. Een package representeert een eenheid software die uitgewisseld wordt. Een package wordt in zijn geheel beheerd. Er is een eigenaar. Voor packages gelden de volgende opmerkingen: Een drawer bestaat uit packages. De packages vormen een tree. We introduceren een nieuw element: de package reference. Een reference staat in het ene package en wijst naar een ander. Zo wordt de tree gevormd: een verwijzing wijst van de top af. Een package reference heeft courses: name, folder reference, existence. Het begrip inner-reach moet nu aangepast worden. Een package reference naar een ander package behoort tot de inner-reach, maar het andere package zelf niet. Naast deze nieuwe definitie van inner-reach voor folders en packages bestaat er soms behoefte om alles binnen een drawer aan te duiden: dan noem ik expliciet: de inner-reach van een drawer. Een top folder van een package blijft altijd de top folder van het package: er is geen course van folder references. Ook is er geen course van names. De eigenschap top of package van Pagina: 57 / 230

58 2.2 Begrippen een folder is er bij het ontstaan van die folder, de eigenschap kan niet later ontstaan, en de folder kan deze eigenschap niet verliezen. Inner-reach en Memberset Wat ik een drawer noem wordt dikwijls een tree genoemd. Bedoelt wordt een folder en file tree. Men moet dan denken aan een groeiende boom die uit de gezamenlijke courses van alle elements bestaat, zoals een file een groeiende file is. In dit verhaal gebruik ik het woord tree alleen bij een snapshot, waarschijnlijk vind ik het een moeilijk begrip: bij een groeiende Pagina: 58 / 230

59 2.2 Begrippen boom zie ik niet iets voor mij waarvan bijvoorbeeld een tak zich verplaatst naar een andere tak. Voor een folder tree van een drawer geldt dat de name van een package reference de name wordt van de top folder van het gerefereerde package. Een drawer zelf bevat een verzameling (Engels: set) packages. Ieder package bevat een verzameling elements. Er is op ieder moment één top package. De reference ernaar staat in de drawer. Verder is er op ieder moment per package hoogstens één reference geldig naar dat package. Die reference moet ook nog eens in een ander package of in de drawer staan. Als een package voorkomt in een drawer dan is het wel de bedoeling dat er minstens een tijdje een reference naar het package geldig is. De courses van een package reference in een package: er is een existence course, en er is een name course, en een folder reference course, maar geen course van references naar packages. Het element heeft gedurende zijn leven één reference naar de kin van één package. De package reference naar het top package van de drawer kent mogelijk wel een course van package references, maar het besluit daarover moet nog genomen worden. Een element in een package kan het package niet verlaten. Folder references zijn lokaal binnen het package. De kin van een element wordt geregistreerd en bijgehouden bij het package in een kin pool, ook de versions van een file komen in een package pool. Omdat een package een eenheid van beheer is zouden changesets bijgehouden kunnen worden per package. Ieder package heeft dan één changeset element. De uiteindelijke beslissing hierover stel ik uit naar de formele beschrijving van het systeem. Er zijn waarschijnlijk drawers die slechts één package bevatten. De later te benoemen importdrawers en export-drawers komen in aanmerking om één package te bevatten De drawer kan dan vereenzelvigd worden met het package, er is geen onderscheid. Al met al lijkt het er momenteel op dat een drawer een andere bolster heeft dan een package, omdat de laatste altijd in een drawer zit, terwijl een drawer in een file system zit, misschien als folder, misschien als file. Samenvoegen package reference en top folder in een working-tree Package en top-folder kunnen eventueel gereduceerd worden tot één enkel element. Pagina: 59 / 230

60 2.2 Begrippen Er is eventueel een alternatief voor het top-package. Een drawer zou standaard een top-folder kunnen bevatten, net als een package. Het werken met packages is dan een optie. Een besluit hierover stel ik uit. In de formele definitie moet maar een keus worden gemaakt. Voorlopig is een drawer een verzameling packages Het meest recente snapshot van een drawer (het heden, nu ) heet de tip van de drawer. De tip kan worden gekopieerd naar een overeenkomstige folder structuur op een desktop, laptop of een server. Zo'n kopie heet een working-tree (ik vond ook de termen working folder, working directory en sandbox). In een working-tree wordt een package reference en de bijbehorende top-folder van het package samengevoegd tot één folder. In zo'n working-tree kunnen updates plaatsvinden. De gewijzigde versions en andere course-items kunnen daarna met de opdracht commit (ook wel check-in genaamd) worden toegevoegd aan de tips van de files in de drawer Ze vormen de nieuwe tips van de elements. Sommige wijzigingen kunnen niet zonder meer aangebracht worden in de working-tree en daarna met commit de courses uitbreiden, bijvoorbeeld naamswijzigingen, folder wijzigingen, het starten of beëindigen van een course. Dergelijke wijzigingen moeten worden aangebracht met Climbexion software in de working-tree, zodat ze daarna of gelijktijdig met commit in de drawer geplaatst kunnen worden. Normaal gebruik ik de Engelse termen, maar ik denk dat ik het werkwoord to commit niet ga vervoegen in het Nederlands. Ik zal dan de term vastleggen gebruiken: iets met commit vastleggen Een file in de working-tree wordt beschouwd als een kopie van de tip van een element als zijn pathname overeenstemt met die van het element, en als zijn timestamp (last changed date/time) overeenkomt met de timestamp van de tip van het element. Als de timestamp afwijkt dan wordt verondersteld dat de file een andere version is geworden. N.B. De timestamp in een filesysteem is vaak minder precies dan die in de repository. Maar voorlopig moet Climbexion het er maar mee doen. Om een nieuwe file in een drawer te specificeren wordt een add opdracht gebruikt. In één add opdracht kunnen meerdere elements worden toegevoegd aan de drawer. Meestal door in de working-tree vast te stellen wat erin voorkomt dat niet inde drawer staat, maar wel van belang is. In Climbexion zou add gebruikt kunnen worden om een nieuwe kin te duiden, terwijl copy of inherit gebruikt wordt als de kin reeds elders bestaat. Bij het gebruik van inherit wordt niet gekeken in de working-tree, maar in een andere drawer. Bij add en inherit worden name en folder reference initieel ingevuld, die courses zijn er daarna reeds. Merk op dat een nieuw package niet zonder meer kan worden afgeleid uit een nieuw element in een working-tree. Verder wordt de term check-out gebruikt om de working-tree af te leiden (soms opnieuw) van de tip van de drawer. Voor het beëindigen van (de courses van) een element zou remove of delete kunnen worden gebruikt. Het gebruik van add wijkt af van het gebruik in sommige andere systemen. Daar werkt men met een schaduw working tree, van waaruit eventueel half gewijzigde files kunnen worden terug gehaald in de working tree, of heel gewijzigde files met commit worden overgedragen in de drawer. Wij gaan uit van persoonlijke drawers, waarin naar hartenlust wijzigingen kunnen worden opgeslagen en eventueel teruggehaald in de working tree, voordat een snapshot ontstaat dat kan worden overgedragen naar een team drawer. Pagina: 60 / 230

61 2.2 Begrippen Over de naamgeving folder: oorspronkelijk een gevouwen map om documenten in te bewaren file: oorspronkelijk een geordende verzameling documenten, die aan een koord zijn bevestigd. Toen ik kennismaakte met computer files, bestond zo'n file uit records, bijvoorbeeld klant records die de de rubrieken naam, adres, woonplaats bevatten. record: oorspronkelijk een document waarin een gebeurtenis is opgetekend. Het Nederlandse kaartenbak laat zich vertalen als file, maar het Nederlandse ordner wordt vertaald als folder. In een software archief denk je bij file toch meer aan één enkel document bijvoorbeeld een source document dan aan een geordende reeks documenten. De begrippen file en document zal ik door elkaar gebruiken, als synoniemen. Bijvoorbeeld een reeks baseline reports vormt niet een file, maar een file-string. package: pakket. Hierbij heeft men het versturen en ontvangen van de spullen op het oog. Ik gebruik het woord package in plaats van (sub) system omdat dit iets meer in lijn is met folder, file, en document. Ik denk dat mijn package voldoet aan de UML definitie. Drawer. filing cabinet: archief kast voor het opbergen van files en folders en packages. Helaas bestaat dit begrip reeds voor archief files van Microsoft. Ik denk dat ik daarom het woord drawer (lade) ga gebruiken. Bovendien komt dat nog het dichts bij het begrip branch in andere VCS systemen. Oorspronkelijk gebruikte ik het woord area, maar dat sloeg nergens op. Drawer als deel van het opbergsysteem van folders files (documenten) en packages blijft horen bij de metafoor. Pool wordt gebruikt in de betekenis: "common reservoir of resources". Dat is een repository natuurlijk ook, maar ik gebruik het begrip voor een verzameling kins, of een verzameling versions, of verzamelingen van andere objecten die gedeeld worden door drawers. Kin: verwantschap. Oorspronkelijk gebruikt ik archetype, toen stolon en ik ben blijven hangen op kin. Zowel het Engelse als het Nederlandse kind zijn hiermee verwant. Hier vond ik geen begrip dat binnen de metafoor bestaat. Gebruikte symbolen Pagina: 61 / 230

62 2.2 Begrippen De organisatie van het geheel aan drawers Drawers van een subproject Drawers zijn er in soorten en maten. Er is een drawer voor een team dat betrokken is bij een project. Van zo'n drawer en de files en folders die erbij horen, wordt de volledige course bijgehouden. Zo'n Pagina: 62 / 230

63 2.2 Begrippen drawer moet zelf ook eeuwig blijven bestaan. Een team is meestal betrokken bij meer dan één project. Er is dan voor elk project een team-drawer. Dan zijn er drawers voor team members. De team members wijzigingen files (via de working-tree) in hun eigen drawer en dragen daarna de wijzigingen over aan de team-drawer. De overdrachten zelf zijn te volgen in het team-drawer. Drawers voor team members moeten kunnen komen en gaan, ze zijn er vooral voor de actuele behoeften. Zo'n drawer is een satellite van de team-drawer. De team-drawer is de center-drawer van zijn satellites. De hele constellation heet naar zijn centerdrawer. Dit komt denk ik overeen met het cone model van een lifeline van Ben-Michael Schueler. Met dit model van recente ontwikkeling wordt het team member een faciliteit geboden om zijn eigen werk te reconstrueren, totdat hij de taak die tot het werk heeft geleid als beëindigd beschouwt. Een overdracht van member naar team brengt de team-drawer "in sync" met (een deel van) de satellite van een team member. Maar er is ook een faciliteit waarmee het team member zijn satellite "in sync" brengt met die van het team. Een satellite is typisch een werkplaats, waar transactions (changesets) op de center-drawer worden voorbereid. De transactions in een satellite zijn daarom meestal nogal fragmentarisch van aard. Bij de overdracht naar de center-drawer wordt een course traject uit de satellite dan samengevat tot één event item. Ook kan een transaction in de satelliet een enkele version van een enkel element bevatten, terwijl de overdracht naar de team drawer meerdere elements en courses wijzigt, omdat de team area op elk moment aan allerlei eisen moet voldoen. In de courses van de satellite kun je de wording van een oplossing volgen. In een satellite kun je desnoods versions vastleggen: gewoon, omdat het lunchtijd is. Waarmee moet je een satellite vergelijken in een DAG (Directed Acyclic Graph) systeem? In de moderne open source version control systems, creëer je op je PC een clone van een centrale repository. Als je een wijziging aanbrengt dan creëer je op de tip van de clone een branch, waarin je de wijziging bereidt. De tip van de branch draag je daarna over aan de (centrale) repository. Een satellite zoals ik hem schetste is in feite een sequence van deze branches. Sterk punt van de DAG is voorlopig: je kunt aan meerdere wijzigingen tegelijk werken. In een satellite moet je strikt sequentieel werken, en voor parallellisme heb je er meer dan één nodig. Aan de andere kant, met satellites heb je lokaal geen clone nodig van de team-drawer. Het lijkt erop dar er twee opties zijn: Je kunt werken met één satellite per teamlid, per center-drawer, per wijziging. Op je PC zou je dan een directory kunnen maken die correspondeert met de center-drawer, en daarin satellites creëren die corresponderen met een probleem (of een stukje delta processing, of echte nieuwbouw, of een change request). Als je je satellite niet meer nodig hebt kun je die naderhand met append toevoegen aan de history satellite. Als je een branch creëert wordt er een working-tree gecreëerd, met folders en versions, en als je een satellite creëert wordt bovendien het eerste snapshot gecreëerd in de satellite. De aanmaak tijd van een satellite is daarom slechter dan de aanmaak tijd van een branch, gesteld dat de betreffende revision control software door dezelfde persoon ongeveer gelijktijdig is gemaakt. Dit is voor mijn hobby acceptabel genoeg. Bovendien, ik wil toch zien of het mogelijk is om met een strikt lineaire en onvertakte structuren te werken. Vaak vindt de overdracht van satellite naar center-drawer niet rechtstreeks plaats, maar via een transfer-drawer. Er vindt (periodiek, bijvoorbeeld 's nachts) een validatie plaats van de Pagina: 63 / 230

64 2.2 Begrippen overgedragen software, en na acceptatie wordt de center-drawer bijgewerkt, vanuit de transfer drawer. In wezen kan de inhoud, als een envelope niet wordt geaccepteerd wel deel uitmaken van de transfer drawer, maar niet van de team drawer. In Synergy gebruikten we een soort transfered status in plaats van een transfer drawer. Zo'n status kun je beschouwen als een tijdelijke branch aan de tip. Bij een status verandering van alle items in de branch naar accepted veranderde de branch in een uitbreiding van de trunk. Dit was, meen ik, zo gemaakt dat items afzonderlijk van status konden veranderen. Binnen de drawer van een team zijn er packages die onderhouden worden door het betreffende team, en packages waarop het team zich abonneert. Een ander team in hetzelfde master project onderhoudt andere packages. Er is dan ook een uitwisseling van recent gewijzigde packages. Tussen projects die hetzelfde package onderhouden ( sister-projects ) wordt er onderling ook heel wat uitgewisseld. Een team in een nieuw project baseert zijn packages op die van voorgaande projects. In sommige fasen wordt een package volledig gesynchroniseerd met die uit een ander project, op een ander moment moeten slechts oplossingen van bepaalde problemen worden overgenomen. Voor beide methoden moeten er faciliteiten komen. We hebben te maken met geheimen. Klanten willen bijna nooit dat hun oplossingen en methoden door NXP worden doorgegeven aan andere klanten. Er moeten daarom een behoorlijke barrières zijn tussen projects voor verschillende klanten. Vaak wordt geëist dat NXP voor een klant een eigen repository gebruikt. Er kunnen export limitations gelden bij de overname van wijzigingen tussen de sister-projects. In een package dat je aanpast volgens specificaties van klant A kunnen geheimen zitten die klant B niet mag weten. Je kunt dan niet onbeperkt alles overnemen als je hetzelfde package aanpast voor klant B. Ook NXP heeft geheimen, die hopelijk een (mogelijk tijdelijke) voorsprong geven op concurrenten. NXP wil niet dat die geheimen via een klant of zo in het bezit komen van de competitie, want ze wil zo lang mogelijk profiteren van de voorsprong, immers alleen met een voorsprong verkoopt ze veel chips voor een behoorlijke prijs. Zolang de digitale tv sterk in ontwikkeling is kan er geconcurreerd worden met geavanceerde oplossingen, en dat gebeurt dan ook. Enerzijds gebeurt dit met patenten, en anderzijds met verrassingen (geheimen). Niet alleen zijn er de barrières tussen de sister-projects, maar ze zijn er ook tussen teams in hetzelfde master project. Soms stellen teams slechts de binaire executable componenten en de interfaces van een package beschikbaar: er moeten faciliteiten komen om export limitations te realiseren. Een team dat zich abonneert op packages is vaak niet geïnteresseerd in alle files in alle folders. Source files zijn belangrijk voor debugging, maar documentatie niet direct. Alles wat te maken heeft met het specifiek testen van het package is niet van belang in de drawer van een ander team. Er moeten dus faciliteiten komen om query's met import limitations mogelijk te maken. Dit is vooral een optimalisatie. Binnen een team kan de ene persoon zich bezighouden met een test van het hele product, de ander is meer geïnteresseerd in de test van een layer, en heeft dan minder packages nodig. Hier moeten zorgvuldig gekozen selecties zorgen voor een beperkte samenstelling van een Pagina: 64 / 230

65 2.2 Begrippen satellite, ook hier is sprake van limited import queries. Een working-tree van de totale software stack is inmiddels tientallen gigabytes groot. Met alle consequenties voor importeren, exporteren, synchroniseren, en compileren: allemaal processen die veel tijd vergen, en zelfs in belangrijke mate de doorlooptijd en capaciteit van een project bepalen. Import limitations kunnen een query betreffen van de files die je wilt overnemen uit een andere drawer, gewoon omdat je daarbuiten niets wilt overnemen uit die drawer. Maar ook kan het zijn dat je bepaalde files of folders nooit in je drawer wilt hebben, dan hangen de import limitations niet aan de query, maar aan de drawer. Mogelijk leidt het bestaan van de limitations tot subpackages. Om import limitations te faciliteren zou mogelijk een subpackage gedefinieerd kunnen worden ten behoeve van de unit tests. Om geheimen te isoleren zou men ook een subpackage kunnen gebruiken. Voorlopig ga ik ervan uit dat een subpackage mogelijk is door hem als een gewoon package te definiëren, indien daar behoefte aan is. Niet alle drawers van een team zullen dezelfde import limitations krijgen. Tijdens het ontwikkelen gebruikt een programmeur vaak documentatie van interfaces en componenten. Voor het analyseren van problemen bijvoorbeeld zal je soms willen beschikken over de documentatie van de packages waarop je bent geabonneerd. Deze zijn dan bijvoorbeeld te vinden in de import-drawer, of de teamdrawer. Maar in een satellite voor een team member moet het voldoende zijn om te kunnen compileren en linken, en om de eigen documentatie te wijzigen. Ondanks import limitations kun je toch vaak beschikken over de documenten die je weert: ze staan immers in de drawer waaruit je importeert. Een import-drawer is een drawer waarin de packages van andere teams uit hetzelfde master project worden binnen gehaald. Een team heeft één zo'n import-drawer voor ieder van zijn projects Hierin zijn alle baselines, dus ook de nieuwste baselines van de packages beschikbaar, ook als ze (nog) niet zijn ingelijfd in de team-drawer. Misschien zijn er meerdere import drawers en bevat zo'n drawer slechts één package. Een externe referentie zoals een referentie naar een ander package, hoeft in zo'n drawer niet te worden opgelost. Een export-drawer is een drawer waarin de baselines van de eigen packages worden geplaatst. Om een eigen package te gebruiken in een ander project binnen het team gelden meestal geen beperkingen, en soms door de klant gevraagde restricties. Om zo'n package beschikbaar te stellen aan een client of een supplier gelden vaak wel export limitations, die van NXP. Vanuit deze drawers kan een package geëxporteerd worden naar een ander team of een ander project of beide. De export limitations die moeten worden gerealiseerd zijn afhankelijk van de rechten van het ontvangende team. Mogelijk bevat een export drawer ook precies één package. Een Project is een begrip dat ook binnen een revision control system gebruikt wordt Een team dat deelneemt aan een (master) project van een client, zorgt voor een (sub) project. Binnen dit subproject worden de drawers gecreëerd. Een team dat deelneemt aan tien projects heeft dus tien team-drawers. Een ander team, dat deelneemt aan vijf projects heeft vijf team drawers, en natuurlijk ook vijf import drawers enzovoort. Als twee teams deelnemen aan één (master) project dan heeft ieder team daarin zijn eigen subproject met zijn eigen drawers. De subprojects van een team worden door mij sister-projects genoemd. Een enkel package wordt beheerd binnen een aantal sisterprojects. Sister-projects kunnen verdeeld zijn over enkele teams. Voor testers komt er mogelijk een aparte drawer, de test-drawer. Veel tests worden gedaan op baselines van packages, en niet op packages die van de ene naar de andere baseline onderweg zijn. Pagina: 65 / 230

66 2.2 Begrippen Eigenlijk worden baseline tests gedaan op de voorlaatste fase van een package, voordat de baseline definitief is. Zelf beheren de testers een aantal package -, layer -, en product - test-cases. Er is een bewaar structuur, waarvoor het revision control system een folder structuur biedt. Test-cases worden samengesteld tot tests. Momenteel worden veel test-cases gedefinieerd in excel sheets. Ik vermoed dat dit nodig is voor een tool van de TMap methode. Ik denk dat dit niet zonder meer een voordeel is, want nu kan er niet geprofiteerd worden van standaard build - en merge - en synchronisatie faciliteiten, die gebaseerd zijn op folder structuren en tekst-files. Naast test-cases, en tests en hun documentatie, zijn er nog de test-logs en test-results, die het waard zijn om te worden bewaard. Verder maken testers een progress report dat bewaard moet worden. Ook testers werken projectmatig, en ook hun drawers zijn exclusief voor een bepaald project. Mogelijk worden hun elements opgenomen in de team-drawer, en worden import limitations gebruikt als hun scripts niet nodig zijn. Als een nieuw subproject start, dan worden de eigen packages gekopieerd vanuit een sister-project dat deel uitmaakt van een ander masterproject, en later mogelijk bijgewerkt met wijzigingen van een sister-project. Hiervoor gebruiken we mogelijk een speciale import-drawer: Merge-importdrawer. In een subproject is er een merge-import-drawer voor ieder sister-project waaruit groepsgewijs wijzigingen worden overgenomen. Bij het oplossen van problemen is de eerste stap die genomen moet worden: reproduceer de fout. Meestal moet de oplossing gerealiseerd worden in de meest recente versie van de team-drawer (via een satellite van een team member). Soms is het probleem daar niet te reproduceren, althans niet met de aanwijzingen in het problem report. Dan moet er geanalyseerd worden met behulp van de drawer van het team dat de fout ontdekte. Hiervoor wordt een expose-drawer bijgehouden. Met in acht neming van export limitations wordt hier een omgeving bijgehouden, die meestal via het web is te benaderen, en waaruit info-trees kunnen worden getrokken. De expose-drawer is van het team dat het probleem ontdekte. Eén van de dingen die je dan bijvoorbeeld kunt doen: Je probeert of je het fenomeen kunt opwekken op een andere manier die wel reproduceerbaar is in de meest recente versie van de team-drawer. Het is me wel eens overkomen, dat ik niet de fout reproduceerde, maar een fenomeen dat er wat op leek. Gelukkig vond niemand het erg, dat ik het verkeerde probleem had opgelost, maar administratief (zie 2.5) was dat toch wel wat werk. Een team baseert zijn packages op die van het reference project, en wisselt soms oplossingen van problemen uit met het reference project. Dit moet soms kunnen met verschillende generaties van één revision control system, en heel soms met een totaal ander revision control system. Het kan ook zo zijn dat een team van de klant andere revision control system software gebruikt dan de NXP teams. Dan moet uitwisseling van software nog steeds mogelijk zijn. Pagina: 66 / 230

67 2.2 Begrippen De organisatie van pools Kin en version pools van Party F Pools zijn er voor versions, en voor kins. Iedere package heeft zijn eigen pools, waarin de versions en kins staan waarnaar wordt verwezen vanuit de inner-reach van drawers. Om redenen van optimalisatie robustness en security kunnen er locations bestaan. Op iedere location staan local pools die de drawers bedienen die tot de location behoren. Een local pool bevat een subset van de kins van een package, en een andere een subset van de versions van de kins. Bij overdrachten vanuit een drawer op location A naar een drawer op location B worden indien nodig kins en versions gekopieerd. Een URL (uniform resource locater) identificeert een location, pool of drawer, of kortom een resource. Pagina: 67 / 230

68 2.2 Begrippen Local pools zijn er op de server van een team. Deze pools bedienen de center-drawers, de import-drawers, de full export-drawers en de full expose-drawers. Voor export-drawers met export limitations komen er pool verzamelingen per party indien nodig. Er zijn twee soorten export limitations: de NXP pools dienen voor distributie binnen het master projects, de CLIENT pools dienen voor de distributie van NXP software binnen sister projects, tenminste als het package client geheimen bevat. Voor ieder package is er een centrale location Een pool daar wordt gewijzigd zodra een kin of een version in twee of meer locations voorkomt, dan wordt de entiteit ook toegevoegd aan de centrale pool. Elk package heeft zijn eigen centrale. Als attributes van een version of een kin wijzigen dan worden die gepusht naar de centrale location, tenminste als daar de version of de kin voorkomt en vandaar met pull methoden gedistribueerd. Eventueel worden notificaties gestuurd naar belanghebbenden. Overigens: onze partners in een masterproject gebruiken onze export pools voor het overnemen van attribute wijzigingen. Eventueel is er een tree van centrale pools, waarvan de nodes een organisatorische eenheid bedienen. De centrale version pool van een package bevat geen versions, dat wil zeggen, niet de content van de versions, maar slechts de attributes. Van envelopes (zie 2.2.6) kunnen er ook lokale kopieën voorkomen. Centraal is de constellation pool, en lokaal zijn de PC pools van de teamleden. Ook nu worden nieuwe envelopes en wijzigingen gepusht vanuit een lokale naar de centrale pool, en vandaar uit met een pull methode gedistribueerd. Een teamlid bepaalt welke envelopes lokaal op zijn PC worden bewaard, en hoelang De organisatie van snapshots Binnen ons team werden 's nachts de overdrachten van de teamleden getest en daarna werden de overgedragen wijzigingen aangebracht in de team drawer. Dan werd er een tag geregistreerd. Een tag definieert de toestand (inner-reach) van een drawer op een tijdstip. Zo'n geregistreerd snapshot garandeert een bepaalde kwaliteit van de drawer. In ons team was er de garantie dat de drawer goed door een acceptatie test kwam. De meest recente tag heet een tip-tag. Een package (of vaak een groepje packages) kan een stadium bereiken, waarop er een baseline wordt geformuleerd, en geregistreerd. Bij een baseline hoort een baseline report. Dit document bevat informatie zoals: de problemen die zijn opgelost en de planning items die zijn gerealiseerd, misschien enige baseline supplement (patch) informatie. Ook worden de baselines van andere packages genoemd waarmee het package is getest. Verder staat erin op welke hardware het package moet kunnen werken, en nog veel meer informatie. Zo'n baseline van een package wordt geëxporteerd naar andere teams samen met het baseline report. Tussen baselines door kunnen er baseline supplements (tussentijdse wijzigingen) nodig zijn op het package. In Climbexion definieert de baseline een snapshot van één of meer packages. Pagina: 68 / 230

69 2.2 Begrippen Baseline report: Eerst noemde ik het baseline document. Later herinnerde ik mij dat een report een beschrijving is van iets dat geobserveerd kan worden. Als je werkt met fasen is een report een afsluitend document van de oude fase. Dat geldt ook als je vooral faseert om regelmatige uitwisseling van software te bewerkstelligen. Andere documenten zijn dan een stuk minder belangrijk, zoals een risico analyse en een plan van aanpak voor de volgende fase, die hoeven misschien pas als een echte project fase is bereikt. Vaak is er wel een plan voor de volgende fase, dikwijls vind je dat in een verslag van een vergadering. Ik denk tags en baselines te realiseren in speciale elements. Tag-elements komen in de absolute top folder van de drawer, en baseline elements in de top folder van het package. Elke keer dat er een nieuwe tag of baseline wordt gedefinieerd wordt de course van het betreffende element uitgebreid met een item. Ook als een bundel packages een nieuwe baseline krijgt, dan nog is het zinvol om een baseline per package te specificeren, gezien de documentatie (het baseline report) die er bij hoort. Als een nieuwe baseline van een package geïmporteerd wordt, dan wordt als laatste een event item uitgevoerd waarmee de baseline tag wordt geïmporteerd. Als een satellite gesynchroniseerd wordt met de tip-tag van een center, dan wordt het tag-item als laatste gekopieerd. De periodieke baselines van een package komen in één tag-element. Maar de bijbehorende baseline reports komen in andere elementen. Bij tijd en wijle wordt een snapshot verheven tot project milestone. We spreken af dat dit snapshot altijd een baseline is. Dit heugelijke feit mag geregistreerd worden door een extra tag toe te voegen aan een package of een drawer. Deze milestone tag ontstaat pas als het snapshot reeds bestaat, en mogelijk opgevolgd is. Er geldt dus doorgaans dat transaction time en valid time verschillend zijn. Vaak volgt zo'n eenmalige tag op een audit, die het licht voor de volgende project fase op groen zet. We kunnen dit eventueel ook realiseren door een attribute toe te voegen aan een baseline tag, die hiermee extra wordt gemarkeerd. Mogelijk kent een subproject milestones, die gelden voor meerdere packages, misschien gelden milestones voor het master project, en als zodanig voor de subprojects en hun packages. De kunst is natuurlijk om deze markeringen niet alleen in de export-drawer te realiseren, maar ook door te voeren bij de afnemers. Tags worden in andere revision control systems wel label genoemd. In Software Configuration Management wordt het begrip baseline hiervoor gebruikt. Ook de term milestone komt voor. Wij zullen het woord baseline gebruiken voor package tags, tags voor drawer tags, en milestones voor fase overgangen van een project. Tags worden waarschijnlijk direct aangebracht in de drawer, zonder envelope. Ze zijn hun eigen changeset. Tags kunnen uit een team-drawer gekopieerd worden in een satellite. De tag-name is bijvoorbeeld 10 augustus 2008, P.M, en het tijdstip waarop de satellite gesynchroniseerd wordt is 11 augustus 2008, 11:30:12. Dit is dan de timestamp van het course-item waarmee de tag-name verschijnt in de satellite. Als de name gebruikt wordt voor een snapshot in de satellite dan wordt bij de name de timestamp van het event bepaald, en daarmee de timestamp van het snapshot. De name geeft terecht aan dat het hier een frozen moment betreft die de team-drawer op het aangegeven tijdstip had. Dit gaat goed als gesynchroniseerd wordt met behulp van de tag. Synchroniseer je met een willekeurige Pagina: 69 / 230

70 2.2 Begrippen timestamp, en wordt daarbij een tag name gekopieerd, dan geeft daarna het gebruik van de tag name een onbedoeld snapshot in de satellite. Als je synchroniseert op de tip van de team-drawer, dan moet je vooraf synchroniseren op de tip-tag, anders is de tip-tag onbruikbaar geworden. Ditzelfde geldt voor baseline-tags. Ook deze worden als laatste gekopieerd als het package wordt gekopieerd, bijvoorbeeld vanuit de export-drawer van team1 naar de import-drawer van team2. Een Tag element heeft een name bijvoorbeeld fortnightly. Deze name heeft uiteraard een course of development. Daarnaast heeft elk snapshot dat gedefinieerd wordt (de tag) een name bijvoorbeeld baseline De werkwijze van NXP zal waarschijnlijk toelaten dat tags toegevoegd worden als gewone elements waarvoor geldt valid time = transaction time. Omdat één persoon, de build-manager ze toevoegt aan drawers die alleen hij wijzigt. Dit omdat het werk van ontwikkelaars niet onmiddellijk wordt toegevoegd aan de courses in de team-drawer, maar eerst een validatie ondergaat, die uitgevoerd wordt door de build-manager, of door een script van hem dat laat in de avond wordt uitgevoerd. Bij meer vertrouwen in de werkwijze van de ontwikkelaars kan deze procedure wijzigen, en zou er een situatie kunnen ontstaan waarin tags worden toegevoegd aan reeds opgevolgde snapshots, die een validatie hebben doorstaan. Dan geldt bij het plaatsen van de tag dat transaction time en valid time kunnen verschillen. Maar als de tip van drawer 2 gesynchroniseerd wordt met een snapshot, dat benoemd is in een tag van drawer 1, dan wordt de tag mee gekopieerd en geldt valid time = transaction time. Transactions worden ook wel changesets genoemd. De eerste aanduiding slaat meer op de handeling, en de tweede op het effect of de inhoud ervan. Net als tags en baselines zijn transactions een speciaal element. Zo horen echter bij een drawer en je kunt ze niet kopiëren naar een andere. De changesets zijn de versions van het transaction element. Ze komen zeker niet in een pool maar horen bij de drawer, en ze zijn niet herbruikbaar. Naast nuttige informatie voor gebruikers wordt het element gebruikt door de repository software om een aantal acties te optimaliseren. Als geregistreerde snapshots is het een reeks waarin elk snapshot verschilt van zijn voorganger. Tags en baselines verschillen een geheel aantal changesets (0 of meer) van hun voorganger. Changesets laten zien wie wat wanneer gewijzigd heeft. In drawers kan er bij een changeset een verwijzing staan naar een envelope staan (zie 2.2.6), of een verwijzing naar een gebruiker, en enig commentaar. Als de wijzigingen die in een satellite zijn gemaakt worden overgenomen in de team-drawer, dan wordt de tip van de satellite overgenomen, of wel de changesets van de satellite worden samengevat tot één changeset. Als een baseline wordt geplaatst in de export-drawer dan wordt de tip van de team-drawer overgenomen in de export-drawer, en de changesets in de team-drawer worden samengevat in één changeset in de export-drawer. Ook als satellites wijzigingen overnemen uit een team-drawer, dan wordt de tip van de team-drawer overgenomen, met in inachtneming van import limitations. Ditzelfde geldt als wijzigingen worden overgenomen in de team-drawer vanuit de import-drawer. Kortom changesets zijn specifiek voor een drawer. Een folder-structuur op een desktop, laptop of server, in het lokale file system, die een kopie is van een snapshot (meestal een tag of een baseline) van een drawer heet een info-tree. Je kunt wel wijzigingen aanbrengen in een info-tree, maar die kan je met commit niet vastleggen in de drawer, dat is het enige verschil met een working-tree. Info-trees zijn bijvoorbeeld van belang bij het analyseren van fouten. Stel een simpele fout: je zapt van het ene naar een ander kanaal en daarna hoor je geen geluid. Hoe vind je nu de statements in de software die fout zijn, het is zoeken Pagina: 70 / 230

71 2.2 Begrippen naar een naald in een hooiberg? Nou, bijvoorbeeld als volgt: Met behulp van een info-tree waarin successievelijk verschillende snapshots worden gedownload, kun je vaststellen wanneer de fout voor het eerst optrad. Daarna bepaal je wat er toen in het revision control system gebeurd is, en zo vind je de fout. (dit is niet het enige middel voor fouten analyse, maar het is zeker een belangrijk middel). In het open source system git git-scm.com/ vond ik een faciliteit die dit automatiseert, met een algoritme dat het aantal te gebruiken snapshots minimaliseert. Je zou een snapshot kunnen zien als een virtuele info-tree. Zo'n virtuele info-tree kun je niet wijzigen, je kunt er alleen in kijken. In een gewone info-tree kun je eventueel logging inbouwen in een programma, of een build uitvoeren, die de binaries terug plaatst in de tree. In een virtuele infotree is dat niet mogelijk: die is read-only. Als je source code moet wijzigen, dan wil je liever geen fout introduceren. Het is dan nuttig om te weten waarom de software is zoals hij is. Vaak ontbreekt overzicht en inzicht. Maar het revision control system moet hier kunnen helpen. Kijk in (virtuele) info-trees van reference en backbone projects waar en wanneer een software constructie is ontstaan. Kennis over de context waarin de software constructie is ontstaan kan dan mogelijk behulpzaam zijn bij het verwerven van het benodigde inzicht en overzicht. Er zit vaak tijd tussen de ontdekking van een fout en de oplossing ervan. Er kan dan een info-tree gemaakt worden om de fout te reconstrueren met de software die indertijd is gebruikt Other-focused files Het betreft hier een soort files waarmee, naar ik hoop, een uitbreiding van het gebruik van de repository mogelijk is. We gaan ermee, als alles goed is, van een source version control system naar een software version control system, en mogelijk is er enig zicht op een software project version control system, waarin alle relevante documenten van een project worden bewaard en beschikbaar gesteld. De versions van een source file, bijvoorbeeld een c module bevatten tekst. Deze tekst slaat op de version zelf. De inhoud beschrijft wat de module doet. Een source file is self-focused. Een version van de file in een course of development geeft de state-of-the-art van de file weer, en draagt bij aan de state of the art van het betreffende snapshot van de drawer. We zeggen ook wel: valid time = transaction time. Een rapport met test resultaten, een baseline report, een verslag van een vergadering, en zelf een executable die met een build procedure is gemaakt: ze gaan allemaal over iets buiten henzelf. Deze files zijn other-focused. Een consequentie is dat voor het inbrengen van versions niet hoeft te gelden: transaction time = valid time. Het zijn wezenlijk verschillende zaken. Een tester selecteert bijvoorbeeld 's morgens een snapshot, test de hele dag, en plaatst 's avonds de test resultaten in de repository. Dan is er geen garantie dat er een snapshot is waarin het geteste en het testresultaat bijeen staan, tenzij je daarvoor een aparte valid time gebruikt. Ik vindt het een goed idee om de test resultaten samen op te slaan bij het snapshot waarop ze betrekking hebben, maar dit zou niet tot een procedure moeten leiden waarbij de tip van een drawer geblokkeerd blijft totdat de tests erop klaar zijn. Dus is er een argument om other-focused files te onderkennen, en te Pagina: 71 / 230

72 2.2 Begrippen faciliteren. Self-focused file versions zijn, behalve de eerste, gebaseerd op een voorganger en willen daarvan verschillen. Other-focused files zijn gebaseerd op een werkelijkheid, en willen daarmee overeenstemmen (zelfs al zijn ze met copy en paste gemaakt uit een andere file). Een other-focused file heeft attributes die het subject specificeren waaronder een valid time attribute, en versions die een transaction timestamp attribute bezitten. De belangrijkste otherfocused files die thuishoren in een software repository slaan op een snapshot in een drawer. Mijns inziens bereik je de uitbreiding van een source revision control systeem naar een software revision control system door een oplossing te bedenken voor other-focused files, en dan met name voor de snapshot-focused files. We gaan ervan uit dat we deze files beschikbaar stellen in de drawer, waarin het snapshot voorkomt. Ook gaan we ervan uit dat dit snapshot altijd een tag of release is. Binnen de other-focused files zijn er waarvan het subject buiten de repository ligt. Bijvoorbeeld de agenda's en verslagen van vergaderingen. Het is mogelijk op het randje om die in een software repository op te slaan, waarschijnlijk erover, maar goed, ze kunnen meeliften op de voorzieningen die ik wil treffen voor de files waarvan het subject zich binnen de repository bevindt. Om ze te benoemen: ze zijn externally-focused. Ik denk dat er pools van other-focused files komen (één per package per owner subproject) waarin de files met hun transaction time courses staan. De meeste geordend in strings. In de drawers staan dan references naar deze files of file-strings. Waarschijnlijk is het voldoende om file-strings te implementeren, single-shot files zijn dan gereduceerde strings. Die references hebben een course van names en een course van folder references, maar niet een string van files en geen course van versions. Snapshot-focused files bevatten informatie die min of meer intrinsiek te vinden is in het snapshot. Een executable die gemaakt is van een snapshot is volledig intrinsiek, maar een test document bevat ook informatie omtrent de TV waarop getest is, de gebruikte audio/video stromen en dergelijke, dus ook de nodige extrinsieke informatie. Binnen de other-focused files herkennen we de files die een enkel incident beschrijven: er is slechts één valid time, maar er zijn misschien wel meerdere versions, voordat de inhoud correct of volledig was. Deze files zijn single-shot files. Bijvoorbeeld review samenvattingen, of audit resultaten. Executables, baseline reports, test-reports van daily tests of van baseline tests, verslagen van voortgangsvergaderingen. Ik ben geneigd om hiervoor objecten te gebruiken met een valid time course. Zo'n complete course is dan als volgt gesorteerd: valid time / transaction time, terwijl meestal een subcourse gewenst is: slechts de meest recente (transaction time) version van een valid time wordt getoond. Deze objecten zijn een repetition van files We zullen ze file-string noemen. Een file uit de string heeft een valid time: het snapshot waarop hij slaat. De versions van de file hebben een transaction time. Twee files uit zo'n string zijn niet verwant in de zin van kins. Dat neemt natuurlijk niet weg, dat ze erg op elkaar kunnen lijken. Met de hand gemaakte repetitions zullen dikwijls voor een deel met copy en paste uit voorgangers zijn gemaakt. De string van een other-focused file-string is gesorteerd op valid time als hoofd sorteer-kenmerk. Pagina: 72 / 230

73 2.2 Begrippen Daarom hoeft een version die met een nieuwe transaction wordt toegevoegd aan de course niet per se te belanden in de tip van de string. Dit in tegenstelling tot een self-focused file waarvan de course altijd wordt uitgebreid aan de tip, immers de transaction time van de nieuwe version is ook de valid time. Een nieuwe version voor een self-focused kin wordt dan ook altijd met commit vanuit een working-tree vastgelegd, terwijl een nieuwe version voor een other-focused file kan worden vastgelegd vanuit zowel een working-tree als een info-tree. Own-drawer-focused file-string Als een file niet voorkomt in een snapshot dan moet dat gemarkeerd worden. Als een file geldig is voor meerdere snapshots dan moet dat aangegeven worden in de string. Het model kan eventueel vereenvoudigd worden door slechts de meest recente versie op te slaan van een file in de string. Voor own-drawer-focused files in een string geldt dat ze geen valid time timestamp hebben, maar Pagina: 73 / 230

74 2.2 Begrippen een tag reference attribute. Per tag reference kunnen er diverse versions zijn, met een verschillende transaction time timestamp, waarvan de meest recente geacht wordt de meest correcte te zijn. Sortering op tag levert niet per se een sortering op valid time op en is dus geen time sequence, maar blijft een set. De uiteindelijke string wordt bepaald in de drawer, waar het tag-element een course heeft. De course van het tags bepaalt de definitieve course van de file-string in de drawer. Er zijn twee presentatie opties voor file-strings. In een working-tree of info-tree kan gelden dat alle repetitions getoond moeten worden in een folder die genoemd is naar de file-string, terwijl de files in de folder genoemd zijn naar hun valid time reference. Dit kan bijvoorbeeld gelden voor alle baseline reports, of alle verslagen van meetings. Maar ook kan gelden dat slechts de occurrence van het snapshot getoond moet worden. Dit geldt bijvoorbeeld voor build targets, of test results. Maar dit kan ook gelden voor baseline reports, en ook verslagen kunnen ook als single getoond worden. Dan wordt de name van de file-string gebruikt voor de file zelf, en wordt er geen file-string folder gemaakt. Stel in een team drawer werd een nieuwe baseline van een package geplaatst. Na een tijdje bleek dit zoveel problemen te geven, dat men besloot om terug te keren naar de vorige baseline. Voor de course van de baseline tags betekent dit bijvoorbeeld de volgorde, Rn, Rn+1, Rn, Rn+2,... Dit geldt dus ook voor de string van de baseline reports in de drawer. Build Targets: Ze kunnen pas gemaakt worden als het snapshot met source files klaar is, daarna kan de build ze zo lang duren, dat er reeds wijzigingen zijn aangebracht in de drawer. Over het algemeen maakt een build manager het target, en slaat het op in de team-drawer, of in de exportdrawer. Anderen kunnen inmiddels reeds transfers uit de satellites hebben gerealiseerd. Om die reden behandelen we ze als own-drawer-focused. Ze worden gemaakt in een info-tree. Een bijkomend voordeel is misschien dat je de builds kunt herstellen in het snapshot waarvoor ze bedoelt zijn. Onder andere het volgende kan mis gaan: De info-tree was vervuild met wijzigingen Er waren foute opties meegegeven aan het build script Er zijn build targets die geëxporteerd worden. Dan worden ze zowel in baselines als in baseline supplements geëxporteerd. De betreffende tags moeten dus ook bijgehouden worden voor zowel de baselines als de baseline supplements. Complete build resultaten, met alle derived files: Het kan nuttig zijn om deze op te slaan, om te vermijden dat ontwikkelaars veel clean builds moeten uitvoeren. Baseline reports: Ze kunnen worden voorbereid voordat er een baseline tag bestaat in de export drawer, want zo'n baseline is planbaar. De satellite waarin het baseline report wordt voorbereid moet dan het betreffende tag-element reeds bevatten. In de betreffende satellite geldt dan strikt genomen niet dat het report own-drawer-focused is, immers het snapshot in de satellite voldoet niet per se aan de specificaties van het baseline report. Een bijkomstigheid: een fout is nog te herstellen. De herstelde file vervangt de foute file in het baseline snapshot. Component descriptions en Interface descriptions: in principe is dit documentatie over een component, of een interface, bedoeld om implementatie perikelen te beschrijven, voor de software engineer die de component als server voor zijn client software gebruikt, of die de interface gebruikt. Als zodanig lijken deze files in aanmerking te komen als other-focused files. Maar nieuwe files zijn wel gebaseerd op voorgangers als je ze wijzigt, ze nemen deel aan een ontwikkelingsgang. Ook wil Pagina: 74 / 230

75 2.2 Begrippen je soms versions of wijzigingen overnemen uit sister projects. In de projects waarin ik werkte zijn de gebruikers te overzien, en een fout hoeft niet per se hersteld te worden in de baseline, of in het snapshot. Zelfs als de gebruikers niet zijn te overzien, kunnen wijzigingen via de normale verbeter procedures worden gedistribueerd. Daarom implementeren we ze als self-focused files. We reserveren other-focused files alleen voor die files waarvoor het bijna niet anders kan. Argumenten voor het onderkennen van other-focused files zijn onder meer: Er moet reeds een snapshot zijn, waarop de file slaat Er is sprake van een file-string. Er moet correctie mogelijk zijn in hetzelfde snapshot Slot opmerkingen. Over het algemeen is het zo dat een file-string niet per se na iedere toevoeging aan de tip-tag van een package opnieuw moet worden uitgebreid met een nieuwe file voor de betreffende valid time. Dus in snapshots die volgen blijft de oude file zichtbaar, totdat er een snapshot komt waarin deze vervangen is. Ook kan het voorkomen dat je het éne moment een snapshot bekijkt, en je ziet een oude version, en de volgende dag bekijk je het snapshot, en nu zie je een nieuwere version. Deze version kan tot dezelfde file behoren, en dus dezelfde valid time hebben als zijn voorganger. Soms is er source file. Dan komt iemand op het idee om de file te genereren, en is het niet langer een source file, maar een derived file en dus mogelijk een file-string. Climbexion heeft voorlopig geen faciliteiten om een file naadloos te laten overgaan in een file-string (visa versa). IBM Rational ClearCase is een revision control systeem waarin ook build resultaten kunnen worden opgeslagen. (in een VOB, wat staat voor Versioned Object Base). Odin is een build systeem waarmee meerdere versies en varianten van build resultaten kunnen worden opgeslagen naast een source revision control system. De architecten van NHSW bedachten een folder structuur waarin self-focused en snapshotfocused files beiden voorkomen. Nu Climbexion NHSW gebruikt als uitgangspunt, is het logisch dat hieraan aandacht wordt besteed Envelopes In Synergy kent men tasks. Een task verwijst naar een problem report, change request of planning item, of een andere werk opdracht. Als je zo'n problem report of ander item oplost, dan zie je dat toch vooral als een stukje arbeid. We zullen ze daarom work-item noemen. Bij een overdracht van wijzigingen vanaf een satellite naar een team-drawer, staan de wijzigingen in de task. De task wordt voorgedragen en als alles goed gaat overgedragen. De overdracht van een task is een transaction, (een atomaire wijziging). Ook het inlijven van een nieuwe baseline in een team-drawer is een task. Wijzigingen, die van het ene project doorgevoerd worden in het andere, gebeuren door een task te kopiëren, en mogelijk, de kopie te modificeren. In Climbexion zullen we spreken over een envelope in plaats van een task. Want task is een begrip uit het planning en tracking gebeuren. Een envelope is voor vervoer, waar een folder is voor opbergen op een vaste plaats. Een envelope doorloopt stadia: Preparation, Transferred, Unallocated, Pagina: 75 / 230

76 2.2 Begrippen Rejected, Implemented. Bij de meeste stadia hoort een drawer waarin de wijzigingen zijn aangebracht die in de envelope staan. De drawers waartussen de envelope pendelt behoren tot dezelfde constellation. Te overwegen valt het woord briefcase voor envelope. Dit woord laat zich vertalen als aktetas, en is mogelijk wat minder geassocieerd met mail en messages, dus met andere begrippen uit groupware en project management. Naast de wijzigingen staan in de envelope de base versions, base names, en base folder references, zoals aangegeven door het team member, of zoals afgeleid door de SCM software. Dus: de nieuwe version x van element A is bedoeld als wijziging op de base version b. De gewijzigde name, of folder reference of version noemen we labored. De base version is ter controle. Als een labored version wordt overgedragen naar de team-drawer dan moet de base version gelijk zijn aan de tip version van de team-drawer. Zodra iemand begint aan het uitvoeren van een oplossing, maakt hij een envelope aan, of hij ontvangt de envelope van een voortgangsmanager. De te wijzigen files en hun course-item in de team-drawer worden toegevoegd aan de envelope: dit is de basis van de wijzigingen. In feite wordt niet de timestamp van het course-item toegevoegd aan de envelope, maar name, folder reference of version-id, afhankelijk van de aard van de wijziging. De file in de team-drawer wordt er (virtueel) door gemarkeerd, en een relatie wordt gelegd met het team member. Hierdoor moet het voor ieder team member zichtbaar zijn dat er aan de file wordt gewerkt. Overleg kan plaats vinden als een ander de file reeds heeft gemarkeerd. Deze markering zorgt voor een zo vroeg mogelijk inzicht in problemen met parallel updates. Als een envelope wordt overgedragen, is ook dit zichtbaar voor iedereen, want dan komen de labored resultaten beschikbaar. Iemand die zijn envelope wil overdragen en ziet dat een file inmiddels is gewijzigd moet een mogelijkheid krijgen om zijn wijzigingen te baseren op het te verwachten, of mogelijk reeds gerealiseerde nieuwe courseitem. De markering schuift dan naar dit nieuwe item. Envelope state diagram State transitions worden gerealiseerd in passages Pagina: 76 / 230 Er is een speciale satellite, de transfer-drawer. Deze begint de dag, als alles goed gaat, met dezelfde tip als de team-drawer. De inhoud van envelopes die worden overgedragen wordt hierin meteen tijdens overdracht geplaatst, waarbij controle plaatsvindt of elk element in de envelope wel de juiste basis heeft dat wil zeggen dat de wijziging gebaseerd moet zijn op de tip van de transfer-drawer, anders wordt de hele envelope geweigerd. 's Avonds als een acceptatie test goed verloopt dan worden de verzamelde envelopes één voor één overgedragen naar de team-drawer. 's Nachts wordt een nieuwe tag voor de team-drawer aangemaakt. Mocht er een fout optreden in de acceptatie test dan kan besloten worden om een envelope te weigeren.

77 2.2 Begrippen De transfer-drawer wordt dan opnieuw gesynchroniseerd met de team-drawer en de envelopes worden opnieuw aangebracht, behalve de geweigerde. Eventuele afhankelijke envelopes, met elements die geen geldige basis meer hebben, omdat ze gebaseerd zijn op de geweigerde envelope worden dan eveneens geweigerd. Nadat een envelope is overgedragen naar de team-drawer is hij geïmplementeerd. Opmerking: de acceptatie test is slechts een deel van de daily test (regressie test). Niet alle projects gebruiken een acceptatie test en vaak alleen in de development fase. Wel worden er altijd ter acceptatie bepaalde builds uitgevoerd, die zonder compilatie-fouten moeten verlopen. Strikt genomen is een transfer-drawer niet nodig, omdat envelopes ook uitgeschakeld kunnen worden in de center-drawer, door de courses uit te breiden met events waarin de wijziging ongedaan wordt gemaakt. Door dit in een transfer-drawer te doen, blijven echter de courses in het center meer toegespitst op hun gebruik bij het vinden van fouten. Dit gaat dan ten koste van project evaluaties, waar je ter lering en vermaak graag de onvolkomenheden bij (de voorbereiding van) transfers in kaart brengt, maar die zijn terug te vinden in de transfer-drawer. De acceptatie test is geen volledige regressie test, maar meer een soort garantie dat de software bruikbaar is voor tests en debugging. Het is een unattended test, die geen menselijke waarneming of handeling behoeft. TV en Image generators worden aangestuurd door het test-script en in plaats van beeld- en geluid- waarnemingen door mensen vergelijkt het script variables en notifications met een norm. (De term in plaats van die ik gebruikte is een slordigheid In een attended test kunnen ook variables en notifications worden vergeleken met een norm, maar daarnaast kunnen ook menselijke handelingen worden uitgevoerd, en menselijke geluid en beeld waarnemingen bijdragen aan het test resultaat). Behalve de binary voor de test op een platform worden ook een aantal andere binaries (executables) gemaakt. Als één zo'n build mislukt, dan is dat dezelfde soort situatie als wanneer de test mislukt, en wordt er navenant gehandeld. Een envelope start zijn leven in een satellite. Bij iedere transitie verhuist hij naar een andere drawer. Deze transities vormen een course of development. Bij iedere transitie behoort de inhoud zoals die tot dan toe is bijgehouden. Deze inhoud is vanaf dat moment frozen. In de state Preparing kan een inhoud worden voorbereid die frozen is na transitie. Nieuwe wijzigingen vervangen niet de frozen content, maar worden opgebouwd voor een nieuwe transities. Bij envelopes spreken we over passage in plaats van snapshot bij zo'n state overgang. Bij een passage hoort een bepaalde changeset, die is toegespitst op de ontvangende drawer, tenminste als er niet sprake is van een terug verwijzing, of een voortijdige beëindiging. In het state diagram zijn state overgangen gekleurd die een changeset toevoegen aan een drawer. De events die een state overgang uitlokken zijn menselijke beslissingen die gerealiseerd worden door Climbexion commands. Alleen de overgangen naar de end state zijn automatisch (en ogenblikkelijk). Een satellite kan op een aantal manieren gewijzigd worden. Sommige wijzigingen vereisen een envelope, andere niet. Sommigen wijzigen een bestaande envelope, andere niet. In principe zijn alle acties die gegevens uit de team-drawer in de satellite kopiëren, en alle acties die gegevens uit andere drawers in de satellite kopiëren wijzigingen die niet via een envelope komen: het zijn autonome changesets. Wel kunnen dergelijke wijzigingen de envelope wijzigen die wordt voorbereid voor overdracht. Synchronisatie met de team-drawer realiseert het snapshot van zijn tip-tag in de satellite en de working-tree: er ontstaat een nieuwe basis voor wijzigingen. Een gewijzigde basis kan de envelope wijzigingen, de merge van een voorheen reeds gewijzigde file, en de nieuwe tip, Pagina: 77 / 230

78 2.2 Begrippen met de vorige base als original kan daarna de envelope wijzigen. Voor de begrippen base, merge, original: zie de sectie over merging: Er wordt niet alleen gesynchroniseerd met de tip-tag. Synchronisatie met de (verwachte) tip wijzigt satellite en working-tree. Een gewijzigde basis kan een envelope wijzigen. Een daarop volgende merge ook. Manueel wijzigen van names en folder references. Dit gebeurt met Climbexion software. Ook de dood van een element wordt zo gerealiseerd. Dit wijzigt de working-tree. Om de tip van de satellite te wijzigen moeten de wijzigingen daarna of gelijktijdig worden vastgelegd. Sommige wijzigingen worden vastgelegd in de envelope, en dus in de satellite, en sommige worden eerst alleen in de satellite vastgelegd, en later mogelijk in de envelope. Manueel wijzigen van names en verplaatsen van elements in de working-tree met andere dan Climbexion tools, moet worden ontraden, maar is niet uit te sluiten. Dergelijke wijzigingen kunnen met gecompliceerde commits worden vastgelegd. Wijzigen of nieuw creëren van een file met een editor wijzigt de working-tree, daarna kan de file vastgelegd worden in de drawer, en mogelijk in de envelope. In de working-tree kunnen files gewijzigd worden door het resultaat van query's in beschikbare Climbexion drawers. Dit betekent in eerste instantie: geen wijziging in een envelope. Pas als de files vastgelegd worden, wordt de envelope bijgehouden. Overigens moet deze methode worden afgeraden, omdat zo geen herkomst relaties kunnen worden gedetecteerd door Climbexion. Door dergelijke queries vast te leggen in envelopes is er een herkomst relatie, en een lijst van wijzigingen die moeten worden geïncorporeerd. Bij iedere passage kan een andere persoon betrokken zijn. Dit moet geregistreerd worden in envelope. Er kunnen 2 personen betrokken zijn bij een implementatie, een software ontwikkelaar in het stadium preparing brengt de envelope in het stadium transfered, en een build manager brengt de envelope in het stadium implemented. Deze mensen worden geregistreerd in de envelope. Een envelope die 20 passages meemaakt, zal mogelijk 21 namen bevatten: één per transfer, en de naam van degene voor wie de envelope nu preparing is. Om een envelope over te hevelen van de ene ontwikkelaar naar de andere, zal de ene hem in het stadium unallocated brengen, Nu is hij beschikbaar voor een voortgangsmanager, die hem opnieuw kan toewijzen. Daarna zal de envelope door de ontwikkelaar worden gebonden aan één van zijn satellites, en opnieuw preparing zijn. Het binnenhalen van een package in de import-drawer, en het plaatsen van een package in een export-drawer vindt plaats met een envelope die minder stadia doorloopt. Ook het initieel vullen en op orde brengen van een team-drawer kan plaatsvinden met envelopes die minder stadia doorlopen, omdat er nog geen eisen worden gesteld aan het center-drawer, zoals compileerbaar, of doorstaat test. Er komen waarschijnlijk speciale envelopes voor het binnenhalen van package baselines in de import-drawer, of het kopiëren van een package baseline in een export-drawer. Die zijn waarschijnlijk simpeler dan een envelope met volledige stadia voor de team-drawer. Eén enkele envelope kan slecht wijzigingen bevatten voor één package. Voor complexe wijzigingen vanuit één satellite kunnen soms een aantal bij elkaar horende envelopes nodig zijn: er is er minstens één per package. De envelopes uit zo'n groep worden comrades genoemd. Er wordt een comrade volgorde vastgelegd zodat eventueel een labored version in de ene envelope kan dienen als base in een volgende. Pagina: 78 / 230

79 2.2 Begrippen Naast comrades die samen en tegelijkertijd, als één transaction worden overgedragen, kan het nog voorkomen dat een work-item niet meteen goed is opgelost met één envelope. Later start dan een andere envelope, waarmee het probleem hopelijk wel goed wordt opgelost. Deze envelopes vormen een succession. Tenslotte kan er een relatie bestaan tussen envelopes als de één de wijziging van de ander overneemt, zodat de wijziging gerealiseerd wordt in binnen twee constellations. De ene is de model envelope, en de andere de adopt envelope. Een voorbeeld van een envelope is te vinden in sectie Baseline supplements, external envelopes In Climbexion zijn baseline supplements het smeermiddel waardoor de teams onderling min of meer onafhankelijk kunnen bewegen. Er zijn een aantal scenario's waarin deze patches nuttig zijn: Nadat een baseline is uitgegeven wordt een fout ontdekt die de voortgang van testers of ontwikkelaars ernstig belemmerd, of mijlpaal audits laat stranden, of een certificaat aanvraag of deelname aan een beurs frustreert. Een wijziging vraagt een aanpassing in de packages van 2 teams. Het ene team gebruikt een tijdelijke wijziging in een package van de ander (en het ander mogelijk een tijdelijke wijziging in een package van het éne). Een team gebruikt een bepaalde (ongebruikelijke) combinatie van baselines van packages die een incompatibiliteit opleveren, het smeermiddel maakt dat ze er nog even mee door kunnen gaan. Soms wil/moet een team zich concentreren op de eigen software ontwikkeling, en wil zich dan niet bezighouden met het invoeren van de baselines van van andere teams. Dan kan er een probleem ontstaan dat opgelost wordt met baseline supplements. Vaak zijn baseline supplements een middel om voort te gaan als plannen mislukken. Baseline supplements zijn, het woord zegt het al, een aanvulling op baselines. Soms is een baseline supplement onafhankelijk, soms is een combinatie van supplements nodig. Bijvoorbeeld als meerdere packages in combinatie moeten worden gewijzigd, of als supplement over supplement voorkomt. Bij baseline supplements geldt: De changeset komt te staan in een external envelope voor een wijziging die wordt aangebracht door een team op een package waarop het is geabonneerd. Vaak wordt de changeset ontwikkeld door het team dat er behoefte aan heeft, maar het team dat verantwoordelijk is voor het package is eindverantwoordelijk en geeft de external envelope uit. Een baseline supplement bevat een external envelope omdat een internal envelope circuleert binnen een specifiek met name genoemde constellation. Waarom een envelope en niet simpel weg een changeset? Wel dit is met het oog op wijziging over wijziging, en wijzigingen die in meerdere baselines moeten worden gerealiseerd, er is vaak een mogelijkheid om dit te realiseren met meerdere base/labored paren in de external envelope. Bij een baseline supplements hoort een sheet met de volgende inhoud: Identificatie van het supplement. Het subproject en de identificatie van degene die hem uitgeeft. Package en baseline(s) waarop het supplement kan worden toegepast. Het probleem dat met het supplement wordt opgelost. Baselines van andere packages dan die waarin het supplement functioneert. Andere supplements die ook moeten worden geïmplementeerd. Pagina: 79 / 230

80 2.2 Begrippen De baseline waarin het supplement niet meer nodig is. De overeenkomstige supplements voor andere baseline combinaties van eigen en andere packages. De external envelope die bij een supplement hoort wordt gemaakt in een satellite van een drawer waarin alle baselines van het betreffende package worden bewaard: de baseline-drawer. Er vindt misschien een overdracht plaats naar de center-drawer, maar zeker naar het patch registratie system, en vandaar naar de team-drawers van de teams die er behoefte aan hebben. Waarschijnlijk komt de sheet in het patch registratie systeem van het master project, maar komen de bijbehorende envelopes in hun export pools, om van daar uit verstuurd te worden naar ieder die er om vraagt. Ook de baselines van packages zouden mogelijk in dit systeem geregistreerd moeten staan, met een verwijzing naar de export drawers, en misschien met een uittreksel (een sheet) van het baseline report. Het wordt dan een baseline en patch registratie systeem. In de satellite vindt eerst een query plaats waarmee een baseline combinatie van packages wordt gerealiseerd als basis waarop de wijziging moet plaatsvinden, eigen packages komt waarschijnlijk uit de baseline-drawer, de overigen mogelijk uit import-drawers. De gewijzigde files zelf en de external envelope kunnen worden aangeleverd aan de integrator door een team waarin ze zijn uitgeprobeerd, of ze worden gemaakt door of namens de integrator van het team dat de envelope uitgeeft. Als een ander team de external envelope voorbereidt dan is er een mogelijk een half security probleem: normaal wijzig je als team alleen je eigen packages. Nu wordt van een team verlangd dat het wijzigt in het package van een ander. De nieuwe versions komen nu niet via importeren bij de package owner vandaan, maar verschijnen via commit in de version pool van degene die de external envelope maakt. De owner van het betreffende package heeft in principe geen autorisatie over een pool die in beheer is bij een ander team, dus er is geen harde protectie tegen lokale wijzigingen, hoogstens kan een team zelf een protectie instellen om zichzelf te behoeden voor ondoordacht wijzigingen in andermans package. Het is dan deze security die tijdelijk moet worden uitgeschakeld. Een baseline supplements scenario Pagina: 80 / 230

81 2.2 Begrippen Er wordt een baseline supplement gemaakt zonder export limitations. Daar worden supplements vanaf geleid, met export limitations die behoren bij de toegangsrechten van de subprojects. Het systeem dat baseline supplements toegankelijk en onderhoudbaar maakt, het patch registratie systeem, is een klein onderdeel van het software configuration management systeem, maar geen onderdeel van Climbexion. In sommige stadia worden wijzigingen niet per baseline maar per changeset doorgegeven naar andere teams In het allerlaatste project stadium, als de projectleider van het master project volledige beheersing wil over de laatste wijzigingen, dan kan hij eisen dat alle wijzigingen doorgegeven worden als basic changesets, in plaats van baselines. Tijdens een field test gaat een groepje engineers een (wereld) reis maken om op locatie de TV te testen. De problemen die ze vinden worden door de thuisbasis zo snel mogelijk opgelost, en de oplossingen worden zo snel mogelijk doorgegeven aan de field testers. De teams van de thuisbasis wisselen hier wijzigingen uit door middel van basic changesets. In deze gevallen is er sprake van een gewone external envelope, die met een sterk vereenvoudigd sheet wordt aangeleverd aan het patch systeem. In zo'n laatste stadium is sprake van zuiver distributed SCM. Maar toch blijven de teams daarnaast nog baselines uitgeven, compleet met baseline tests en baseline reports. Dit gebeurt om zicht te houden op het bereikte stadium, en om de kwaliteit van de software te waarborgen. Daarom wordt de baseline als test en verificatie discipline gehandhaafd Resources In zijn algemeenheid geldt dat resources identificeerbaar zijn met een URL 1. Kin Pools Lichtzinnig heb ik ervoor gekozen om entity types, en misschien toegestane names en folder references op te nemen bij kins. Hierdoor zijn het objecten geworden die moeten worden opgeslagen. Indien we ervan afzien zouden het codes zijn die bij het kopiëren mee gekopieerd worden. Opgeslagen kins: één centrale database per package. Eigenaar van een package database is de party van het subproject. Om security redenen, ten behoeve van beschikbaarheid en performance, en om garbage collection te vermijden zou men kunnen werken met local pools voor bepaalde locaties. Naast een centrale pool kunnen er local pools worden gebruikt op Pc's en bij third parties. Local pools op Pc's bedienen de satellites en mogelijk de clones op de PC, Uittreksels bij andere subprojects bedienen daar de import-drawers, en development drawers. Er is dan een gedistribueerde discipline wenselijk, met name om gewijzigde attributes aan elkaar door te geven. 2. Version pools Hiervoor geldt in principe hetzelfde: een centrale opslag capaciteit per package. Deze opslag wordt niet toegankelijk gemaakt door een database server maar door een file server. Echter de toegangsrechten worden bepaald door de rechten in de drawers en packages waarin de versions worden gebruikt. In principe zijn er twee soorten recht: het recht om een version te lezen, en het recht om een version toe te voegen. Om security redenen, ten behoeve van beschikbaarheid en performance, en om garbage collection te vermijden op de centrale pool zou men kunnen werken met local pools. Hiervoor geldt hetzelfde als voor kins. Mogelijk is er een gecombineerde pool voor Pagina: 81 / 230

82 2.2 Begrippen versions en kins. Het werken met local pools betekent wel, dat er bij overdrachten en synchronisaties niet alleen versies gekopieerd worden van of naar working-trees, maar dat er ook gekopieerd wordt tussen pools. Indien men strikt met local pools werkt, zou de centrale pool geen content hoeven te bevatten, maar uitsluitend attributes. Deze centrale pool speelt dan een rol bij het doorvoeren van attribute wijzigingen. Een probleem met local pools wordt veroorzaakt door de attributes. Dit geldt voor versions en voor kins. Normaal worden pools bijgewerkt door synchronisaties van drawers of packages, of door transfers, of omdat satellites worden bijgehouden vanuit working-trees (commit). Hierbij zijn een tweetal drawers betrokken, of een drawer en een working-tree. Wordt echter een attribute bijgewerkt in een (local) pool, dat moeten de attributes worden bijgewerkt in alle local pools van het package, tenminste als daar de version of de kin voorkomt. Er zijn wat implementatie mogelijkheden: 1. Er is een push mechanisme zonder dat een specifiek target is opgegeven door een gebruiker. Alle locations kunnen target zijn, en moeten bekend zijn in het climbexion systeem. 2. Er is een pull mechanisme. Alle locations waarin deze attributes kunnen wijzigen moeten bekend zijn in de location die zijn pools up-to-date brengt 3. Een push /pull combinatie: een push naar een universeel bereikbare location vindt plaats in de location waar een attribute is gewijzigd, een pull vindt (periodiek) plaats in iedere location. Daar worden de wijzigingen getrokken uit de universeel bereikbare location. Ieder package kan zijn eigen center location alloceren. Als een kin of version voor het eerst gekopieerd wordt vanuit de ene location naar de andere, dan wordt ook de center location bijgewerkt met die kin of met die version. Wordt daarna een attribute gewijzigd dan wordt dit doorgegeven naar de center location. Als een kin of een version niet te vinden is in de center location, dan wordt een lokale attribute wijziging ook niet doorgegeven. Deze derde methode zal waarschijnlijk worden geïmplementeerd, omdat die nauwelijks administratie vereist. 4. Een universeel bereikbare plaats voor het doorgeven van version attributes, hoeft zelf geen version content te bevatten, alleen de identifier en de attributes volstaat. 3. Packages. De centrale pools van een package staan op een location met een package gerelateerde URL Het package is onder meer identificeerbaar met behulp van deze URL 4. Pools voor other-focused files. Wijzigingen moeten worden doorgevoerd in locale pools en in working-trees en info-trees. Ook hiervoor is een goede push/pull discipline nodig, en goede hulpmiddelen om de discipline te realiseren. 5. Pools voor envelopes. Envelopes horen bij het subproject, bij de drawer constellation waarbinnen ze de wijzigingen transporteren, ze staan in een constellation gerelateerde pool. Ze kunnen ontstaan op een laptop, maar zodra hun inhoud publiek is moeten ze ook zijn geplaatst in een constellation pool. In het stadium prepared wordt in de constellation pool de envelope bijgehouden met de base items waarop gewijzigd gaat worden. Op de PC wordt een pool bijgehouden waarin ook de labored items staan. Bij de overgang naar transfered wordt de envelope in de constellation pool voorzien van de labored items. Pagina: 82 / 230

83 2.2 Begrippen 6. Pools voor external envelopes. De external envelope ontstaat als een gewone envelope in een constellation pool, en wordt gekopieerd in een (master) project pool. Sheets kunnen waarschijnlijk ontstaan en blijven in een (master) project database, want er zijn allerlei query's op de verzameling sheets, bijvoorbeeld welke patches zijn er op baseline X van subsysteem S of welke patches kunnen er zijn op andere packages als ik baseline X van package S implementeer. Het database systeem waarin de sheets release supplements (en misschien ook die van releases) worden bewaard valt buiten de scope van Climbexion. 7. Drawers. Een drawer wordt gealloceerd in een file system. Waarschijnlijk behoeven packages geen zelfstandige allocatie, maar kunnen ze deel uitmaken van de drawer. Een drawer kent een aantal structuren. In de eerste plaats is een drawer een lineaire structuur van packages. Een package heeft een content van elements, elements hebben een development course, en zijn mogelijk gegroepeerd per soort: files bij files, folders bij folders, cross references bij elkaar, package references bij elkaar. Dan is elk package te zien als een opeenvolging van changesets, en tenslotte is elk snapshot in een package te zien als een folder-tree, Een tag is een snapshot over alle packages in een drawer met een integrale folder tree. 8. Parties, teams, users, projects registration. Misschien is het zinvol om hier ook een URL voor te reserveren. Iedere party heeft hiervoor een eigen administrator database. Daarnaast kunnen er registraties nodig zijn in de computers met drawers en pools. Systeembeheerders, bijvoorbeeld providers van services hebben namelijk ook hun eigen administrator, en security faciliteiten. 9. Files, folders, en andere elements Ze worden geïdentificeerd door hun kin en hun drawer. Snapshots die naar buiten komen, in infotrees of working-trees krijgen hun eigen path-name. Ze worden over het algemeen lokaal geïdentificeerd. 10. Tenslotte Van iedere resource bestaat minstens één kopie. Meerdere kopieën op meerdere plaatsen zijn mogelijk als de betreffende file of database server daarin voorziet. Voorlopig zullen hoogstens beperkte voorzieningen worden getroffen voor lokale kopieën die door Climbexion worden bijgehouden. Een vertaling van een package, een party, een team, een project of een combinatie hiervan in een URL gebeurt met gegevens die geleverd worden vanuit de administrator database. Het kan voorkomen dat een version in een satellite uiteindelijk niet overgedragen wordt, en mag vervallen als de satellite wordt opgeschoond of opgedoekt. Hetzelfde geldt voor envelopes. Dit vindt plaats in pools van de betreffende location. Pagina: 83 / 230

84 2.3 Metadata 2.3 Metadata Inleiding De keuze om allerlei attributes te specificeren, de keuze om hier een course of metadata corrections voor bij te houden: dat is typisch het terrein van de kamergeleerde, het plezier om dit soort dingen te bedenken en te maken. Ik heb nu niets te maken met mensen die zeggen: maar dat komt toch nooit voor in de praktijk dat dat fout gaat, je moet praktisch blijven. (Terwijl we geen van beide eigenlijk beschikken over goed vastgelegde metingen). Het geheel aan doelstellingen voor Climbexion rechtvaardigt het gebruik van metadata courses of corrections. Wel verwacht ik een soort self fulfilling prophecy, als je attributes niet kunt wijzigen, dan bedenk je je wel twee keer voor je ze één keer invoert, als je ze kunt wijzigen dan zou je slordiger kunnen worden, en na een fout moet je ze dan wel wijzigen. Dan zeg je natuurlijk: Goed dat het kan. Zijn er alternatieven voor het verbeteren van attributes? Een event of een version met foute attributes kan worden opgevolgd door een event of version met correcte attributes. Een kin met een fout attribute kun je verlaten en verder gaan met een kin waarin het attribute wel goed is. Bij een fout element attribute zou je het element moeten beëindigen, om een nieuw element te beginnen met het correcte attribute. Hiervoor zou de uitspraak: een element vertegenwoordigd de kin in de drawer, niet langer gelezen mogen worden als: een element vertegenwoordigd als enige de kin, maar meer als op enig tijdstip is er hoogstens één element dat de kin vertegenwoordigd. Alleen al omdat ik de eerste lezing omarm, en de tweede verwerp, moet het mogelijk zijn om fouten te verbeteren. In principe gaat het om uitspraken: in een event is een stuk historie vastgelegd, maar er worden ook een aantal uitspraken vastgelegd over dat event. In een repository worden een aantal kins vastgelegd, maar ook een aantal uitspraken over de kins. In een drawer worden een aantal files vastgelegd, maar ook een aantal uitspraken over de files. In een pool worden een aantal versions vastgelegd, met uitspraken over die version. Voor deze uitspraken geldt: Elke mogelijke uitspraak zou moeten kunnen wijzigen in elke mogelijke andere liefst zinvolle uitspraak. Een uitspraak vandaag over een historisch feit gisteren moet mogelijk zijn Attributes, soorten en maten Over file karakteristieken kan het nodige gezegd worden. Op de IBM mainframes waarop ik ooit werkte had een file karakteristieken als bloklengte, recordlengte, recordformat, access methode, wijze van space allocation, om maar eens wat te noemen, om zo'n file te kunnen maken moeten al die karakteristieken worden opgegeven. Momenteel is er de Mime standaard, waarin file-types gekarakteriseerd zijn met 2 trefwoorden, bijvoorbeeld voor een adobe acrobat file: application/vnd.adobe.edn. Doorgaans herken je het file-type aan de extensie van de file. In de property sheet van de file explorer van mijn windows (98) systeem zit een tabblad met file extensies, mime-types en Pagina: 84 / 230

85 2.3 Metadata dergelijke. Bij een bepaald type hoort een programma om zo'n file te wijzigen, een viewer, en mogelijk nog meer software. In het revision control system is een dergelijke lijst ook nodig. We willen bijvoorbeeld weten of er een merge programma bestaat voor een bepaald filetype, of een pretty print formatting programma. De build folders die opgeslagen worden in het revision control system kunnen worden geplaatst in een archief-file (bijvoorbeeld een.zip file of een.tar.gz file) bij opslag, en de archief-file moet (meestal) worden uitgepakt als ze in een working-tree of info-tree wordt gedownload: dus build archief folder is van een ander type dan een file of een gewone folder. De folders in de NHSW folder tree zijn in te delen in soorten, sommige zijn er voor interfaces, anderen zijn een componenten set, weer anderen een enkele component enzovoort. De architecten hebben entity types voor ze bedacht. revision control programma's die een snapshot van een drawer zichtbaar maken kunnen een viewer aanroepen, als de inhoud van een version moet worden bekeken. Hiervoor moet je het type weten. Bij merging is er sprake van bases, neighbors en originals. Die moeten tot hetzelfde type behoren, en het type moet bediend worden door het merge programma. Er zijn diverse conventies voor carriage/return characters in tekst files. De gebruikte conventie is een attribute van de version, Als wordt gedownload in een omgeving met een andere conventie, dan moet er automatisch worden geconverteerd. In de documentatie van Subversion vond ik nog het volgende: een attribute om aan te geven of een file wel of niet uitvoerbaar is: dit is een Unix attribute. Sommige typen file beginnen met een aanhef waarin Climbexion informatie moet plaatsen als datum, versie, naam van degene die de file gewijzigd of gemaakt heeft, en dergelijke. Andere file-types hebben hiervoor een property sheet (extended metadata). En sommigen hebben helemaal niets. We moeten weten of een file een dergelijke aanhef kan hebben, of een dergelijke property sheet. Dit is dan al één extra attribute. Om informatie te plaatsen moeten er mogelijk additionele attributes worden bijgehouden. Dit feature van revision control systems bestaat in ieder geval reeds sinds SCCS. Het is een klassieker. Berucht in ons wereldje zijn endiaanse problemen met raw file formats, en ASCII /EBCDIC /Unicode conversies van teksten. Hopelijk zijn dergelijke conversies niet nodig, maar als ze nodig zijn, dan moet de betreffende codering samen met de file worden opgeslagen. Een revision control systeem heeft hier een bemiddelende rol tussen diverse omgevingen. Software entiteiten (class, component, procedure en dergelijke) moeten overeenkomen met een file. Om aan te geven wat voor soort entiteit is opgeborgen in de file kun je een attribute gebruiken. Het file-type is dan bijvoorbeeld C++ header file en het entiteit type abstract class. Dit is van belang voor templates en pretty print programma's. Typeringen kunnen van belang zijn om import limitations of export limitations te realiseren Templates, wizards, pretty printing, macro's, en zo In enkele van de revision control systemen waarmee ik heb gewerkt gold: als je een nieuwe file introduceert, en (daarmee een nieuwe kin) dat zijn er twee mogelijkheden: Je bied meteen een version aan. Je registreert de nieuwe version in het revision control system die daarop een nieuwe Pagina: 85 / 230

86 2.3 Metadata maagdelijke working-tree file maakt met behulp van een template. Om een file aan de hand van een template te genereren is het meestal niet voldoende om een filetype te specificeren. Vaak moet de aard van de file moet ook gespecificeerd worden, bijvoorbeeld: dit Kword document is een interface beschrijving, of dit open-office document is een component beschrijving, of deze header file is een applicatie interface. De aard noemen we het entity type. Ik denk dat een template tool buiten Climbexion blijft. Het kan aan de hand van een model file of een model folder een initiële invulling maken. Enige wizard faciliteiten zorgen voor de juiste naamgeving van het element en mogelijk enige interne entiteiten. Het is de bedoeling om dit eenvoudig te houden, om aan de standaards van de architecten te voldoen. Wel zou zo'n tool optioneel de gegenereerde lege elementen moeten kunnen registreren in Climbexion, zodat hun kin gemaakt wordt. Anderzijds moeten ze ook zonder Climbexion kunnen werken, zodat ze behulpzaam kunnen zijn bij het overnemen van oude oplossingen in nieuwe structuren. Dezelfde gegevens kunnen in sommige gevallen gebruikt worden om tijdens commit een version in een working-tree door een pretty print programma te leiden dat de version formatteert volgens een ideaal, voordat die wordt vastgelegd volgens de standaards van de package owner. Versions die gedownload worden in een info-tree of working-tree kunnen wanneer dat gewenst wordt eveneens door een pretty print programma geleid worden, om te voldoen aan lokale standaards. Zoiets heb ik ooit meegemaakt geloof ik. Deze programma's horen ook niet bij Climbexion. Hun gebruik als filter kan voor Climbexion hinderlijk zijn. Versions worden waarschijnlijk geïdentificeerd door een hash van hun inhoud. De version die aangeboden wordt aan een filter heeft een andere identificatie dan de version die het filter verlaat. Het file-type kan ook gebruikt worden door een version control system om vast te stellen dat de file macro's kan bevatten, die revision control data plaatsen in een comment paragraaf, of dat de file een property sheet (extended metadata) bevat die ingevuld moet worden met revision control data volgens een template. In een comment paragraaf worden de waarden ingevuld die de macro's genereren. De waarden kunnen het best worden ingevuld als de version in een working-tree of infotree geplaatst wordt. De waarden worden het best verwijderd tijdens commit of als de version betrokken is bij een merge. Hiervoor geldt hetzelfde als pretty print: ze zijn hinderlijk omdat ze een moderne version identificatie hinderen. Advies: gebruik deze macro's niet in content. Voor de property sheet met extended metadata geldt mogelijk niet het probleem van de content hash. Speciale macro's specificeren welke repository data in de metadata van een working-tree, of info-tree file terechtkomt. Gebruik extended metadata in plaats van macro's in de code. Over het algemeen zullen de templates en de pretty print regels vastgelegd zijn per package. In configuratie files en template files die in het package zijn opgenomen. De hulpprogramma's zelf. kunnen eventueel staan in een tools folder van het package. Pretty print hoort eerder thuis in een build dan in een commit, samen met een eventuele static analyzer. De pretty print regels voor het plaatsen in info-tree en working-tree kunnen thuishoren in het toppackage, eventueel met bijbehorende tools. Andere begeleidende tools zijn merge programma's die gebruikt worden om parallel wijzigen en ontwikkelen mogelijk te maken, en misschien een static analyzer die een aanvulling is op een merge programma, om mogelijke fouten van een merge operatie te signaleren. Analyzers kunnen specifiek Pagina: 86 / 230

87 2.3 Metadata zijn voor file-types en/of entity types. Merge programma's moeten mogelijk in staat zijn om hun input versions rechtstreeks te lezen uit Climbexion. Hun output komt in de working-tree, en kan daar verder geanalyseerd en bewerkt worden, om daarna met commit in de repository opgenomen te worden File-type Als je kijkt naar een filenaam, dan begint die met een pad: een reeks folder namen. Daarna komt de naam, en tenslotte de extensie. De extensie is rechtstreeks afleidbaar uit het file-type. Als je het filetype bijhoud, dan zou extensie geen onderdeel van de name horen te zijn, althans onder Windows. Er is best wel een probleem met een attribute als file-type Als het een attribute is van version en de waarde is fout, dan is er best kans dat je een heel traject aan versions in een course moet wijzigen. Dit duidt op een slechte normalisatie: file-type is een eigenschap van de file, met een course of development, en een course of metadata corrections. Er zou dus een development course item File-type moeten bestaan met een file-type attribute en een valid time attribute die corrigeerbaar zijn. Nu neem je een bestaande version en plaatst die in de tip van een file in een drawer, Deze file is bijvoorbeeld een Visio plaatje, en de nieuwe version, ik noem maar iets, is een Smartdraw plaatje, en is gekopieerd uit een file die een Smartdraw plaatje is. Als file-type een eigenschap is van de file, dan is hierna de version meertypig, in twee courses met ieder een eigen type. Dat kan natuurlijk niet, en deze mogelijkheid duidt op een slechte data structurering: file-type moet een eigenschap zijn van de version. Blijkbaar gelden beide regels. Voor de repository kies ik voor een implementatie die de combinatie van valid time en transaction time vermijdt. Het overnemen van versions uit andere drawers moet probleemloos verlopen: een eigenschap als file-type wordt een directe eigenschap van de version, zodat de eigenschap gaat gelden voor de file als de version wordt geïntroduceerd. De course of development van de eigenschap in de file wordt wanneer nodig, met een algoritme bepaald. En er is het automatisme dat een nieuw gecreëerde version het huidige file-type erft van zijn voorganger in de course, tenzij anders vermeld. Mogelijk komen er handige opdrachten die attributes in een reeks versions in een traject van de course wijzigen, mocht een verbetering van het type nodig zijn Ook geldt: als zo'n attribute van een version verbeterd is en daardoor is gaan afwijken van een opvolger, dan moet dit in de course van de file gemarkeerd worden, als je die bekijkt. Als het attribute verbeterd moet worden, en de version is wijd uitgezwermd over de drawers en heeft op veel plaatsen opvolgers, dan moet er heel wat uitgezocht worden om alle courses in beeld te krijgen, die verbeterd moeten worden. Dat verbeteren kan dan weer met de handige opdrachten, dat wel, maar ja dan zijn er weer nieuwe verbeterde versies die uitgezwermd kunnen zijn, in weer andere drawers. Voorkomen is stukken beter dan genezen, maar als er moet worden genezen, dan is het goed als er middelen voorhanden zijn. De kans op onopzettelijke fouten is erg klein, omdat op de desktop de file extensie gebruikt wordt door allerlei software. De meeste fouten zullen waarschijnlijk aanloop fouten zijn, als een file geregistreerd wordt in Climbexion voordat de eerste version gemaakt wordt op de laptop of desktop, waarna de version gegenereerd wordt met hulp van een sjabloon. Er is dan nog geen uitzaaiing. Het is zeker dat er opzettelijke fouten kunnen worden gemaakt. Dat wordt bijvoorbeeld Pagina: 87 / 230

88 2.3 Metadata gebruikt bij het testen van Climbexion. Dus is er een rechtvaardiging voor het corrigeerbaar zijn van filetype. Introductie van een nieuw file-type in een bestaande course is niet triviaal voor de gebruiker, commit moet immers een (work) file met een andere extensie dan de voorganger koppelen aan een file. Het overnemen in een andere drawer is dan weer gemakkelijk, dan is er een kin match. Met de toekenning van het file-type attribute aan een version lijkt het bijna 100% mogelijk om de juiste typering te specificeren. Echter zonder al te goed je best doet, is het waarschijnlijk mogelijk om een version te maken die aan geen één type beantwoordt. Als ware informatie freak overweeg ik dan ook voor om naast het file-type word document het subtype mislukt word document te specificeren. Hier kun je problemen krijgen met het dualistisch karakter van file-type: zo'n subtype van een word document kan beter niet automatisch doorgegeven worden aan een opvolger. In het ene project kunnen tools gebruikt worden waarin een version goed functioneert, terwijl in een ander project dezelfde version een tool laat crashen. Het specificeren van de juiste subtypes voor files is daarom een kunst op zich zelf. Voorbeeld: File subtypes van Microsoft word zijn bijvoorbeeld: Microsoft word 95 Microsoft word 97 Microsoft word 6.0 Microsoft word Failure Oorspronkelijk hadden we slechts Microsoft word, en closed world subtypes Correct en Failure maar op een gegeven moment raakten we in de problemen. In project A wordt de extensie doc gegenereerd voor: geen subtype attribute Microsoft word 95 en de extensie undoc voor: Microsoft word 97 Microsoft word 6.0 Microsoft word Failure In project B wordt de extensie doc gegenereerd voor: geen subtype attribute Microsoft word 95 Microsoft word 97 Microsoft word 6.0 en de extensie undoc voor: Microsoft word Failure Normaal zal iemand, normaal zal Climbexion, proberen te voorkomen dat failures of niet verwerkbare versions worden doorgegeven van het ene drawer naar het andere, maar zolang het subtype attribute niet correct is bijgewerkt kan de falende version verspreid worden. Er is nog de mogelijkheid dat het ene (sub) project werkt met andere tools dan het andere. Pagina: 88 / 230

89 2.3 Metadata Bijvoorbeeld: het ene project gebruikt MS Word, het andere gebruikt Framemaker, het ene gebruikt Visio, het andere Igrafx Flowcharter. Er moet een mogelijkheid komen om een version te weigeren als het file-type niet wordt ondersteund. Versions komen in een pool. Als er voor een version slechts één pool is dan is er geen probleem. Helaas zullen er lokale pools zijn, en komt een enkele version op meerdere plaatsen voor. Het doorvoeren van file-type correcties zal dan geen eenvoudige zaak zijn. De correctie moet doorgevoerd worden in alle locaties waarin de versie zich bevindt. Als we aannemen dat de locaties waarin een package voorkomt een tree vormen, dan is er een automatisch push mechanisme dat het gewijzigde attribute naar de top duwt. En een pull algoritme waarmee locaties zich up-to-date houden. Dat laatste vereist enige discipline. Programmeer taal Als je een pascal programma een modula programma noemt, dan is dat een bewering die fout is, het is niet de werkelijkheid die geldt voor het programma waarop deze bewering slaat. In principe moet je dit kunnen verbeteren. Aangezien je een zo volledig mogelijke log wilt hebben van alles dat zich afspeelt in de repository, gelden voor dit soort wijzigingen transaction times. Programmeer taal attributes kunnen een course of corrections hebben. Om te beginnen zullen we eens kijken of het een attribute van de kin kan zijn. Een correctie die je vandaag maakt, geldt voor alle versions van de kin, ook die van gisteren. Een conversie van een programma naar een andere taal betekent een nieuwe kin. Dit zouden we kunnen verantwoorden, omdat we verwachten dat een overgang naar een andere taal ook het einde van Koala (als additioneel tool?) betekent. Een groot deel van de architectuur zou meteen mee veranderen, waardoor een mixed language overgang die begint met een één op één file conversie onwaarschijnlijk is. Maar een dergelijke toekenning van dit attribute aan een kin is geen garantie dat de versions werkelijk tot de geregistreerde programmeertaal behoren. Het is een SOLL voorschrift en niet een IST eigenschap. Eén enkele version in een verkeerde taal, en één in de goede, is een niet te repareren inconsistency als het een ist eigenschap betreft. Toch zijn er consequenties, want met behulp van de programmeertaal kan Climbexion de file extensie in een full path name genereren. Het is dan zeker niet een vrijblijvend voorschrift, en een verbetering kan sommige bestaande versions onbruikbaar maken. Als programmeertaal een attribute wordt van de kin, dan is het natuurlijk onzin om mislukt fortran op te nemen als mogelijke subattribute waarde, ook al is er misschien een version die een denial of service teweeg brengt tijdens het compileren. Ook verfijningen, zoals compiler version, zijn niet zinvol voor kins. Tot zover de kin studie. Programmeer taal, is een subset van file-type. We hoeven ze natuurlijk niet speciaal te behandelen. Mijn voorkeur gaat ernaar uit, om het file-type attribute toe te kennen aan versions, en programmeer taal niet speciaal te behandelen, zeker na deze overwegingen. Subtypes voor programma's kunnen worden gebruikt om hun afhankelijkheid aan te geven van target systems, zoals MIPS, ARM, TriMedia. Ook zijn er smaken als 8 bits, 16 bit, 32 bit, 64 bit processors, of endiaanse beperkingen, die voor sommige programma's gelden. Daarnaast zijn er de Pagina: 89 / 230

90 2.3 Metadata diverse compiler/linker systemen. Veel programma's zullen portable zijn, maar mogelijk is het zinvol om voor sommige versions aan te geven dat ze gebonden zijn aan een omgeving zodat gewaarschuwd kan worden als ze worden hergebruikt. Geldt voor programma's dat portabiliteit wel of niet bereikt wordt, voor andere files gelden regels van al dan niet bereikte compatibiliteit. Dit is niet hetzelfde. Programma's zijn individueel te beoordelen op portabiliteit. In een vakkundige omgeving worden er regels opgesteld voor taal features die je wel of niet moet gebruiken om deze portabiliteit te waarborgen. Er zijn tools die statische analyses uitvoeren op programma's om de portabiliteit te waarborgen. Gewone files, die geen programma zijn, en die gemaakt zijn door een bepaalde generatie van een tool, zijn meestal als groep te beoordelen op compatibiliteit met een andere generatie van het tool. Voor het ene filetype kunnen er dus andere regels en algoritmes gelden voor subtyping, dan voor het andere. Koala ontwikkeling Toen we begonnen maakten we van een Koala Component een plaatje: een rechthoek met op de rand de ingaande en uitgaande interfaces, en erbinnen grafische symbolen voor modules, switches en componenten. Die inwendige componenten hebben ook ingaande en uitgaande interfaces. Interfaces zijn binnen de rechthoek verbonden met elkaar, met modules en met switches. Eerst maakten we ze volledig met de hand met Microsoft Visio, later kwam er een tool dat ze genereert. Het tool genereert een nogal lege xml file uit een cd file, als die er nog niet is. Het plaatje dat zo ontstaat ziet er niet uit. Pas als met de hand de symbolen en lijnen op hun plaats zijn gezet is er een redelijk ogend schema. Ook kunnen lijnen worden voorzien van hoeken, zodat we van een druk schema een printplaatachtig schema kunnen maken. Deze gewijzigde en nieuwe posities worden geregistreerd in de xml file. Koala Component Dit plaatje komt uit de Koala documentatie. Het tool om de plaatjes te maken en te bekijken gebruikt de koala cd file en de gelijknamige xml file, die in dezelfde folder staat. Het vereist enige goede wil om de xml versies te zien als de opvolgers van van visio versies, immers de functionaliteit van het visio plaatje wordt niet bereikt met de xml file maar met de combinatie van een cd file en een xml file. Ook is er enige goede wil nodig, omdat het visio plaatje zuiver self-focused is, terwijl de xml file enigszins other-focused lijkt. Als je de situatie nader bekijkt dan zie je dat de xml file een referentie bevat naar de cd-file, dus de cd file wordt door het tool ingelijfd in de xml file om het plaatje te genereren, zoals een header file wordt ingelijfd in een C file om een object file te maken. Het blijkt dus toch een self-focused source file te zijn. Dus kunnen we besluiten om de MS visio" versies van de file op te volgen met koala graphic versies Entity type Het entity type geeft de aard van een file of folder weer. Bijvoorbeeld: de file is een component beschrijving, of een abstract datatype, of een test resultaat. Of bijvoorbeeld: de folder is een component, de folder bevat public interfaces, of unit-tests. Pagina: 90 / 230

91 2.3 Metadata Het is niet goed voorstelbaar dat je één kin hebt waarvan sommige files of versions een component beschrijving zijn en anderen een test resultaat. Soms is het misschien dubieus of je een file op een bepaalde manier mag voortzetten of dat je een nieuwe file en daarmee een nieuwe kin moet beginnen. Maar als er één attribute in aanmerking komt om een eigenschap van een kin te zijn dan is het wel het entity type. Versions met een verschillende aard horen niet in dezelfde file of in dezelfde kin. Het is wel een typisch soll attribute, gewoon omdat het een intentie is van de kin en van degene die de kin maakte die niet automatisch geldt voor elke version. Je kunt daarin fouten maken. In ieder geval kan ik deze fouten opzettelijk maken, dus mogelijk kan het ook per ongeluk gebeuren. Correctie is nuttig als je per ongeluk een verkeerde entity type waarde hebt geselecteerd of getypt bij het aanmaken van de kin, maar is niet mogelijk na commit van een version met een verkeerde aard (misschien moet je bij een version in een attribute aangeven dat het item een vergissing was). Moet je een course bijhouden van de corrections? Ach, waarom niet, nu we in zijn algemeenheid hiervan gebruik maken. Een toepassing van entity type is ongetwijfeld het gebruik in import limitations. Een andere belangrijke toepassing is de mogelijkheid om templates te bieden. Templates zijn niet slechts van belang voor files, maar zeker ook voor folders. Hun type bepaald vaak al welke files en subfolders erin moeten of mogen voorkomen. Koala is een programma dat tijdens build begrenzingen vast stelt, voor dependency lists, en van de sources die nodig zijn om een executable, te maken. Hierbij wordt gebruik gemaakt van het entity type van folders, om packages, component folders, interface folders, tools folders, test harness folders, scoop folders, en dergelijke te herkennen. Momenteel wordt daarvoor de naamgeving en structuur van folders gebruikt, en natuurlijk de files die erin staan. Legacy en verschillen tussen teams kunnen een belasting gaan vormen die mogelijk met entity metadata is te voorkomen. Ik denk dat er een probleem kan zijn met entity type. De levensduur van een package, en daarmee de levensduur van een kin is veel groter dan die van een project. Dat betekent minstens dat de codering van een entity type kan veranderen. Al was het alleen maar omdat een uniforme codering binnen een master project gewenst kan zijn. En anders zijn er wel internationale standaards, of tools die een bepaalde codering eisen. Mogelijkheden: Meerdere coderingen van het entity type moeten mogelijk zijn, om steeds te voldoen aan een modern coderingssysteem. Het lijkt erop dat een entiteit attribute moet gaan bestaan uit het paar (code van de standaard, code van de entiteit). Een project kiest een standaard. Bij een package wordt een codering bijgehouden, die aan geen andere standaard voldoet dan die van het package. Een stelsel entiteit codes kan alleen maar uitbreiden, maar niet wijzigen. Binnen een project wordt een vertaling gemaakt ten behoeve van tools, zodat de metadata in de working-tree voldoet aan de project eisen. Maar de metadata in de kins voldoet aan de package standaards. Heeft de kin alleen maar soll eigenschappen? De eigenschap dat een kin gebonden is aan een package is een ist eigenschap. Elements en versions behoren onvervreemdbaar tot het package omdat hun kin ertoe behoort. Het gegeven dat de kin aangemaakt is door Joost is een ist eigenschap die niet geldt voor al zijn elements en versions. Pagina: 91 / 230

92 2.3 Metadata Soll en ist zijn begrippen uit de administratieve organisatie en diens interne controle, waar een actuele werkelijkheid ( ist ) wordt vergeleken met een norm ( soll ). In het boek Information modeling and Relational Databases van Terry Halpin en Tony Morgan vond ik de begrippen deontic en alethic (niet helemaal) in plaats van soll en ist voor het typeren van business rules. Bijvoorbeeld: juridische wetten zijn deontic, en natuurkunde wetten zijn alethic. In feite heb je alleen bij een deontic rule een norm (soll) en een werkelijkheid (ist) die ermee vergeleken kan worden; bij een alethic rule is er uitsluitend een eigenschap van de werkelijkheid, in dat geval interesseert de interne controle niet voor ist, want er hoeft niet gecontroleerd te worden of aan een norm is voldaan. Nog even in Wikipedia gekeken. Modale logica: redeneren met de modaliteiten possible en necessary en contingent is alethic logic, en redeneren met de modaliteiten obliged en forbidden, permitted is deontic logic. De begrippen SOL en IST, die ik gebruikte zijn dus niet terecht. Beter is het om ze deontic en alethic attributes te noemen Restricties op kins Bij een kin zouden lijstjes van toegestane folders of toegestane names kunnen worden bijgehouden, met het doel de package varianten in de diverse subprojects onderling vergelijkbaar te houden, niet slechts voor Climbexion, die met kins kan werken, maar ook voor stervelingen die met names en folder names werken. Om name en folder wijziging te realiseren is er overleg en overeenstemming nodig tussen de teams die een package beheren. In principe heeft men hier geen speciale voorzieningen voor nodig. Afspraken zouden voldoende moeten zijn. Mocht je er toch toe besluiten om op deze wijze enig conservatisme te willen afdwingen, dan zou je kunnen overwegen om een kin door stadia te loodsen. In het born stadium, als de kin net is gerealiseerd kunnen name en folder reference vrij wijzigen. Later als de kin wordt aanvaard door de community, treedt het registered stadium in, en gaan de lijstjes gelden, en kunnen normale gebruikers slechts wijzigen voor zover de lijstjes dit toestaan. De lijstjes zelf worden bijgehouden door een autoriteit. In plaats van lijstjes zouden eventueel regular expressions kunnen worden gebruikt. Dergelijke lijstjes zijn typisch metadata. Het eigenaardige van dergelijke restricties is dat ze niet gelden voor de bestaande course items in de elements, maar uitsluitend voor nieuwe name en folder wijzigingen Classifications ten behoeve van export limitations Classifications voor de geheimen van NXP zouden aan kins kunnen worden toegekend, maar misschien is er enige flexibiliteit nodig en zouden uiteindelijke definities kunnen worden vastgesteld in de subprojects, en dan gelden voor de elements in de drawers. De openheid of geslotenheid in het ene project kan afwijken van die in een ander project, en een wijziging in het beleid is niet automatisch van toepassing op alle bestaande subprojects. Ook bij gemeenschappelijk beleid is er flexibiliteit, als de uitvoering in het éne project kan verschillen van de uitvoering in een ander project. De scoop van een classificatie system is dan ook het subproject. Binnen een subproject worden classifications toegekend, die uiteindelijk resulteren in export limitations. Voor zover classifications Pagina: 92 / 230

93 2.3 Metadata worden toegekend aan versions, of elements betekent dit dat de betreffende attributes het subproject niet verlaten, maar dat ze de uitgangen van het subproject bewaken. Een subproject waarin een package geïmporteerd wordt mag die in principe niet doorgeven aan derden. Dus een geïmporteerd package is in zijn geheel strikt geheim. Het is te verwachten dat classifications simpel zijn, twee of drie, hooguit 4 classificatie niveaus is waarschijnlijk alles dat nodig is. Bijvoorbeeld: er zijn ingewijden die alles mogen zien, versus buitenstaanders die maar een beetje mogen zien. Binnen NXP zou de kaste van audio/video bewerkers meer ingewijd kunnen zijn dan de kaste der driver makers, die weer meer mogen zien dan klanten. Ingewijden zouden bijvoorbeeld geheime en openbare files mogen zien, en buitenstaanders alleen openbare. Er zijn dus classifications die betrekking hebben op geheimen van NXP die de distributie binnen het masterproject beperken. De beperkingen hoeven niet voor alle teams hetzelfde te zijn Verder is er mogelijk een set files, waarvan je niet wilt dat die opduiken in een sister-project, omdat dit het vertrouwen van een partner beschaamt. Een geheim van een partner is geïmplementeerd in de software van NXP. Dit betekent een een tweede classification codering. De classification kan de export naar sister projects en reference design project aan banden leggen. Niet elk sister project zal dezelfde beperkingen hebben, bijvoorbeeld sister projects voor dezelfde klant kunnen het geheim vrij uitwisselen. Deze classification kan bovendien de distributie binnen een masterproject beperken, waardoor niet alle teams alle files krijgen. Classifications moeten op orde zijn als een baseline wordt samengesteld, maar ook, als een specifieke info-tree (uit een expose-drawer) worden samengesteld ten behoeve van debugging door een ander team, of misschien voor een demo. Ook als wijzigingen doorgegeven worden met behulp van external envelopes moeten de classifications blijven gelden. Het gebruik van envelopes van wijzigingen in een sister project zijn ook onderhevig aan de classification toets. Voor classificaties geldt dat het beleid (de classifications) ten aanzien van geheimen handmatig moet worden vastgelegd in of bij de repository. Dit kan bijvoorbeeld in de team-drawer voor files, en package references, want dit is de bron, vanwaaruit de andere drawers worden gevuld. Primair gelden de attributes daar voor de elements: files en package references. Voor het propageren van classifications naar andere drawers, geldt dat dit het beste kan met version attributes. Dus classification attributes moeten ook (automatisch) aangebracht worden als attributes van de versions, zodat ze gemakkelijk gepropageerd kunnen worden naar andere drawers. Versions met een classification moeten deze (automatisch) propageren naar nieuwe versions die eruit ontstaan. Tenslotte geldt dat geclassificeerde versions en package references niet mogen worden gekopieerd naar omgevingen (pools, drawers, working-trees, viewtrees) die lager geclassificeerd zijn. Een en ander kan betekenen dat allerlei tools en file systems onder controle staan van security mechanismen. Mogelijk is die situatie niet bereikt in de eerste releases van Climbexion. Van een package met classifications wordt normaal gedurende de looptijd van het project een library met binary object code of een executable met binary code beschikbaar gesteld aan buitenstaanders. Alle source code is gecompileerd om de binary code te maken. Ergens binnen de binaries, die zelf openbaar zijn, zitten, hopelijk onwaarneembaar, de geheimen. Daarnaast Pagina: 93 / 230

94 2.3 Metadata worden sources ten behoeve van de application interface beschikbaar gesteld, en gebruikersdocumentatie. Van de sources van de binary code en van hun ontwerp en implementatie documentatie wordt mogelijk een deel beschikbaar gesteld ten behoeve van debugging en analyse, voor zover dit geen geheimen onthult. Deze werkwijze is een praktische randvoorwaarde. Stel de binary ontbreekt, en een source file wordt op zeker tijdstip (maar wel voor de looptijd van de file) geheim verklaard, dan moet er terstond een binary van de file gemaakt worden voor alle snapshots waarin die ontbreekt. Dit is additioneel fragmentarisch werk, dat erbij komt als classifications wijzigen. Dit geldt voor classifications binnen het masterproject, voor classifications voor sister projects geldt dit niet, want een package voor een sister project wordt niet letterlijk overgenomen, en de benodigde binaries worden binnen het sister project zelf gemaakt. classification update in een package op een welgekozen snapshot Weliswaar is het snapshot gekozen, maar de attributes die bijgewerkt worden zijn attributes van het element. Handmatig classification attributes toekennen aan files: Een wijziging van een classification betekent een wijziging voor alle versions in de course of development van de file. Zo'n wijziging kan een correctie zijn van een onjuiste classificatie, maar vooral ook een beleidswijziging. Er is dus sprake van een veranderde werkelijkheid. Maar, het is geen intentie van de repository om iets te registreren over een beleid, het is de intentie om iets vast te leggen over een file. Onder normale omstandigheden participeren classification event items niet in een (valid time) snapshot, maar wordt altijd de tip van de (transaction time) course van classifications gebruikt, ook op oude snapshots van files. Het attribute heeft dus een valid time gelijk aan de levensduur van de file waarop hij betrekking heeft, en een transaction time die ongeveer overeenkomt met een bepaald beleid, ten aanzien van geheimen. Pagina: 94 / 230

95 2.3 Metadata Handmatige classifications toekennen aan folders en files. Een package snapshot wordt gebruikt om classifications toe te kennen. Top-down worden classifications toegekend aan folders, met toenemende geheimhouding. In feite worden de classifications toegekend aan de inner-reach van de folders. Enerzijds heeft men zo een systematische werkwijze, anderzijds, nu folders een classification attribute hebben, kunnen files die nieuw gecreëerd worden, het attribute erven van de folder waarin ze ontstaan. Misschien wordt deze exercitie enkele malen herhaald gedurende de looptijd van een project, want in nieuwe snapshots kunnen nieuwe files en folders staan. Mogelijk wordt dan meer fragmentarisch gewijzigd, top-down vanaf subtoppen. Gedurende de looptijd van een subproject kunnen files verplaatst worden van de ene naar de andere folder. Dus niet in elk snapshot zal gelden dat een file minstens zo geclassificeerd is als de folder waarin hij staat. Een export query selecteert de versions die niet te geheim zijn, en de folders die dan niet leeg zijn, dus de query maakt geen gebruik van folder classifications. Merk op dat er 2 rollen zijn van het attribute classification. Een classification die toegekend wordt aan een file of een package reference geldt voor het element: het element wordt wel of niet beschikbaar gesteld. Het attribute toegekend aan een folder heeft een heel andere rol: het wordt bij sommige gebeurtenissen gebruikt om de waarde door te geven aan een file of package reference in zijn inner-reach maar geldt niet voor de folder. (In plaats van classification levels, zou mogelijk ook gewerkt kunnen worden met permission levels, en dus afnemende geheimhouding naarmate je lager in de tree komt. De hele tree inhoud is dan alleen voor ingewijden, en sommige delen zijn ook voor buitenstaanders.) Waarom zo ingewikkeld? Ik hoop dat de top-down methode systematisch is. Ook hoop ik dat de methode navolgbaar is, zodat review en kritiek mogelijk zijn. Is dit nu alles? Nee, want niet alleen beleid kan veranderen, maar ook de software. Een module zonder geheimen kan wijzigen in een module met geheimen, als een verbeterd algoritme wordt geïmplementeerd. Het resultaat kan zijn dat het onmogelijkheid wordt om elk snapshot te beveiligen met dezelfde classifications. Een toekenning van classifications is dan adequate voor het ene snapshot maar is te restrictief of te ruimhartig voor een ander, en er is geen bevredigende gemeenschappelijke toekenning. De onderstaande studie is bedoeld om tot een beheersbare methode te komen die gebruik maakt van een course of development van classifications, zoals die er zijn voor versions, names, en folder references. Zodra een element door wijziging geheim wordt, of openbaar, wordt er vlak voor het course item dat de nieuwe version in de course plaatst een course item opgenomen dat een anchor is waarin voor de toekomst van de course het classification attribute wordt bijgehouden. Dit anchor kan een course of corrections ondergaan waardoor hij verplaatst wordt in de course of development van het element, hij kan geïntroduceerd worden of vervallen. Het anchor refereert aan een security change die herkend wordt door titels als: de introductie van een privaat 3d-comb filter algoritme, of de overgang naar een openbaar stroomlijn algoritme. Een reversed list toont per security change de betreffende anchors in de elements, zodat er een controle is op juistheid, volledigheid en ontwikkeling. Het anchor noemen we een classification-anchor en de security change noemen we een classification-set. De set is de verzameling elements waarin de nieuwe anchors staan. Pagina: 95 / 230

96 2.3 Metadata Als een nieuw element gemaakt wordt, dat wordt er ook een classification-anchor gemaakt. Dit kan een anchor zijn met of zonder referentie naar een classification-set. Alle latere classification-anchors hebben altijd een referentie naar een set. Het invoeren van een classification-set moet tijdig gebeuren, vóór of samen met de changeset die een geheim introduceert, tenminste als het er om gaat een geheim te introduceren, om een openbaarheid te introduceren kun je beter te laat zijn dan te vroeg. classification-set, classification anchor Het lijkt erop dat classification-sets op snapshots en tags lijken, wat betreft de inclusie van changesets. Maar snapshots en tags kijken terug in de tijd naar de meest recente event items van courses, terwijl classification-sets vooruit kijken, van nu af aan gelden de nieuwe classifications. Dus de timestamp van de classification-set wordt virtueel afgerond zodat die ouder is dan de revision waarop hij duidt, maar jonger dan de vorige revision. Het ziet ernaar uit dat classifications_sets worden bijgehouden buiten de changesets. Ik zal kort 2 scenario's beschrijven. In het ene houdt een expert alle classifications bij, en in het andere houdt het team de classifications bij, maar zorgt een expert voor een basis en correcties. Expert De expert is volledig en als enige verantwoordelijk voor het toekennen van classifications. Een expert voert de top-down exercities uit, en creëert classification-sets. Als een teamlid een file of folder verplaatst (door de folder reference te wijzigen), dan behoudt die de classifications die toegekend zijn door de expert. Team and Expert Ieder in een team is verantwoordelijk voor het uitvoeren van het beleid ten aanzien van geheimen. Bij de start van een subproject worden de betreffende packages voorzien van extra folder paren waarvan de naamgeving aangeeft welke classification er geldt. Ze heten bijvoorbeeld secret en disclosed. Een element start zijn leven in de inner-reach van zo'n Pagina: 96 / 230

97 2.3 Metadata folder. Mocht er een foute classification geconstateerd worden dan wordt wordt de file verplaatst naar de inner-reach van de andere folder, met de transaction optie: classification correction, waardoor de classification van het element wordt bijgewerkt in het bestaande classification-anchor. Als een file of (groepje files) verplaatst wordt met de optie: classification development, dan wordt een nieuwe classification-set gecreëerd, en voor de betrokken elements classification-tags. De file en folder structuur van een package in de tip van de drawer bepaalt de classifications van de files in de meest recente classification-set. Daarnaast is er nog een expert nodig voor review en correctie van classifications in classification-tags, voor het tussenvoegen, verplaatsen en laten vervallen van classificationtags in elements, het doorvoeren van beleids-wijzigingen en dergelijke. Naast het vastleggen van het beleid is er nog het propageren van classifications. Als een version wijzigt ontstaat een nieuwe version, met de classification van het origineel. Als een version ontstaat uit twee andere versions, dan is de nieuwe classification (automatisch) minstens zo restrictief als de classifications van de twee. Dit moet gerealiseerd worden voor wijzigingen in satellites en workingtrees. Het liefst zo dat het propageren van de classification onontkoombaar is. De automatische propagatie gaat uit van een worst-case aanname, die mogelijk nog gecorrigeerd moet worden. Als nieuwe versions de team-drawer binnenkomen, dan moet hun classification in overeenstemming zijn met die van de file, anders moet er (handmatig) een conflict opgelost worden. Zie:Dorothy E. Denning: A Lattice Model of Secure Information Flow. Communications of the ACM May 1976, Volume 19 number 5. Het kopiëren naar export-drawers en expose-drawers gebeurt volledig op version en package reference classifications. Mochten er daarna nog classification corrections komen dan geldt: jammer dan. Hoogstens kan daarna nog een snapshot aangemaakt worden, dat qua classifications correct is. In de folder tree van NHSW komen de folders public en private voor met een andere betekenis dan de folders secret en disclosed die ik hier introduceerde. Public : de components en interfaces in de inner-reach mogen worden gebruikt in andere packages, Private : de components en interfaces in de inner-reach mogen niet worden gebruikt in andere packages. Het betreft hier information hiding ten behoeve van maintainability, en reliability. De informatie (component en interface descriptions) in private folders is verborgen voor software in andere packages, maar niet voor mensen in andere subprojects Original en neighbor Stel je gebruikt een envelope uit een ander project om een wijziging door te voeren, dan krijg je min of meer automatisch de attributes original en neighbor ingevuld bij het de element reference in de eigen envelope (zie voor deze begrippen: 2.4.1). Als er bijvoorbeeld 5 files in de envelope staan dan kunnen de attributes in 5 maal ingevuld zijn. Nu kun je voor sommige programma's besluiten om niet merge samen te voegen, maar om een andere oplossing te programmeren. Dan kan het zijn dat je de attributes wilt uitgummen. Ook als je wel merge gebruikt maar naderhand ook nog wijzigt, dan wordt het mogelijk dubieus of de attributes nog wel gelden. Aan de andere kant is het misschien wel zo dat je deze attributes wilt opgeven, terwijl je er geen merge tool voor hebt gebruikt. Kortom, Pagina: 97 / 230

98 2.3 Metadata je moet ze kunnen verbeteren. Het is wel zeer verleidelijk om wijzigen toe te staan zonder transaction times bij te houden, immers dit speelt zich voornamelijk af als de envelope ontwikkeld wordt in een satellite, die heeft immers een typisch een werkplaats karakter. Toch schakel je dan bij voorbaat een stukje logging uit. Bovendien kan het natuurlijk ook voorkomen, dat iemand zijn wijzigingen overdraagt, en twee nachten later opeens wakker schrikt, overeind zit in zijn bed en weet: original en neighbor zijn fout ingevuld. Dus net als wijzigingen van de attributes van andere entiteiten hoort er een transaction time bij. Nu is het zo dat één van mijn uitgangspunten is dat een persoon of een groep zijn eigen proces vastlegt en vervolgens zijn product presenteert aan anderen Het volledig vastleggen van de ontwikkeling van de envelope in een satellite is typisch informatie over het proces. Deze informatie moet samengevat worden tot product informatie bij een overdracht, dus alleen het uiteindelijke resultaat wordt overgedragen, en niet de ontwikkeling tot het uiteindelijke resultaat. Een envelope is toch iets dat als één geheel pendelt tussen satellites en center-drawer en eventueel een transfer drawer. Dus toch maar geen transaction times voor attributes. Voorlopig geef ik dus toe aan de verleiding Base en labored In envelopes kent men een reeks die bestaat uit base event items, die een basis leggen voor wijzigingen, en labored event items die de voorgaande base opvolgen. In principe geldt hiervoor wat gold voor original & neighbor. We zullen voorlopig geen transaction times bijhouden, maar de labored version overschrijven Kin references Een file verwijst naar een kin. Het kan voorkomen dat iemand een nieuwe file, en dus een nieuwe kin begint, en later blijkt dat dat er al een kin bestaat voor de file. Dan moet je de reference van de file naar de kin kunnen verbeteren. Ook, als een kin reeds bestaat, en een file is erop gebaseerd, en later blijkt dat de file verwijst naar de verkeerde kin, dan zou je de verwijzing moeten kunnen verbeteren. Dergelijke fouten kunnen zijn uitgezwermd over veel drawers, het verbeteren is dan geen fluitje van een cent. Misschien heeft het zin een kin naar een ander te laten verwijzen als blijkt dat ze hetzelfde zijn. Deze verwijzing zou dan bij gelegenheid, (bijvoorbeeld als onderdeel van een synchronisatie) kunnen resulteren in een update van het file attribute. Actieve drawers die een synchronisatie ondergaan komen dan vanzelf aan bod voor een update Attributes van drawer, package, pool, machine Drawer Een drawer speelt een rol in een constellation. Rollen zijn: center, transfer, satellite. Zowel rol als constellation zijn attributes. In wezen is constellation de referentie naar centrale pool waarin Pagina: 98 / 230

99 2.3 Metadata envelopes bewaard worden. Een constellation heeft dus een URL. In satellites kan er behoefte zijn aan een private pool, waarin een envelope verkeert totdat er een bepaalde kwaliteit bereikt is, en mogelijk dient de lokale pool ook om een kopie te kunnen gebruiken, als je niet op je werkplek bent, en afgesloten van het intranet. De referentie naar de lokale pool is ook een attribute. Moet je deze rol en deze referenties kunnen wijzigen? In principe wel, maar de samenhang moet gerealiseerd zijn als je met de constellation werkt (om deze attributes te wijzigen wordt de drawer als het ware even uit de lucht genomen, soms moet dit mogelijk voor de hele constellation). Moet je de historie bewaren? Liefst wel, maar bij historische gegevens kan de samenhang waarschijnlijk niet gelden, als bijvoorbeeld een envelope pool, of een center-drawer wordt verplaatst dan wijst een vorige URL nergens naar. De constellation pool waarin envelopes bewaard worden wordt genoemd in meerdere drawers, en hetzelfde kan gelden bij lokale envelope pools. Als de envelope pool verplaatst wordt dan moet dit bij alle drawers worden aangepast. Heeft een drawer een kin? Voorlopig zie ik daar geen directe toepassing voor. Attributes van een package Er zijn de references naar lokale pools voor versions, kins, other-focused files en dergelijke. Deze referenties moeten zo worden bijgehouden dat de samenhang gehandhaafd blijft. Al deze references zijn URL's. Attributes van pools Vaak refereren ze naar een centrale pool, die nuttig is bij de distributie van wijzigingen Tenslotte Uiteraard hoort bij een transaction, of het nu een update van een attribute betreft of de update van een element, de naam of user-id van degene die de wijziging uitvoert. Dit is een belangrijke reden om courses of metadata corrections bij te houden voor attributes: de wie,wat, waar, wanneer reden. Waarschijnlijk moet er een zekere eenheid bestaan binnen een masterproject. Voor attributes als file-type, entity type en dergelijke, kunnen het best standaards worden gespecificeerd zowel wat betreft de waarden, als ook de toekenning van het attribute aan een climbexion entiteit. Teveel verschillen tussen packages leiden waarschijnlijk tot meer werk bij het opstarten van een project. Als je erover nadenkt dan valt het op dat er eigenlijk niets triviaal is aan de attributes die je wilt opnemen bij kins, files, event items, en versions, enzovoort. Ze zijn moeilijk op één hoop te gooien, qua wijze van bijhouden, wijze van doorgeven, en wijze van gebruik. Pagina: 99 / 230

100 2.4 Werkwijzen 2.4 Werkwijzen Merging Simpele interactieve merge Basics Er zijn meestal twee programma's betrokken bij merging, een difference program en een merge program. Het merge program gebruikt de resultaten van het difference program. Tegenwoordig is er ook vaak een interactief (GUI-based) programma, waarmee naast merging ook editing mogelijk is. Er zijn drie versions van een kin betrokken bij een merge. Een original O en twee nieuwe varianten N1 en N2. De wijzigingen om van O een N1 te maken kunnen worden bepaald met het difference program. We noemen deze wijzigingen diff(n1,o) Ook diff(n2,o) wordt bepaald. Het merge program moet nu de combinatie diff(n1,o) en diff(n2,o) aanbrengen op O. Dit mag echter alleen als er geen conflicterende overlap is tussen beide. Stel 2 files worden met elkaar vergeleken met een difference program en ze komen voor 95% overeen. Aan het 3-way merge programma geven we een null file op als original van deze 2 files. Conflict tijdens merge Pagina: 100 / 230

101 2.4 Werkwijzen Dan hebben we 100% overlap en dus potentieel 100% conflict. We gaan dan additionele analyses uitvoeren op de twee files om een refinement van de conflicts te vinden. In het version control programma dat we gebruikten ging merging al mis door de aanhef van de source files. Ze begonnen met conflicten. /* * Copyright(C) 2002 Koninklijke Philips Electronics N.V., * All Rights Reserved. * This source code and any compilation or derivative thereof is the * proprietary information of Koninklijke Philips Electronics N.V. * and is confidential in nature. * Under no circumstances is this software to be exposed to or placed * under an Open Source License of any type without the expressed * written permission of Koninklijke Philips Electronics N.V. * *############################################################ */ /*! * \file avpppy_mpow.c * * \brief * */ /* * * * %version: 4 % * %date_created: Sat Aug 26 17:48: % * %date_modified: Mon Sep 17 14:26: % * %derived_by: memphis % * * *############################################################ */ Conflicts zie je in "version", "date_modified", "derived by" als je een merge uitvoert. De default oplossing van het merge programma: twee regels "version", twee regels "date_modified", en twee regels "derived by", dus je moest wel ingrijpen. De opensource adepten zullen wel zeggen: "Dat komt er nou van" Stel bijvoorbeeld dat er een original version is, die in twee files (iedere file in zijn eigen drawer) voorkomt en dat in de course van beide files exact dezelfde wijziging is aangebracht, dan behoort de wijziging tot de overlap. Nu zou de overlap wel eens volledig conflict-vrij kunnen blijken te zijn bij additionele analyses. We veronderstellen dat een (original) file bestaat uit een reeks atomen (bijvoorbeeld regels), en dat een difference analyse ontdekt welke atomen veranderd zijn, of verdwenen, of verplaatst, of dat er atomen zijn toegevoegd tussen 2 atomen van O. Het kan zijn dat diff(n1,o) en diff(n2,o) beiden een wijziging tonen op hetzelfde atoom in O, of dat beiden laten zien dat er tussen dezelfde 2 atomen toevoegingen zijn geweest. Dergelijke wijzigingen noemen we de overlap. Bij een unattended merge mag één der files N1 of N2 dominant worden verklaart. Als N1 dominant Pagina: 101 / 230

102 2.4 Werkwijzen is dan wordt N1new bewaard. Het merge programma bepaalt de wijzigingen zonder overlap van N1 en die van N2. Dan wordt N1new gemaakt door de wijzigingen zonder overlap van N2 en alle wijzigingen van N1 aan te brengen op O. Ook N2new, wordt gemaakt door de wijzigingen zonder overlap van N1 en alle wijzigingen van N2 aan te brengen op O. Dan bepaalt diff(n1new,n2new) de conflicten, en de gewijzigde dominante file wordt behouden. Een veel preciezere beschrijving van een drieweg merge en conflicts vond ik in Wikipedia: A Formal Investigation of Diff3 van Sanjeev Khanna, Keshav Kunal, and Benjamin C. Pierce. Een theorie voor wijzigingen en het overnemen ervan vond ik in het Darcs manual: het hoofdstuk: "Theory of patches" Mijn beschrijving is misschien leuk voor het begrip, maar echte merge en diff programma's hebben meestal een veel sneller algoritme dan ik hier beschrijf, en bovendien soms ontzettend veel opties, onder meer om defaults aan te nemen bij conflicts. Vaak wordt een merge interactief uitgevoerd door een ontwikkelaar met een programma dat 2 files vergelijkt: N1 en N2. De ontwikkelaar wijzigt één van de twee files door er wijzigingen van de ander in aan te brengen. Het programma kent niet de original file, maar de ontwikkelaar wel. Die moet weten wanneer er een conflict is, en welke wijzigingen moeten worden overgenomen. Interactieve 2-way merge Cunie weet dat ze Jos niet verwijderd heeft, dus ze zal alleen Lenie toevoegen, Klaas wijzigen en Rein verwijderen uit de versie van Lagus Niet voor alle files zijn er difference program, maar voor tekst files zijn ze wel te koop. Ook als er wel een difference program is, is er niet voor alle typen files een merge program, en soms slechts een al dan niet interactive 2-way merge. Waarschuwing Niet altijd is merging toereikend. Daarom is het goed om te overleggen, als parallel-wijzigingen verenigd moeten worden. In het voorbeeld Merge is onvoldoende zouden Lagus en Cunie Pagina: 102 / 230

103 2.4 Werkwijzen kunnen afspreken dat Lagus zijn aanpassing uitbreidt als hij het laatste zijn envelope overdraagt maar dat Cunie het doet als zij het laatste is. In het voorbeeld zijn de wijzigingen geconcentreerd in een tabel in een file. Maar je kunt ook langs elkaar heen werken in verschillende files, of in verschillende delen van één enkele file, dan is het merge programma helemaal ontoereikend, om een conflict te herkennen. Een klein testje toonde aan dat ook mijn c compiler hier geen warning gaf. Dus mogelijk zou zo'n onvolkomenheid zeer laat en moeizaam ontdekt kunnen worden. Voorbeelden die mis kunnen gaan: Merge is onvoldoende de classes C1, C2, C3 erven van class C. Cunie breidt C uit met een functie, en controleert in C1, C2 en C3 of deze functie moet worden overschreven, en in C3 is dat inderdaad het geval. Ondertussen maakt Lagus de class C4 die ook erft van C. In C4 is de controle van Cunie achterwege gebleven. Stel nu dat veel later ontdekt wordt dat de functie in C4 ook overschreven had moeten worden, dan moeten de registraties in de repository kunnen tonen dat de oorzaak van de fout hoogst waarschijnlijk een parallel update is. Als je erop doorzoekt vindt je misschien de class C5 van Lepus, die in diezelfde tijd is gemaakt. Als je dan C5 en C4 naast elkaar legt dan blijkt bijvoorbeeld, dat het assignment C5 object = C4 object niet triviaal is maar expliciet moet worden geprogrammeerd. Lagus en Lepus hadden slechts C1, C2, C3 hierop gecontroleerd. Als je wijzigt op één plaats in de source code, dan controleer je misschien wel tien plaatsen op neveneffecten, maar het kan je ontgaan dat er een elfde plaats ontstaat, of dat één van de tien gewijzigd wordt. Cunie lost probleem P1 op en Lagus P2. Beide problemen vereisen dezelfde wijziging in functie F. Bijvoorbeeld: er moet een teller T verhoogd worden. Cunie plaatst aan het begin van de functie het statement T= T+1, en Lagus plaatst aan het eind van de functie het statement T = 1 + T (of misschien wel T++). Na merge zijn beide statements geïmplementeerd en wordt de teller onbedoeld twee maal verhoogd. Cunie implementeert het raadplegen van een variabele of de aanroep van een procedure die door Lagus verwijderd wordt. In het Darcs manual hoofdstuk Theory of changes worden wijzigingen integraal op de folder-tree beschouwd en wordt aandacht besteed aan replacements zoals naamswijzigingen van bijvoorbeeld variabelen of procedures. Met het simpele merge programma op versions, Pagina: 103 / 230

104 2.4 Werkwijzen soms gecombineerd met een commander-achtig programma voor de wijzigingen op de folder-tree ben je soms (of misschien wel vaak) niet rigoureus genoeg. Bijvoorbeeld: de één verplaatst een procedure van file1 naar file2, terwijl de ander er een wijziging in aanbrengt. "Darcs" ( Conclusie: merge is slechts goed, voor een deel van de problemen met parallel updates. Maar voor versie één van Climbexion zullen we het er maar mee doen. Incidenten met parallel oplossen zal ik in de rest van het verhaal een Lagus & Cunie noemen. Waarom Lagus en Cunie? Ik heb mij laten vertellen dat die een doorsnee gehuwd stel representeren. Merge in Climbexion In Climbexion wordt een merge programma gebruikt op versions van dezelfde kin, die behoren tot hetzelfde file-type. Als we een merge uitvoeren om in de eigen team-drawer wijzigingen over te nemen van een file uit een andere drawer, bijvoorbeeld alle wijzigingen vanaf snapshot A tot en met snapshot B in de andere drawer, dan noemen we: 1. de version van het snapshot A: original 2. de tip uit de eigen drawer: base 3. de version uit snapshot B: neighbor. De wijzigingen die nodig zouden zijn om van de original version de base version te maken zijn de te behouden wijzigingen, ofwel de keep. De wijzigingen om van de original version de neighbor te maken noemen we de update. Wanneer een envelope implemented is, en daarna wordt besloten om de wijziging niet door te laten gaan, dan zijn er voor een betrokken file twee mogelijkheden: de labored version uit de envelope is nog steeds een tip: dan maken we zijn directe voorganger tot labored in de undo envelope, en de tip wordt base. De version heeft opvolgers: Nu nemen we de version zelf als original, zijn voorganger (de base version uit de envelope) wordt de neighbor, en de tip van de file wordt de base. De wijzigingen op original om zijn voorganger te maken zijn de update, de wijzigingen op original om de tip te maken zijn de te behouden wijzigingen, de keep. Als we gisteren programma versie V2 hebben gemaakt in onze satellite, gebaseerd op V1, en we zien vandaag een nieuwe tip V3 in De team-drawer, waarop we de wijzigingen willen baseren, dan is voor de overgang op de nieuwe basis: V1 de original V3 de base V2 de neighbor voor de uit te voeren merge. Het belang van een merge tool is vooral dat wijzigingen gemaakt in omgeving A overgenomen kunnen worden in omgeving B. Deze overnames willen we graag zo routinematig mogelijk uitvoeren, het liefst zo dat het tool dit autonoom doet, zonder interactie. Pagina: 104 / 230

105 2.4 Werkwijzen Tenslotte We hebben gezien dat het file-type kan wijzigen in de course van een file. Dan kun je geen merge gebruiken om wijzigingen in een versie met type FT1 over te nemen in een versie met type FT2. Dat wil natuurlijk niet zeggen, dat zo'n wijziging onmogelijk kan worden overgenomen, maar het kan niet routinematig, laat staan unattended. Zou je in plaats daarvan niet een andere file, dus een andere kin moeten gaan gebruiken? Waarschijnlijk is daar wel wat voor te zeggen, maar ik denk dat ik die beslissing aan de gebruiker laat, en niet aan Climbexion, of zijn bedenker. Veel document editors bieden faciliteiten voor het opslaan van meerdere versies, in één document, om versies te integreren (merge) in een resultaat versie, om progressie te tonen met een difference analyse en dergelijke. De integratie van deze faciliteiten met Climbexion zal zeker niet onmiddellijk plaatsvinden, en misschien wel nooit. Eigenlijk zou je het liefst een versie van zo'n tool hebben zonder ingebouwde merge, maar met een drieweg merge tool meegeleverd. Dit weer typisch een voorbeeld van een revision control systeem dat eisen stelt aan een tool dat voor development wordt gebruikt. Voor veel documenten, maar ook voor spreadsheets, en vector en object gebaseerde plaatjes (diagrammen), is er een syntaxis gedefinieerd zodat er ook een gewone tekst opslag mogelijk is (bijvoorbeeld TeX, XML, RTF, comma separated files). In principe zou een normaal merge programma hierop losgelaten mogen worden. Een voorwaarde is waarschijnlijk dat degene die de merge uitvoert de tekst file zou moeten kunnen lezen en verbeteren, bijvoorbeeld om conflicten op te lossen. Een merge zou gevolgd kunnen worden door uitvoering van een static analyzer: een check programma op syntaxis en onwaarschijnlijke constructie, die het conflicten lijstje, indien nodig, uitbreidt. Software-ontwikkel-teams met een werkwijze die afhankelijk is van merge zouden hun ontwikkel tools zo moeten kiezen dat de source files die gemaakt worden kunnen worden verenigd met merge. Ze kunnen verbeterd worden met een tekst editor in een IDE, liefst natuurlijk zo dat ze het effect van de wijziging meteen WYSIWYG kunnen bekijken in een window met het document, de spreadsheet, of het diagram. Je hebt niet alleen de juiste tools nodig maar ook de juiste mensen die niet alleen maar wysiwyg kunnen werken. Dat eist wel enige opleiding denk ik. Integratie tot een binary kan plaatsvinden met behulp van een make tool en een compiler. Deze geïntegreerde files zijn er voor de lezers en gebruikers van de informatie. De makers van de informatie wijzigen bijvoorbeeld direct op de source files, of ze zien de tekst van de source files en het resultaat wysiwyg, en wijzigen op één van beide presentaties, en zien de wijziging ook in de andere. Al met al lijkt het een behoorlijke inspanning te kosten om te komen tot een repository voor alle source files, als ze allen parallelle ontwikkelingen moeten kunnen doormaken die later met een merge tool verenigd moeten worden. Voorlopig is er ook de oplossing dat software wordt toegewezen aan kleine groepjes personen, die parallel ontwikkelen vermijden, als het gaat om binaire source documenten voor analyse design en development. Waarschijnlijk is de afhankelijkheid van een merge programma voor een repository een reden dat men terughoudend is met de introductie van case-tools, immers een adequaat 3weg merge tool ontbreekt meestal. Een andere reden kan zijn dat men terugdeinst voor de derived files die met case-tools gegenereerd worden, en die mogelijk ook hun plaats verdienen in de repository. Pagina: 105 / 230

106 2.4 Werkwijzen Synchronisatie Soorten De meest simpele soort synchronisatie maakt de tip van een drawer exact gelijk aan een snapshot van een ander. Ook een deel van een drawer, bijvoorbeeld een package kan exact gelijk worden gemaakt aan die van een ander. Dit noemen we exact copy. Exact copy wordt uitgevoerd op alle typen course-items. (Name, folder reference, version). Envelope references worden niet gekopieerd, want ze worden niet gerekend tot de course van een element, maar tot een attribute van het event dat de course uitbreidt. Alleen een wijziging breidt een course uit. De course van een ongewijzigd element blijft ongewijzigd. Import en export limitations zijn mogelijk, maar niet altijd noodzakelijk. Dan is er synchronisatie die mogelijk periodiek plaatsvindt. Uit drawer A wordt gekopieerd naar B. Wijzigingen die in B zijn aangebracht (neighbor) sinds de vorige synchronisatie (original) mogen niet vervangen worden, maar moeten worden worden gemengd (merge) met overeenkomstige nieuw gewijzigde elements in A (base). Het resultaat (labored) komt in de working-tree, en kan met commit worden geplaatst op de tip. Als het overeenkomstige element niet in A gewijzigd is hoeft er uiteraard niet gekopieerd of gemengd te worden. Ook dit kan plaatsvinden over de hele drawer of over een deel ervan. Naar keuze kan merging wel of niet unattended (automatisch, zonder toezicht) plaatsvinden. Een unattended merge kan incidenten loggen, als er conflicten optreden, of als er files betrokken zijn waarvoor geen merge program bestaat. Als er conflicten of problemen opgelost moeten worden moet alsnog iemand met een editor de integratie van de wijziging verzorgen, of bij een naam of folder conflict beslissen welke naam of referentie gebruikt moet worden. Kopiëren met unattended merge noemen we merge copy. Zonder unattended merge synchroniseren betekent dat gewijzigde elements in B niet automatisch worden vervangen, als elements ook in A gewijzigd zijn. De merge moet handmatig (interactief) gebeuren. Deze methode noemen we careful copy. Een lijstje dat aangeeft welke elements een interactieve merge moeten ondergaan of waar een beslissing moet worden genomen over een naam conflict dient dan als to do lijstje. Vaak worden import limitations gebruikt om files die niet met merge zijn samen te stellen, uit te sluiten. Climbexion software moet het volgende garanderen bij deze copy methoden: Als een course item de tip niet wezenlijk wijzigt (version, name of folder reference blijven hetzelfde), dan vindt het event dat de course zou uitbreiden niet plaats. Er wordt geen event toegevoegd. Synchronisatie is een pull action: in de eigen drawer synchroniseer je elements met een andere drawer. Er wordt geen envelope gebruikt voor een dergelijke actie, maar als import of export drawers gesynchroniseerd worden met een nieuwe release dan dient de envelope als certificaat. De envelope is dan eigenlijk een externe representatie van de changeset, en garandeert dat de nieuwe release door de build manager in de drawer is geplaatst, want de envelope bevat zijn elektronische handtekening. Pagina: 106 / 230

107 2.4 Werkwijzen Synchronisaties tussen satellite en working-tree Nieuwe elements In een working-tree kunnen files voorkomen die niet in het revision control system zijn geregistreerd. Bijvoorbeeld build results voor unit tests, of test results, adhoc programmatuur, of nieuwe folders en programma's. In version control systems zorgt een configuratie file ervoor dat nieuwe files in hun totaliteit, als groep, geregistreerd kunnen worden in de satellite: de configuratie file fungeert dan als poortwachter, die sommige files niet toelaat. We veronderstellen dat dergelijke configuratie files eenvoudig door één man in een team zijn te maken, en bij te houden. In wezen betreft dit import limitations op een satellite, voor nieuwe elements die overgedragen moeten worden vanuit de working-tree. Ook de entity types en file-types van de nieuwe files en folders moeten of worden herkend met behulp van de configuratie files, of alsnog met de hand worden toegekend. Een nieuwe file betekent: Er wordt een kin voor vastgelegd in een pool. Er wordt een element met course voor gemaakt in de satellite. Een version wordt geplaatst in een pool. Climbexion werkt met privé satellites, dus is er mogelijk nauwelijks een argument te vinden om files in een working-tree niet ook op te slaan in de satellite: hun bestaan is immers een historisch feit, en je hoeft zo'n file immers niet per se over te dragen naar de center-drawer. De meeste files moeten worden worden geregistreerd als gewone file, maar sommigen zijn otherfocused files. In de configuratie file moet mogelijk ook aangegeven worden welke files in aanmerking komen om als other-focused file te worden geregistreerd. Behalve files kunnen ook nieuwe folders en packages voorkomen in de working-tree. Nieuwe folders registreren, door ze te creëren in de working-tree en ze daarna met de registratie opdracht in de satellite en de pools te registreren is net zo simpel als files registreren. Gewone folders moeten wel zijn te onderscheiden van packages (via de configuratie files of door middel van manuele opgave of met behulp van van metadata). Een elders bestaand package moet kunnen worden geregistreerd als een reference, om daarna de satellite en de working-tree te synchroniseren vanuit een andere drawer. Een nieuw package registreren, en er de pools voor opzetten moet ook mogelijk zijn. De inhoud van het package moet daarna toch vanuit de working-tree zijn te registreren. Registreren vanuit de working-tree gebeurt in veel revision control systemen met een add opdracht. Deze opdracht kan parameterloos zijn, of hij kan een expressie bevatten die de registratie beperkt tot de elements die met de expressie geduid worden. Eventueel impliceert het registreren ook het overnemen van name, folder reference, version en dergelijke in de drawer, dus add impliceert commit. Een nieuw element maken voor working-tree en satellite samen. Dit is mijn favoriete methode. Een tool gebruikt een template om de folder, of de file te maken in de working-tree en registreert het element meteen in satellite en kin pool. Een configuratie file lijkt niet nodig. Een mogelijke variant: Het tool werkt onafhankelijk van Climbexion, de add opdracht Pagina: 107 / 230

108 2.4 Werkwijzen wordt gebruikt voor opname in de drawer. Geregistreerde elements bijwerken vanuit de working-tree. Hiervoor gebruikt men over het algemeen de commit opdracht. Naam en folder reference wijzigingen kunnen niet zonder meer met commit worden overgedragen, maar eisen speciale opdrachten. Ook het beëindigen van een course eist mogelijk specifieke opdrachten. Opmerking: Als het file system van de working-tree toestaat dat kin identifiers, element-types en dergelijke als metadata worden opgeslagen bij de elements, zou met één enkele opdracht de satellite kunnen worden bijgewerkt vanuit de working-tree. Voorbeelden: bij nieuwe elements zou de top folder van een package herkend kunnen worden aan de metadata. Bij bestaande elements zou beëindiging, verplaatsing, en naamsverandering kunnen worden herkend, want de kin identifier is bekend. Een nieuwe version wordt herkend aan de version identifier, i.p.v. De date last modified. De working-tree bijwerken vanuit de satellite. Exact copy maakt de working-tree gelijk aan de tip van de satellite. In de configuratie file kan staan welke ongeregistreerde files en folders kunnen vervallen en welke je wilt behouden. Merge copy plaatst het resultaat van een merge in de working-tree. De merge vindt plaatst met original en neighbor in een drawer, en base in tip van de satellite. Er is commit nodig om de satellite up-to-date te maken. Eventueel kunnen merge conflicten interactief, of naderhand met een editor worden verholpen, voordat commit wordt uitgevoerd. Pagina: 108 / 230

109 2.4 Werkwijzen Het werken met team-drawer, transfer-drawer en satellite. Course Element E1 Envelope Element E1 version Type Timestamp Seqnr version Type Wa Base T 1 Wa Base Wb Labored T+1 2 Wc Labored Wc Labored T+2 Synchronize, Edit, en Commit Course Element E1 Envelope Element E1 version Type Timestamp Seqnr version Type Wa Base T 1 Wa Base Wb Labored T+1 2 Wc Labored Wc Labored T+2 3 Wd Base Wd Base T+3 4 We Labored 1) We Labored 1) T+4 Synchronize again, Merge, Commit 1 ) In dit geval zullen we de satellite niet vervuilen met de triviale informatie dat Wa de original, en Wc de neighbor is van een merge die leidt tot We. Om met een schone lei te beginnen doen we een exact copy over de hele inhoud van de tip-tag van de center-drawer, naar de satellite. De tip van de satellite wordt met een tag tot base verklaart, want hij vormt de basis van nieuwe wijzigingen. Als de base de start van een nieuw probleem markeert is het zelfs een problem base. Dan wordt de working-tree gelijk gemaakt met de tip van de satellite: exact copy. We gaan nu wijzigingen aanbrengen in de working-tree, die we met commit vastleggen in de satellite. Als we wijzigingen willen behouden dan beginnen we met commit van alle betreffende files. Dan plegen we exact copy vanaf de tip-tag van het center. Deze copy wordt de nieuwe tip van de satellite, en voorzien van een base tag. Daarna vindt de merge plaats met de vorige base als original en de zojuist vervangen tip als neighbor. De nieuwe versies komen in de working-tree. commit plaatst ze terug in de satellite. Met de opdracht commit worden wijzigingen vanuit de working-tree overgedragen naar de satellite, maar vaak tegelijk ook ook naar een envelope. In een envelope komen base / labored paren van de elements die gewijzigd zijn. Het meest recente labored version vervangt een eventueel eerder geregistreerde version in de envelope. Voor de envelope geldt: alleen het resultaat telt, dus niet de historie. Met een expliciete opdracht kunnen een oude base, en het labored snapshot op die base verwijderd worden uit de envelope. Dit moet met een aparte opdracht worden gedaan, want, zoals later blijkt, het kan zin hebben om dezelfde wijziging te baseren op meer dan één base. Pagina: 109 / 230

110 2.4 Werkwijzen De envelope variant Envelope gebaseerd op tip-tag van het center en tip van de transfer-drawer Geselecteerde implementation data Bij het implementeren van wijzigingen kan het voorkomen dat iemand gebruik maakt van Pagina: 110 / 230

111 2.4 Werkwijzen beschikbare of van adhoc instrumentatie. Eerst ter analyse, later om het effect van de wijziging te demonstreren. Hierbij kunnen working-tree files buiten de envelope gewijzigd zijn. Bijvoorbeeld om enige logging te activeren, wijzigt men een gedefinieerde constante in een programma. De variant begint als altijd met een exact copy van de tip-tag van de team-drawer. Afhankelijk van de duur van analyse, software wijzigingen en testen kan besloten worden om tussentijds met merge copy een nieuwe base te implementeren. Tenslotte volgt een fase waarin de uiteindelijke wijzigingen hun vorm krijgen. Als de envelope klaar is worden de component test en de overdrachts-test (een kleine regressie test) uitgevoerd. Dit is een test met menselijke waarneming en handmatige handelingen. In sommige projects wordt ook een statische analyse uitgevoerd met het QAC tool. In deze één na laatste laatste fase mogen er in files buiten de envelope geen verschillen meer zijn met de tip-tag van de team-drawer, want dat wordt vereist voor de component en regressie tests. Om dit te waarborgen kan gebruik worden gemaakt van een synchronisatie die zorgt dat alles buiten de envelope een exacte kopie wordt van de tip-tag van de team-drawer, en alles binnen de envelope met merging wordt gebaseerd op de tip-tag. Deze methode is de envelope variant of careful or merge copy. Careful copy is met name van belang als er in de elementen in de envelope gewijzigd is ten behoeve van ad hoc logging, want deze wijzigingen mogen niet overgedragen worden naar de team-drawer. Met een interactieve merge kun je deze wijzigingen teniet doen. Waarom de tip-tag van de team-drawer en niet de tip van de transfer drawer? Wel, voor de tip-tag geldt dat er een kwaliteit waarborg is afgegeven door de build manager. Dit maakt het iets waarschijnlijker dat test of build problemen veroorzaakt worden door eigen fouten. Als laatste fase kan synchronisatie worden herhaald met de verwachte tip (in plaats van de tip-tag van de team-drawer): dit is de tip in de transfer-drawer. Deze tip wordt een snapshot in de teamdrawer als alle envelopes, die zijn overgedragen sinds de tip-tag ontstond, worden overgedragen aan de team-drawer. Als voorgaande, reeds overgedragen envelopes (mogelijk van anderen) één of meer elements bevatten die ook in de eigen envelope voorkomen, dan is er, door deze laatste merge copy, voor sommige elements een nieuwe base ontstaan, en een door merge verkregen nieuwe labored version. Deze worden in de envelope geplaatst (dus de versions die gebaseerd zijn op de center tiptag blijven ook in de envelope staan). De programmeur controleert of het compileren goed verloopt (en in sommige projects of QAC geen warnings geeft), en zo ja dan kan de envelope worden overgedragen. In deze laatste fase blijven de tests achterwege, maar er wordt wel een build uitgevoerd. Dit waren de regels in de meeste fasen in de meeste projects van NXP. Als de wijzigingen van een element gebaseerd zijn op versions die geen tip zijn in de transferdrawer of de team-drawer, dan wordt de envelope geweigerd als je hem wilt overdragen naar de betreffende drawer. Tenminste één van de paren base/labored van een element moet de juiste base hebben. Nadat een envelope met inhoud is overgedragen naar de transfer-drawer, vinden er ook van daar uit nog acceptatie tests plaats, voordat de overdracht naar de center-drawer wordt gerealiseerd. Dit hoort een formaliteit te zijn, maar soms worden fouten geconstateerd. Dan is het zaak om een envelope als schuldige aan te wijzen (soms meerdere). Als de build manager besluit om de foute envelopes niet mee te nemen dan kan hij de tip-tag van de team-drawer gebruiken om opnieuw een basis te creëren in de transfer-drawer, en daarop de niet geweigerde envelopes opnieuw aan te brengen, eventueel met enige extra base / labored paren. Ook kan de build manager besluiten om de Pagina: 111 / 230

112 2.4 Werkwijzen schuldige envelope tegen te boeken, met een undo envelope op de tip van de transfer-drawer. In de laatste fasen van een project wordt vaak de transfer-drawer overgeslagen. Envelopes worden dan na een aangepaste overdrachts-test onmiddellijk in de team-drawer geplaatst. Daarna wordt er een external envelope gemaakt, en verstuurd. Overdrachten worden gerekend tot de push methoden: vanuit de eigen drawer (de satellite) wordt gepusht in de andere drawer (de transfer-drawer). Normaal streeft men er naar om een wijziging binnen een dag te realiseren, soms lukt dit niet. Sommige wijzigingen zijn niet simpel te splitsen in hapklare brokken van één dag, soms heeft men pech met hardware, of komt er een hogere prioriteit wijziging tussendoor. Vaak echter kan iemand meerdere wijzigingen op één dag realiseren. Soms realiseer je meerdere envelopes en pleegt dan de vereiste overdracht tests en builds op het geheel. Routine werk met Climbexion Routine werk met Climbexion: 1. Full snapshot copy 2. Difference snapshot copy: base for merge. 3. Difference snapshot copy: base for envelope variant of merge. 4. Difference snapshot copy: base for envelope variant of merge. 5. Transfer copy: envelope content 6. Transfer copy: envelope content opmerking: Een M /EM boog representeert original en neighbor, de pijlpunt representeert de base van de merge. Pagina: 112 / 230

113 2.4 Werkwijzen Enige kanttekeningen. Door de architectuur van de layer waaraan ik werkte, waren er sommige files die zeer frequent gewijzigd werden. Deze files werden op één dag soms door meerdere mensen gewijzigd en zo ontstond de behoefte om meerdere alternatieve base / edit paren aan te bieden in een envelope. De geschetste werkwijze beperkt het aantal paren tot twee. Gegeven de eis om bepaalde builds uit te voeren voor elk snapshot waarop de wijzigingen zijn gebaseerd is het ondoenlijk om als derde of vierde in een rij van envelopes een alternatief maken voor elke mogelijke situatie die zich kan voordoen, als voorgaande envelopes worden geweigerd. (Zie ook 2.8.3) Mijns inziens kan de overdracht van transfer-drawer naar team-drawer zo geautomatiseerd worden, dat ze meermalen per dag uitgevoerd kan worden. Er kunnen dan meerdere tags per dag gemaakt worden. Dit zou de kans op update op update van nog niet geïmplementeerde envelopes kunnen verminderen. De deel van oplossing is misschien om te zorgen dat de individuele checks afdoende zijn, zodat transfers rechtstreeks kunnen worden aangebracht in de center-drawer, en ieder altijd de tip van de center-drawer gebruikt als base. De build manager zorgt éénmaal per dag, of extra tussendoor na klachten, voor builds en regressie tests. Als een fout gevonden wordt, dan wordt een nieuw probleem geregistreerd, of een oud probleem heropend. Als de situatie urgent is dan wordt de fout onmiddellijk opgelost, samen met de boosdoener wiens envelope de fout introduceerde. Dit kan eventueel door een undo van de betreffende envelope, maar liefst door de fout te herstellen. In deze situatie komen other-focused files zoals build results, en test results van de regressie tests goed tot hun recht. Er hoeft niets voor te worden geblokkeerd. In een working-tree kunnen twee soorten wijzigingen voorkomen: wijzigingen binnen een envelope, en wijzigingen erbuiten. Wijzigingen binnen een envelope moeten worden zichtbaar gemaakt, voor andere gebruikers van de center-drawer. Voor een envelope in het preparing stadium zou je een commit commando moeten gebruiken om hem zichtbaar te maken, zodra de wijziging zich aftekent. Satellites maken het mogelijk om een gewijzigde version onmiddellijk vast te leggen in de satellite. Er zijn dan files die wel, en files die niet worden bijgehouden in een envelope. Er kunnen commits plaatsvinden van versions met adhoc logging, en tenslotte van versions zonder deze logging. Op deze manier is een satellite een persoonlijke log van van de eigen activiteiten. Ideaal zou zijn als één persoon één satellite heeft. Maar het is waarschijnlijk efficiënter als een satelliet onlosmakelijk bij een center hoort. Werkt iemand voor twee centers dan zijn er in ieder geval twee satellites. Werkt iemand binnen een center-drawer aan twee onafhankelijke wijzigingen tegelijk, dan zijn er twee satellites nodig. Het meest overzichtelijk is waarschijnlijk het gebruik om per wijziging één satellite te maken. Hoe één en ander in zijn werk gaat bij de moderne gedistribueerde version control systems: zie DVCS Round-Up: One System to Rule Them All? van Robert Fendt ( Op het internet vond ik vergelijkingen van revision control systems, waarin gemeld werd dat sommigen de wijzigingen opslaan die leiden tot een nieuwe version. De wijzigingen voor adhoc logging hoeven niet te worden meegenomen in de envelope, maar de echte wijzigingen wel. Hiervoor werd de term interactive commit gebruikt. In de eerste release van Climbexion wordt deze methode niet geïmplementeerd: de resulterende versions worden Pagina: 113 / 230

114 2.4 Werkwijzen vermeld in de envelope, niet de delta ten opzichte van de base. Een systeem met dergelijke faciliteiten: Darcs" ( "Fossil", ( In plaats van Interactive commit is er in Climbexion: careful copy en die gaat aan de commit vooraf. We hebben te maken met een viertal tests. De eerste drie worden uitgevoerd door een programmeur. De programmeur is aanwezig op de werkplek en kan geluid en beeld controleren, de afstandsbediening gebruiken, een dvd in een speler stoppen, apparaten aansluiten of pluggen eruit trekken. Adhoc tests. Eerst laten ze zien wat het probleem is daarna dat de wijziging werkt. Component tests laten zien dat de gewijzigde components zich gedragen zoals verwacht. (sommige component tests hoeven trouwens niet te draaien op een TV, maar kunnen uitgevoerd worden op een PC) De transfer test, toont aan dat de layer nog steeds voor dagelijks gebruik geschikt is. De acceptatie test wordt uitgevoerd op een vooraf geprepareerde werkplek zonder dat er iemand aanwezig is. Het is een uitgebreide regressie test, die door de build manager wordt gebruikt. De adhoc tests worden meestal uitgevoerd met behulp van de afstandsbediening of middels een interactieve sessie. Met uitzondering van de adhoc tests volgen de tests een script, dat in samenwerking met een tester is gemaakt. Component test scripts worden gemaakt door de programmeur, en daarna beoordeeld door een tester. De inhoud van transfer tests en de acceptatie test zijn volledig de verantwoordelijkheid van de testers. Omdat ze de verantwoordelijkheid waren van de testers, liepen de tests soms achter bij de software. Er werd dan ook wel eens op gemopperd. Dat was niet altijd terecht. Ik heb wel eens gemopperd op de test en daarna een showstopper overgedragen. Met de test was niets mis, maar met mijn wijziging in de software wel. Er zijn nogal wat builds betrokken bij dit alles. Voor MIPS software is er een debug mode en een optimize mode mogelijk voor een build. Voor TriMedia software wordt gebruik gemaakt van een optimize mode, wel of niet met logging options, en een assert mode. Probleem reproductie: product en/of layer build in optimize mode of debug mode. Adhoc tests: product en/of layer build in debug mode. Component tests: build van een eigen test harness of misschien een layer build, in debug mode Transfer test: layer build, in debug mode Pre transfer build: product en/of layer build, in optimize mode Daily builds door build manager: product en layer builds in debug en optimize mode. Tijdbesteding van een ontwikkelaar (in willekeurige volgorde): Synchroniseren en kopiëren (koffie drinken). Het voorbereiden van een test werkplek. (soms moet je zoeken naar spullen) Testen Soms moet je wachten tot een werkplek of een apparaat beschikbaar komt (koffie drinken). Builds (koffie drinken) Analyseren en programmeren Pagina: 114 / 230

115 2.4 Werkwijzen Een geabonneerd package inlijven Geabonneerd package overnemen. Geabonneerd package overnemen. Ongeveer worst case scenario, omdat er wijzigingen ontwikkeld worden, en er external envelopes ontstaan. Die hadden er eigenlijk al moeten zijn 1. Copy exact: base 2. Copy exact: differences of package only: source for envelope External envelope applied to satellite, source for envelope External envelope applied to satellite, source for envelope Envelope originated from differences between 1 and Envelope originated from external envelope Envelope originated from external envelope Envelope on own packages source for external envelope Envelope for own packages source for external envelope External envelope originated from envelope 8 Pagina: 115 / 230

116 2.4 Werkwijzen 11. External envelope originated from envelope New base for envelopes 8 to Additional base for envelopes 8 to Transfer as a whole 15. Transfer as a whole 16. External envelopes are finished in baseline constellation for final base / labored pairs Als een integrator een nieuwe baseline van een geabonneerd package implementeert dan wordt de baseline exact overgenomen. Eventuele patches raak je kwijt, eventuele nieuwe patches kunnen daarna worden aangebracht. Dit betekent: De integrator synchroniseert zijn satellite met het center, om een base te maken. De tip van de satellite, de primaire envelope, en de working-tree worden bijgewerkt door een query die een baseline van het package uit de import drawer kopieert. Er vinden tests plaats, mogelijk worden baseline supplements aangebracht in de satellite en één op één gekopieerd in eigen envelopes. De eigen packages worden indien nodig gewijzigd, dat kan soms betekenen dat deze wijzigingen ook als baseline supplements worden uitgegeven. De aanpassingen van eigen packages komen in separate envelopes. Alle envelopes worden gerelateerd aan elkaar en aan de primaire envelope, en er wordt een onderlinge volgorde vastgesteld: de comrade volgorde. Deze volgorde realiseert de partiële ordening die ontstaat als de labored file version in de ene envelope een base version is in de andere. De wijzigingen op de eigen packages moeten mogelijk tussentijds en tenslotte opnieuw worden gebaseerd op de tip-tag van het center, waarna de vereiste builds en tests plaatsvinden. Daarna worden ze nog eens gebaseerd op de tip van de transfer-drawer, waarna de vereiste builds plaatsvinden. Het geheel wordt overgedragen Het overnemen (adopt) van envelopes uit een sister-project Het principe is simpel: de eigen envelope bevat een referentie naar de over te nemen andere envelope. Voor elke file in de andere envelope geldt: De base van de ander wordt het original in de eigen. Labored in de ander wordt de neighbor in de eigen. Immers diff(base ander,labored ander) representeert de wijziging die is teweeg gebracht door de andere envelope en diff(base ander, base eigen) representeert datgene dat behouden moet worden. Soms zijn er alternatieve base/labored paren bij een file. Dan geldt over het algemeen het paar dat geïmplementeerd is in de center-drawer. In principe kun je net zo veel envelopes opnemen in de query van de eigen envelope als je wenst. Op deze manier kan gesynchroniseerd worden, terwijl een aantal wijzigingen niet meegenomen worden. Als een file voorkomt in meerdere envelopes dan leidt dit tot de volgende lijst: base original neighbor labored (new base for next merge) Pagina: 116 / 230

117 2.4 Werkwijzen original neighbor labored (new base for next merge) labored labored (edit conflict and wrong solution solving) Climbexion moet mogelijk zo gemaakt worden dat de volgorde van originals en neighbors in deze lijst overeenkomt met de volgorde van de changesets in het andere project. Overnemen van een wijziging uit een ander project Deze mogelijkheid om meerdere envelopes over te nemen in één enkele wordt misschien niet meteen geïmplementeerd in Climbexion. Dus zal men dit moeten realiseren met comrades, en vindt er geen "indikking" plaats waarbij uiteindelijk alleen de laatste labored version wordt overgedragen naar transfer en team-drawer. Optimistisch als altijd heb ik slechts één edit versie opgenomen in deze lijst, maar er mogen er meerdere zijn. Flexibiliteit is vereist. Vaak zal er een mix zijn van overgenomen wijzigingen, en een keuze voor andere oplossingen. Bijvoorbeeld een wijziging die geïmplementeerd is gedurende een development activiteit: het streven bij zo'n wijziging is om de complexiteit van de software zo klein mogelijk te houden. Maar bij een wijziging laat in de verificatie fase is het streven primair om zo weinig mogelijk regressie te veroorzaken. Dit wordt bereikt door defensive programming en door de wijziging zo klein mogelijk te houden. Als een wijziging wordt overgenomen in een backbone project, dan kan de focus verschuiven omdat in een backbone project de nadruk ligt op het minimaliseren van de totale complexiteit, en reusability waar die bij de laatste fasen van het designin project ligt bij het minimaliseren van regressie en te wijzigen code. Ook het implementeren van een feature dat geselecteerd kan worden is met behulp van een configuratie file of andere vormen van diversity kan in een backbone project anders zijn dan in een design-in project. Pagina: 117 / 230

118 2.4 Werkwijzen In NXP wordt een systeem van problem tracking gebruikt waarin sibling relaties mogelijk zijn voor problem reports en change requests, en is er regelmatig overleg of problemen gevonden in het éne project moeten worden overgenomen als sibling in het andere. Ook bij Philips CE was men hierop zeer alert. Daarnaast is het nog mogelijk dat men oplossingen uit andere projects overneemt, zonder dat hierbij een envelope of een change request of een problem report in de andere drawer een rol speelt. Een original is dan mogelijk niet eenduidig aan te wijzen. Onder die omstandigheid is het waarschijnlijk niet correct om de file waaruit de oplossing wordt overgenomen, om die een neighbor te noemen. envelope copy envelope copy 1. Full snapshot copy 2. Existing envelope supplies original and neighbor 3. Apply merge 4. Snapshot copy: some differences are additional base for envelope E 5. Transfer copy: envelope E content 6. Transfer copy: envelope E content Undo envelope Een envelope die erg op een adopt envelope lijkt is de undo envelope. Ook deze refereert naar een andere envelope, alleen de toewijzing van originals en neighbors is anders. De labored versions in de gerefereerde envelope worden de originals in de eigen envelope De base versions in de gerefereerde envelope worden de neighbors in de eigen envelope Pagina: 118 / 230

119 2.4 Werkwijzen synchroniseren van eigen packages met die van een sisterproject (adopt merge) File Original Base neighbor Action File1 File1.A File1.C File1.E merge File2 File2.C File2.C File2.E copy File3 File3.D File3.C File3.A merge Merge_copy package from Project Old to Project New Het betreft hier wijzigingen op de eigen packages. De integrator begint met twee snapshots (of baselines of tags) te kiezen in de andere drawer, één voor de originals, en één voor de neighbors. Dan vindt er een query plaats die niet erg simpel is. Het synchroniseren van name en folder reference wijzigingen, en synchroniseren als een element intussen slechts in één van de drawers voorkomt: mijns inziens is een algoritme hier niet toereikend, iemand moet een beslissing nemen, en Climbexion levert slechts een conflict lijstje. Zo gaat de integrator te werk.: Creëer een envelope en refereer naar een merge work-item kopieer de base van de center-drawer naar je satellite (exact copy) Als baseline Tn-1 van het sister-project de vorige keer geen neighbor was of als import of export limitations sindsdien gewijzigd zijn: importeer het package met baseline Tn-1 in de betreffende merge-import drawer. Dit worden de originals Importeer het package in de betreffende merge-import-drawer, met tag Tn. Voer eventuele undo envelopes uit voor wijzigingen die niet overgenomen moeten worden. Dit doen we in de merge-import-drawer (via een merge-import satellite natuurlijk). Merge: original tag Tn-1, neighbor is de tip van de merge-import drawer, base de tip van de team satellite. De merge vindt plaats in de team satellite. Eventueel edit (mergeables en Pagina: 119 / 230

120 2.4 Werkwijzen unmergeables). Het resultaat komt in de tip van satellite en envelop. build, test, improve, resynchronize, transfer. Team-drawer na Transfer original en neighbor zijn primair geregistreerd in de envelope, en daardoor indirect in het event. Undo envelopes kun je toepassen op de merge-import-drawer voordat je een merge uitvoert, of op de labored versions in de team-drawer satellite nadat de merge is uitgevoerd. In het laatste geval loop je het risico dat je eerst conflicten oplost tijdens merge, en daarna nog eens tijdens undo, voor conflicten die gerelateerd zijn aan de wijzigingen die je niet wilt hebben. Verder zijn er mogelijk wijzigingen gerealiseerd in beide subprojects, door envelopes te adopteren. Undo daarvan kan het beste plaatsvinden op de merge-import-drawer. Undo hiervan in een team-drawer satellite is ongewenst: daarin wil je de reeds gerealiseerde wijziging behouden. Ook zijn de wijzigingen in het sister project mogelijk iets anders geïmplementeerd dan in de team-drawer: merge en daarna al dan niet undo levert dan een chaos op. Conclusie: undo pas je toe op de merge-import-drawer. De afkomst relaties blijven behouden door de query (inclusief export-drawer en sister-project) op te nemen in de envelope, en door original en neighbor in de envelope op te nemen bij de betreffende files in de envelope. De volgende keer dat vanuit dezelfde drawer gesynchroniseerd wordt, kan de base voor de undo operaties het original worden: de synchronisatie is dan adjacent ten opzichte van de voorgaande synchronisatie. Als je voor het eerst synchroniseert vanuit een sister-project waaruit het package door kopiëren is ontstaan, dan is de synchronisatie adjacent op de kopieer actie. De eerste versions in de eigen courses zijn dan de originals. Synchronisaties hoeven niet per definitie adjacent ten opzichte van elkaar te zijn. Als je bij een synchronisatie een willekeurig snapshot opgeeft in de drawer vanwaaruit gesynchroniseerd wordt, dan worden de wijzigingen vanaf daar tot aan de tip overgenomen. Als je in plaats van de tip een snapshot opgeeft, dan worden de wijzigingen tussen beide snapshots overgenomen: het eerste snapshot definieert de originals, het tweede de neighbors. Pagina: 120 / 230

121 2.4 Werkwijzen Envelope voor file1 en file2 Om dit te automatisch goede synchronisatie aansluiting te realiseren moeten de synchronisaties die een package ondergaat worden opgeslagen. Hiervoor wordt de drawer merge-imports gebruikt, waarin de changesets voorkomen die de vorige keer gebruikt zijn. Zo'n synchronisatie vindt enkele malen plaats bij de start van een project, daarna worden wijzigingen overgenomen door de envelopes over te nemen. Soms wordt een backbone project op deze manier voorzien van de wijzigingen in een design-in project. Adopt merge schema Pagina: 121 / 230

122 2.4 Werkwijzen Gemeenschappelijk beheerde packages. Het avs (audio video system): de besturingslaag (eigenlijk moet ik zeggen: de server) waarin de drivers huizen, bevat packages die worden bijgehouden door NXP en enkele door de klant, of een third party. Bijvoorbeeld Horcom gebruikt een model van alle audio en video paden. Dit model is min of meer exclusief voor één enkel type televisie, maar een groot deel modelleert de structuur van de NXP chip. Het model van de av-stromen wordt gerealiseerd met Koala interfaces: waar een audio- en/of video- stroom loopt tussen hardware componenten, daar zit een Horcom interface paar tussen de driver besturings-componenten. De besturingscomponenten vormen op die manier een soort puzzelstukjes die nog in elkaar gezet moeten worden. Dat doe je door de ingang van een component te verbinden met een uitgang van een directe voorganger, en dat dan voor alle ingangen en uitgangen. De component waarin al die verbindingen liggen wordt zowel door de klant als door NXP bijgehouden, maar de eigenaar van het master project is eigenaar van deze integratie component. De component wordt als package uitgegeven door de eigenaar. De diversity van dit package is gecentraliseerd in een package dat weliswaar bestaat uit cd files, en c files, maar dat wordt bijgehouden als een invulformulier, waarop voor elk item een waarde of een functie aanroep wordt ingevuld. Ook dit package is van de eigenaar van het master project, maar wordt ook voornamelijk door NXP teams bijgehouden. Een ander voorbeeld: Een team in India en een team in Nederland werken beide aan hetzelfde package en hebben ieder een team-drawer met satellites. Er zijn meerlingen methoden denkbaar. Meerlingen zijn bijvoorbeeld te realiseren met een gemeenschappelijke team-drawer (commondrawer), waarin de teams hun wijzigingen mengen, waarna ieder synchroniseert (exact copy) met de tip van de common-drawer. Een discipline zou kunnen zijn dat eerst de team-drawer up-to-date gebracht wordt met behulp van envelopes. De common-drawer heeft een transfer-drawer. Nadat de overdrachten van de team transfer-drawer naar de team-drawer klaar zijn, vindt een merge copy plaats van de team-drawer naar de transfer-drawer van de common-drawer (original: de tag in de teamdrawer direct na de vorige keer, neighbor: de tip van de team-drawer), en na acceptatie checks (builds en mogelijk tests) een overdracht naar de common-drawer. Dan vindt een exact copy plaats van common-drawer op team-drawer. Dan wordt de tag voor de originals van de volgende keer gemaakt. Iedere envelope wordt na acceptatie in de team transfer-drawer aangebracht in de commondrawer, indien nodig worden daartoe base en labored paren toegevoegd aan de envelope. De team-drawer wordt bijgewerkt als clone van de common-drawer: alle changesets in het common-drawer worden ook changesets in de team-drawer. De team transfer-drawer wordt daarna met exact copy bijgewerkt. Voor envelopes betekent dit dat ze pendelen tussen common-drawer, en de team transfer-drawer en satellites die bediend worden door de common-drawer. Variatie op de vorige werkwijzen: Eerst brengen alle teams hun wijzigingen aan op de common-drawer, daarna pas nemen met exact copy ze het resultaat over in hun eigen teampagina: 122 / 230

123 2.4 Werkwijzen drawer. Er is nu een moment waarop alle team-drawers inhoudelijk dezelfde tip hebben. Adjacency: wijzigingen voor de common-drawer hebben als original de vorige exact copy vanuit de common-drawer. Het geheel is natuurlijk gevoelig voor een probleem dat gelijktijdig wordt ontdekt en opgelost in meerdere teams, ieder op zijn eigen wijze, liefst ook nog met zijn eigen work-item, en zijn eigen beschrijving. Soms kun je dat niet voorkomen. Dan moet je de software herstellen, en proberen te vermijden dat je blijft zitten met een dubbele gemixte oplossing Baseline samenstellen Zolang er een wekelijkse baseline werd uitgegeven, kregen wij (de software engineers) op donderdag te horen: Vandaag en morgen niets inchecken, we gaan de baseline klaarmaken. Er mochten dan nog slechts problemen worden ingecheckt, die noodzakelijk waren om de baseline te vervolmaken. Nu we drawers hebben kunnen we in één zo'n drawer en zijn satellites een baseline voorbereiden. In de team-drawer kan dan gewoon worden doorgegaan. Een consequentie is wel, dat je in de teamdrawer geen baselines van eigen packages kunt herkennen, de eigen baseline is namelijk niet altijd een snapshot in de eigen team-drawer, terwijl de baselines van geabonneerde packages er wel in terug te vinden zijn. Mogelijk worden ook de baseline reports alleen bijgehouden in de exportdrawer en niet in de team-drawer. In de officiële export-drawer wil je liefst geen tussenresultaten, maar uitsluitend baselines. Er is dus een extra center nodig: de baseline-drawer, waarin de wijzigingen worden opgebouwd tot de baseline klaar is. Daarna wordt met exact copy de export-drawer zelf bijgewerkt. De voorbereidende envelopes pendelen hier dus tussen baseline satellites en baseline-drawer. Het kan zijn, dat er vooraf afspraken zijn gemaakt over de inhoud van de baseline. Het snapshot van de tag van woensdag op donderdag kan wijzigingen bevatten waarvan afgesproken is dat die nog niet ingaan, ook kan dit snapshot wijzigingen missen die er nog met prioriteit in moeten komen. Niet alles is expliciet afgesproken, dan geldt in principe voor de wijzigingen: hoe eerder hoe beter, hoewel dit voor de ene wijziging meer geldt dan voor een andere. Het kan zijn dat wijzigingen niet genoeg zijn uitgekristalliseerd voor een baseline en daarom niet meegenomen worden: ze falen in de baseline tests. Ook kan het zijn dat wijzigingen falen in een baseline test en met prioriteit verbeterd worden, omdat het ernaar uitziet dat dat kan, en/of omdat het afgesproken is. Dank zij het gebruik van een baseline-drawer en zijn satellites is het geen probleem om met prioriteit dingen te doen, terwijl het gewone werk doorgaat. De envelopes die daarbij gebruikt worden kunnen deels gebruikt worden om daarna zonder prioriteit de team-drawer te verbeteren, op dezelfde manier als waarop wijzigingen uit een ander project worden overgenomen. Allereerst wordt met exact copy uit de team-drawer een base gemaakt in de baseline-drawer. Undo operaties gebruiken de envelope waarmee de wijziging is aangebracht in de team-drawer. De labored version uit de envelope is het original in de merge, de base version uit de envelope is de neighbor in de merge, en de tip version in de satellite van de export-drawer is de base van de merge. De volgorde der envelopes: de timestamps van de changesets, de meest recente eerst, denk ik, voor Pagina: 123 / 230

124 2.4 Werkwijzen de zekerheid. Verbeter acties vinden verder plaats zoals in de team-drawer en zijn satellites. Tenslotte kan de baseline, met inachtneming van de export limitations gekopieerd worden naar export-drawers. Baseline samenstellen met 2 ontwikkelaars en een tester Project dependencies. Binnen een product familie kennen we generaties, voor de software van NXP is een nieuw ontworpen chip een nieuwe generatie met een nieuw reference design / backbone project en daar van afgeleid de design-in projects. Wijzigingen in de design-in projects die algemeen bruikbaar zijn, zoals opgeloste fouten, worden ook aangebracht in het backbone project. Tussen het backbone project en de design-in projects wordt dan ook aardig wat gesynchroniseerd, en worden envelopes over genomen. Ook bij grote klanten wordt er vaak gewerkt met een fictief project: het backbone project. Ook hier is een nieuwe generatie (of een andere leverancier) van de elektronica vaak de reden om een nieuw backbone project te beginnen. Wijzigingen in design-in projects worden, als ze algemeen bruikbaar zijn, ook aangebracht in de backbone drawer. Nieuwe design-in projects worden gebaseerd op het backbone project. Van de software van het backbone project wordt geëist dat ze compileerbaar is voor alle layer builds, en alle product builds, en mogelijk dat delen ervan uitvoerbaar zijn op enkele testplekken. Synchronisatie en het overnemen van envelopes komen hier systematisch voor. Bij deze grote klanten participeert NXP niet alleen in de design-in projects, maar ook in het backbone project. In de eerste projects baseert NXP zijn packages op het eigen reference design project, later worden deze klanten bedient met packages die zijn gebaseerd uit het backbone project van de klant. Pagina: 124 / 230

125 2.4 Werkwijzen Een opmerking over het backbone / reference design project. Zolang design-in projects uitsluitend wijzigingen overnemen uit dit project, en wijzigingen ook invoeren in dit project, fungeert het project als een buffer tussen de diverse design-in projects. Er is een tendens om wijzigingen uit te wisselen tussen design-in projects, omdat het beleid voor wijzigingen tussen design-in projects overeenstemt. Na een start wordt dit beleid al gauw: minimaliseer de wijziging. Bij een backbone project is het beleid meer: houdt de totale complexiteit zo laag mogelijk. Het is immers steeds opnieuw een uitgangspunt voor andere projects. Dit verschil in beleid maakt dat er vaak manueel gewijzigd wordt, als wijzigingen van een design-in project worden doorgevoerd in het reference design. Soms als aanvulling op een merge, soms zonder merge. Een opmerking over adopts. Een nieuwe generatie chips begint met een design project. En daarmee een nieuwe reference design drawer. Deze begint met een import uit een voorgaand reference design. Kort na het begin van een design project, als de initiële integratie een werkend geheel heeft opgeleverd, worden de meer rigoureuze wijzigingen uitgevoerd zoals uitbreidingen, en redesign, nieuwe drivers voor nieuwe hardware enzovoort. Dit vindt voor het grootste deel plaats in het reference design / backbone project. Zolang herstructurering zich beperkt tot folder herindelingen, en hernoemen tot andere namen voor elements, kan Climbexion de samenhang met drawers van voorgaande projects vasthouden. Als hernoemen en herstructureren plaatsvindt op entiteiten binnen files, bijvoorbeeld procedures, die splitsen of verhuizen naar andere files, of waarvan de naam integraal gewijzigd wordt, dan heb je niets aan Climbexion: de samenhang met andere chip generaties is verloren gegaan. Na het design project beginnen de design-in projects, en daarmee de adopts. Binnen de chip generatie is adopt met mechanische middelen zoals een merge programma min of meer betrouwbaar, maar als je na de beginfase nog wijzigingen uit andere chip generaties wil overnemen dan moet je bedacht zijn op problemen die niet altijd met een merge programma zijn op te lossen Informatie, werkelijkheid, gedistribueerd systeem De synchronisaties tot nu toe betreffen een uitbreiding met één snapshot. Zelfs als wijzigingen over een langere periode worden overgenomen, dan worden ze ingedikt tot één enkele merge of copy. Daarnaast is er een synchronisatie methode die elk detail van de courses kopieert. Dit wordt cloning genoemd. De eerste toepassing is natuurlijk het testen van Climbexion: het uitgangspunt van een test wordt gekopieerd en de kopie wordt gewijzigd door de test. De tweede toepassing betreft het leren van Climbexion, waarbij de leerling wijzigt in een kopie. Als je behalve het kopiëren ook in staat bent de kopie van een drawer af en toe of geregeld aan te vullen met met de de laatste uitbreidingen van de courses, dan is Climbexion aardig op weg om geïmplementeerd te kunnen worden als zuiver gedistribueerd systeem. Nu is het de vraag of zo'n kopie exact gelijk is aan het origineel. Een bit voor bit vergelijking zegt waarschijnlijk: ja hoor ze zijn precies gelijk. En zo is het ook, beide geven ze de historie weer die het origineel heeft ondergaan. Dat is ook meteen het verschil: de clone heeft die historie helemaal niet ondergaan, het is louter informatie, over een werkelijkheid die zich heeft afgespeeld in het origineel. De event en transaction timestamps in de clone zijn pure valid times waar ze in het origineel zeker ook transaction times zijn. Stel dat je besluit om op clones wijzigingen toe te staan, dan bevat de course events die de werkelijkheid van het origineel weergeven, en events die die de werkelijkheid van de clone weergeven, dan is dit een vervaging. Ik vind het een kleine frustratie van één van de uitgangspunten: het opslaan van de Pagina: 125 / 230

126 2.4 Werkwijzen historie, je weet nooit waar het goed voor is, ik raad het af, wees liever precies in de duiding van de werkelijkheid. Een clone hoort uitsluitend informatief te zijn, en geen zelfstandige ontwikkeling te hebben. Je kunt altijd nog een nieuwe drawer maken die is gebaseerd op een snapshot van de clone, en daarin wijzigen. Ik denk dat, als clones volledig geïmplementeerd worden, dat het dan het beste is om Climbexion de transaction time van een synchronisatie te laten bijhouden. De transaction time is de tijd waarop de clone wordt uitgebreid met de laatste course gegevens. Omdat een clone niet altijd up-to-date is kan hij aanleiding zijn tot fouten en misverstanden. Als je weet waarom een fout is gemaakt, dan kun je beoordelen of er mogelijk nog meer fouten zijn gemaakt. (Kennis van de oorzaak kan soms verontrustend en soms geruststellend zijn). De transaction time kan daarbij mogelijk helpen, samen met de discipline om een clone consequent bij te werken vanuit één referential drawer, bij voorkeur het origineel, en niet vanuit verschillende (niet volledig up-to-date) clones. Om een volledig gedistribueerd systeem avant la lettre te maken is nog het volgende nodig. Naast de drawer die gekloond wordt zijn er ook nog de pools met versions en kins. Het moet ook mogelijk zijn om een uittreksel uit een pool te maken en te onderhouden in een local pool, die de drawers van de locatie bedient. Deze bediening betreft zowel de clones, als de lokale originelen. Wijzigingen moeten in andere local pools worden doorgevoerd, als op die locatie wijzigingen worden overgenomen. Dit betreft zowel snapshotgewijze overnames, als coursegewijze overnames. Envelopes horen in principe bij een constellation. Ze horen zichtbaar te zijn voor ieder die de center-drawer onderhoudt of analyseert. Voor de pool met envelopes geldt waarschijnlijk hetzelfde als voor de pool van versions: als er op locatie references staan naar envelopes dan moet de envelope zich in de betreffende local pool bevinden. Daarboven geldt voor een envelopes die prepared of transfered is, dat die teamgenoten moet kunnen informeren, zelfs als er nog geen reference bestaat in hun locaties. Als changesets bijgehouden worden in één element in een drawer, dan is een drawer de eenheid van cloning. Mochten we besluiten om ieder package een changeset element te geven dan is een package de eenheid van cloning, en is er in een drawer een mix van clones en originals mogelijk. Geabonneerde packages in een team drawer zouden een clone kunnen zijn van zo'n package in de import-drawer, tenminste als je baseline supplements realiseert in de import-drawer. Als je baseline supplements realiseert in de team-drawer, dan kunnen import-drawers clones zijn van exportdrawers. Vooralsnog lijkt er geen belangrijke toepassing te zijn voor cloning per package. Als het komt tot een vergelijking tussen een lokale clone van een center-drawer en daarop lokale branches ten opzichte van een center-drawer enerzijds en alleen lokaal een satellite anderzijds dan heb ik het volgende bedacht. 1. In een satellite moet je met exact copy een base creëren voor de volgende wijziging. In een lokale clone is de base voor de branch reeds aanwezig. 2. Als je tussentijds of tenslotte je wijzigingen gaat baseren op andere snapshots dan betekent dit voor Climbexion dat een nieuwe base wordt overgenomen uit de center drawer, dit overnemen hoeft niet bij een DAG 3. Een clone moet worden bijgehouden. Als je er geen hebt hoef je die ook niet bij te houden. 4. De privacy lijkt gelijk. De satellites blijven privé op je PC, maar de clone met branches ook. En slechts de resulterende changesets worden overgedragen naar de community. 5. De clone biedt een volledige historie, met voordelen voor offline werken, de satellite en ook de branch slechts de historie van de snapshots die nodig waren voor de wijzigingen. Pagina: 126 / 230

127 2.4 Werkwijzen 6. Een branch is altijd afhankelijk van een trunk, voor bases en originals, een satellite bevat zelf alle relevante informatie. Een course in een drawer is eenvoudiger dan een DAG. 7. Een drawer is flexibeler dan een branch, want je kunt een satellite (her)synchroniseren met een center-drawer, en met een transfer-drawer, zelfs met een drawer van een ander project. Een branch aan een clone kun je synchroniseren met de clone. (zie afbeelding). 8. Met drawers is er een uniforme methode voor family members, projects, satellites en dergelijke: er is één begrip: de drawer. Met DAG's zijn er twee begrippen: de DAG en de branch. Je moet min of meer arbitraire beslissingen nemen wanneer je een nieuwe DAG begint, en wanneer een nieuwe branch, en bovendien moet je besluiten of de trunk van een DAG een clone is van een branch uit een andere DAG. 9. Je kunt op een drawer de security van het file system op toepassen. Dit kan niet bij een branch. Het revision control systeem moet zijn eigen zijn eigen security onderhouden, als branches anders toegankelijk moeten zijn dan trunks, of als iedere branch zijn eigen toegangs-rechten heeft. Satellite versus clone/branch manier van werken: zoals beschreven voor satellites Pagina: 127 / 230

128 2.4 Werkwijzen Al met al lijken branches qua performance superieur ten opzichte van de satellites. Immers als je werkt met steeds dezelfde satellite, dan kun je niet werken aan meerdere problemen tegelijk, en werk je met een satellite per probleem, dan is er zeker een performance achterstand. Ik hoop dat het effect van punt één beperkt is, omdat courses geen versions bevatten, maar slechts verwijzingen ernaar, maar bij de start van een satellite wordt een compleet snapshot gekopieerd, en niet slechts de wijzigingen ten opzichte van de vorige keer. Punten twee en drie zullen elkaar wel opheffen qua performance, voor een gebruiker is punt drie een aparte handeling, maar bij punt twee is de actie van Climbexion mogelijk geïntegreerd met de merge zelf. Voor thuiswerken en werken op reis is het vijfde punt ook een voordeel, maar niet uitgesloten als je werkt met een satellite. Punt zes lijkt vooral een implementatie voordeel voor de ontwikkelaar van Climbexion, en misschien ook voor een gebruiker die niet echt een lokale clone nodig heeft, er zou toch een tendens kunnen zijn om te gaan werken met clouds. Al met al lijkt een feature waarbij een satellite zich kan funderen op een snapshot in een andere drawer, zonder dat daarbij het snapshot daadwerkelijk wordt gekopieerd zeer wenselijk. Op het performance verlanglijstje staat primair de wens om een drawer te beginnen met een snapshot reference, maar misschien zou in principe elke base tag een reference mogen zijn. Of misschien moet ik voor satellites een uitzondering maken en branches toestaan. Een simpel snapshot model zou volstaan. De snapshots vormen bijna een caterpillar tree. Een caterpillar tree heeft een lange stam en daaraan korte branches van één edge. De stam bevat adjacent synchronisaties van de satellite met de de center-drawer, in de branches worden de problemen opgelost en de envelopes voorbereid. De korte branches zijn wel wat langer dan één snapshot, dus het is geen echte caterpillar tree. Door de structuur simpel te houden blijft het nummeren van snapshots simpel. Bijvoorbeeld, de snapshots van de stam krijgen een volgnummer, de korte takken heten naar het probleem dat ze oplossen, en het snapshot waarop ze zich baseren. De snapshots in de branches krijgen een lokaal volgnummer. Het bepalen of twee course items van een element een ancestor relatie hebben zou simpel moeten zijn, en ook het vinden van een live course item gegeven een snapshot zou zo betrekkelijk simpel moeten zijn, zonder een snapshot tree te hoeven raadplegen. Voorlopig is dit alles voorbarig. Ik zag een promotie video van Linus Torvalds over Git. Kanttekeningen bij enkele opmerkingen: Er is de stelling: met clones is backup overbodig. Het probleem met backups is toch wel dat restore maar zo zelden voorkomt. Als het eens onverwacht nodig is, na een crash of zo, dan sta je met het angstzweet op het voorhoofd af te wachten of het allemaal wel goed gaat. Van clones die op locatie daadwerkelijk gebruikt worden, weet je in ieder geval dat de clone hoogstwaarschijnlijk correct is, en leesbaar. Je hebt dus nog voornamelijk te maken met het probleem dat de clone niet 100 procent up-to-date hoeft te zijn: de tip van het origineel kun je kwijt zijn. Dit probleem geldt overigens ook voor een periodieke backup, maar mogelijk niet bij een systeem met logging, of bij het gebruik van RAID. Dus een aanvulling kan gewenst zijn. Zo'n aanvulling kan natuurlijk een werkwijze of procedure zijn waardoor altijd minstens één clone up-to-date is. Recovery van een software fout in de climbexion software zelf, of van sabotage of van een fout tijdens onderhoud door een systeembeheerder, eist mogelijk dat je terug moet naar een eerdere Pagina: 128 / 230

129 2.4 Werkwijzen versie van een drawer. (Zelf heb ik ooit, in de rol van systeembeheerder, een restore gedraaid in plaats van een backup, we werkten met een zoon, vader, grootvader systeem, met rouleren van de backup schijven). Ook moet je er rekening mee houden dat te laat ontdekte fouten kunnen zijn uitgezaaid in clones, pools, satellites, backups, en log-files, waardoor je terug moet naar een oude backup. Dit kunnen fouten zijn die geheel of gedeeltelijk de course of development onbruikbaar maken. De recente historie ben je dan na restore voorgoed kwijt en moet je mogelijk vervangen door opnieuw wijzigingen aan te brengen. Ik denk dat ik voor de zekerheid toch periodieke backups zou bewaren. Veel van de problemen die een recovery veroorzaken zijn te voorkomen met procedures en (geprogrammeerde) controles, en zo. Maar toch, clones in hun eentje zijn mogelijk geen afdoende backup middel bij een worst case scenario. Als belangrijk argument wordt vermeld om met clones te werken: je kunt offline werken, zonder internet, VPN of intranet. Zo kun je werken in de trein van werk naar huis, en vice versa. Bij NXP zijn ze niet onder de indruk. Er is nog enige concurrentie van het systeem planning-items of work-items : problem reports, delta requests, en change requests, en de rapportages daarop. Een clone van een deel van dit systeem kan ook handig zijn. Ook hierin is een ontwikkelingsgang te volgen. Als je zou moeten kiezen, dan is het maar net wat je gewend bent. Waarschijnlijk hoef je niet te kiezen: als je toch bezig bent kun je ook hieruit kopiëren wat je nodig denkt te hebben, en dit lokaal opslaan. De methode om de transaction te zoeken die de fout veroorzaakte is een belangrijke methode, maar het is niet de enige methode, immers de fout bevindt zich in de tip en kan zonder volledige historie gevonden worden. Ook als je de envelope kunt aanwijzen waarbij de fout zich begon te manifesteren, dan is dat vaak een begin: een fout kan ontsloten zijn door de wijziging, en ook kan het zijn dat te weinig files gewijzigd zijn bij de implementatie van een work-item. De analyse hiervoor kun je plegen op de tip, je hebt de complete courses niet nodig. Kortom een clone is handig maar niet per se noodzakelijk. Soms, bijvoorbeeld bij ontbrekende delta processing, levert de zoektocht door de snapshots geen resultaat op. Die volledige historie moet je met een korreltje zout nemen, baselines van niet eigen packages en adopt merges betekenen een course indikking. De details ervan bevinden zich vaak niet in de teamdrawer. Import limitations kunnen files weglaten uit een team-drawer maar zijn wel te vinden zijn in andere drawers. Een internet verbinding is dan wel gewenst. Sommige drawers zijn niet direct door iedereen benaderbaar, en van de packages die erin worden bijgehouden krijg je slechts die files waarvoor geen export restricties gelden. Dan moet je soms mensen benaderen met een vraag of een probleem. Een telefoon is dan ook wel handig. Als je wijzigingen wilt overnemen uit sister projects, dan heb je ook daarvan misschien een clone nodig, maar liefst een internet toegang. Wat je echt mist is een test omgeving, de lab tafel, de 60 inch televisie, de satelliet schotel en zo. Die krijg je niet zomaar in en op de trein. Dus testen en debuggen kun je hoogstens met unit tests. Debuggen op de televisie is toch ook een zeer belangrijk hulpmiddel om de oorzaak van een fout te vinden. De clone is een halve oplossing, waarbij je slechts een deel van je werk kunt doen. Helaas ben je offline, dus remote debuggen en testen is ook geen optie. Pagina: 129 / 230

130 2.4 Werkwijzen Handicap schatten. De handicap range is 0 <= h <= 1. Hierin betekent handicap 0: je hebt alles beschikbaar (geen handicap), en handicap 1: je hebt niets beschikbaar (geheel onthand), van alles dat je op het werk hebt. Voorlopige stand. Met working-tree en satellite: handicap 0,75; heb je ook een clone van de teamdrawer: handicap 0,6; heb je ook nog een test systeem bij de hand: handicap kleiner dan 0,4. In een thuis of reis omgeving zou je mogelijk kunnen inloggen in een VPN. Lokale clones bieden dan waarschijnlijk een belangrijk performance voordeel ten opzichte van het interactief raadplegen van remote originelen, maar het is niet meteen een probleem, als je af en toe moet kijken in een drawer, die je niet lokaal hebt staan. Het remote testen zou ook georganiseerd kunnen worden. Dit is nog lang niet hetzelfde als ter plekke testen en debuggen, waarbij beeld-fouten en geluid-fouten worden ontdekt met behulp van ogen en oren, rechtstreeks vanaf het beeldscherm en de speakers. En waar je je handen gebruikt, om apparatuur in en uit te pluggen, of om audio/video generatoren in te stellen, bijvoorbeeld door een dvd in een speler te stoppen. Maar structureel meer thuiswerken, of werken in een naburig café met een wifipunt, in plaats van werken in het laboratorium met zijn (snelle) intranet begint mogelijk te worden. Handicap 0,5. Met de handicap cijfers zelf zal mogelijk iedereen het oneens zijn, maar met de ordening die hierdoor ontstaat kun je waarschijnlijk wel instemmen. Je kunt op je werkplek in het laboratorium je laptop voorbereiden op het werk dat je elders denkt te gaan doen. Dan kun je je handicap definitie natuurlijk laten afhangen van het werk dat je voorbereidt. Ook kun je je werk natuurlijk zo indelen dat je alleen datgene elders doet, waarvoor je geen faciliteiten nodig hebt, die buiten je werkplek ontbreken, je actuele handicap wordt dan 0,0. Je structurele handicap is natuurlijk niet nul, want je kunt niet alles elders doen: je kiest voor een werk indeling die afwijkt van de normale gang van zaken, dus waarschijnlijk toch minder efficiënt is. Bij NXP waren er altijd wel mensen die werk mee naar huis namen, of die voor de zaak op reis waren. Maar vanwege de afhankelijkheid van testsystemen en apparatuur werd er ook vaak overgewerkt. Pagina: 130 / 230

131 2.5 Planning & Tracking en Repositories 2.5 Planning & Tracking en Repositories Introductie Work-items (of planning-items) zijn interessant omdat er items zijn waarnaar verwezen wordt in envelopes en patches en mogelijk satellites. Zo zijn er development, delta-process, change, problem, test, maintenance, integration, patch items en misschien nog wel meer. De items waarnaar verwezen wordt zouden in principe net zo lang moeten bestaan als het revision control system zelf, om te voorkomen dat de verwijzing iemand in de toekomst blij maakt met een dode mus. Van het één komt het ander, als je deze items opneemt in een eeuwig durende file, waarom dan niet alle work-items waarop in het project het werk en de voortgang wordt gecontroleerd? Een work-item heeft een voortraject. De meeste Problem reports komen voort uit tests door testers, sommigen uit reviews of uit debugging door ontwikkelaars, sommigen uit field calls. We maken nog onderscheid of het problem is gevonden door het eigen team, of door een ander. Change requests komen voort uit gewijzigde inzichten, of een gewijzigde markt, en uiteindelijk via de opdrachtgever. Delta-process en Nieuwbouw items komen voort uit requirements en uit een nieuwe omgeving. Patch items kunnen voortkomen uit een behoefte een bepaalde voortzetting in de software ontwikkeling te faciliteren. En zo moet er soms verschillend over worden gerapporteerd. Een opdracht om te testen kan wel een work-item zijn, maar is geen opdracht om software te wijzigen. Een integratie opdracht kan betekenen dat een bepaalde drawer wordt bijgewerkt met bestaande software. Work-items hebben een W.B.S. (work break down structure). Er is een W.B.S. als een work-item moet worden gesplitst om te worden uitgevoerd door meerdere subprojects. Voor wat betreft items die leiden tot een wijziging van de center-drawer of tot patches geldt in ieder geval dat ze moeten worden opgesplitst tot er een item voor een enkele package is bereikt. Een item dat opgedeeld is blijft zelf bestaan. Zijn status is de gezamenlijke status van zijn onderdelen. En het is klaar als alle onderdelen klaar zijn. Op een work-item kunnen activities worden uitgevoerd. Zo'n activity wordt gekenmerkt door een stadium. Voor de meeste work-items is er een vastgesteld arsenaal aan te doorlopen stadia. De voortgangsmanager heeft enige speelruimte voor stadium overgangen, zoals terugverwijzen naar een voorgaand stadium, het item aborteren, het item op ijs zetten en zo. In NXP geldt: activities worden gekenmerkt door twee stadia. Bij het stadium analyze hoort het stadium analyzed, bij het stadium implement behoort het stadium implemented, na een gebiedende wijs volgt een voltooid deelwoord. Alleen start en end stadia zijn singles. Een gebiedende wijs stadium wordt gestart door de voortgangs-manager die iemand aanwijst om de betreffende activity uit te voeren en daartoe een opdracht formulering kan toevoegen aan het item. Degene die de opdracht krijgt probeert zo snel mogelijk een verslagje toe te voegen aan het work-item, en vult enige attributes in, om daarna het bijbehorend voltooid deelwoord stadium te starten, zodat de voortgangsmanager weer aan zet is. Als neveneffect (gezien vanuit het work-item management system) zijn er dan in de wereld, bijvoorbeeld in het revision control system, dingen veranderd, getest of uitgezocht. Misschien is het beter om algemene voltooid deelwoorden te gebruiken, die voor alle stadia gelden: interrupted als teruggemeld wordt als de betreffende activiteit om de een of andere reden niet is voltooid, en completed als de uitvoerder vindt dat het stadium met de betreffende activiteit is Pagina: 131 / 230

132 2.5 Planning & Tracking en Repositories afgerond. Of misschien zou de uitvoerder een aanbeveling kunnen doen voor het volgende stadium: dus verified met als aanbeveling: for baseline of implement again ; en analyzed met als aanbeveling reject of analyze again of implement, of break down. De ontwikkeling van de WBS en het doorlopen van stadia vindt gelijktijdig door elkaar plaats. Bijvoorbeeld een analyse activity kan leiden tot een ontwikkeling van een WBS structure van het work-item ten behoeve van daarop volgende implement activities. In TV software, en in de teams herkent men een aantal competences, dwars door de lagen en de teams heen kan men spreken over front-end, audio, video, performance, start-up, zapping enzovoort. De competences zijn nodig voor een work-item, om te worden ingeschat voordat het wordt toegekend aan een subproject, of verdeeld wordt over de subprojects. De stadia vormen een course of development, ze volgen elkaar op, en als het ene stadium geldt, dan geldt er geen ander, het zijn successions. De verslagen en de opdracht beschrijvingen die geleverd worden zijn geen course of development, het ene verslag vervangt niet het andere, alle informatie is tegelijk geldig, het zijn hoofdstukken die toegevoegd worden. Een attribute als uren besteed bijvoorbeeld. Als het work-item 2 maal de stadia analyze en analyzed doorloopt en de eerste keer wordt gemeld dat er 3 uur besteed zijn en de tweede keer dat er 2 uur besteed zijn, dan vervangt de tweede melding de eerste niet: er zijn 5 bestede uren gemeld. Het is geen course maar wel een log. Activities kunnen een composition structuur hebben. Bijvoorbeeld: in een baseline test worden de verifying activities van andere work-items uitgevoerd, terwijl het test stadium van het baseline work-item wordt gerealiseerd. De test activity van het baseline work-item is een compositie van een aantal verify activities van diverse work-items, dus eigenlijk het omgekeerde van work-break-down. Zo'n planning en tracking systeem heeft best wel een interessante structuur voor een database ontwerper. Net als envelopes kunnen work-items worden overgenomen in parallelle subprojects, dus naast parent/child (w.b.s) relationships kunnen er siblings zijn. We kunnen ons voorstellen dat elk subproject zijn eigen planning & tracking systeem beheert met work-items. We kunnen het ons niet alleen voorstellen, zo was de situatie in de projects waaraan ik deelnam. Maar WBS, siblings en zo kunnen refereren dan aan items in diverse systemen. Verslagen en status wijzigingen van children moeten bereikbaar zijn vanuit parents en vice versa. Belanghebbenden, die notificaties wensen kunnen zich in andere teams bevinden. Het geheel moet zijn te overzien in het masterproject, ook als items daar niet zijn ontstaan. Distributie en confidentiality problemen zijn hier een grote uitdaging. Tussen NXP en Philips SC was dit geregeld. Dit is een separaat systeem, buiten Climbexion. In Climbexion zijn work-items slechts opgenomen als attribute in een envelope. Het moet mogelijk zijn dat Climbexion controleert of het work-item bestaat en gebruikt mag worden, en om er een verwijzing naar een envelope aan toe te voegen. Naast de work-items waarnaar verwezen kan worden in envelopes zijn er nog andere shared phenomena: de packages, projects, teams, mensen en dergelijke. Voor teamwork, fout-reconstructie en dergelijke vormt een dergelijk systeem een onmisbare aanvulling op Climbexion: het is een ander deel van Software Configuration Management, net als Build Management. De probleem beschrijvingen en de analyse en implementatie rapporten die aan work-items kunnen worden toegevoegd zijn natuurlijk alleen dan nuttig als ze ook worden gelezen. Als een rapport aangeeft, dat een wijziging nogal wat vergt, kan besloten worden om een simpeler oplossing te Pagina: 132 / 230

133 2.5 Planning & Tracking en Repositories zoeken, of soms, om de wijziging niet te implementeren, of zelfs om de wijziging terug te draaien, als er reeds aan begonnen is. Als ieder in het team ze leest, bijvoorbeeld voorafgaand aan een voortgang bijeenkomst dan kunnen mogelijk vroegtijdig problemen met parallelle wijzigingen gesignaleerd worden. Misschien zijn de wijzigingen dan al ingevoerd, want vaak analyseert en implementeert iemand meerdere items per dag, maar het is altijd nog eerder dan een signaal uit een regressie test: volledige regressie tests vinden plaats voordat een audit start. Hoe houd je de discipline erin? Door elkaar erop aan te spreken als de rapporten niet gelezen blijken te zijn, of als ze nietszeggend lijken te worden. Het commentaar dat je kunt invullen als je een activiteit uitvoert moet zinvol zijn. Wat is nu zinvol commentaar dat je invult voor de analyze activity? Bij een gewoon problem report gaat het allereerst om het reconstrueren van probleem: beschrijf hoe het probleem onder diverse omstandigheden kan worden gereproduceerd. Dan een afbakening de software die gewijzigd moet worden, en tenslotte om een inschatting van de impact van de wijziging, en misschien van de risico's als de wijziging niet en als die wel wordt doorgezet. Het commentaar dat je kunt invullen als je een activiteit uitvoert moet zinvol zijn. Wat is nu zinvol commentaar dat je invult voor de implement activity? Elders heb ik beschreven dat een merge niet altijd toereikend is als je wijzigingen overneemt. Hier zou je een poging kunnen doen om te beschrijven waarmee je zelf rekening hebt gehouden toen je de wijziging implementeerde, en waarmee iemand rekening moet houden als die jouw wijziging wil adopteren. Dit commentaar moet natuurlijk al beschikbaar zijn als je een envelope overdraagt, immers een ander zal je gewijzigde software mogelijk gebruiken als een nieuwe base voor zijn eigen wijzigingen, en daarmee jouw wijzigingen adopteren in zijn satellite. Misschien moet er wel een pseudo-taal voor ontwikkeld worden Relaties met envelopes Envelopes kunnen verwijzen naar work-items, en ook de inverse relatie wordt bijgehouden: een work-item wijst naar de envelopes. Een work-item kan het stadium verify met succes hebben doorlopen, en nu is baseline aan de beurt. In deze stadia, of in een eindstadium, of in een on ice stadium mag er geen envelope gecreëerd worden die naar dit item verwijst, dat mag alleen na een implement opdracht en voordat er een implemented melding is geweest. Na een baselined melding (met aanbeveling end ) is het work-item voorgoed afgesloten. In eerste instantie zou je zeggen dat er nooit een successor envelope gemaakt mag worden nadat het resultaat van een work-item baselined is. Het op te lossen problemen is nu: stel een probleem wordt uiteindelijk opgelost in de baselinedrawer (en zijn satellites) en pas daarna in de team-drawer. Het work-item raakt dan baselined, maar is toch nog niet af. Het is pas compleet klaar als de wijziging ook is aangebracht in de team-drawer. Deze situatie is herkenbaar omdat er envelopes zijn voor de baseline-drawer, met een adopt envelope voor de team-drawer. De volgorde is nu bijvoorbeeld: (verify verified), (baseline, baselined), (finish, finished). Tijdens finish worden de adopt envelopes gebruikt om de wijziging te implementeren in de team-drawer. Daarna moet het work-item toch wel echt geëindigd zijn. Mocht er dan nog een fout opduiken, dan wordt die gerealiseerd met een nieuw work-item. Een work-item mag natuurlijk niet reeds in het stadium verify, gebracht worden als het niet eerst implemented is verklaard (met als aanbeveling verify ). Voor de opdracht verify is het verder Pagina: 133 / 230

134 2.5 Planning & Tracking en Repositories nog nodig dat er geen envelopes in uitvoering zijn (behalve één voor finish ), en dat er minstens één het envelope stadium implemented heeft gehaald. Menselijk beslissen lijkt toch noodzakelijk. Stel je voor dat in een succession van twee envelopes de laatste een undo realiseert van de eerste, dan verifieer je toch wat anders, dan wanneer de undo ontbreekt. Of dat in een succession van drie envelopes de derde een undo realiseert van de eerste, dan wil je toch wel een extra verklaring van voltooiing, voordat verify start. In zijn algemeenheid geldt waarschijnlijk dat de envelopes van een work-item moeten zijn beëindigd ( implemented of rejected ) voordat het implement stadium van het work-item wordt verlaten Composite Activities Baseline samenstellen Het is de bedoeling dat de gegevens in het work-item systeem gebruikt worden bij het samenstellen van de baseline. Hier volgt een scenario: Allereerst wordt met exact copy de tip van de baseline-drawer gelijk gemaakt met die van de team-drawer. Daarna vinden er, in de baseline drawer, undo operaties plaats van wijzigingen die nog niet vrijgegeven moeten worden. De work-items die hierbij een rol spelen zijn die work-items die slaan op het betreffende package, die te maken hebben met software wijzigingen, en die niet verify hebben bereikt, of zijn gestopt. Het lijstje undo work-items moet het liefst met een query gemaakt kunnen worden. Dan is het zaak de lijst te preciseren. Bijvoorbeeld: sommige work-items moeten alsnog worden geïmplementeerd en geverifieerd, die moeten uit deze lijst verwijderd worden. Dan moet de work-item lijst vervangen worden door een envelope lijst, van die envelopes in de team-drawer waarvoor een undo envelope gemaakt moet worden voor de baselinedrawer. Dit is ook een query of een script. Ook moet er een script worden uitgevoerd dat de undo envelopes voor de baseline-drawer prepareert. De undo envelopes worden gerealiseerd, waarschijnlijk als comrade envelopes die gezamenlijk moeten worden overgedragen. Vaak worden in de baseline-drawer soms nog (kleine) wijzigingen geïmplementeerd. De lijst met work-items in de toestand verify, kan gebruikt worden voor het verify deel van de baseline test. Na verificatie (de baseline test) moeten er mogelijk nog meer undo of redo operaties worden uitgevoerd. Die kunnen verzameld worden door een query voor verified work-items met een implement recommendation. De work-items met een baseline recommendation hoeven natuurlijk niet te worden geselecteerd voor undo of redo. Nadat de baseline is gerealiseerd moet er een baselined melding plaatsvinden op de betreffende work-items, de meeste met aanbeveling end maar sommige met de aanbeveling finish. Voor deze laatste moet er een adopt envelope worden aangemaakt die afgeleid is van de envelope in de baseline-drawer. Dit alles wordt mijns inziens gerealiseerd met een script, als een composite activity. Tenslotte moeten er nog query's worden uitgevoerd ten behoeve van het baseline report: om de lijst met opgeloste work-items te documenteren. Pagina: 134 / 230

135 2.5 Planning & Tracking en Repositories 2. Het synchroniseren van de eigen package met die uit een ander project. Van de work-items in het sister-project die worden overgenomen moeten siblings gemaakt worden in het eigen project: dat kan deels met een script. Deze siblings moeten uiteindelijk allen op implemented uitkomen. Meestal zal men synchroniseren met de export-drawer van het sisterproject. De work-items die erbij betrokken zijn zijn te verkrijgen met een query: alles wat baselined is sinds de voorgaande synchronisatie. Deze work-items worden gesplitst in drie lijsten: één voor de over te nemen work-items. (hiervan worden sibling work-items gemaakt) één voor de niet over te nemen items. (hiervan worden undo envelopes gemaakt voor de merge-import-drawer) één voor de reeds gerealiseerde work-items, waarvoor reeds siblings bestaan. (hiervan worden undo envelopes gemaakt voor de merge-import-drawer) Alle undo envelopes zijn comrades die refereren aan het adopt work-item. De composite activity bestaat uit: 3. Als we veronderstellen dat het snapshot met originals reeds aanwezig is in de betreffende merge-import-drawer: exact copy van het snapshot met potentiële neighbors. Dit wordt het snapshot met originals voor de volgende keer. De copy plaatst de tip (of een baseline) van de export-drawer van het sister-project in de merge-import-drawer. We realiseren de undo envelopes in de merge-import-drawer. De nieuwe tip van de mergeimport-drawer bevat de uiteindelijke neighbors. We realiseren een globale merge via een satellite in de team-drawer. Dit gebeurt op de gebruikelijke manier: eerst nemen we de tip-tag van de team-drawer als base, dan vinden builds, tests en plaats, en worden verbeteringen aangebracht, en tenslotte wordt het resultaat gebaseerd op de tip van de transfer-drawer, en overgedragen. Dit vindt plaats onder toezicht van de composite activity van een adopt work-item dat de gehele synchronisatie begeleid. Als dit work-item de melding implemented ontvangt worden ook de sibling work-items op implemented gezet. Adopt en undo operaties tijdens groeps-operaties. Er kunnen work-items zijn die zelf niet refereren aan een envelope, bijvoorbeeld omdat ze met een groeps-operatie (merge vanuit een ander project) zijn geïmplementeerd. Deze work-items zijn siblings van andere work-items die mogelijk wel een envelope hebben, of die zelf weer geïmplementeerd zijn met een groeps-operatie, enzovoort. Via work-item siblings is er altijd wel één te vinden met een envelope, of een set envelopes (envelope comrades en envelope successors). Van die work-item siblings die met envelope zijn implemented kan er één gekozen worden voor de adopt of undo operatie. Misschien kan een script de meest geschikte kandidaat vinden, maar voorlopig ga ik er maar vanuit dat je er een mens voor nodig hebt. 4. In plaats van adopt merge werken met een zwerm adopt envelopes Deze methode is aan te bevelen indien er veel wederzijdse uitwisseling bestaat. Immers tussen originals en neighbors zijn veel gemeenschappelijke wijzigingen gerealiseerd in beide subprojects. Die wijzigingen hoef je niet meer over te nemen. Ook kunnen er veel wijzigingen zijn gerealiseerd in het andere subproject die je niet wilt overnemen. Kortom als het aantal undo envelopes aanzienlijk wordt, dan is de zwerm zeker aan te bevelen. Er vinden selecties plaats op de work-items in het andere subproject om een lijstje work- Pagina: 135 / 230

136 2.5 Planning & Tracking en Repositories items te krijgen waarvan de siblings in het eigen project moeten worden gemaakt. Het lijstje work-items wordt gebruikt om die envelopes te vinden waaruit adopt envelopes moeten worden gemaakt. Een script maakt de sibling work-items in het eigen package, en de envelopes voor de betreffende merge-import-drawer. Met exact copy wordt het snapshot base versions binnen gehaald in de merge-importdrawer. Dit is de tip van de eigen team-drawer. De adopt envelopes worden hierop gerealiseerd, (met behulp van een satellite van de merge-import-drawer). Eventuele aanvullende wijzigingen worden gerealiseerd. In dit drawer en zijn envelopes zijn alle details terug te vinden. Een verschil met adopt merge, voor zover het de groep activity betreft: Een merge vindt plaats naar een satellite van de team-drawer, op de gebruikelijke wijze zodat daar een ingedikte overname plaatsvindt, zoals bij adopt merge. Hier wordt ook een overgang gerealiseerd: eerst was een tip-tag van de team-drawer de base, nu kan men de wijzigingen baseren op de tip van de transfer-drawer. Adopt zwerm: Het work-item voor de merge refereert aan de envelope in de team-drawer waarmee de merge wordt gerealiseerd, maar alle siblings bevatten een envelope waarmee de individuele implementatie in de merge-import-drawer is gerealiseerd. Adopt merge: Het work-item refereert aan alle envelopes: de undo envelopes en de merge envelope. De sibling work-items bevatten geen envelope referentie. De zwerm heeft als voordeel dat alle wijzigingen gerelateerd zijn aan envelopes in de sibling workitems, ook eventuele aanvullende wijzigingen die voortkomen uit build en test resultaten. Dit maakt de zwerm aantrekkelijk ten opzichte van de adopt merge met undo. Pagina: 136 / 230

137 2.6 Builds en Repositories 2.6 Builds en Repositories De invloed van builds op Climbexion Het build proces gebaseerd op recent timestamp. Normaal wordt een build uitgevoerd door een build programma aan de hand van een scrip file. De uitvoering bestaat uit twee delen. Deel 1 creëert een directed graph en deel 2 gebruikt de graph voor generen, compileren en linken. Deze 2 fasen methode is de way of working als je Koala gebruikt. In wezen is de graph een data flow diagram. In wezen is de graph een workflow diagram. Minstens één van beide zal wel waar zijn. De graph bestaat uit 2 soorten nodes, file nodes en script nodes. File nodes bevatten een verwijzing naar een file, en script nodes bevatten een script. Zo'n script beschrijft meestal een compilatie en roept een compiler aan, of het is een link procedure,en roept een linker aan, maar in zijn algemeenheid kan het ook een programma of een script aanroepen dat compileerbare code genereert uit plaatjes of specificaties. Een script node heeft een aantal input nodes, dit zijn altijd file nodes. In de graph zijn het de directe voorgangers van het script. Ze worden wel de dependency list van de scrip node genoemd. Een script node heeft ook één of meer output nodes, dit zijn ook altijd file nodes, en ze volgen rechtstreeks op de script node. Alleen die outputs van een script worden opgenomen in de graph die nodig zijn om de end-node te bereiken, maar eventuele andere output files van het programma dat door de script node wordt aangeroepen worden wél gegenereerd als het script wordt uitgevoerd. Een graph bevat een aantal begin-nodes, en één end-nodes. Begin-nodes zijn file nodes. De endnode is een file node die gewoonlijk een fictief target representeert. Als een build wordt uitgevoerd wordt één file node aangewezen als target. Bij dit target hoort een subgraph naar de reachable begin-nodes. Deze subgraph wordt gebruikt om het target up-to-date te maken. Targets zijn meestal executables of libraries. Het target is de end-node van de subgraph. Over het algemeen wordt in fase 1 slechts de subgraph aangemaakt. Een output file die gegenereerd wordt heet ook wel een derived file, en een file die in begin nodes voorkomt wordt source file genoemd. Een output file die geen target is wordt wel intermediate result file genoemd. Een output file wordt altijd maar op één manier gemaakt. Daarom kan een script node, indien nodig, een unieke naam krijgen als hij wordt genoemd naar de file van de eerste output node. Vaak heeft één van de input files dezelfde naam als de output file (op een type aanduiding na). Deze file noemen we de primary input. Wie de andere input files zijn is dan vaak af te leiden uit de content van de primary input file en de content van reeds gevonden input files. Deel 1 formeert in het algemeen de graph, aan de hand van een script file, parameters, en de bevindingen in het file system. Het is niet eenvoudig om de graph zo precies mogelijk te maken. Als een script node meer inputs nodes heeft dan er werkelijk gebruikt worden tijdens uitvoering van het script, dan gaat dit ten koste van de efficiëntie van het build process. Als er minder input nodes zijn Pagina: 137 / 230

138 2.6 Builds en Repositories dan er gebruikt worden dan kan het build process een foute target genereren. Bijvoorbeeld: de build kan mislukken omdat de linker een oude object file gebruikt, met verouderde referenties, en zonder de nieuwe symbolen. buildgraph Er zijn ontwikkelomgevingen waarin de graph handmatig wordt bijgehouden in een make file. Moderne IDE's houden een project-file bij, waarin alle source files staan, en met de aanname dat elke object file afhangt van een gelijknamige primaire source file en van alle header files, en dat de target afhangt van alle object-files, wordt hieruit de graph gemaakt. De graph kan echter ook (deels) geconstrueerd worden door tools die de structuur van de graph vaststellen, door te kijken wat er in de source en header files staat. De Cpp preprocessor heeft bijvoorbeeld een optie om een dependency list te genereren door na te gaan welke header files worden gebruikt in een C of C++ programma en hun header files. Voor NXP Mips software is er het Koala gereedschap dat wordt gebruikt om vast te stellen welke object files nodig zijn voor een target. Koala bepaalt dit aan de hand van de koala files. In feite kijkt koala welke Koala files gewijzigd zijn ten opzichte van de vorige keer, en wijzigt zo de tree van de vorige keer. Pagina: 138 / 230

139 2.6 Builds en Repositories Hoe dan ook, de build scripts zijn vaak complex en net zo "under construction" als de software zelf, dus lang niet altijd volmaakt. Deel 2 voert script nodes in de subgraph uit. Een node wordt uitgevoerd omdat één van de output files ontbreekt. Er is wel een output node maar de genoemde file staat niet in het file system. Na uitvoering van het script is de file er wel. Een node wordt ook uitgevoerd als de timestamp van één van de input files recenter is dan die van één van de output files. Na afloop van het script hebben alle output files van de node een recentere timestamp dan de input files. Een node mag pas worden uitgevoerd, als die script nodes zijn uitgeprobeerd, en mogelijk ook zijn uitgevoerd, die een input file leveren voor de node. Er worden net zo lang script nodes uitgevoerd tot er geen aanleiding meer is: alle output files van elke node in de subgraph zijn er en ze zijn allemaal recenter dan de betreffende input files. In plaats van te zeggen: de node wordt uitgevoerd, of het script van de node wordt uitgevoerd zegt men ook wel: de node vuurt of het script wordt afgevuurd of de node vuurt het script af. Als deel 2 afgebroken wordt, bijvoorbeeld doordat een compilatie mislukt en een error code afgeeft, en je verbetert de fout, dan gaat deel 2 van een nieuwe build verder waar de oude is gebleven. Het is altijd mogelijk om een volledige build uit te voeren voor een gekozen target. Dit werkt als volgt: iedere node in de subgraph moet eenmaal vuren. Een node gaat vuren als geen van zijn input files wordt gegenereerd door een andere node het zijn allemaal source files. Een node gaat ook vuren als alle script nodes hebben gevuurd, die één van zijn input files genereren. Dit is nodig als het geheel aan source files en intermediate result files is gecorrumpeerd, bijvoorbeeld omdat de timestamps niet kloppen, of omdat een fout verlopen generator wel een foute output file heeft gemaakt. Ook na wijziging van het build process, of van de tools die erin gebruikt worden is het raadzaam om een volledige build uit te voeren. De verzameling derived files kan gemanipuleerd worden buiten de build procedure om, dat kan corruptie veroorzaken, waarna een clean build nodig is. Het is aan de gebruiker om vast te stellen of een volledige build nodig is. Een indicatie is bijvoorbeeld dat een gewone build mislukt, of dat de binary zich onverwacht gedraagt. Maar als de volledige build dan ook mislukt, of als de binary zich nog steeds onverwacht gedraagt dan lag het mogelijk niet aan de build. Een zwak punt : Als er oudere source files opduiken in de working-tree dan die van derived files in de vorige build, dan is dat bij een nieuwe build geen aanleiding om een node af te vuren. Hier is de werking van het revision control system in het geding. Een working-tree synchroniseren levert vaak recentere timestamps op van gewijzigde files en altijd dezelfde timestamps voor ongewijzigde files. Maar het kan voorkomen dat wijzigingen in de working-tree worden tenietgedaan door synchroniseren, dan is de timestamp van een gewijzigde file niet per se recenter dan die van de vervangen file. We specificeren een optie die Climbexion laat werken op de volgende manier: Pagina: 139 / 230

140 2.6 Builds en Repositories De timestamp wordt geleverd door het tip event van de course van de file. Wanneer de working-tree wordt gesynchroniseerd met de drawer dan kan de repository software aan de course van een element het event toevoegen dat het element is gekopieerd naar de working-tree Dit is het touch event. Dit event heeft een jongere timestamp dan de voorgaande build, en is gelijk aan de timestamp van de working-tree file na synchronisatie. Het revision control system is dan nog steeds in staat om te controleren of kopiëren nodig is, ingeval van exact copy. Deze optie van het revision control system is er speciaal voor builds die gebaseerd zijn op recent timestamp. Een bekend voorbeeld van een make programma gebaseerd op recent timestamps: GNU Make. Een programma dat Koala lijkt te evenaren als het gaat om builds over een complexe folder structuur, en het scheiden van sources en derived files: Cmake. De opslag van tussenresultaten: Elke target heeft een eigen folder voor de derived files: de build folder. Een product target heeft andere derived files dan een platform target, (dank zij o.m. de compile time interface binding van KOALA, die header files genereert voor elke c source file: een gecompileerde file voor een product verschilt daardoor van die voor een platform) de object modules in debug mode verschillen van die in optimize mode, dus voor één target kan er een folder zijn voor debug, en één voor optimize. De.h files en c files die gegenereerd worden door de idl compiler zijn altijd hetzelfde, of ze nu in een platform build worden gebruikt, of in een product build, of in een component build. In debug mode of in optimize mode, ze zijn hetzelfde. Hiervoor wordt dan ook een aparte folder gebruikt, zodat de ene build kan profiteren van de tussenresultaten van de andere. Binnen de inner-reach van zo'n build folder vindt je vaak een folder structuur voor de nette opslag van intermediate result files. De targets zelf komen als member terecht in de build folder. Deze target wordt mogelijk gekopieerd in de inner-reach van een package, bijvoorbeeld om met het package gedistribueerd te worden. Het build proces gebaseerd op different timestamp. De studie hier is om te kijken of de build folder kan worden opgeslagen in de team-drawer na de acceptatie test. Als een satellite wordt gesynchroniseerd, dan wordt ook de meest recente build folder van de daily build beschikbaar gesteld en hoeven alleen de eigen wijzigingen te worden gecompileerd. Een inner-reach van een build folder voor de derived files van de daily builds is voorlopig één enkel element in het revision control system, dat wil zeggen een archief (zip, tar) file van zo'n folder is een element in het revision control system. De vraag is nu hoe de build procedure moet worden aangepast om builds in working-trees of info-trees goed te laten verlopen: Het build process moet niet langer testen of de timestamp van de file in een output node minder recent is dan dat van één van de input nodes, maar of de timestamp van de input node afwijkt van die van de vorige keer. Dit kan door de graph op te slaan met de timestamps van de betrokken files. De timestamps worden opgeslagen op de input edges van Pagina: 140 / 230

141 2.6 Builds en Repositories de script nodes, en up-to-date gebracht nadat het vuren van de script node goed is verlopen. Als een file uit het revision control system wordt geplaatst in een working-tree of info-tree, dan moet de timestamp niet de timestamp zijn van het tip event in de betrokken drawer, maar de timestamp van de version. Deze timestamp is de datum laatste wijziging van de file ten tijde van de commit. Deze optie van het revision control system is speciaal voor builds die gebaseerd zijn op different timestamp. De optie is een een waarde van een attribute van de drawer. Edges van Begin Nodes met Timestamps De builds voor platform of andere onderdelen en voor het product worden hierdoor mogelijk minder langdurend. In plaats van een clean build kun je dan de build folder uit het revision control system halen, en profiteren van de resultaten die daar reeds behaald zijn. Dit build process is mogelijk kwetsbaarder voor corruptie dan een build gebaseerd op recent timestamp, omdat de graph met timestamps permanent moet worden opgeslagen, ook nadat er een (compilatie) fout is opgetreden. Pagina: 141 / 230

142 2.6 Builds en Repositories In feite gaat het om de betrouwbaarheid van een permanente gegevensbank: die kan gaan afwijken van de werkelijkheid. Deze kwetsbaarheid is reeds begonnen bij Koala, die gebruik maakt van een voorgaande data om de huidige data bij te werken, en de buildgraph te creëren. Meer dan bij een recent timestamp methode geldt in zijn algemeenheid: Kies een gerenommeerd build tool. Kies gerenommeerde compilers, linkers, generators en vooral betrouwbare tools om delen van de buildgraph te af te leiden. Zorg voor een adequate discipline om de eigen scripts en tools bij te houden. Zorg voor een adequate omgeving en discipline om de builds uit te voeren. Zorg regelmatig voor clean builds. Bijvoorbeeld de dagelijkse builds in de team-drawer zouden clean builds kunnen zijn: hierbij kan de buildgraph opnieuw gemaakt worden. In feite is het voor deze timestamp methode niet per se nodig om de gehele graph op te slaan. Een graph bestaat uit nodes en edges. De edges vanaf een source node naar een script node zijn van belang. Voor elk van deze edges moet de timestamp van de source bewaard worden. Dit is natuurlijk minder robuust, dan een methode die alles opslaat. Het make algoritme werkt nu als volgt. Een script node mag pas vuren als al zijn voorgangers zijn geprobeerd, en mogelijk hebben gevuurd. Als de file van een output node ontbreekt dan kan gevuurd worden. Als de file van een output node minder recent is dan die van een intermediate result input node, dan kan gevuurd worden. Als de timestamp van een file van een source input node afwijkt van de timestamp op de edge, dan kan gevuurd worden. Ook als er geen timestamp bekend is van een vorige build, kan gevuurd worden. Als het vuren zonder fouten afloopt wordt de edge up-to-date gebracht, met de timestamp van de source. Voorbeelden van make programma's gebaseerd op different timestamp: Alcatel-Lucent Nmake ( free software: Odin ( In plaats van een timestamp wordt ook wel gesteld dat je beter een content hash kunt gebruiken. Climbexion versions krijgen als interne identifier waarschijnlijk een door Climbexion gegenereerde content hash. Deze zou als metadata in een working-tree file kunnen worden geplaatst. Het best zou de hash door het edit tool kunnen worden gegenereerd bij een "save" opdracht, en berekend kunnen worden voor gegenereerde files, zodra die ontstaan: dus voordat een commit plaatsvindt. Samenvatting recent en different timestamp builds Climbexion heeft 2 opties: Voor recent timestamp builds: Een working-tree element krijgt als datum laatste wijziging de timestamp van het laatste event in de course. Als een working-tree file opnieuw wordt gesynchroniseerd met de satellite (exact copy) dan wordt dit als event (touch event) geplaatst in de course van de gekopieerde file. De working-tree file krijgt de timestamp van dit laatste event. Voor different timestamp builds: Een working-tree file krijgt de timestamp van de version (de datum laatste wijziging) of anders diens content hash. Elements zonder versions (folders) krijgen de geboorte timestamp van de kin, of de kin id in plaats van de hash. Pagina: 142 / 230

143 2.6 Builds en Repositories Soortgelijke opties vond ik bij Synergy. Het build proces zonder timestamp of checksum, gewoon voor de lol. De methode die ik nu beschrijf is van origine een push algoritme. Dit wil zeggen dat een update wordt gepropageerd naar alle targets. Een voorwaarde is dat er een taak (ihook) is opgestart die in actie komt zodra een (gewijzigde) file in de working-tree terechtkomt, een hook van de file close procedure zeg maar. Ik weet niet of er build tools bestaan die zijn gebaseerd op dit principe, in mijn jeugd heb ik mij hieraan bezondigd voor een software transitie van de afdeling ontwikkeling naar de afdeling productie. Mijn amateuristische implementatie was echter niet robuust en niet herstartbaar na een compilatiefout, en de methode is een stille dood gestorven. In de praktijk kan een wijziging van een source leiden tot een wijziging in de structuur van de buildgraph. De beschrijving van het algoritme houd ik hier eenvoudig door uit te gaan van een ongewijzigde opgeslagen buildgraph: De script nodes in de buildgraph worden genummerd zodanig dat een node X waarvan een output file input is voor een node Y een lager nummer krijgt dan node Y. Naast de buildgraph wordt er een heap bijgehouden. De taak ihook plaatst node nummers in de heap. Voor elke (gewijzigde) file die de working-tree binnenkomt wordt uitgezocht voor welke script nodes de file een input file is, en die node nummers worden door ihook in de heap geplaatst. Een build procedure haalt steeds de laagst genummerde node volledig uit de heap en voert die uit. Dit resulteert in nieuw gewijzigde files in de working-tree, zodat ihook weer (met prioriteit) in actie komt en de heap uitbreidt. Een en ander maakt dat het algoritme voornamelijk geschikt kan zijn voor build managers. Een drawer voor een build manager staat bijvoorbeeld open voor overdrachten van ontwikkelaars (met een overdrachtstool), en periodiek wordt de drawer gesloten en vindt de build plaats (met een build tool). Het algoritme zou in die situatie simpel geïmplementeerd kunnen worden, want ihook is eenvoudig te implementeren als een procedure in beide tools. Over het algemeen is het de vraag of er een ihook gemaakt kan worden die altijd en overal werkt, en je wilt de situatie vermijden dat er met veel regels en beperkingen gewaarborgd moet worden dat ihook werkt. Helaas is het niet praktisch als de build manager andere tools hanteert voor de build dan de ontwikkelaars. Eigenlijk kan het principe worden toegepast zonder heap, op zo'n manier dat file-to-script edges in de buildgraph gemarkeerd worden door ihook. Er zouden daarna pull algoritmen gebruikt kunnen worden. Merk op dat ihook kan markeren buiten de subgraph die bij een pull methode gebruikt wordt, ook als ze door het pull algoritme aan het werk gezet wordt. Bij de different timestamp methode kan eerst de structuur van de buildgraph worden bijgewerkt in de deel 1 fase van de build. Daarna tijdens deel 2 van de build fase worden nieuwe timestamps opgeslagen. Maar bij deze ihook methode moet de buildgraph in deel 1 niet alleen bijgewerkt worden maar ook nog gemarkeerd worden door ihook. Het weghalen van een markering vindt in het build proces plaats meteen nadat de node met succes heeft gevuurd in deel 2. De kwetsbaarheid van ihook komt bovenop de kwetsbaarheid die reeds gold voor de different Pagina: 143 / 230

144 2.6 Builds en Repositories timestamp methode: de permanente opslag van de buildgraph die altijd een getrouwe administratie moet zijn van de werkelijkheid. Als er iets mis gaat is de graph opnieuw af te leiden uit de werkelijkheid, maar opgeslagen timestamps en markeringen niet. Een verschil tussen een timestamp in een input edge en een markering van een input edge: als de timestamp niet is ingevuld dan is dat een reden om de script node te laten vuren, als een markering niet is ingevuld, dan is dat geen reden om de node te laten vuren. Eigenlijk is de timestamp (of hash) van een file in een gebruikelijk file system geen unieke identificatie van de versie van een file: theoretisch is het mogelijk dat een andere versie van een file de working-tree binnenkomt die dezelfde timestamp (of hash) heeft als zijn voorganger. Wat dat betreft is deze ihook methode uitstekend en theoretisch volmaakt. Aan de andere kant als een bestaande file voor de tweede keer de tree binnenkomt, dan is een markeer reactie overbodig, en zou die onderdrukt moeten worden, en dat vermogen heeft mijn methode niet. De buildgraph lijkt wel wat op een petri-net, maar er zijn typische verschillen, Zo bevinden zich de tokens bij de buildgraph op de arcs van file-nodes naar script nodes (input arcs). Een script node (transitie) mag vuren als minstens één input arc een token bevat of als een output file ontbreekt. Als een token geplaatst wordt op een arc, dan verenigt deze zich met een eventueel reeds aanwezig token. In een petri-net bevinden de tokens zich in places, moeten alle input places een token bevatten voordat een transitie mag vuren, en verenigen tokens zich niet. Een script node in een buildgraph vuurt pas als er geen verdere plaatsing van tokens wordt verwacht op de input arcs, er is sprake van een gedwongen volgorde, in tegenstelling tot het non determinisme van petri-nets. Ik vermoed dat een buildgraph vertaald kan worden in een petri-net, maar wel één met de nodige extensies waardoor er weinig toegevoegde waarde is: het petri-net is waarschijnlijk niet beter analyseerbaar en verifieerbaar, dan de buildgraph. Het zou misschien belangrijk kunnen zijn voor de taxonomie: make of build software is een vorm van workflow software First class citizens of tarballs Ik ga er tot nu toe vanuit dat voor Climbexion een build folder een file element is, een tarball of een zip file. In principe betekent dit dat grote hoeveelheden content worden getransporteerd en opgeslagen. Als je aanneemt dat het vooral clean builds (builds vanaf scratch) zijn die worden opgeslagen dan is dit mogelijk gerechtvaardigd. Het element-type "gearchiveerde folder" kan geïntroduceerd worden voor het opslaan van folder-structuren met derived files. Als je twee keer dezelfde source file compileert en je vergelijkt de content van de twee object files, dan blijken die soms te verschillen. Dit komt omdat in een aantal formaten van object files de compilatie timestamp of link timestamp deel uitmaakt van de inhoud van de files, en er niet slechts als metadata bij de file-id of in een file fork aan is toegevoegd. De content in een intermediate result file of in een target zal daarom verschillen van die van een voorganger als hij opnieuw gemaakt wordt. Er zijn waarschijnlijk nog andere oorzaken waardoor twee compilaties van precies dezelfde sources kunnen verschillen. Met simpele compare tools en checksum of hash tools herken je zo geen files die eigenlijk hetzelfde zijn. Enige mogelijke bijkomende oorzaken: Niet geïnitialiseerd data geheugen, niet geïnitialiseerde gaps. Pagina: 144 / 230

145 2.6 Builds en Repositories Non determinisme (bijvoorbeeld door het gebruik van threads tijdens compileren), Linkers en library tools zijn vaak in staat om incrementeel object files te incorporeren in executables en libraries. Ook vervangen en verwijderen van objecten is mogelijk. Je kunt verwachten dat het adres van de geheugen allocatie van een object binnen de executables of libraries afhangt van de volgorde waarin de mutaties zich aandienen. Dit geldt in ieder geval voor sommige van deze tools. Er zijn C macro's als DATE en TIME. De datum en tijd zouden slechts dan in de content van een object file mogen worden opgenomen als deze macro's daadwerkelijk gebruikt worden. zelflerende compilers. ;-) Ik heb niet de indruk dat ik de volgende vraag volledig en uitputtend behandeld heb: wanneer kun je niet met een simpel compare tool of met een hash bepalen of twee derived files hetzelfde zijn. Mogelijk is een test of het wel of niet kan erg simpel. Misschien is mijn scepsis gebaseerd op spoken uit een ver verleden, en komen dit soort problemen momenteel helemaal niet voor. Toen ik in Wikipedia een vergelijking vond van formaten van object files, was er sprake van de mogelijkheid om metadata op te slaan in de content. Maar misschien wordt hiermee debug informatie bedoeld, zoals line numbers, en non external symbols. Gebruik je een object file formaat waarin geen metadata wordt opgeslagen in content, en een compiler / linker die de hele content initialiseert enzovoort, dan kan Climbexion met een simpel tool herkennen dat object files hetzelfde zijn, en is het efficiënt om geen tarball te gebruiken maar om individuele versions te vervangen en te transporteren, zelfs bij builds vanaf scratch. Als er sprake is van non determinisme, dan kan in de praktijk gelden dat er een reële kans is dat een object file in twee opeenvolgende builds op dezelfde PC gelijk zijn. Als je werkt met verschillende typen derived files, dan zijn sommige typen vast wel exact reconstrueerbaar. Misschien geldt dan: neem die kans en werk met first-class-citizens. Het gebruik van build procedures gebaseerd op recent timestamp is een belangrijke reden om regelmatig clean builds uit te voren, maar ik ben er van overtuigd dat het niet de enige reden is. Soms is een clean build aan te bevelen als source files verplaatst of hernoemd zijn, want een build tool kent gewoonlijk geen kin, en zou ten onrechte een verweesde derived file kunnen tolereren als een source file. Een build manager die bouwt voor een wijzigend team zal alleen al daarom voor de zekerheid regelmatig clean builds uitvoeren, liever dan nauwkeurig na te gaan wat er precies gewijzigd is en dan manueel te zorgen voor precies de juiste rebuild. Maar misschien is zijn er inmiddels goede tools, immers een source file hoort niet voor te komen in een folder voor derived files; een goed tool weet dat en verwijdert een verweesde file, en Climbexion hoort dit ook te weten en vult een nihil file in in de filestring, of wijzigt name en folder reference in de file-string reference. Uiteindelijk zou een clean build slechts nodig zijn bij een wijziging van de build software, of corruptie of verlies van de build database waarin de identifiers van de oorspronkelijke versions zijn opgeslagen. Misschien is een clean build nodig bij corruptie of verlies van build folders, maar een goed tool herkent mogelijk de corruptie en verwijdert derived files die afwijken van de build database, voordat de build start. Nu we kunnen besluiten om build results niet op te slaan als archive, moeten we maar een kijken naar de gegenereerde folders, zijn dat other-focused folders? Een folder is in Climbexion gedefinieerd als een element zonder inhoud, waarnaar andere elementen mogen wijzen. Zo'n folder slaat echt niet op een snapshot, maar is een gewone folder, met hooguit een entity type build Pagina: 145 / 230

146 2.6 Builds en Repositories container. Af en toe moet maar eens gekeken worden, of zo'n folder beëindigd moet worden Build Forest Deze trend in de ontwikkeling definieert een working-tree, of een info-tree als een verzameling build trees, die min of meer onafhankelijk van elkaar builds kunnen uitvoeren. Zo'n build tree bestaat dan uit packages. Een executable (binary) die gemaakt wordt in de ene build tree moet kunnen samenwerken met die uit een andere als ze worden uitgevoerd in de televisie. Dit samenwerken kenden we reeds: een TriMedia binary moet samenwerken met een MIPS binary en met een 8051 binary, maar nu krijgt elke binary een eigen subtree, en er komen meerdere binaries voor de MIPS processor. Sommige van mijn collega's zijn bezorgd en spreken over het naderen van de dependency hell, waarmee ze runtime afhankelijkheden aanduiden. Mijns inziens wordt de hell pas bereikt als independent deployment wordt bereikt, en voorlopig zal ik het geen hell noemen maar een uitdaging. Build forest Om op runtime te kunnen communiceren worden interface gegevens, en referentie codes van servers mee gecompileerd en gelinkt met clients. De betreffende files worden gedefinieerd in een package van de ene tree, of in een package in de andere, of zelfs in een derde tree. De methode die gebruikt wordt is hetzelfde of is afgeleid van de COM methode van Microsoft. Dit houdt in dat een midl compiler wordt gebruikt in een build. Een package bevat 2 soorten shared data: public binnen de build tree (local public). public binnen het build forest (global public). In een local public folder structuur worden voornamelijk koala interface files en koala data definitie files, en public koala componenten beschikbaar gesteld, en in een global public folder (gpf) structuur een mix van sources en derived files. Er kunnen mogelijk koala interfaces in staan maar zeker ook COM en idl elementen. Bij derived files in een global public folder moet men denken aan gegenereerde proxy/stub/guid source modules, en gegenereerde header files. Zo'n global public folder moet ook gebruikt worden buiten de build tree waarin hij staat, er zijn dan ook verwijzingen vanuit andere build trees naar de global public folder. Voor Climbexion betekent dit dat er een element bijkomt: de soft-link van een build tree naar een Pagina: 146 / 230

147 2.6 Builds en Repositories global public folder in een andere build tree. Strikt genomen is dit niet nodig omdat de koala pd files zo'n tree kunnen definiëren. Maar ik zag dat ze hiervoor Windows shortcuts te gebruiken. global public reference structuur Er zijn twee smaken: de soft-link naar een folder binnen het package, en de soft-link naar een folder in een ander package. Het tweede type hoeft niet per se opgelost te worden. Net als package references trouwens. In export en import drawers komt immers geen volledige tree voor. Het gebruik van import limitations op satellites en info-trees kan gebruikt worden om een aantal build trees te trimmen zodat daarin alleen de global public folders en de executables beschikbaar worden gesteld. De subtrees met eigen packages bevatten natuurlijk wel alle sources, om de eigen executable te maken. Om dergelijke import limitations te kunnen gebruiken zal de executable, de target van de build waarschijnlijk gescheiden van de intermediate result files en de buildgraph worden bewaard. Normaal mag een team slechts eigen packages wijzigen. Packages van andere teams worden normaal alleen gewijzigd met patches. (je kunt wel files wijzigen in info-trees en working-trees, en misschien satellites maar niet en in de center-drawer, want de version pool is read-only voor normale transfers). Nu Climbexion faciliteiten biedt om build resultaten op te slaan wil je dat niet prijsgeven als het build forest geïntroduceerd wordt. Maar als build folders verspreid in packages staan, dan zou hun inhoud ook gewijzigd moeten kunnen worden door andere teams, bijvoorbeeld tijdens hun dagelijkse build, bijvoorbeeld als de build een clean build is, waarbij h files proxies, stubs en guids c files worden gegenereerd. Dus deze derived elements mogen vrij worden gewijzigd. Deze files zullen daarom misschien in een andere pool, met andere access rechten moeten komen. Pagina: 147 / 230

148 2.6 Builds en Repositories Het lijkt er op dat soft-links het best gespecificeerd kunnen worden in een global public folder van een aan het masterproject gerelateerd package. Ze staan dan met z'n allen centraal in een lijstje, en hoeven alleen daar te worden bijgehouden. Er is dan wel een mechanisme nodig in de build tools, om ook de global public folders van de eigen tree via die soft-link te benaderen en niet rechtstreeks, dan wel dat ze juist niet via soft-links benaderd worden, maar wel rechtstreeks, maar in ieder geval niet dubbel. Hopelijk is dit verder oplosbaar zonder bijdrage van Climbexion. Climbexion zou mogelijk slechts moeten bewaken dat soft-links niet buiten de working-tree of de info-tree verwijzen. Het kan voorkomen dat de ene televisie een tuner gebruikt van Fabrikant A, met een driver in package TunerA, en de andere televisie een tuner van Fabrikant B met de driver in TunerB. Beiden implementeren interfaces uit de UHAPI standaard. De middleware moet dus de ene keer zijn referentie gegevens inlijven uit de global public folder van TunerA, en de andere keer uit de global public folder van TunerB, vaak afhankelijk van het project, en soms afhankelijk van diversity binnen het project. In het laatste geval moet de build procedure de juiste soft-link kiezen, afhankelijk van build parameters. Waarom wordt dit niet opgelost met louter Koala component structuren? Ik denk dat deze methode een redelijk overzichtelijke structuur is, voor ieder die aan de software werkt. De structuren van de pd files zijn normaal niet zichtbaar voor iemand die met de file browser door de tree gaat. Normaal werk je aan de sources voor één executable tegelijk. Die staan dan in een subtree. Waarom kan dit beter opgelost worden met pd files? Wat in deze structuur niet kan is een package met onderdelen voor de ene executable en met onderdelen voor de andere. Een package kan zich slechts in één tree tegelijk ophouden. Dit is een extra eis aan een package. Normaal is een package een eenheid van distributie en beheer, een extra eis kan betekenen dat een package opgesplitst moet worden. Als je dit met pd files regelt, om opsplitsing te voorkomen, dan kan een package zelf mogelijk zo gestructureerd worden, dat er meerdere pd files in voorkomen. Er is dan verschil tussen een Climbexion package en een Koala package. Een Climbexion top folder van package Pa0 zou dan kunnen bestaan uit de folders: Pa0-computer-1, Pa0-computer-2, Pa0-common, Pa0-gpf Build bij NXP Koala als make tool De cd files van Koala bevatten voor iedere c file (bijvoorbeeld foo.c) een module clausule, (de clausule foo). Zo'n clausule is de entiteit die vertaald moet worden in een h file (foo.h), waarbij gegevens uit gerefereerde id files en dd files worden bewerkt en ingelijfd in de h file. De buildgraph daarvoor wordt geconstrueerd tijdens uitvoering van het engine dat in de Koala documentatie is beschreven. Het genereren vindt meen ik plaats onder de eigen besturing van Koala, dus niet met behulp van een make tool. De folder met header files (één per nodige module) die Koala bijhoudt zijn daarna de de basis van de buildgraph. Test harness generator Voor het audio/video platform wordt een aparte executable gemaakt, om dit platform te testen. De methods van de UHAPI interfaces kunnen in deze executable rechtstreeks aangeroepen worden met behulp van een menu en de remote control. Ook kunnen de interfaces gebruikt worden in testscripts Pagina: 148 / 230

149 2.6 Builds en Repositories via een RPC methode tussen een desktopcomputer en een televisie, waarbij het script verwerkt wordt door een tool op de desktop. Het test-harness bestaat uit software voor menu en remote control enerzijds en voor communicatie met een testscript op de PC anderzijds, en wordt voor een belangrijk deel automatisch gegenereerd. De test harness generator van het platform onderhoudt veel menu files, en veel header en c files. De cd file van het harness moet afgestemd blijven met de cd file van het platform. Allen moeten ook nog eens afgestemd blijven en met een aantal id en dd files. Een aantal interfaces van het platform worden niet bediend door het harness, zoals bijvoorbeeld de pump en pump engine interfaces. Die worden door de harness component doorgegeven naar de top cd file. Misschien is de generator lastig te combineren met Koala, en is hij daarom buiten de build procedure gebleven. Mogelijk speelt ook mee, dat de repository (Synergy) vooral voor sources is bestemd, dus niet voor de files die uit een reguliere build komen, en is er daarom niet gezocht naar een methode om de generator in de build procedures te krijgen. Dus moeten de ontwikkelaars zelf het test-harness genereren als dat nodig is en daarna het nieuwe harness overdragen aan de teamdrawer. Hier gaan dingen fout als in latere project stadia vooral met product software getest wordt. De ervaring leert dan ook dat het zinvol is om dergelijke generatoren koste wat het kost in de reguliere build procedures in te bouwen, en het gegenereerde te beschouwen als derived files. Als het genereren nagelaten wordt leidt dat vaak niet meteen tot compilatie fouten, maar wel tot moeilijk te determineren fouten op run tijd. Een opmerkelijk fenomeen doet zich hierbij voor: als een ontwikkelaar tegen het probleem aanloopt is het vaak de eerste keer dat die ertegenaan loopt en dus zoekt hij zich wezenloos. De fout staat maar zelden vooraan in de persoonlijke checklist van de fout zoekende programmeur. Maar toch: velen hebben ooit zo'n probleem opgelost. Iets anders dat mis gaat met de test-harness generator is de vertaling van constanten. Ik bedoel hiermee symbolen die in een nummer vertaald worden door de compiler. Toen ik NXP verliet was dit probleem nog niet opgelost. Het tool dat de testscripts afhandelt gebruikt een andere notatie wijze van de declaratie van deze symbolen dan wat geleverd wordt door de generator. Dit heeft geleid tot een dubbele registratie van de constanten: zowel in de data definitie files van Koala als in aparte tekst files voor het test tool. Ook zo'n dubbele administratie is niet aan te bevelen, en een bron van fouten. Er zijn nog enkele van dergelijke generatoren in gebruik, maar daarmee heb ik niet of nauwelijks te maken gehad, dus die blijven hier onbeschreven Versnipperingen Meerdere buildgraphs en build scripts Hoewel de binnen NXP gebruikte (recent timestamp) make methode toestaat dat er één build script wordt gebruikt voor alle targets, is dit niet de werkwijze binnen NXP. Er is gescheiden beheer van build scripts, gewoon omdat degene die verantwoordelijk is voor een product build niet verantwoordelijk is voor een platform build, en de beheerder van een unit-test build weer een ander kan zijn. De build scripts bevatten de duiding van het target, de cross-compiler/linker en overige Pagina: 149 / 230

150 2.6 Builds en Repositories generator referenties, en de top cd file. Dank zij KOALA is er weinig reuse van intermediate results, zoals object files. Dus kan elke buildgraph zijn eigen build folder hebben. Er is één script per target met opties als debug, assert, optimize en dergelijke, die ieder hun eigen folder krijgen. Per folder wordt er één make file (buildgraph) gemaakt. Binnen een buildgraph zijn er subgraphs voor speciale doeleinden, bijvoorbeeld om een build vanaf scratch uit te voeren. Dit vind je ook terug in de build scripts. Nu er gebruik wordt gemaakt van COM is er een hoeveelheid shared intermediate result files. De structuur is navenant: Er is een gemeenschappelijke general folder met een gegenereerde make file waarin de buildgraph voor de general derived file wordt beschreven. Er is een build folder voor elke target. Waarin de make file wordt geplaatst die de buildgraph van de target beschrijft, en een script dat eerst de general build uitvoert en dan de eigen build. Ontwikkelingsgang Oorspronkelijk in de Tv software werd er één build folder (met een inner-reach structuur) gebruikt. Dat wil zeggen één voor iedere executable: debug executable en optimize executable hadden ieder hun eigen build folder. Met de komst van Koala kwam een test harnas voor het AV platform in een andere build folder dan een test harnas voor Middleware. Deze build folders stonden en staan in de top folder van de tree. Deze indeling is er nog steeds, maar om een aantal redenen zijn een aantal derived files in een eigen folder terecht gekomen. Toen Philips SC dedicated chips ging maken voor televisies kwam een deel van de software ontwikkeling voor rekening van SC en een deel maakte de klant, en kwamen er export limitations. Oorspronkelijk gebeurde dit doordat object files uit de build folder werden geselecteerd, en in een statische library werden geplaatst, die zelf in een folder van het betreffende package stond. (één voor testen: (assert, logging, debugging), één voor optimize). Dit gebeurde dus met een extra kopieerslag. Toen kwam KOALA waardoor dit moeilijker was. Immers, door de compile time binding van KOALA is de objectcode van een module in executable A anders dan de objectcode in executable B. Bij software voor de MIPS zag men de constructie dat een static object library ingebed werd in een KOALA component, die de interfaces naar die library verzorgde. Voor de TriMedia werden executables beschikbaar gesteld. In beide gevallen één voor optimize en één voor het testen. Met de introductie van de com component methode kwam er in de top van de tree een folder voor gegenereerde header, stub, en proxy files. Met de introductie van het build forest gaan deze gegenereerde header en c files in de global public folder komen, waarin ze thuishoren. Nu, met het build forest, wordt het weer eenvoudig mogelijk om binary code per package te distribueren. Echter de oude situatie waarin gegevens gekopieerd werden uit de build folder in een repository folder lijkt achterhaald. De gegenereerde code kan beter door de build procedures meteen in de juiste folder in het package geplaatst worden zodat er een uniforme Pagina: 150 / 230

151 2.6 Builds en Repositories manier van werken is voor de builds in import/export gelimiteerde en in de ongelimiteerde omgeving; voor de producent van het package en voor de consument. De uniforme methode betreft zowel de builds van binaries, als ook de packaging die nodig is om een werkend systeem te onderhouden in de televisie. De build folders in de top van de tree zullen geheel verdwijnen. Vermoedelijk wordt Koala op termijn opgevolgd door een methode die wat minder uitgaat van de resource restricted aard van een televisie en de daarvan profiterende compile time oplossingen: er is misschien wel genoeg geheugen en genoeg processing power voor runtime oplossingen, en het overslaan van code kan desnoods zelfs plaatsvinden in installatie procedures. (In software kun je nu eenmaal alles van hot naar haar verhuizen.) Dan ontstaat een systeem waarin diverse targets diverse object files en diverse header files kunnen delen, Voorlopig heb ik hiermee geen rekening gehouden. In de hele elektronica branch zal de software wel variëren van uiterst resource restricted systems, to zeer resource rich systems. Import/Export limitations dragen ook bij aan de versnipperingen omdat het target van een build gescheiden wordt van de intermediate result files. De targets zijn de (dynamic link) libraries of de executables. Zij worden altijd beschikbaar gesteld. De intermediate result files zijn bijvoorbeeld de object files en de door KOALA gegenereerde header files. Deze laatsten worden mogelijk niet beschikbaar gesteld aan derden, of ze worden toch niet gebruikt door degenen die het target niet zelf willen genereren. Naast Philips CE worden de chips verkocht aan een groot aantal afnemers. Geen van die afnemers werkt met KOALA, dus dat is een interne aangelegenheid van NXP, in haar deel van de software. Daardoor is het leveren van gegenereerde code onvermijdelijk: de klant beschikt niet over de Koala generatoren. Sommige klanten werken met de volgende procedure om een compleet product samen te stellen: source code, static libraries, dynamic libraries en executables worden opgestuurd naar de klant, en die maakt er een product package van dat wordt teruggestuurd. Dit is een no-nonsense procedure: je levert naast libraries natuurlijk geen source code die toch niet gebruikt wordt voor het samenstellen van het product. Deze methode is een combinatie van import en export limitations. Het is niet bepaald een optimale methode voor een gemeenschappelijk project. De bedoeling van Climbexion is dat deze wijze van werken vervangen wordt door methoden waarbij ieder optimaal kan beschikken over source informatie, en zelf de binaries kan genereren waarin de eigen software is ingebed. Deze klanten eisen dat de software kwaliteit die NXP levert aan het begin van de samenwerking hoger is, dan wat NXP/Philips CE gewend zijn. Dat is natuurlijk niet zonder reden: nu de import/export limitations tot het uiterste worden doorgevoerd is het lokaliseren of toewijzen van een bug geen peulenschilletje. Bij NXP zeggen ze: wij passen ons aan aan de Aziatische manier van zaken doen. Ik verwacht en ik hoop dat deze kwaliteit verbetering lukt zonder het idee van gezamenlijke chip en software ontwikkeling geweld aan te doen. Het is natuurlijk niet de bedoeling dat gewacht wordt tot het reference model van NXP helemaal volmaakt klaar is voordat de eerste grote klant instapt. Daarvoor heb ik mijn repository niet Climbexion genoemd. En Pagina: 151 / 230

152 2.6 Builds en Repositories bovendien is internationaal samenwerken om te ontwikkelen daarvoor veel te leuk. Mijn verwachting dat kwaliteit verbetering lukt is hierop gebaseerd: NXP leunde soms wat te veel op acceptatie tests van CE, om daarna met verve de daaruit voortvloeiende problemen op te lossen. Die tests hadden ze zelf kunnen doen: acceptatie tests horen een formaliteit te zijn. Je klanten horen jou niet te vertellen wat de status is van je product, maar jij hoort je klanten te vertellen wat de status is van je product. De invloed op builds De versnipperingen zijn als volgt samen te vatten: Containers voor derived files bevinden zich op diverse plaatsen in de working-tree. Deze containers bevatten natuurlijk? de bijbehorende permanente dependency lists, die van hen zelf en die van hun content. De permanente dependency lists moet waarschijnlijk even versnipperd opgeslagen worden als de derived files. Veel containers kunnen waarschijnlijk daar in de workingtree geplaatst worden, waar er een primary source file bestaat met gegevens over die container. Op de plaats waar een Koala top component staat, daar zullen ook wel containers horen, maar toch zeker ook in global public folders. Build tools moeten de versnipperingen faciliteren. Als build targets en hun intermediate result files gedistribueerd worden betreft dit waarschijnlijk een vooraf afgesproken beperkte hoeveelheid varianten. (voor TriMedia bijvoorbeeld: assert, optimize). Maar voor persoonlijke opslag zouden mogelijk meerdere varianten, en gemengde targets gewenst kunnen zijn, dus de opslag in satellites kan complexer zijn dan de opslag in export drawers. Met name het activeren van logging van de inhoud van variabelen kan aanleiding zijn tot meer persoonlijke intermediate result files en targets. Binnen de debug containers komen dan objects waarin logging is geactiveerd, en mogelijk ook varianten, waarin logging niet is geactiveerd Other-focused build results In een team-drawer zonder transfer-drawer waarin dagelijks build results worden opgeslagen moet welhaast gebruik worden gemaakt van other-focused build results. Als de clean build klaar is, kan er alweer een changeset zijn overgedragen, en slaat het build result niet langer op de tip van drawer. Gegeven de aard van een derived files: ze horen bij een tag, en zijn een vorm van informatie over de tag maakt dat ze principieel behoren tot de other-focused files. Een reden om build results überhaupt op te slaan in de team drawer: builds kunnen onbetrouwbaar zijn, zodat je regelmatig clean builds wilt uitvoeren. Dit kan efficiënt worden uitgevoerd door de build manager die dit periodiek doet voor het hele team. Dit argument vervalt als builds onder alle omstandigheden erg betrouwbaar zijn, maar spreekt weer erg aan als per work-item een satellite met working-tree gebruikt wordt. Een andere reden om other-focused files te gebruiken: een ontwikkelaar test met twee build targets, en controleert nog twee andere builds op foutloos resultaat, je hebt dan 4 builds gepleegd maar het team heeft behoefte aan de opslag van een stuk of 16 build targets. Ook hier zou de build manager dit geregeld kunnen doen voor het hele team. Build voor baselines en patches: in principe zouden build results kunnen worden overgedragen samen met de source files. Vanuit drawers die exclusief door een build-manager worden beheerd. Dus zijn other-focused files hier mogelijk vermijdbaar. Pagina: 152 / 230

153 2.6 Builds en Repositories Mogelijk wordt in de toekomst meer gewerkt met script talen zoals bijvoorbeeld Python. Die hoeven niet gecompileerd te worden. Of met JIT compilers die op runtime compileren, net voordat de module gebruikt wordt, hoewel sommige JIT compilers byte code compileren naar machine code. Dit vermindert mogelijk de behoefte aan builds en build results, en misschien ook de behoefte aan de opslag ervan in een repository. Soms kun je zulke programma's niet alleen laten interpreteren, maar kun je ze ook statisch compileren, om de werking te versnellen. De behoeft aan wel of niet other-focused build results is hier niet direct te overzien. Builds worden momenteel gebruikt als een soort kwaliteit borging bij overdrachten. Dit is niet alleen omdat mensen steken laten vallen, maar ook omdat merge programma's niet volledig zijn te vertrouwen. Dit gebruik is op zich geen reden om build results op te nemen. Wat je bij een overdracht of periodiek mogelijk hierom wilt opslaan in de repository is de boodschap van het build programma: build finished with error code 0 (of niet natuurlijk). Dit is typisch informatie die in een een other-focused file wordt geplaatst: het vertelt iets over het snapshot Conclusies Export limitations maken het noodzakelijk dat binary code wordt opgenomen in de repository, verschillen in software engineering practices tussen de teams noodzaken soms tot de opslag van build results, ook import limitations maken het soms wenselijk. Efficiency op de werkvloer kan aanleiding zijn om build results op te nemen in de repository. Als je binaries opneemt in Climbexion dan lijkt een build methode gebaseerd op different timestamp of content hash onvermijdelijk, en alleen al door het gebruik van een repository is deze methode te verkiezen boven de recent timestamp methode, zelfs als je de build results niet opslaat. Als je build results via de repository beschikbaar wilt stellen, dan is het absoluut noodzakelijk. Het gegeven dat distributies plaatsvinden per package betekent dat te distribueren build folders met hun inhoud worden opgeslagen bij die packages, misschien als tarball, liefst als een verzameling first class citizens. Build targets moeten in ieder geval als first class citizens behandeld worden in verband met de limitations. We wisten reeds: build managers kunnen langdurig builds uitvoeren, zonder team-drawer en/of transfer-drawer langdurig te blokkeren voor wijzigingen: door build resultaten op te nemen in owndrawer-focused files Build extra's. DianPush Build Gatherers en Outliners Probleem: 1. Een beetje intelligente linker geef je een start module, en je wijst hem een verzameling met object-files. De linker zoekt bij external references, die modules die de externals bevatten. Dit gebeurt met een verzamel algoritme of gatherer. Na het linken is bekend welke modules ingelijfd zijn, en daarmee is de dependency list bekend, en kun je vaststellen of er gelinkt had moeten worden. 2. Een compiler geef je een source module en wijst hem een verzameling met import files. De Pagina: 153 / 230

154 2.6 Builds en Repositories compiler lijft dankzij de referenties in de code de betreffende import files in. Dit gebeurt met een andere soort gatherer. Na het compileren is de dependency list bekend en kun je vaststellen of er opnieuw gecompileerd had moeten worden. Gatherer type één. Linkers kunnen dit op libraries. De link-editor op IBM mainframes had zo'n algoritme. Het werd daar altijd toegepast omdat een object file altijd in library terecht kwam. Op de Microsoft en Unix systemen waarop ik sinds de jaren tachtig actief ben worden libraries vooral toegepast voor standaard software libraries, en minder voor de software die men zelf onderhanden heeft. Daar verzamelt de linker niet wat hij nodig heeft uit het aanbod, maar lijft hij alles in dat aangeboden wordt, met uitzondering van datgene dat in de standaard libraries staat want daarvoor gebruikt hij de gatherer. De eerste gatherer eist dat zijn input pool in zijn geheel op orde is: alle bekende primary sources moeten zijn gecompileerd tot objects. Immers een unresolved reference vertelt niet in welke file de betreffende external wordt verwacht, dus make weet niet welke file gemaakt moet worden. Om de pool op orde te krijgen kunnen eventueel script nodes buiten de subgraph van de executable uitgevoerd worden. De aard van de tweede gatherer is zo dat die weet welke file ingelijfd moet worden. Als die er niet is, dan kan worden nagegaan of er een subgraph bestaat met de file als target, en uiteindelijk of zo'n subgraph kan worden aangemaakt, als die nog niet bestaat. Kun je met gatherers een buildgraph maken door gebruik te maken van uitgeklede linkers en compilers die de gatherer bevatten, en die vooraf werken? Dan is er, in ieder geval voor het verzamel algoritme van de linker het probleem die pas kan worden uitgevoerd als de objects er zijn, zelfs als het een verzamel algoritme type twee zou zijn. Hoe vooraf is dat nog? Voorlopig zoeken we een oplossing zonder vooraf de graph te maken. Wat een voorwaarde is voor de different timestamp methode, namelijk de permanente opslag van de timestamp van een file, is tevens een optimalisatie van het automatische generatie proces. Er wordt gebruik gemaakt van de dependency lists van de vorige keer, en alleen die dependency lists met hun subgraphs worden bijgewerkt waarvan minstens één lid is gewijzigd, of verdwenen, en uiteraard wordt de betreffende script node uitgevoerd. Een dependency list die uitsluitend uit source (niet afgeleide) files kan bestaan kan worden geselecteerd door de gatherer en opgeslagen als output file van zijn script node. Ook het linker algoritme waarvoor de object library vooraf op orde moet zijn kan op die manier werken. Deze dependency list wordt gemaakt door het verzamel algoritme, door de gatherer, niet vooraf, maar tijdens het vuren van de script node en is na afloop beschikbaar voor permanente opslag, samen met de versie identificatie van de bijbehorende input files. Stel de gatherer wil files inlijven die derived zijn. De dependency list moet dan mogelijk al gaande worden ontwikkeld. De file die op het punt staat om ingelijfd te worden moet diep gecontroleerd worden op actualiteit, en misschien gegenereerd worden. De uitvoering van de script node kan pas verdergaan nadat controle en/of generatie klaar is. Een bezwaar tegen zo'n recursieve procedure is dat mogelijk niet iedere generator en niet ieder operating system faciliteiten levert om te wachten op een file, die mogelijk nog gemaakt moet worden. Een ander bezwaar is dat er meerdere tools tegelijk aan de gang zijn, die elkaar mogelijk ernstig vertragen, omdat ze allen liefst alle beschikbare geheugen gebruiken. Voor een simpele oplossingen zonder pipes geldt verder: van die generatie tools is er één aan het werk, en de anderen wachten op hem, terwijl ze hem ondertussen Pagina: 154 / 230

155 2.6 Builds en Repositories vertragen. Voorlopig noemen we dit: the unwanted recursion als we ernaar verwijzen. Soms is er een alternatief voor deze recursive procedure. De oplossing die ik ken is een push methode. Na afloop zijn alle targets up-to-date. Dit is bijvoorbeeld mogelijk onder de volgende condities: 1. Elke generatie tool werkt met een primary input. 2. De primary input van een generatie tool moet als zodanig herkenbaar zijn, Bijvoorbeeld, een tool dat slechts nodig is voor twee van de tien c files gebruikt niet de parameters uit het script, maar leest een parameter file als primary input. De c files zijn dan voor hem geen primary input, maar de speciaal getypeerde parameter files wel. 3. Voorlopig eisen we dat primary input files altijd source of derived files zijn, zodat er voor iedere script node een primary input file bestaat, zelfs als deze leeg is, of als zijn inhoud op de een of andere manier verondersteld kan worden. Andere oplossingen dan met een primary file beschouwen we voorlopig als frivool, en goed voor later. Nu gaat het om een rigide systeem. Waarschijnlijk is rigide hier beter dan frivool. Ook voor secondaire data zoals opties prefereren we trouwens een input file boven environment variables, zodat een verandering opgemerkt wordt. 4. Je moet een generatie volgorde kunnen aanwijzen: bijvoorbeeld je wilt eerst alle idl compilaties uitvoeren, dan koala, dan c compilaties, dan zo nodig object libraries bijwerken, tenslotte de te vernieuwen executables maken. Kortom er is een categorie indeling van de generatie tools, en er is een volgorde waarin de categorieën afgehandeld worden. Zo'n categorie zullen we een push-position noemen. De eerste drie condities zijn natuurlijk ook heel praktisch als je met een pull algoritme zou werken. We zullen ze de build preconditions noemen. Merk op dat aan de output zijde niet geëist wordt dat er een output file gemaakt wordt met dezelfde name als primary input file. De opgeslagen dependency list is natuurlijk wel een file die dezelfde name krijgt als de primary input file. Push make op een volledige working-tree is vermoedelijk een make procedure die je het bloed onder de nagels vandaan kan halen door alle extra werk die hij verricht voor hij de ene executable levert die je nodig hebt. Aan de andere kant is dit toch wel de natuurlijke methode als je gebruik wilt maken van de dependency lists van de vorige keer: de nieuwe list is een output file van de gatherer, en is beschikbaar na afloop van het script van de node en kan dan voorzien worden van de version metadata van de input. Stel je hebt een folder voor derived files voor zowel een product target, een platform target en enige targets voor unit tests. We gebruiken een c compiler, een library tool en een linker. Als je een product target wil maken dan is de target selectie best wel mogelijk: er is een primary source file voor ieder target. Het push algoritme slaat dan de primary source files voor de andere targets over. Iets soortgelijks kan vervolgens gelden voor libraries. En tenslotte selecteert een product build de c source files van de working-tree, minus de c files voor tools, en minus de c files voor test harnesses enzovoort. Ook deze selectie lijkt niet te moeilijk. Een unit test gebruikt de c file sources uit zijn harness folder en de modules van een paar componenten. Het platform target gebruikt de c files van zijn harness folder, plus de c files in de platform subtree minus folders voor tools en test harnesses. Folders voor harnesses gebruiken mogelijk soft-links naar extra resources. Expliciete subtree selectie in de working-tree, en subtree duiding door folder entity type selectie of exclusie lijken redelijk stabiel, en niet erg onderhoud gevoelig. Ze zouden simpel en overzichtelijk moeten zijn. Maar anderzijds: de NHSW tree bevat een allegaartje aan folder entity typen, en is een integratie van allerlei substructuren, er is legacy. Simpel, overzichtelijk, betrouwbaar, en stabiel is niet Pagina: 155 / 230

156 2.6 Builds en Repositories gegarandeerd. Expressies voor afbakening van de input zouden voor targets en intermediate result files kunnen worden vastgelegd. We noemen de software die tijdens build een afbakening beschikbaar stelt een outliner. Die software zou dus van de expressies gebruik kunnen maken. We blijven rigide: een outliner die een outline beschikbaar stelt doet dat voorlopig in de vorm van een index met de resource locator's van files. Outliners kun je gebruiken als gatherers ontbreken, of nog niet bruikbaar zijn. Ze worden gebruikt in push methoden voor primary source selectie uit de working-tree, en sturen ook die pull methoden, waarvan de primary source selectie volledig vooraf wordt geconstrueerd. Voor een pull methode kan de buildgraph als volgt gemaakt worden. De outliner van de linker weet waar in de working-tree de primary source files van zijn libraries staan, maakt er een lijst van, en vertaalt de source namen in library namen. De outliner van een library weet waar zijn c files staan en vertaalt de namen van de c files in namen van de object modules. De vertaalde namen vormen de dependency list voor de script node die de library aanvult, of de linker creëert. Bij een push methode wordt eerst een outline gemaakt van alle betrokken c files. Als de object files gemaakt zijn, wordt een object outline gemaakt voor de eerste library en wordt die bijgewerkt. Zo worden ze successievelijk bijgewerkt. Tenslotte wordt de outline van libraries voor de linker vastgesteld en wordt die uitgevoerd. In het algemeen lijkt de push methode de voorkeur te hebben boven pull, immers in de build sessie hoeven de script nodes dan niet in een graph structuur te worden gezet, maar in simpeler gesorteerde lijst (precondition 4) Bij een pull methode moeten de outlines van te voren beschikbaar zijn, maar bij een push methode hoeft een outline pas beschikbaar te zijn als je aan een pushposition begint. Er kan gebruik worden gemaakt van derived files die wel of niet zijn ontstaan in voorgaande push-positions. Kun je gatherers gebruiken als outliners? De primary file waarop de gatherer wordt losgelaten in fase één van de build moet up-to-date zijn, dus een source file zijn. Je moet de gatherer dus vooraf gebruiken. Dan geldt voor een aantal references misschien dat ze unresolved zijn, en van een aantal dat ze derived files zijn. Een garantie zou moeten zijn dat de dependency list compleet is, dus liefst geen references of altijd dezelfde in de derived files. Verder geldt voor iedere derived file dat de primary input name moet zijn af te leiden uit de file name. Deze primary input file en de erbij behorende outline zijn zijn dependency list. In de (rigide) beschrijving van DianPush ga ik er vanuit dat er geen gatherers gebruikt worden. In feite ga ik ervan uit dat het afgebakende deel van de working-tree niet top-down tot stand hoeft te komen. In de working-tree worden outliners gebruikt om een build zoveel mogelijk te beperken tot de essentiële primary input files, en om restricties op te leggen aan de plaatsen waar de gatherer mag zoeken naar secondary input files. NHSW kent secondary input files die alleen binnen een component of binnen een package gebruikt mogen worden. Een outliner kan dit faciliteren en zo bijdragen aan de integriteit en onderhoudbaarheid van de software. Als je zondigt en ten onrechte zo'n file wilt inlijven dan heeft dat een error tot gevolg: hij behoort immers niet tot de outline. Compilers en linkers zijn typisch entiteiten die gebaat zijn met een gatherer. Normaliter is die ingebouwd. Folders en libraries voor derived files zijn typisch entiteiten die een outliner gebruiken Pagina: 156 / 230

157 2.6 Builds en Repositories die in zijn geheel ingelijfd wordt. Gathering voor een linker wordt vaak vermeden met zeer nauwkeurige outliners. Overall outliner. Inleiding Koala is een gatherer om een outline te maken. De component description files (cd-files) bevatten een lijstje met in te lijven componenten en een lijstje van modules die bij de component horen. Voor ieder target is er een top cd-file. De begrenzing van Koala is de working-tree. De begrenzing van de verzameling waaruit de linker de objects verzameld voor het target: die lijst met modules wordt door Koala samengesteld door een componenten tree op te zetten. Koala gebruikt elementen uit het working-tree landschap om de componenten tree te trimmen en om modules te selecteren: met name pd files, id files dd files. Ook gegevens in de cd files worden bij het trimmen gebruikt. De cd files hebben een aantal c files uit hun directe omgeving onder hun hoede en staan in contact met een aantal andere cd files en bij een build word een subgraph samengesteld van de cd files. Ik heb niet veel werk verricht voor de TriMedia's. De programmeurs daar gebruikten recursive make, maar waren blij dat ze er dankzij Koala vanaf konden komen. Als ik hun gemopper goed begrepen heb: ze hadden het pull algoritme vervangen door een ander recursief algoritme. Daardoor werd er wel eens gevuurd voordat de files uit de dependency list up-to-date waren. Met Google vindt je er talloze beschrijvingen en voorbeelden van. Trouwens je vindt dan ook veel commentaar op recursive make, maar ook regels om het goed te doen. Ik denk dat ze recursive make vooral gebruikten vanwege het feit dat iedere make file een aantal sources onder zijn hoede heeft en en in verbinding staat met andere make files. Waarschijnlijk komen er of zijn er meer verzamelende outliners, dan Koala. Die verzorgen de afbakening van waarschijnlijk alle script nodes. We zullen zo'n outliner een custodian outliner noemen. Maar in het vervolg, als we spreken we over de outliner dan bedoelen we de custodian outliner. Omdat de component descriptor file reeds voorkomt bij Koala zullen we spreken over een custodian file. Een custodian heeft in zijn directe omgeving een aantal source files onder zijn hoede en staat in verbinding met enkele andere custodians. Onder zijn hoede hebben of hoede zelf zullen we vertalen als notice. Onder zijn hoede zal ik noteren als in notice Custodian is toch wel een mondvol. We zullen dit afkorten tot dian. Voorlopig ben ik rigide en plaats naast iedere cd file van Koala een dian file, Daarnaast komen er nog dian files die folders voor h, id, dd, idl files in de gaten houden, buiten de componenten. En tenslotte zijn er de dian files met de folders voor derived files in notice. Waar Koala zelf zijn outlines bepaalt is dat natuurlijk overbodig, maar ik wil toch wel een indruk krijgen voor wat betreft de feasibility van dians. Als je naar een cd tree kijkt, dan kan een component er meermalen in voorkomen. Eigenlijk is dat een vorm van node splitsten. De graph structuur is een DAG. Het lijkt logisch om een DAG toe te staan voor dians. De outliner kan daarmee rekenen: indien bij het bepalen van een outline een dian andermaal bezocht zou worden, dan wordt hij overgeslagen. Als een build start is de parameter die je aan de outliner geeft: een start dian. Je vraagt de outliner om een build outline te maken: wat de outliner retourneert: een index van dians die bij de build betrokken zijn. De index wordt mogelijk intern in de outliner gebruikt. Alle bij de build betrokken primary source inputs horen bij één van de dians in de outline. Ook primary derived inputs vallen binnen de dians, maar die staan nog niet vast. Ze kunnen immers voor een deel gegenereerd worden als het push algoritme aan de gang gaat. Zelfs, zoals we nog zullen zien, kunnen ze gaande de build Pagina: 157 / 230

158 2.6 Builds en Repositories vervallen. Een positie in een normale outline van een dian outliner bevat (voorlopig) de fully qualified name van de dian, en een local name van de file. Er komt een moment dat een file of een outline nodig blijkt als input voor een tool, dan moet het paar (dian,file) alsnog worden vervangen door de fully qualified name van de file. Voorbeelden van requests aan de outliner: Gegeven Dian: /nhsw/product/target.dian Request Dians outline Resultaat Index of dians Folder: objects Primary inputs outline: Dian: /nhsw/platform/derived/object.dian type: c files Index of c files File: m3.c, Dian: /nhsw/platform/tuner.dian Secondary inputs outline: type: h files Index of h files File: m3.c, Dian: /nhsw/platform/tuner.dian Folder to store derived output: type: obj files Index with 1 folder Folder: object, Is file in primary source Dian: /nhsw/platform/derived/object.dian outline of folder? File: m3.c, Dian: /nhsw/platform/tuner.dian yes De Stored Input Output File (sio file) De dependency list met version informatie van de betrokken input, samen met de lijst gegenereerde output files worden opgeslagen in een sio file. Ook de version informatie van die files wordt opgeslagen. Wijzigingen in de working-tree, waardoor input files ontbreken of opschoning acties waardoor output files ontbreken, of corruptie als een output file is gemaakt door ongeldig handelen zijn hiermee te corrigeren. Namelijk door de script node te laten vuren. Omdat we met een rigide systeem werken zijn alle ins en outs van een script node files met version data. Hier kunnen we misschien maar beter niet frivool worden. Het is denkbaar dat een generatie tool de secondary input file foo inlijft als die er is, maar als foo ontbreekt dan wordt net zo goed output geproduceerd. In dat geval verwachten we in de sio file in de output list de regel foo ontbreekt. Derived Folders Folders voor derived files hebben een primary source input. Deze primary input files zijn zelf nooit derived omdat ze in de allereerste push-position in het build process worden gecompileerd tot folders. De df file geeft informatie over de derived folders die samen met hem in een gewone folder staan. Een van die folders is de sio folder. In plaats van een folder voor object files, zou een library gespecificeerd kunnen worden. We noemende de primary input file een df file. In de file staat een push-position (het volgnummer voor de push volgorde). De generatie tools die horen bij die push-position schrijven hun output en hun sio file in de folders die in de df file genoemd worden. Er is altijd een sio folder. Die bevat uitsluitend sio files. Pagina: 158 / 230

159 2.6 Builds en Repositories Waar wordt de sio file van de df file opgeborgen? In dezelfde folder als de df file of in een verzamel folder van het package. Het besluit daarover moet nog genomen worden. De dian die de df file in notice heeft, heeft ook de inhoud van de derived folders in notice. Op deze manier worden de versnipperingen bedient. Varianten Stel je hebt een script node en je doet één van de builds en de script node heeft als source input: foo versie A De dag erna doe je één van de andere builds, en nu is de source input foo versie B Dan is het de vraag: heb je hier te maken met een opvolger, of met een alternatief. Als geen van de sources gewijzigd is dan heb je zeker te maken met een alternatief. Die moet zijn ontstaan omdat de outliner de tweede keer een andere input koos, dan de eerste keer. Als dit onopzettelijk is gebeurt dan is het waarschijnlijk een fout, waarbij builds elkaar tegenwerken en waarbij de nieuwe output de vorige vervangt en opvolgt. Dit gebeurt keer keer als de verschillende build elkaar opvolgen. Varianten ontstaan niet spontaan in ons systeem. Spontane varianten zijn fouten. Wij werken met opzettelijke varianten. Stel we hebben besloten: compiler_level {debug, assert, optimize} computer {Mips, TriMedia, IntelP50} (Dit zorgt ervoor dat de juiste cross compilers gebruikt worden) Compiler_level noemen we het variant type, debug noemen we de variant. Files die alternatieven van elkaar zijn behoren tot verschillende varianten of variant combinaties. Rigide als we zijn slaan we varianten als volgt op: Waar tot nu toe een file staat in de working-tree daar staat vanaf nu een gelijknamige folder. In die folder bevinden zich de files. Een file die altijd bruikbaar is heet...\file\{,} Een file in debug mode voor IntelP50 heet...\executable\ {debug,intelp50} Een file kan dus heten:...\module.o\ {assert, Mips} of...\global\compiler-options.txt\{optimize,} of...\tools\linker\{,trimedia} Bij een build wordt een file opgegeven met de varianten die gelden voor de build: de varianten file. In frivole systems hebben variant combinaties vriendelijke namen en worden ze op een andere plaats in de path-name van een file geplaatst, bijvoorbeeld: {,} verdwijnt, "{optimize,}" wordt optimize\, "{assert, Mips}" wordt assertmips\ en zo. De variant combinaties komen dan bijvoorbeeld vlak voor de file name...\tools\trimedia\compiler. Ook zie je wel dat varianten deel uitmaken van de file name, bijvoorbeeld in source files:...\global\compiler-options-optimize.txt. Als een bepaalde input van een script node zoals een c compiler de varianten file inlijft, dan begint het ermee dat die de varianten selecteert die van toepassing zijn De betrokken de output files zijn varianten met de juiste variant combinatie in hun naam, en de gatherer selecteert de input files met de juiste variant combinatie. Vaak is dit slechts een deel van alle varianten. Een c file is geen debug of intelp50 variant, de option file voor een compiler heeft alternatieven dankzij het compiler-level type. De (cross-) compiler is een alternatief dankzij het computer type. De object file heeft alternatieven dankzij een combinatie van varianten. Pagina: 159 / 230

160 2.6 Builds en Repositories Enige overwegingen. Een Koala package moet waarschijnlijk verteld worden wat de computer is, want dit beïnvloedt mogelijk de diversity. Misschien maakt het voor het package niet uit of optimize of debug gekozen is, en is dat irrelevante variant data. Computer data kan belangrijk zijn voor Koala packages: het is een diversity parameter. De output files van Koala zijn alternatieven dankzij Computer. Een eigenaardigheid van een dergelijke variant is misschien wel, dat er geen executables zijn die elkaars alternatief zijn in de projects waarin in actief was:, een TriMedia oplossing hoeft nooit op de Mips te draaien en omgekeerd. Voor Koala geldt misschien daarom ook dat gegenereerde files en object files niet als alternatieven van elkaar behandeld hoeven te worden, want die komen zo wie zo al in verschillende folders. We zouden mogelijk "target system"als variant type kunnen opvoeren. Bijvoorbeeld In het master project maken we software voor een Noord Amerikaanse, een Zuid Amerikaanse, en een Euraziatische televisie. Een team dat Koala niet gebruikt zou mogelijk als volgt kunnen werken: de header files waarin de diversity beschreven is zouden dan alternatieven van elkaar zijn, en de geproduceerde object files en executables ook. Dit variant type is van belang voor Koala packages, om de betreffende diversity te kiezen. De variant selecteert de diversity, De intermediate results en targets zijn varianten. Voor systemen met product families is diversity een vereiste, ook als ze Koala niet gebruiken. Diversity kan er soms toe leiden dat er tijdens compilatie een output file ontstaat, maar soms moet die juist vervallen. De preprocessor of de compiler zou dan met een geforceerde exit code moeten eindigen. Ook kan het voorkomen dat soms external functies uit een programma worden aangeroepen, en soms geen één, terwijl ze niet tot null zijn gereduceerd. Als je product families wilt onderhouden met uitsluitend compilers, library tools, en linkers, (maar wel met een dian build natuurlijk), dan moet je welhaast gebruik maken van object libraries, en de gatherer van de linker. Het zal je opgevallen zijn dat ik de dominantie van Koala over een working-tree probeer over te nemen met dian build, in een poging Koala te beperken tot de Koala packages. Het Push Algoritme Push gaat sequentieel door de push-positions. Een voorbeeld: de push-positions definiëren bijvoorbeeld de afhandeling van: 1. controleren df files, eventueel folders maken. 2. compileren idl files 3. genereren test harnesses 4. genereren Koala header files 5. compileren Koala header files 6. compileren van gewone c files 7. verzamel libraries bijhouden 8. samenstellen executables Push vraagt de outline (in de vorm van een index) van de sio folders van de current push-position. Vervolgens gaat push de index af en vraagt per sio folder de outline van de betreffende primary inputs en gaat die af. Alleen die primary files komen in aanmerking die behoren tot de outline van Pagina: 160 / 230

161 2.6 Builds en Repositories de dian van de derived folder, en tot de outline van de start dian. Push werkt met een merge algoritme, waarvan de sio files van de folder en de primary inputs van de outline de inputs zijn. Een sio file zonder match wordt gecontroleerd. Zijn primaire input file moet bestaan, en behoren tot de volledige primary source outline van de sio folder en anders vervallen de sio file en de bijbehorende output files. Een sio file met match wordt gecontroleerd. Alle file items in de sio file moeten kloppen met de werkelijkheid, anders wordt een script node opgezet en meteen afgevuurd Een primary input file zonder match leidt ertoe dat de script node wordt opgezet en meteen afgevuurd. We zien hier een late vaststelling van de outlines van primary en secondary inputs. Voor software die deel uitmaakt van product families geldt dat veel derived input er de éne keer wel is en de andere keer niet of omgekeerd. Als je uitgaat van bestaande software uit een family en je maakt daaruit software voor een nieuw gezinslid, dan wil dat gaandeweg nog wel eens veranderen. Ook zullen er vaak, dank zij de diversity, minder derived files zijn, dan je zou verwachten als je kijkt naar de source files. De late vaststelling is een voordeel. Maar de late vaststelling is niet dermate laat, dat primary input files mogen ontstaan in de push-position waarin ze worden verwerkt, laat staan in eerdere push-positions. Het kan voorkomen dat een primary input in file twee derived folders wordt gecompileerd, het algoritme moet dit toelaten. Ook kan het voorkomen dat een primary source die binnen de outline van de start dian valt niet gebruikt wordt omdat hij buiten de outlines blijft van alle derived folders. Mijns inziens is een warning hier op zijn plaats. De object files van global public folders Normaal met het importeren van secondary input files wordt een ruime outline gebruikt en een gatherer die de selectie uit het aanbod verzorgt. Dit is vaak ook de build outline voor gpf files. Normaal horen alle idl files in gpf folders, samen met hun derived files. Nu deze files gebruikt worden in meerdere executables, ligt het voor de hand om dynamic shared libraries te gebruiken voor de opslag van object files. We willen natuurlijk geen object files opnemen die helemaal niet gebruikt worden, dat bezet maar flash en main memory op het target system. Nu zijn er onder Linux twee manieren om shared libraries te gebruiken: dynamic linking en dynamic loading. Waarschijnlijk is geen enkele vorm van automatische gathering mogelijk bij dynamic loading. Maar bij dynamic linking kies je voor een vorm waarbij op compile-time de references worden opgelost, al worden ze op runtime gerealiseerd. Je offert daarom mogelijk een COM eigenschap op. Voor dynamic linking moeten alle objects zijn verzameld in één of meer shared libraries. We kiezen voor één om zoek problemen te voorkomen bij het binden van references. Dit gaat,als het nodig is, vooraf aan elke uitvoering van de linker. Bij het maken van een installatiefile zou mogelijk de reference data uit de executables kunnen worden samengesteld om te gebruiken bij het samenstellen van de uiteindelijke dynamic shared library van de objects uit de gpf folders. Het variant type dat hierbij gebruikt wordt: target televisie. Voor TriMedia en Standby processor is misschien static binding nodig, gesteld dat daar geen dynamic libraries zijn geïmplementeerd. Variant type target computer moet daarin eventueel voorzien. Pagina: 161 / 230

162 2.6 Builds en Repositories Een manuele methode zou in de basic dians kunnen worden bijgehouden. De gebruikte idl interfaces van de modules in notice worden door de programmeur geboekt in de betreffende base dian. Zo wordt een selectie van idl files expliciet toegevoegd aan de build outline. Ook deze informatie is mogelijk afhankelijk van het variant type target televisie. Op die manier is per target bekend welke idl files betrokken zijn. De idl outlines die zo verzameld kunnen worden in een file zijn een bijproduct bij het maken van de executable. Ze worden bij het samenstellen van de uiteindelijke dynamic library gebruikt als secondary input. Fase één secondaire inputs Een script node moet eerst opgezet worden, en kan dan pas vuren. Input files en outlines bij het opzetten: De varianten file. df files. Om de folders van de output files te selecteren. We nemen aan dat een sio file maar in één folder terecht mag komen, voor de meeste andere output files geldt dat ook. Om df files te achterhalen is er misschien een outline van df files nodig, waaruit de juiste wordt geselecteerd. Merk op dat de folders waarin output files komen niet hardcoded voorkomen in het script van de node, maar uit de geselecteerde df file gehaald worden. Het generatie tool zelf. De outlines voor de secondary inputs Koala en bib Onze rigide build methode heeft een probleem met Koala. Koala genereert een header file die ingelijfd wordt in een c file. Dit moet net omgekeerd zijn. Voor onze build methode is dit fout. Koala moet een primary input file genereren waarin de andere file geïmporteerd wordt. Na de Koala push-position start de push-position van deze files. Precies die files die Koala in de betreffende derived folder achter laat worden gebruikt in Push. Daarom moeten juist zij de primary inputs zijn. De files zijn een subset die door het Koala engine zijn bepaald, aan de hand van compile time diversity. Als in plaats daarvan de c files zouden worden gecompileerd zou dat leiden tot veel fouten omdat de header file kan ontbreken. Waarschijnlijk is de huidige omkering een legacy optie van Koala en hebben NXP en CE jarenlang opgezien tegen de wijziging van een fout die misschien al in de vorige eeuw ontdekt werd. In een dual window televisie bijvoorbeeld komen veel components in tweevoud voor. Er is dan één component met twee instances. Voor iedere instance genereert Koala een header file voor een c file die behoort tot de component. De bijbehorende c file moet dus twee keer gecompileerd worden, één keer met de ene h file, en één keer met de andere. Het script voor de compilatie van een Koala module zou de name van de h file als een parameter moeten doorgeven aan de compiler, zodat die tenslotte ingevuld kan worden in het #include<> statement van de c file. Het script moet natuurlijk ook de name van het c programma selecteren uit de name van de header file. De omkering is, als ik mij goed herinner, slecht één van de fouten: in de c programma's wordt mogelijk verkeerd omgegaan met instance names. Tot aan mijn pensionering werd een omslachtige en onderhoudsgevoelige methode gebruikt om maar geen gebruik te maken van meerdere instances van een component. De c files konden hergebruikt worden, maar de cd files werden in tweevoud bijgehouden. Pagina: 162 / 230

163 2.6 Builds en Repositories Koala is een build system van zichzelf, die een aantal output files van de vorige keer opnieuw inleest om aan de hand van gewijzigde input de wijzigingen door te voeren. Momenteel gebruikt Koala zijn eigen sio file, maar eigenlijk kunnen Koala en build er één delen. Eigenlijk hoeft build geen dependency list op te slaan omdat Koala er één gebruikt. De Koala build is niet te doen met Push, vandaar. Zo'n build in een build kunnen we in veel eenvoudiger vorm ook zien bij sommige linkers en archivers. We zouden ze bib kunnen noemen: build in build. Ook de test harness generator is een bib. Bib Coöperaties Pull make is mogelijk te implementeren als bib. De nodes in make worden tweemaal bezocht, voor een activiteit. Eenmaal heen en eenmaal terug. De heenweg visite zou gebruik moeten kunnen maken van de outliner voor de primary sources, de terugweg visite benut outlines voor de secondary input files. Koala bepaalt bij een cd file de outline van id files en h files. De outliner zou die kunnen leveren. Een bib zou een alternatief voor sio files kunnen gebruiken. De sio file die push gebruikt zou dan slechts de fase één inputs bevatten. Globals Er is een centraal document waarin een aantal zaken vermeld zijn: Variant types en een opsomming van hun varianten File-types Build filetypes eisen soms een verfijning van de normale filetypes. Bijvoorbeeld: de h files die gegenereerd worden door Koala worden gerekend tot een filetype die een primary input is, terwijl de c file die een Koala module representeert slechts een secondary input is. Er moet een list zijn van Build filetypes. dians weten van hun files tot welk build filetype ze behoren. Generatie tool Er moet een template zijn van zijn script node. Push-position Bij een push-position horen een generatie tool, een primary input type, en een volgnummer. Het volgnummer bepaalt ook het sio subtype. Enige opties als: altijd vuren, Tool als er niet gevuurd moet worden en zo. Frivool is een lijstje generatie tools, ieder met een primary input type, en eventuele opties. Binnen de NHSW tree kunnen restricties bestaan voor bepaalde typen secondary input files. Een secondary file mag alleen gebruikt worden. als de primary file tot dezelfde component behoort. Restrictie: component. Een secondary input file mag gebruikt worden als de primary input hoort tot het package. Restrictie: private Pagina: 163 / 230

164 2.6 Builds en Repositories De secondary input file heeft geen restrictie: public. Scoop typen vormen een globale lijst. We gingen ervan uit dat binnen de dian outliner een file referentie bestaat uit het paar (file name, dian). Voor id files en h files geldt bovendien dat ze vanwege de scoop waartoe ze behoren dat de component name en package name toegevoegd zijn aan het tuple. Dat is daarmee een goed idee voor alle files. Nu build filetypes kunnen afwijken van gewone filetypes, kunnen die ook het best aan het tuple worden toegevoegd. Dians voor buildgraph afbakening, overwegingen Dians zijn objecten die een aantal functies implementeren. De meeste functies retourneren een outline. Voor afbakening van een buildgraph kan de outliner vragen om een outline gegeven een bepaald filetype. Voor afbakening ten behoeve van secondary files kan de outliner vragen om een outline gegeven een bepaalde restrictie en een bepaald filetype. Ze retourneren outline indexen van de files die ze in notice hebben, en de outliner moet die samenstellen tot één geheel. In frivole oplossingen kunnen de basic dians ook een lijstje retourneren van andere dians. Ze kunnen het package retourneren waartoe ze behoren, en of ze private zijn of public. De meeste dians zijn basic, maar er zijn enkele speciale. Dians zijn bedoeld als een oase van standaardisatie in een NHSW tree vol legacy en verschillen tussen teams. In frivole oplossingen vormen basic dians een verzameling trees. Een tree bevind zich in een package, meerdere trees kunnen voorkomen in een package. Een tree ontstaat omdat een dian een aantal anderen in notice heeft. Nog frivoler wordt het als trees trees in notice hebben, en dan vooral trees buiten het eigen package. De toppen van de trees in een package kunnen public zijn of private. Een dian uit een ander package mag public trees in notice hebben. In rigide oplossingen zijn basic dians niet gekoppeld. De top in een package is een entry dian. Een entry dian heeft df files in notice, en basic dians. In de folders die afgeleid zijn van de df files komen derived files terecht ten gevolge van de eigen primary input sources. Deze derived files zijn op hun beurt weer primary input, of zeer precies afgebakende secondary input, als gathering ontbreekt. Er zijn df dians. Die hebber derived folder files in notice. In rigide oplossingen hebben ze basic dians in notice. Die op hun beurt hebben de primary inputs in notice voor de derived files die in die folders moeten worden opgeslagen. In frivole oplossingen hebben ze trees van basic dians in notice. Let wel de notice wordt niet gebruikt voor de afbakening van de buildgraph, maar voor onderhoud van een derived folder. Er zijn start dians. Misschien is elke df dian ook een start dian. De outliner bepaalt via de substructuur die door de start dian afgebakend wordt wat de primary input outline is. Mogelijk speelt de start dian ook een rol in het afbakenen van secondary input outlining (zie de sectie over global public, en local public). In een rigide systeem hebben ze basic dians door de hele NHSW tree in notice, in frivole systemen hebben ze de toppen van trees in notice. In een frivole oplossing is de notice van dians verspreid over de hele verzameling dian files. Bij rigide systemen zijn ze geconcentreerd in enkele start en df dian files. Waarom frivool? In een rigide structuur betekent een wijziging in de constellatie van dians in een package dat meerdere start en df dians moeten wijzigingen. In een frivole structuur wordt alleen lokaal gewijzigd. In een rigide structuur: bij elke wijziging van de structuur wijzigt de start node, die wordt Pagina: 164 / 230

165 2.6 Builds en Repositories dus veel gewijzigd, en moet vaak overgedragen worden aan Climbexion, dus merge met de bijdragen van velen is gegarandeerd. Als de structuur frivool verspreid is over de dian files worden ook de wijzigingen verspreid over de files en hoeft merge minder vaak te worden gebruikt. In een rigide structuur kan een wijziging binnen een package ook een wijziging van starters betekenen in andere packages. In een frivole structuur kan gezorgd worden voor stabiele entry-points in een package, zodat wijzigingen binnen een package geïsoleerd kunnen plaatsvinden. Ook overgangen binnen een package naar een ander stelsel entry dians kunnen zo georganiseerd worden dat teams elkaar niet blokkeren. In een rigide structuur wijzigt Cunie een constellation binnen een package en loopt daarna de df en start dians na, of die ook gewijzigd moeten worden. Lagus maakt ondertussen een nieuwe starter of een nieuwe df dian aan, die gebaseerd is op de oude constellation. Beiden dragen hun wijzigingen ongeveer tegelijk over aan de transfer drawer. De kans dat dit gebeurt lijkt met de rigide oplossing veel groter dan met de frivole. De rigide oplossing lokt Lagus & Cunie uit. Waarschijnlijk initialiseert de outliner door een sessie node te maken voor iedere dian. In de starter nodes en df nodes kan de buildgraph wordt vereenvoudigd tot outlines en opgeslagen. In de basic nodes kunnen alle pointers bidirectioneel worden uitgevoerd. Sessie nodes kunnen ook worden gebruikt om outlines, die reeds zijn bepaald, op te slaan voor later gebruik. Door goed te initialiseren is het voor een script node redelijk efficiënt om bij een primary input file een derived folder te vinden, en omgekeerd. De outline van alle primary inputs voor een target build moet zo precies mogelijk zijn, anders wordt er te veel gewijzigd. Outlines voor import in generatie tools mag vaak ruim zijn, de gatherer van het generatie tool lijft alleen in wat nodig is. Als een tool zo gebruikt wordt dat die altijd de hele outline van de input inlijft, dus zonder gatherer, dan moet de outline zo natuurlijk zo precies mogelijk zijn. Dat is de normale manier om met een linker om te gaan Ik weet niet of het voorkomt, een derived file bij de ene df dian is primary input voor een folder in een andere. Als het kan kunnen mogelijk cross verwijzingen voorkomen, en moet de outliner daarmee rekenen. Dians kunnen zich bevinden in een folder van het package of op afstand staan, of zelfs met meerderen in een file al dan niet op afstand. Deze implementatie details doen momenteel niet ter zake. Een feit is dat ze een aantal folders van een package in notice hebben met de files die er instaan. Ze bevatten een referentie naar die folders. Een package kan read-only zijn, in dat geval worden derived folders in het package beschouwd al source folder. Secondary input outlining buiten de primary input outlines van een starter dian. Misschien komt er een extra dian, de tree dian, die helpt bij het maken van public outlines van secondary input files. Ook komen er package dians, die de outline verzorgen van de public files, en de outline van de package restricted files. Pagina: 165 / 230

166 2.6 Builds en Repositories Basic dians in een package In plaats van het strikt volgen van de componenten structuur van Koala is een structurering binnen een enkele entry dian mogelijk, waardoor en maar één is per public component, één per test harness één per tool, indien daar source van zijn. De primary input dian heeft dan een lijst van de componenten in notice, waar Koala een tree heeft. Per component zijn dan speciale vermeldingen mogelijk, zoals c files die niet door Koala gebruikt worden en zo. De dians die hij in notice heeft zijn dan dians in een ander package, of df dians in eigen package. Er is natuurlijk wel enig risico om hier één per package van te maken, gegeven de discussie over rigide en frivole dian structurering. Een secondary source dian zou er kunnen zijn per package. Secondary input dians voor id, h, dd, files kunnen ver buiten folders van een primary input outline. Deze dian maakt deel uit van een structuur die overeenkomt met de structuur van de working-tree in dit geval een subset: een package tree. In een mixed tree omgeving zou een algemene outliner de specifieke van Koala kunnen vervangen. Voor Koala Componenten zou de outliner de Koala files kunnen gebruiken in plaats van de dians, of dians creëren uit Koala files. In packages zonder Koala zullen ze dan met de hand gemaakt moeten worden. Als een team ze niet mee levert bij een package, dan kunnen ze gemaakt worden in een folder die op afstand staat van het package. Een dian kan het entity type van een folder lezen. Dit type is reeds aanwezig in de kin. Hiermee weet een dian of de folder een interface folder is, of een koala component, of een com component, of wat voor entity type dan ook. Target directed df dian Sommige df folders zijn er voor executables. De primary inputs van de executable en van Koala moet zich bevinden in de primary input outline van de target df dian. Ook de df file voor de koala folder waarin die de header file plaatst, en mogelijk nog één voor de database die nodig is om wijzigingen door te voeren als Koala de volgende keer start, staan hier in notice. Om de executable up-to-date te maken moeten zij zich, samen met de df dian bevinden in de outline van de start dian. Opnieuw df files Derived folder files definiëren folders voor derived files. Deze folders bevindt zich samen met de df file in een gewone folder, tenminste als ze reeds bestaan. Van elke folder is gespecificeerd welke filetypes hij kan bevatten. Dit staat in de df file. Folders voor de opslag van sio files bevatten uitsluitend sio files. Secondary input outlining voor id, h, dd, pd, idl files kunnen de hele NHSW tree benutten. Ook de gespecificeerde folders ontvangen de outputs van de betreffende script nodes. Variant folders moeten mogelijk onderhouden worden. Welke varianten bij een folder moeten worden onderhouden hangt waarschijnlijk af van een generatie tool uit de push-position. Het generatie tool zelf kan een variant zijn, of minstens één van zijn input files kan een variant zijn. Afhankelijk van de varianten frivoliteit van de output files, moeten er een varianten folders worden gemaakt. De folders van een gewijzigde df file die betrokken is bij een build worden gecontroleerd op op hun eigenschappen. Deugen filetype en push-position in de folders nog wel? Na een wijziging vervalt Pagina: 166 / 230

167 2.6 Builds en Repositories alles in de folders dat niet voldoet aan de specificaties, eventueel vervallen oude folders, nadat hun bruikbare inhoud is gekopieerd in de nieuwe. Eisen aan tools Van een tool wordt verwacht dat die zijn dependency list kan produceren, dat zijn gatherer dit lijstje maakt. Bij voorkeur met version informatie. Als een tool een variabele aantal output files produceert, Dan wordt verwacht dat die zijn sio file kan produceren. Bij voorkeur doet elk tool dit. Bij voorkeur met version informatie. De inputs in fase 1 van de script nodes hebben reeds een dependency list opgeleverd. Die kan worden toegevoegd aan de sio file van het tool. Een tool moet voor zijn secondaire input gebruik maken van de outlines die door de outliner gemaakt worden. De rigide outliner levert outlines in de vorm van een index van files, Als een tool uit de outline kan breken, of geen raad weet met een geleverde outline dan zou de script node moeten voorzien in conversie. Mogelijk met behulp van de outliner, die misschien een lijstje folders kan leveren, in plaats van files. Een tool dat een ernstige fout produceert moet een reset plegen. De output files die overschreven zijn, of die zijn vervallen moeten in oude staat hersteld worden. De fout moet adequaat worden doorgegeven aan script en push in uitvoering. Als reset niet goed is dan moet ieder geval het adequaat doorgeven op orde zijn, zodat output files en sio file kunnen vervallen. Tot slot. Al met al lijkt er met push en dians een build mogelijk waarmee midl, Koala, Harness generator en home-made generatie tools uitgevoerd kunnen worden, en waarmee gemengde oplossingen mogelijk zijn, dus Koala packages en non Koala packages zijn te combineren, omdat hun derived files, bijvoorbeeld de object files, gescheiden kunnen worden opgeslagen. Start dians voor één enkele executable zijn er voor programmeurs. Start dians voor meerdere executables zijn er voor build managers en programmeurs, en lijken te kunnen wedijveren met clean builds. Wel eist iedere variant combinatie zijn eigen build. Het zelf reinigende vermogen van het geschetste push algoritme en het gebruik van df files zou volledige clean builds moeten voorkomen. Pagina: 167 / 230

168 2.7 Security 2.7 Security Het revision control system sluit aan bij de security van de server waarop iemand is ingelogd. De user-id die daarbij gebruikt wordt is de sleutel die toegang geeft tot het revision control system en die bepaald wat iemand mag zien en wat iemand mag bewerkstelligen. Een user kan behoren tot één of meer teams, werkzaam zijn in één of meer projects, en verscheidene rollen vervullen Security entiteiten Rollen: Administrator: Zij of hij registreert clients, teams, projects, users, packages, locations, pools, drawers en hun samenhang Build manager: Deze beheert de inhoud van drawers en constellations, plaatst elements in centers vanuit transfer drawers, importeert, en exporteert. Developer: Zij/hij bezit (create/delete/empty) één of meer satellites van de team-drawer, en een location voor pools en drawers. Tester: bezit één of meer satellites van de test drawer, en mogelijk ook van de team-drawer, en een location voor pools en drawers Architect developer, architect tester: kan ook de attributes van kins onderhouden. Integrator: bezit één of meer satellites van de team-drawer, en mogelijk ook van de mergeimport drawers en baseline-drawers, en een location voor pools en drawers Guest: Een guest krijgt toegang tot sommige drawers, working-trees en info-trees. Ze mogen erin kijken. Niet alle guests krijgen dezelfde toegangsrechten. Afhankelijk van de export limitations die voor hen gelden krijgen ze toegang tot een bepaalde export-drawer, of ze mogen alleen bij een expose-drawer. Kijken en downloaden (exporteren) zijn hun mogelijkheden. Project leader: Deze heeft mogelijk slechts indirect, via medewerkers toegang tot de repository, tenzij de project documentatie en de status reports worden opgeslagen in de repository, dan moet hij in ieder geval toegang hebben tot deze documenten. Change manager: Deze gebruikt de repository voor project evaluaties, statistieken en zo. Configuration manager: Deze benoemt en beheert de locations, pools, drawers en constellations, installeert Climbexion, en mogelijk het work-item system, en build system, import/export limitations en scripts en dergelijke. Organisaties: Party: Een organisatie. We onderscheiden NXP, client, third party. De owner van een master project heeft de rol van client. Team. Voor een team kunnen er export limitations gelden voor packages die in beheer zijn bij andere teams. Vaak is dit het geval als de teams behoren tot verschillende parties. Project: Een tijdelijke organisatie waarin verschillende teams van verschillende parties participeren. Vaak is er een project leader per party (soms meerdere, als er veel soorten televisies ontwikkeld worden, of als een party meerdere producten (bijvoorbeeld chips) onderhoudt). We onderscheiden een master-project: het overall (software) project van de klant, en subprojects: waarin een deel van de software wordt opgeleverd. Het team in een Pagina: 168 / 230

169 2.7 Security subproject behoort tot één party, en is verantwoordelijk voor een deel van de software. Objecten: Drawer: Hiervoor gelden toegangsrechten van teamleden, afhankelijk van de rollen die ze vervullen. Voor leden van andere teams gelden guest rechten, die afhangen van de party waartoe het team behoort. De toegangsrechten bepalen ook de rechten op de files die tot de inner-reach van packages behoren, en de versions die tot de courses van de files behoren. Ook het satellite recht behoort tot de toegangsrechten., De sheets van patches die zijn aangebracht op de drawer zijn toegankelijk als de drawer toegankelijk is. De bij een patch behorende envelope is toegankelijk met de patch, en ook de envelopes die genoemd worden in de events van de courses van elements in de drawer zijn toegankelijk. Package: de toegangsrechten zijn afhankelijk van het ownership, en van de drawer waarin het package zich bevindt. Pool: voor versions, kins, envelopes zijn er de pools, met toegangsrechten tot een pool kunnen beperkingen plaatsvinden van de files waartoe men inzage heeft. Location: Waarin de pools staan voor de versions binnen packages, voor de kins binnen een package, voor de envelopes binnen een subproject, voor drawers. Een location representeert een organisatorische eenheid, zoals een persoon met satellites op een PC, of een team of een groep teams binnen een party, met center-drawers op een server, of in een cloud. Files, Folders, Soft-links: Deze objecten kunnen geheimen bevatten, of ernaar verwijzen. Security doelen en middelen Te bereiken discretie. Party en team discretie. Geheime algoritmes. Als de algoritmes in de software van een team een concurrentie voordeel opleveren, dan zal men ze soms geheim willen houden. Zo zal NXP bepaalde algoritmes niet in source vorm beschikbaar stellen aan klanten, of andere partijen in een master project. Soms implementeert NXP geheime algoritmes van klanten in zijn software, en mogen die algoritmen niet gebruikt worden in projects van andere klanten. Actualiteit. Een team dat meerdere projects bedient, mag soms geen actuele gegevens, (requirements en change requests, problem reports, project states, test results, plans) lekken van het ene project naar het ander, bijvoorbeeld als er concurrentie of competitie bestaat tussen de projects. Een probleem dat gevonden is bij de één en ook opgelost moet worden bij de ander, mag dan geen verwijzingen naar de één bevatten. Dit beperkt de gegevens in bijvoorbeeld envelopes, referentie naar en citeren uit problem reports als comment in source code e.d. Voor Climbexion betekent dit dat niet méér informatie op een scherm verschijnt dan nodig is. In mijn voorbeelden van envelopes vermelde ik Client, Team en Project, maar project is voldoende. Voor degenen voor wie het bedoelt is zijn dan team en client en master project bekend. Ook bevat een envelope herkomst informatie als referenties naar parallelle projects, en original en neighbor gegevens. Deze gegevens mogen niet getoond worden buiten de teams die het package beheren. In baseline reports moet daarom verwezen worden naar een work-item extractie die dergelijke gegevens niet bevat. Way of working. Waarschijnlijk heeft dit geen directe invloed op Climbexion. De way of Pagina: 169 / 230

170 2.7 Security working die door één party vereist wordt kan uiteraard invloed hebben op de way of working van een team in het algemeen. Maar het is niet netjes om hier de competitie tussen parties te beïnvloeden door te lekken. Soms bestaat er competitie tussen projects zelfs van één client. In het verleden is het zelfs zo geweest dat Philips verschillende merknamen gebruikte, en dat die merken vooral elkaar op de markt beconcurreerden. Het niet aan Climbexion of NXP om de gegevens van het éne project te lekken naar het andere. Tussen de projects van een client kunnen soms hoogstens afspraken worden gemaakt over de verdeling van capaciteit. Anderzijds kan het zo zijn dat een client een aantal projects heeft lopen, bijvoorbeeld per marktsegment, of per regio, en dat uitwisseling van informatie (kruisbestuiving) gewenst wordt. Er zijn dus projects waartussen informatie uitwisseling integraal moet plaatsvinden, maar ook projects waarin teams niet prijsgeven of bepaalde oplossingen of probleem beschrijvingen uit het ene project zijn overgenomen in het ander project. We zullen het begrip "party"gebruiken: als master projects tot dezelfde party behoren wisselen allen gegevens integraal uit, maar als master projects tot verschillende parties behoren, dan wordt het uitwisselen van informatie beperkt en blijft binnen de afzonderlijke teams. Gegevens over een wijziging in een package beperken zich dan tot de teams die het package beheren. Stel je eens voor dat de laatste hobbel die genomen moet worden om van Climbexion het wereldwijde standaard systeem te maken voor het opslaan van TV software, dat dat het beveiligingssysteem is. Dan moet de verlangde discretie overtuigend bereikt worden. Ik vond een artikel van Dorothy E. Denning: A Lattice Model of Secure Information Flow. Communications of the ACM May 1976, Volume 19 number 5. Er komt een fase in het ontwerp waarin het datamodel, de processen en de menselijke rollen volledig in kaart zijn gebracht. Dan moet dit Lattice model gemaakt worden en tonen dat de discretie en geheimhouding gewaarborgd is. Hopelijk is een statisch model voldoende voor de data entiteiten. Dan moeten er nog waarborgen komen dat de repository uitsluitend integere climbexion software gebruikt, dat de mensen die Climbexion gebruiken zijn wie ze zeggen dat ze zijn, dat het niet mogelijk mag zijn om van buiten af waarnemingen te doen omtrent data in het revision control system of in de communicatie tussen de processen. Dat er dergelijke eisen aan zo'n systeem worden gesteld in een situatie waarin trade secrets worden gebruikt is normaal: degene die recht heeft op een geheim, moet soms kunnen aantonen dat het geheimhouden beveiligd was, en dat er inbraak nodig was om te komen tot een schending van het geheim. Waarschijnlijk behelst het totale lattice niet slechts de classificatie van files, maar ook die van drawers, pools, packages en dergelijke. Een repository is niet een alles omvattend systeem, en dat geldt ook voor de beveiliging van het systeem. De tralie van Dorothy Denning betreft de repository elements waaraan security classes worden toegekend. Waarschijnlijk worden mensen dynamisch gebonden. Ze zijn dan tijdelijk een entity waarheen, in een transaction informatie stroomt, die mogelijk na bewerking weer teruggevoerd wordt naar de repository. De classificatie van de terug te geven elements is dan de mogelijk de kleinste bovengrens van betrokken geraadpleegde elements. Mogelijk is voor zo'n mens een boven-grens gedefinieerd van de classificaties die voor haar/hem toegankelijk zijn. Verder reken je op haar of zijn discretie. Een build procedure is een process entity waarheen versions van geclassificeerde elements kunnen stromen, en die dan een resultaat leveren dat lager is geclassificeerd dan het supremum van de inputs. Immers de geproduceerde binary wordt geacht de geheimen te verbergen, die in de source Pagina: 170 / 230

171 2.7 Security files aanwezig zijn. Dit is faliekant in tegenspraak met de worst case aanname dat het opgeleverde resultaat de betreffende geheimen onthult, aan ieder die er toegang toe heeft, en dus het supremum als classificatie moet hebben. Er zal dan ook af en toe ingegrepen moeten worden op zo'n rigoureus geautomatiseerde beveiliging. Als je wilt komen tot een verfijnd systeem van export limitations middels een classification methode, dan is er een periode, na het opstarten van het project, dat de classifications niet op orde zijn. Gedurende die periode mogen alleen ingewijden toegang hebben tot de repository. Naast al deze eisen aan Climbexion, is er nog een middel dat gebruikt wordt. Een TV fabrikant kan NXP vereenvoudigde of oudere packages ter beschikking stellen. De werkelijke status van zijn software is dan niet bekend binnen NXP. Dit kan ten koste gaan van het vermogen om fouten te reproduceren en op te lossen. Voor Climbexion zou dit betekenen dat niet iedere baseline van iedere package in een master project beschikbaar is voor iedere party. Een vergelijking van export limitations ten opzichte van verouderde packages: Onderwerp Export limitations Oud package Onderhoudbaarheid Simpel?? Review op package Ingewijden Ingewijden Testen van product Allen Ingewijden Fout reproduceren Allen Ingewijden Fout analyse na product-test Soms allen, soms ingewijden Ingewijden Het gebruik van een dergelijk substituut is in wezen niet aan te bevelen omdat de independent deployment van Szyperski niet bereikt is. Het was in ieder geval nog niet bereikt toen ik gepensioneerd werd. Anno 2008 moest de software van NXP nog steeds getest worden met de tv en software van een klant. NXP zou dat zelf moeten kunnen doen. In ieder geval zouden ze een fout zelf moeten kunnen reproduceren en analyseren. Het one-roof gebeuren stelt specifieke eisen aan de discretie: ieder team kan beschikken over kennis die men niet wil delen met leden van een ander team, maar de leden zitten soms wel quatre main achter één display met toetsenbord. Ik weet niet hoe je onder die omstandigheden discretie waarborgt met functionaliteit van software. Voor Climbexion ga ik dit niet oplossen. Herkomst garantie Als teamlid Lepus een wijziging aanbied, dan wil je zeker weten dat het inderdaad teamlid Lepus is die de wijziging stuurt. De changesets en versions in een envelope zullen worden voorzien van een content hash. Versleuteling van de hash met haar private key, en controle met haar public key moeten waarborgen dat de wijziging inderdaad van Lepus afkomstig is. Elke transfer van een envelope kan uitgevoerd worden door een andere persoon, en zal een andere versleuteling van de hashes betekenen. De envelope waarmee een te exporteren baseline is gerealiseerd moet zichtbaar en verifieerbaar zijn voor degene die importeert. Voor external envelopes geldt hetzelfde. Waarschijnlijk worden public keys geregistreerd door administrators die ze via vertrouwde kanalen verkrijgen, die daardoor de rol van waarborg krijgen. De administrator database speelt hier een belangrijke rol. Pagina: 171 / 230

172 2.7 Security Database garantie Als je inlogt op een center-drawer, dan moet het gewaarborgd zijn dat je inderdaad inlogt op de betreffende drawer. Inloggen doe je via de administrator database, die je in verbinding brengt met het betreffende drawer. Ook van envelopes moet gewaarborgd worden dat ze zijn die ze zijn. En verder moet de administrator database zelf een toppunt van vertrouwen zijn. Niets mag fake zijn, alle inhoud van een database moet via een regulier en vertrouwd process zijn aangebracht. Ook de integriteit van de courses, de versions, de drawers en packages kan waarschijnlijk met (cryptografische) checksums en elektronische handtekeningen worden gewaarborgd. Ik denk dat hiervoor aardig wat beveiligings-techniek komt kijken. In het begin van Climbexion is mogelijk nog niet alles beveiligd Gentlemen agreements Er zijn een aantal afgesproken regels die niet echt of volledig afdwingbaar zijn met beveiligingssoftware. Overtreding van dergelijke overeenkomsten kunnen partijen of projects in problemen brengen. Discretie is er één. Niet wijzigen in de software van een ander is er ook één. Climbexion is waarschijnlijk niet in staat, om overtreding van zo'n overeenkomst onmogelijk te maken. Climbexion moet natuurlijk wel zo gemaakt worden, dat het mogelijk is om je aan de agreements te houden, of zelfs dat overtreding niet wordt uitgelokt. De baseline supplements discipline: De owner van een package is de enige die de patch uitgeeft. Dit moet onder andere voorkomen dat lokale wijzigingen in andermans packages tot gevolg hebben dat nieuwe baselines van een package niet meer kunnen worden ingevoerd, of dat een team niet langer aansprakelijk kan zijn voor de werking van zijn package in een project. Nu er local pools bestaan is er niets afdwingbaar. De discipline zou als volgt ondersteund kunnen worden met security middelen: kins en versions kun je slechts gebruiken en importeren maar niet maken in een package waarop je geabonneerd bent maar dat je niet beheert. Maar op het moment waarop iemand een patch voorbereid voor een package van een ander team, dan zou de security toch omzeild moeten worden, of zou er buiten Climbexion om moeten worden uitgewisseld. Dat laatste is natuurlijk niet de bedoeling: Climbexion is er immers voor de uitwisseling. Export limitations: Deze worden gebruikt als een krakkemikkige methode om algoritmen geheim te houden. De gedachte is dat broncode noodzakelijk is om het geheim te leren kennen. Er is natuurlijk wel iets prijsgegeven: er is bijvoorbeeld een brochure waarin de loftrompet wordt gestoken over het algoritme, en er is gedocumenteerd hoe het algoritme geïntegreerd en geïmplementeerd moet worden. Met reversed engineering technieken zijn de algoritmen mogelijk toch te achterhalen. Er zijn zeer expliciete methoden: Zo kun je de beschikbare software inbedden in een test-harnas en testen, om te achterhalen hoe ze werken. Het doel van machine code is om een taal te maken die gemakkelijk is voor computers, maar niet om een taal te maken die onmogelijk is te lezen voor mensen: er zijn dan ook disassemblers die helpen bij het leesbaar maken van machine code. Deze methoden zijn inderdaad omslachtiger dan het gebruik van broncode. Verder moet je als je soortgelijke broncode wilt vervaardigen een ontwikkelingsproces volgen, dit is zeker omslachtiger dan het kopiëren van kant en klare broncode: bescherming tegen domweg kopiëren lijkt Pagina: 172 / 230

173 2.7 Security gewaarborgd, maar het beschermen van uitvindingen en ideeën niet. Het lijkt erop of software octrooien uit de gratie raken en dat vooral auteursrechten gaan gelden voor software. Dit is een ontwikkeling die rond de eeuwwisseling nieuw was voor chip en set makers: hardware octrooien zijn normaal, en met software octrooien lijken er altijd problemen te zijn. Vermoedelijk is het geheimhouden van algoritmes van korte duur, je profiteert in nieuwe televisies een half of een heel jaar van een nieuw algoritme, of een noviteit, en daarna wordt de implementatie geëvenaard of overtroffen door jezelf en de concurrentie. Misschien wordt dit de trend: je houdt software algoritmen een tijdje geheim en nadat je iedereen ermee verrast hebt maak je er GPL software van. Problemen met rechten op embedded software werden tot in de jaren negentig vaak vermeden. De software was er voornamelijk voor de gebruikers interface. Software werd (en wordt) gratis weggegeven bij de verkochte chips. In de praktijk was men er vaak guller (officieel: slordiger) mee, dan volgens het officiële beleid. De simpele gebruikers interface is inmiddels uitgegroeid tot applicaties en ook vervangt software hardware. De kosten van ervan zijn gigantisch geworden en de hoeveelheid chips of televisies met dezelfde software uitgave zijn kleiner geworden. Kortom software is geen weggevertje meer. De prijs ervan is nu significant aanwezig in de prijs van een televisie of in de prijs van een chip. Voor mensen is expertise en communicatie belangrijker dan broncode om zich een idee te vormen omtrent de algoritmen. Pas voor de laatste details is soms broncode nodig (of reversed engineering). Bijvoorbeeld, goed en kwaad leer je niet uit het wetboek van strafrecht (de broncode), maar je verwerft expertise door middel van communicatie en na-apen (de opvoeding). Misschien moet je je soms wel verdiepen in de details van een stukje wet. Voor zo'n wetboek gelden allerlei regels en gebruiken die we zullen samenvatten met de opmerking dat het een wetboek moet zijn. Door je kennis soortgelijk in wetboek fragment te gieten, lijkt het al een beetje op het echte wetboek fragment. Gaten en leemten zijn mogelijk meteen duidelijk. Door je eigen (denkbeeldige) stukje wetboek onbetrouwbaar te achten kun je een plan maken van de details die je wilt verifiëren (dit zijn gerichte of gesloten vragen). Als je niet beschikt over een wetboek, maar wel over een database met gerechtelijke uitspraken, dan kun je toch veel details achterhalen, die je denkbeeldige stukje wetboek verbeteren, tot niemand meer een verschil merkt met het echte. Je zou de methode kunnen noemen: van raden naar weten. Ik heb zo'n methode dikwijls gebruikt om me snel in te werken in een project. En vaak bij het analyseren van fouten of het vermijden van regressie: eerst bepaal je hoe je denkt dat het gedaan is, of desnoods hoe je iets zelf zou doen of maken: je gebruikt reeds verworven expertise. Dan test, kijk en vraag je hoe het gedaan is. Eerst vul je leemten in je kennis, dan verifieer je je kennis. Alles wat voorhanden is en iedereen die beschikbaar is is potentieel bruikbaar. In alle beschikbare informatiebronnen ga je gericht en systematisch zoeken naar de informatie die je nodig hebt. De methode is niet zonder gevaren: immers je begint met een vooroordeel, en misschien heb je niet het inzicht om te weten wat je niet weet. Voor eye openers is het daarom aan te raden om ook meer open vragen te stellen, en zeker ook om te communiceren met anderen. Voorbeeld van een open vraag: hoe zou jij het doen?. Pagina: 173 / 230

174 2.7 Security Kern van de methode is waarschijnlijk de verbeelding, waarmee je de voorstelling creëert waaraan je gaat werken, tot die de werkelijkheid benaderd. Export limitations worden gebruikt in organisaties met engineers van mijn slag, en de meesten zijn vaardiger, nieuwsgieriger, slimmer en beter opgeleid dan ik, in teams die veel expertise delen, immers in elke party is veel TV kennis. In een project waarin de software gemaakt, geanalyseerd en verbeterd wordt, en waarin dergelijke activiteiten moeten worden verdeeld onder de deelnemers is het vaak onvermijdelijk dat mensen zich een beeld vormen, soms zelfs een gedetailleerd beeld, van niet openbare algoritmen, immers ook die kunnen de schuld krijgen van een fout, of behulpzaam zijn bij het vinden van een fout. Minimale protectie, maar ietsje meer dan niets. In de stad waar ik woon, was vroeger een grasveldje met een bordje: verboden op het gras te lopen. Het grasveld was omgeven door een twintig centimeter hoog hek, zodat je wist wanneer je de overtreding maakte. Op snelwegen zie je dat veel asfalt is neergelegd, dat vervolgens afgeschermd is voor gebruik, door middel van een witte streep (??). Toen een overtreder bekeurd werd, werd zijn excuus ik wist niet dat je kwaad werd van tafel geveegd, maar toen iemand een bal van het gras haalde die een peuter er per ongeluk op geschopt had, rechtvaardigde de ernst van de calamiteit de overtreding. Export limitations zijn zo te implementeren dat ze maar iets hinderlijker zijn dan het bordje, het hekje, en de streep. Bijvoorbeeld door extra een ongelimiteerde export-drawer beschikbaar te stellen voor analyse en debugging, terwijl normaal met een gelimiteerde drawer wordt gewerkt. Als je kennis verwerft wordt je geacht te weten dat het een geheim betreft, en dat geheimhouding vereist is. Niet lekken is een gentleman's agreement. Gerealiseerde export limitations van zichzelf zijn niet erg duidelijk in het markeren van geheimen, immers de geheimen worden juist niet gepubliceerd. In de ongelimiteerde export-drawer zouden de geheimen goed gemarkeerd moeten worden, wat natuurlijk ook een risico inhoud. Nu ik erover nadenk, geloof ik niet dat dergelijke minimale protectie werkt in de samenwerking tussen elektronica multinationals. Die willen toch iets roofdierachtigs uitstralen iets van lean and mean. Zo'n regeling vinden ze geschikt voor watjes. Beschikbaarheid nadat het project beëindigd is: Voor evaluaties, voor het vermijden van regressie, misschien wel in juridische conflicten, en mogelijk zelfs voor de wetenschap is het van belang dat langdurig beschikt kan worden door alle betrokken parties, en misschien soms zelfs door buitenstaanders, over het ontwikkel traject van software in beëindigde projects. Hiertoe moeten afspraken gemaakt worden door parties over het gebruik van original storage waarin de packages, projects en subprojects worden bewaard. Het moet minstens niet eenvoudig zijn om original storage te vervalsen, zodat er een certificaat is voor de juistheid der historie, en het moet (politiek?, juridisch?, organisatorisch?) onmogelijk zijn om eigenmachtig original storage af te sluiten, of te vernietigen, of beschikbaar te stellen aan derden buiten de gemaakte afspraken om. Pagina: 174 / 230

175 2.7 Security Maintenance afspraken: Tot de afspraken in de vorige categorie behoren de maintenance afspraken. Onderhoud is meestal nodig bij field calls. Bijvoorbeeld als er compatibiliteitsproblemen zijn met een specifieke zender of een specifieke dvd speler of zo. Meestal duurt het onderhoudscontract, tot er een opvolger is van de TV, binnen de garantie periode wordt een field call dan opgelost door de slachtoffers de opvolger aan te bieden. Onderhoudscontracten hebben enkele smaken, bijvoorbeeld: De party die eigenaar is van het package verzorgt het onderhoud nadat het project is beëindigd. De party levert expertise voor het herleiden van een probleem tot een oorzaak, wijzigt indien nodig eigen packages, voert er tests over uit, en brengt patches uit. De party die eigenaar is machtigt een andere party, mogelijk die van het master project, om het onderhoud van de packages te verzorgen. Misschien levert de eigenaar (incidenteel) expertise. Deze optie zou strijdig kunnen zijn met het idee van discretie. Immers degene die een package onderhoudt heeft de beschikking over alle package variëteiten in alle subprojects waarin het package is gebruikt, ook die van concurrenten. Voorlopig komen hiervoor geen faciliteiten binnen Climbexion. Inner team security: Binnen een team heeft ieder lees-toegang tot center-drawers, envelopes, en dergelijke. Satellites zijn in principe slechts toegankelijk voor degene die ermee werkt, voor eigen evaluaties. Openbaar is echter de inhoud van de envelopes, maar die bevatten niet de history van de preparation state maar slechts het huidige resultaat. Dit komt overeen met de opvatting dat je iemand moet beoordelen op de resultaten, maar dat er enige privacy bestaat bij het realiseren van het het resultaat. Verder heb ik het liefst dat er gewerkt wordt met interactieve (Gui) climbexion add-ons, die de IDE uitbreiden, zodat wijzigingen definitief worden opgeslagen in de satellite als je op save drukt, en waarin mogelijk een undo / redo faciliteit komt, zolang je niet op save hebt gedrukt. Na save is de wijziging definitief. Je moet save natuurlijk niet eindeloos uitstellen: het is immers de bedoeling dat de course of development wordt vastgelegd, ook voor satellites. Pagina: 175 / 230

176 2.8 Overige aspecten 2.8 Overige aspecten Status en Progressie Het standaard status diagram van een element in Climbexion bevat de statussen: satellite, team, baselined. Bij een status hoort een kwaliteitsgarantie in de vorm van een regressie test en een scope, of wel een verspreidingsgebied, dat wil zeggen, de verzameling mensen die er normaal over beschikken. Daarnaast kan een status nog iets zeggen over het gebruik dat je van een element kunt maken. De standaard van Climbexion: Satellite, Team, Baselined, is de status die vanaf het begin wordt geïmplementeerd. Document status De architectuur van de software (we zullen architectuur hier opvatten als een aantal regels waaraan software en software ontwerpers moeten voldoen) eist bij public components en bij public interfaces een document, met een vastgelegde structuur. Dit is met name om semantische en pragmatische aspecten vast te leggen. Deze documenten, en eigenlijk ook de interfaces en components die ze beschrijven, doorlopen stadia. Ik meen dat dit het drietal: draft, exposed, accepted is. Voor interfaces is er nog de status obsolete, die is er om gebruikers aan te sporen om over te stappen op de opvolger; eigenlijk hoort hij in het rijtje niet thuis, omdat hij niet te maken heeft met kwaliteit, scope, en gebruik. Er is een tijd geweest dat er voor interfaces een folderstructuur bestond met de status namen, de folder interfaces omvatte in zijn memberset de folders draft, en obsolete, en verder de accepted files. Voor interfaces geldt een sterke binding tussen de status van het document en de status van de software: document en software worden gezamenlijk in sync bijgehouden. Voor components ligt het wat anders, als het document de status accepted bereikt dan kan het zijn dat de software nog gemaakt moet worden, maar soms is de software dan al klaar. Het gebruik en scope aspect is wel interessant, je kunt aan een document werken, je kunt het lezen, en je kunt het gebruiken (je implementeert de interface of component). De scope bestaat uit: de schrijver, een groepje reviewers en iedereen. Draft Exposed Accepted Schrijver Werken aan: X Lezen X Gebruiken X Iedereen X Schrijver Reviewers Schrijver X X*) X**) X X X X X X X Iedereen *) Indirect: de schrijver brengt de wijzigingen daadwerkelijk aan. **)Interfaces mogen niet gewijzigd worden, ze mogen slechts opgevolgd worden. Merk op: de draft status, die voor iedereen de komst van een component of interface aankondigt. Vaak wordt dit opgevat als: gebruik voor eigen risico. Oorspronkelijke betekenis: ten behoeve van inspraak en planning: alleen voor informatie. Interessant is de scope van exposed: Er is niet een vast team van reviewers, maar het groepje wordt adhoc samengesteld. Eigenlijk komt exposed nog het meest overeen met de envelope status transferred, waarbij gekeken wordt of de versions een build en een test doorstaan. Bij exposed Pagina: 176 / 230

177 2.8 Overige aspecten wordt soortgelijk gekeken of een document een inspectie doorstaat. In de teams waarin ik werkte werd het review gebeuren als belastend ervaren. Architecten konden erin verzuipen, en ook anderen die zich naast hun eigen problemen en hun eigen competentie gebied ook nog eens intensief moesten inwerken in het werk van collega's konden de druk ervaren. De kwaliteits-officieren vonden dit onzin: een review hoefde toch maar een uur te duren: een half uur lezen, en een half uur praten. En daar hebben we ons toen maar aan gehouden. Toch kwam het soms voor dat reviews en inspections werden uitgesteld en uitgesteld, en iedereen met draft documents werkte. De kwaliteits-officieren hadden wel gelijk: in de status draft kan het document aan de orde worden gesteld in de meetings die architecten wekelijks houden, en kunnen mogelijk inhoudelijke wijzigingen worden aanbevolen; het review kan zich richten op zaken als duidelijkheid, volledigheid voldoen aan regels en dergelijke. Officieel werd gesteld dat na een wijziging (of een opvolging bij interfaces) de status weer draft moest zijn. In de praktijk werd het doorlopen van de toestanden slechts gedaan als een component of interface nieuw werd gemaakt, of bij aanzienlijke delta processing als het veel werk was om een component of interface over te nemen uit een voorgaand project. Daarna werd verondersteld dat er dermate zorgvuldig werd gehandeld dat de status accepted gehandhaafd bleef. In één enkel project was er dus sprake van progressie en zelden van cycli. Als Climbexion ooit is ingevoerd, moet maar eens bestudeerd worden of men voor verschillende typen files verschillende status en scope schema's kan implementeren in Climbexion, en of die dan gelden in plaats van de status-set satellite/team/baselined of ernaast, en of ze net zo dwingend mogen zijn met hun scope en sequence. Immers, we willen met Climbexion gestructureerd samenwerken mogelijk maken. Dan moet ook maar eens gekeken worden of er in Climbexion een opvolger relatie moet worden vastgelegd voor interfaces, of dat dit erbuiten geregeld wordt. (opmerking: een interface opvolging is geen succession de oude en nieuwe interface bestaan een tijd lang naast elkaar, en als alles volgens plan verloopt dan verdwijnt de oude op een gegeven moment). In ieder geval kun je eventueel een folder gebruiken om elkaar opvolgende interfaces te bundelen. Zeker nu een folder een entiteit parameter heeft. Certificaat tests Nadat een systeem is ingediend voor een certificaat-test mag het betrokken deel van de software niet meer gewijzigd worden. Indien de TV slaagt dan geldt dat nog slechts serieuze fouten mogen worden opgelost, en wel zodanig dat het keurmerk niet beschaamd wordt. Ook hier hebben we te maken met status overgangen, en een mogelijke terugkeer naar een voorgaande status. Ik heb geen informatie omtrent de precieze regels die gelden, of over regels die de afbakening van de gecertificeerde software regelen. Het eist dus nadere studie als Climbexion regels voor deze status moet faciliteren. De stadia zijn bijvoorbeeld: preparation, evaluation, succeeded. Een project zal dus zeer voorzichtig zijn met wijzigen van gecertificeerde software en hardware, en als een wijziging toch nodig is, intern de certificaat test uitvoeren. progressie Er zijn ook een statussen die zeer zeker niet cyclisch zijn. De status van een (sub)project: de requirements- en voorbereidingsfase, ontwerpfase, Pagina: 177 / 230

178 2.8 Overige aspecten development fase, integratie fase. De status van het product, of de status van een package zoals vastgesteld door tests. In wezen wordt de status bijgehouden door het afvinken van de requirements lijst. Een vooraf gedefinieerde mijlpaal wordt bereikt als een patroon van vinken gerealiseerd is. Je kunt tests en audits afvinken die doorstaan zijn. Stel een requirement is: het package zal CVBS signalen afhandelen. Afvinken kun je dan: het afhandelen van het CVBS signaal is de functionele test gepasseerd, de stretch test, de field test, de gebruikers test, of de certificaattest. De testers proberen ook nog uit of bepaalde functies testbaar zijn, en vinken ook af of een vereiste functie reeds is geïmplementeerd, maar eigenlijk zouden niet zij, maar de ontwikkelaars moeten rapporteren, of de functie al klaar is voor testen De status van components en interfaces worden gedurende development fase (waarin nieuwbouw en delta processing plaatsvinden) gecontroleerd, door een Pert network of Gantt chart bij te houden, van de geplande activiteiten. Deze geven dan de status aan die bereikt is. Wat geldt voor document stadia en certificaten geldt ook voor audits en mijlpaal overgangen: je mag daarna niet zodanig handelen dat het bereikte stadium een farce wordt. Naarmate de software voldoet aan meer requirements groeit ook de regressie test. Dit is één van de waarborgen dat een bereikt stadium gehandhaafd blijft. Een andere waarborg is dat bepaalde change requests niet meer worden gehonoreerd. Ook de wijze van software wijzigen zal op het laatst veranderen: men zal de wijziging minimaliseren, en dus niet gelijktijdig de software herstructureren. Het bereiken van een mijlpaal is reden voor een borrel. De bijdrage van Climbexion: Mijlpaal documenten kunnen worden opgeslagen als other-focused files. Het master project kan een drawer bijhouden waarin overall mijlpalen in geregistreerd staan. Het is de vraag of deze mijlpalen werkelijk een snapshot worden in team-drawers. Desalniettemin willen de teamleden wel hun feestje Het top package De top van een drawer is een bijzonder package. Teams kunnen hun eigen top definiëren, of een top kan gemeenschappelijk zijn binnen een master-project. Testers kunnen mogelijk een andere top behoeven dan ontwikkelaars, met hun eigen package references. Tool leveranciers behoeven een top die toegespitst is op het tool. Kortom: waar teams nauw moeten samenwerken is een gemeenschappelijk gedefinieerde topstructuur gewenst, specialisten kunnen behoefte hebben aan een afwijkende structuur, en teams kunnen behoefte hebben aan een structuur met privé packages. Er zullen dus misschien meerdere top packages nodig zijn. Sommige kunnen uit elkaar voortkomen met hulp van import limitations. Bijvoorbeeld testers gebruiken andere import limitations dan ontwikkelaars, op een gemeenschappelijk top package. Een top package in beheer bij een ander team dat bij ons vrij uitbreidbaar is met references naar eigen privé packages wordt niet echt gefaciliteerd. Privé packages kun je aanroepen vanuit eigen public packages en dan export limitations gebruiken. Opmerking: het top package representeert niet het product Er is een speciaal package voor het product. Van het top package mag mogelijk verwacht worden dat die de toppen van het Build Forest Pagina: 178 / 230

179 2.8 Overige aspecten definieert, en dat die de cross references naar de global public folders bevat. Ik ga er maar vanuit dat het top package geleverd wordt door het master project, en met behulp van import en export limitations getrimd wordt voor drawers van subcontractors, en specialisten Locks Transactions in databases moeten voldoen aan de ACID regels (zie Wikipedia). Lock mechanismen zijn nodig om ongewenste effecten van parallel updates, en van parallel update en retrieval te voorkomen. Ze zijn een hulpmiddel om een transaction geïsoleerd aan te brengen, zodat als een transaction min of meer gelijktijdig met andere transactions, of met gelijktijdige requests de database benadert, dat dan voor de andere transactions geldt: of ze zien de database van vóór de transaction, of erna. Locks worden vaak gecombineerd met een rollback methode die ervoor zorgt dat transactions atomair zijn zodat alle wijzigingen van een transaction worden aangebracht in de database, of geen één van alle. Expliciete locks zijn vaak te vermijden: Satellites bijvoorbeeld, hebben over het algemeen één enkele gebruiker, die met één tool in één process de database benaderd. Haar of zijn opdrachten komen niet gelijktijdig, maar achter elkaar: er zijn geen effecten van parallel update In een drawer wordt niets overschreven, maar alles wordt in een course geplaatst. Als de drawer wordt benaderd voor louter retrieval, op de tip, dan wordt eerst de timestamp gelezen van de laatste correct geëindigde transaction, en die wordt als snapshot gebruikt. Het mechanisme van de transfer-drawer zorgt dat envelope transfers in een rij gezet worden, en dan sequentieel afgehandeld. Dit is het meest basale principe van locking: een envelope transfer is in lock totdat hij aan de beurt is in de rij waarin hij staat. In een database zijn vaak meer verfijnde methoden gerealiseerd, waarbij verschillende transactions parallel kunnen worden afgehandeld, maar die zijn voor een repository mogelijk niet altijd nodig. Naast dergelijke interne locking, die vaak niet langer duurt dan enkele seconden, is er in veel revision control software nog een locking mechanisme dat uren of zelfs dagen kan duren, en die niet alleen interne processen blokkeert, maar ook mensen die iets willen wijzigen. Een geblokkeerde file kun je niet wijzigen, althans je kunt de wijziging niet in de betreffende drawer plaatsen. Behalve natuurlijk als je zelf de blokkade hebt ingesteld. Als je een wijziging wilt doorvoeren op een aantal files, dan moet je wachten tot er geen meer geblokkeerd is. Parallel updates en dus merging worden zo voorkomen, maar mensen kunnen slechts wachten tot de lock voorbij is. Bord en kaartspelen zijn speciaal uitgevonden om dergelijke wachttijden door te komen. Climbexion implementeert dit niet, maar gaat ervan uit dat wijzigingen gebaseerd op snapshot A, gemakkelijk, bijna automatisch -, gewijzigd kunnen worden in wijzigingen gebaseerd op snapshot B, zodat je niet op elkaar hoeft te wachten, maar alvast aan het werk kunt op een voorlopig snapshot. Langdurende locking is dus normaal niet nodig, ten koste van het meer keer aanbrengen van een wijziging, hetzij door merging, hetzij met de hand. We gaan er dus van uit dat alleen de eerste keer wijzigen langdurig werk is. En dat dit niet alleen geldt als een merge programma kan worden gebruikt, maar ook als je de wijzigingen met de hand moet integreren in andere version. Normaal zal de eis dat bij een transfer zowel de base version als de nieuwe version worden vermeld Pagina: 179 / 230

180 2.8 Overige aspecten in de envelope, samen met een notificatie als files op meerdere plaatsen onderhanden zijn, en een eventuele onderling overleg, voldoende zijn om te voorkomen dat parallel updates de consistentie verstoren. Climbexion controleert dan of de base version de tip is van de course die moet worden uitgebreid, en weigert envelopes als er geen match is met een uit te breiden tip. In ons team waren er bepaalde files die zeer frequent door iedereen gewijzigd werden. Dan viel het niet altijd mee om een envelope over te dragen. Het kon voorkomen dat anderen je steeds voor waren, en je een aantal malen moest instellen op een nieuwe base, (en een build uitvoeren ter verificatie). Ik meen dat zo'n situatie, waarbij je steeds opnieuw moet beginnen maar nooit het eind haalt, starvation (hongerdood) wordt genoemd. Een file die transfer competitie uitlokt kunnen we een choke-point noemen. De platform cd file, en de cd file van de platform diversity component zijn voorbeelden. In de beschrijving van dians is er ook één bedacht. In de team-drawer zijn het de files met een excessieve lengte van de version course. Tussen de tien files met een de langste course zullen ongetwijfeld enige choke-points zitten. Starvation is een mooie term, maar eigenlijk was het zo dat je je ei maar niet kwijt kon. Ik ben natuurlijk geneigd om verwijtend naar de architecten te kijken, die niet een structuur bedacht hebben waarin dit soort files vermeden wordt. Maar aan de andere kant is het natuurlijk een uitdaging voor een tool-maker om hier een oplossing te bedenken. Zelfs als architecten een oplossing weten voor zo'n probleem, dan moet het zich waarschijnlijk eerst manifesteren, en is er een periode waarin Climbexion kan schitteren met een oplossing. Het blijft laveren tussen ontwerpen is vooruit zien en de mensheid lijdt het meest aan 't lijden dat men vreest..., tussen bedenken en bekijken, tussen rationalisme en fenomenologie. In software ontwikkeling is er mogelijk een tendens om vooral te voorkomen, want de gelegenheid om te reageren op bedenkelijke fenomenen die zich in de software voordoen is er te vaak niet. Maar voorkomen van zaken die later geen probleem blijken te zijn levert zelf ook rare constructies op. In ieder geval voor de geschetste starvation probleem geldt dat het niet voorkomen werd. Anti-starvation. In zo'n situatie zou een lock op de file wel eens gewenst kunnen zijn. Als meerderen een lock zetten op een file, met vermelding van hun envelope, dan ontstaat er in feite een queue, een vooraf bepaalde volgorde, waarin de envelopes mogen worden overgedragen. Als je envelope aan de beurt is baseer je de wijzigingen op het laatste snapshot, pleeg je de builds en geef je de envelope vrij voor transfer. Het is een oplossing die nieuwe problemen creëert: wat als de eigenaar van een envelope inmiddels in een vergadering zit of zo als zijn envelope aan de beurt is, dan houdt die de hele queue op. Er is dus waarschijnlijk extra communicatie en queue management nodig. Sommige envelopes zullen in meerdere queues zitten, dan kan de ene queue de andere ophouden, en zo zijn er nieuwe problemen die om een oplossing vragen. Ik denk dat we dit maar niet te snel moeten doen: locks op transactions, die interacties plegen met mensen. Zo'n probleem beschrijving als hierboven is wel ongeveer een introductie op een inleiding. De manier waarop dergelijke locks gedaan worden in databases (in twee fasen) is bijvoorbeeld beschreven in: C.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger: The Notions of Consistency and Predicate Pagina: 180 / 230

181 2.8 Overige aspecten Locks in a Database System ; Communications of the ACM; November 1976 Volume 19 Number 11 p (In 1976 was de term ACID nog niet bedacht) De queues die ik gebruik zijn afwijkend ten opzichte van The Notions of Consistency and Predicate Locks in a Database System. In The Notions... betekent de opdracht lock in een thread op een queue waarin voorgangers zitten ogenblikkelijk: kom in een wait state totdat de voorgangers uit de queue zijn verdwenen, en vervolg dan de thread. Ik ga uit van messages met een callback procedure, die aangeroepen wordt als de entry in de queue aan de beurt is. De thread die de message stuurt gaat gewoon door na het sturen. In The Notions... wordt expliciet de opdracht unlock gegeven, in de door mij geschetste methode betekent return van de callback procedure: message verlaat de queue. Als je kiest voor een queue/lock per element, en je wijzigt de version, de name, en de folder reference, dan betekent dit in the Notions... één lock voor alle wijzigingen, voor de message queues kan iedere wijziging een message zijn. Mijn message queues zijn natuurlijk niet van mij. Ze zijn bijvoorbeeld beschreven in in de sectie Pumps en pump engines. Het is wel zo, dat ze identificeerbaar zijn met een willekeurige name (de kin id bijvoorbeeld). De meesten worden automatisch gecreëerd als de eerste message wordt toegevoegd, en verdwijnen automatisch als de laatste message is verwerkt. Maar sommigen worden expliciet gecreëerd, en vervallen expliciet, en mogen in de tussentijd messages bevatten of leeg zijn. Een kin id wordt geacht uniek te zijn binnen een package. Als je hem gebruikt als queue/lock name dat betekent dit mogelijk een kleine vergroving van de granulatie van de queue/lock, als de kin id ook in gebruik is in een ander package. Het mogelijke parallellisme wordt nauwelijks aangetast. Nu er courses worden bijgehouden is het voor de isolation rule nodig dat als twee envelopes twee dezelfde files wijzigen, dat óf de ene (direct of indirect) gebaseerd is op de tips die de ander achterlaat óf omgekeerd, maar wat niet mag is dat de ene file eindigt met de tip van envelope één en de ander met een tip van envelope twee. De startfasen van de overdracht van aangeboden envelopes kunnen daarom het best één voor één af gehandeld worden, bijvoorbeeld met behulp van een startfase queue. De startfase (de locking fase) start nadat een envelope is aangeboden voor overdracht, zodra die aan de beurt is in de queue. In de startfase worden de messages gestuurd naar element queues, met onder meer references naar de envelope en de callback procedure. De onderlinge volgorde van de envelopes in de startfase queue wordt ook de onderlinge volgorde in de queues van gemeenschappelijke elements, en wordt ook de onderlinge volgorde waarin ze de courses van de gemeenschappelijke elements uitbreiden. Daarom is de sequencing in de startfase queue reeds voldoende is: het vrijgeven van messages in element queues hoeft niet per se te wachten tot fase twee. Het is natuurlijk wel zo dat er ook nog een changeset moet worden bijgehouden. Een lege changeset zou je meteen in het begin van de startfase op de tip van het transaction element kunnen plaatsen, zodat een volgende transactie er ook één aan kan toevoegen. De invulling vindt dan plaats als de elements worden bijgewerkt. De locks die worden uitgevoerd zijn locks (en dus updates van queues) op kin id's (eventueel meer verfijnd: locks op de courses van elements). Er is dus in principe een queue per element (of per course van een element), voor de elements die op een zekere tijd betrokken zijn bij een overdracht. Pagina: 181 / 230

182 2.8 Overige aspecten Er komt of er is een moment waarop er voor een envelope geen voorgangers zijn in een element queue. Dan moet soms een nieuw base/labored paar worden gemaakt door de indiener. Een element waarvoor geen nieuw base/labored paar nodig is wordt vrijgegeven zodra er geen voorganger is in de queue, en de tip van de betreffende course is bijgewerkt. Een element waarvoor een nieuwe labored version moet worden gemaakt wordt pas bijgewerkt op de tip en vrijgegeven bij het beëindigen van de overdracht, nadat is merge is uitgevoerd, merge fouten verholpen, en builds foutloos zijn. Dit vrijgeven komt erop neer dat de message de element queue verlaat, zodat zijn eventuele opvolger aan de beurt kan komen. Over het algemeen zijn database transactions niet vrij van deadlocks. Deadlocks kunnen voorkomen als een transaction aan de beurt moet zijn in meer dan één queue tegelijk. Per element, en dus per queue is er één actie, zodra de envelope aan de beurt is. Combinaties van queues waarin de envelope aan de beurt moet zijn voordat iets mag gebeuren worden niet gebruikt, en zo'n combinatie is wel nodig voor een deadlock. Zonder startfase queue, had de transaction moeten wachten tot ze in alle element queues aan de beurt zou zijn, voordat tips konden worden bijgewerkt. Omdat dan niet voorkomen wordt dat de éne envelope aan de beurt is in de éne gedeelde queue en de andere in een andere gedeelde queue is deze methode, zonder verdere maatregelen, niet vrij van deadlocks. Enige aandacht is vereist voor het aanbrengen van tips in courses. De timestamps van course items bestaan mogelijk uit de datum/tijd van de start van hun envelope overdracht, en een event aanduiding, zodat deze altijd vroeger zijn dan de timestamp van de start van een volgende envelope. Het geschetste algoritme kan enigszins uitgebreid worden. In het begin, voordat enige version is overgedragen kan de overdracht gratis (zonder rollback) gecanceld worden. Het zou een overdrachtsoptie kunnen zijn: als merge zou moeten plaatsvinden, cancel dan de overdracht, want dan probeer ik het later nog eens, nadat ik de satellite heb gesynchroniseerd met de tip van de transfer-drawer. (dit is de starvation situatie). Nadat hierop is gecontroleerd, en er geen problemen zijn, kan een changeset worden geïnitieerd, en kunnen de betreffend queues worden worden uitgebreid. De voorganger in de element queues moet hiervoor geïnspecteerd kunnen worden: immers de labored version die eruit voortkomt moet bekend zijn en overeenstemmen met een base version in de huidige envelope. De methode kent als beperking dat uitsluitend die files mogen worden gewijzigd waarvan Climbexion aangeeft dat een nieuwe labored version moet worden gemaakt in de envelope. Als er buiten de betreffende files moet worden gewijzigd, moet de overdracht worden gecanceld en moet een nieuwe overdracht worden voorbereid. Als het wijzigen van de drawer begonnen is, en er moet een merge plaatsvinden, dan is het toch wel een plicht om de overdracht tot een goed einde te brengen. Als je dan toch besluit om de overdracht te cancelen, dan betekent dit: Eerst moeten ook alle erop volgende, niet voltooide, transactions tijdelijk gecanceld worden. Het is denkbaar dat dit verfijnd kan worden: transactions die een element delen met een uitgeschoten voorganger, hun transaction moet ook gecanceld worden, maar wel tijdelijk. Dit is een soort olievlek effect. Dan vindt rollback plaats. Dit herstel van de drawer is een soort transaction zonder envelope. In plaats van rollback stel ik het volgende voor: Elke tips die reeds was bijgewerkt door de uitgeschoten envelopes moeten uitgebreid worden door het juiste voorgaande course item opnieuw aan te brengen. Dergelijk herstel laat dus littekens Pagina: 182 / 230

183 2.8 Overige aspecten achter in de drawer, die later gebruikt kunnen worden bij evaluaties van overdrachtsprocedures. Dit is niet zuiver atomair, en is een herziening van het duration principe qua ACID. Daarna moeten alle tijdelijk uitgeschoten envelopes opnieuw overgedragen worden. Het blijft natuurlijk een probleem dat menselijke interactie is vereist bij de uitvoering van de transaction, en dat ze duurt totdat de indiener tevreden is met alle merge, rework en rebuild resultaten. De locks op de aan te passen elements duren daardoor lang, zelfs als de mens ogenblikkelijk beschikbaar is. Een optie kan zijn om bij de overdracht waarbij een merge moet plaatsvinden, om dan een niet interactieve merge unattended uit te laten voeren door de overdrachtssoftware. Alleen bij merge conflicten (of build errors) wordt overgegaan op een interactieve modus, of wordt de overdracht gecanceld. Indien gekozen wordt voor cancel, kunnen base versions in envelopes die na de uitgeschoten envelope komen hun match met een tip verliezen, waardoor ook deze envelopes een probleem hebben. Mocht deze methode over het algemeen goed verlopen, dan zou je kunnen besluiten om de laatste synchronisatie, die nu plaatsvindt vóór de overdracht, te laten plaatsvinden tijdens de overdracht. Enige aandacht is vereist voor het uitvoeren van een build. Het synchroniseren van satellite en working-tree, met de transfer drawer is hier geen trivialiteit. Voor merge is het voldoende als een envelope geen voorganger heeft in de betreffende element queue. Voor het synchroniseren van een tree ten behoeve van build moeten de overdrachten van alle voorgaande envelopes voltooid zijn, dus de envelope zelf mag geen voorgangers hebben in een synchronize queue. De build zelf mag pas plaatsvinden als alle merge en synchronisatie klaar is in de betreffende tree. Niet alle transactions vereisen een build,en deze transactions verlaten de synchronize queue terwijl ze mogelijk nog voorgangers hebben. Het verlaten van de synchronize queue betekent het einde van de transaction en mag plaatsvinden als alle element queues zijn verlaten, en alle tips zijn bijgewerkt. Files die niet met een merge tool verenigd kunnen worden (bijvoorbeeld: documenten, spreadsheets, plaatjes), kun je overdragen in een envelope met de mogelijkheid van cancel in het begin. Als deze optie niet gekozen wordt dan geldt voor een dergelijke file dat ze alleen handmatig gewijzigd kan worden tijdens een transfer, dus niet unattended: er is immers geen merge programma. Ook geldt waarschijnlijk dat er op het eind geen build of extra verificatie nodig is. Meestal zijn dergelijke files niet de files die starvation of queuing veroorzaken. Het enige bezwaar met de interactieve methode zit hem in het verlaten van de synchronize queue als de transaction voorbij is, hierdoor kan een handmatige methode het uitvoeren van builds ernstig vertragen. Er zijn drie basis overdrachtsopties: Eventueel cancelen in fase één (mogelijk starvation) Interactieve merge, rework en build. (mogelijk langdurig ophouden van enkele queues) Niet interactieve merge en build en cancel bij conflicten en fouten (mogelijk moeten envelopes opnieuw worden aangebracht, met alle problemen van dien wat betreft tip/base matchen). Deze opties hebben zo hun nadelen. Je kunt dit moeilijk schitteren met een oplossing noemen. Nog enige opmerkingen: Pagina: 183 / 230

184 2.8 Overige aspecten De messages in een queue kunnen het best in dezelfde thread afgehandeld worden, ze moeten immers toch successievelijk afgehandeld worden. De startfase queue, zou mogelijk met een lage prioriteit kunnen worden afgehandeld in zijn eigen thread. Dat houdt de element queues zo klein mogelijk. Misschien kan een element queue zelfs vermeden worden als er nog geen queue is en en de base komt overeen met de tip. De betreffende callback procedure kun je dan direct aan roepen in de startfase procedure. Nu iedere element queue een eigen thread heeft moet ervoor worden gezorgd, dat de wijzigingen op de changeset geordend verlopen. Dit kan bijvoorbeeld gebeuren met een queue als de andere, of met een synchronisatie primitieve als een semaphore, critical section, mutex en dergelijke. Een wait state kan plaatsvinden in de callback procedure ten behoeve van interactieve of unattended acties, totdat de envelope is bijgewerkt met het juiste base labored paar (voor element queues). Ook in de procedure van de synchronize queue vindt een wait state plaats, totdat de transaction mag eindigen. Normaal in database transactions is er binnen een transaction een samenhang die moet worden bewaakt, waardoor er afhankelijkheden zijn tussen de database opdrachten. Bij software repositories wordt de samenhang bewaakt buiten de transaction, door builds en tests, en QA software, vandaar dat we met de geschetste queues kunnen werken, en ieder element afzonderlijk kunnen toevoegen. Ik heb bedacht: Starvation kan altijd nog vermeden worden door één persoon aan te wijzen die een file mag wijzigen: de owner. Maar toen herinnerde ik mij het eerste project in 2002, waarbij de eerste digitale TV werd ontwikkeld. Er werden nogal wat programmeurs ingehuurd, die voor het eerst te maken kregen met tv's en hun software. De platform software werd in eerste instantie overgenomen uit analoge tv's en heel of half gelukte hybride voorgangers, en dan aangepast aan de nieuwe tv chip. Dit werd gedaan door het ingehuurde team. Ieder kreeg een een paar componenten toegewezen, en was daarvan gedurende de looptijd van het eerste reference project de component owner. Toen al manifesteerden zich de files die zeer frequent gewijzigd moeten worden. De componenten waartoe die files behoorden waren de eersten zonder owner: iedereen moest zelf de files aanpassen als de ontwikkeling van zijn eigen componenten dat eiste. Het werk dat zich voordien ophoopte bij de owner frustreerde de voortgang, bracht iedereen tot wanhoop, en de owner misschien wel tot waanzin Notifications Bepaalde gebeurtenissen in het revision control system kunnen leiden tot notificaties voor de betrokkenen. Dit gebeurt traditioneel door ze een te sturen. Het plaatsen van een package in een export-drawer is aanleiding om de integrators van andere teams een te sturen. De Transfer van een envelope kan een trigger zijn om de build manager een te sturen. De implementation van een envelope waarmee een nieuwe baseline van een package beschikbaar komt is een reden om mails te sturen naar de satellite owners, enzovoort. De notificaties waarop iemand zich kan abonneren, zijn mogelijk afhankelijk van security regels. Pagina: 184 / 230

185 2.8 Overige aspecten Overigens kun je altijd de status van het revision control system bekijken: door dit geregeld te doen heb je eigenlijk geen notificatie nodig, en als je een faciliteit hebt die automatisch en regelmatig polst, dan is er mogelijk een eenvoudige implementatie. Dit is in ieder geval een mogelijkheid voor een eerste aanzet van Climbexion. Ieder is dan autonoom en bepaalt zelf welke notificaties worden gepolst. In sommige bestaande systemen worden RSS-feeds gebruikt. Op een gegeven moment moet er ook maar eens gekeken worden of er mogelijk ook notificaties zijn waarvan anderen vinden dat iemand ze moet ontvangen, en die dan rücksichtslos instellen. Behalve het notificeren zouden er al dan niet automatisch scripts gestart kunnen worden om de notificatie af te handelen. Bijvoorbeeld als er een nieuwe baseline beschikbaar komt van een geabonneerd package, dan worden automatisch een import area, een satellite en een envelope voorbereid voor het inlijven van de baseline in de team-drawer Pool operaties We kunnen het ons gemakkelijk maken en ervoor kiezen om iedere drawer te voorzien van een location voor alle denkbare pools. Voor de gemiddelde gebruiker is dat waarschijnlijk het gemakkelijkst. Het betekent wel dat de objecten in een pool vaak gekopieerd moeten worden. Zoek je een optimum, waarbij zo min mogelijk wordt gekopieerd, de security nog acceptabel is, en waarbij er niet teveel garbage verschijnt in de centrale pools, dan is er mogelijk ook nog wat plezier voor analisten en ontwerpers, om na te gaan hoe je en dergelijk complex opzet. Ook anderszins kunnen we het ons gemakkelijk maken met de regel: er zijn geen lokale pools. Er is per package slechts één kin pool en één version pool. Merk op dat hierbij niet geldt dat een drawer verwijst naar de location van de package pools, maar dat iedere package reference verwijst naar de pools van het package. Met een dergelijke structuur benaderen we de eenvoud van de vorige oplossing, maar in ieder geval ten koste van de security van export limitations, en van beschikbaarheid en mogelijk performance als er netwerk problemen zijn. In deze situatie, zo is de verwachting, zijn overdrachten zeer efficiënt. Er hoeft immers niet met versions te worden gesleept (behalve om working-trees en info-trees bij te houden). Deze twee uitersten zijn mogelijke opties. Maar we zullen toch maar bedenken hoe we moeten handelen met pools in locations die niet strikt gebonden zijn aan drawers of packages. Package pools Creëren, splitsen, samenstellen Pools zijn opgeslagen in locations. Een drawer verwijst naar de (ene) location waarin de pools van zijn packages staan. Dit is geen statische en eeuwige situatie. Locations kunnen ontstaan en beëindigd worden, waardoor de eigenaars de verwijzing van hun drawers moeten aanpassen. Een package moet geïntroduceerd worden in een location als het package opduikt in één van de drawers die naar de location verwijzen, en het package mag verwijderd worden, als de gezamenlijke drawers die overblijven op een location het package niet gebruiken. Er kunnen redenen zijn om locations te splitsen, als dit vereist wordt door security, groei, splitsen van teams, thuiswerken, of intensivering van bepaalde activiteiten. Bijvoorbeeld: binnen een subproject gaan een aantal mensen samenwerken aan een nieuw onderdeel van een package, en Pagina: 185 / 230

186 2.8 Overige aspecten creëren een sub-team-drawer, en een gemeenschappelijke location voor center en satellites. Deze location splitst zich feitelijk af van de center location van het team. Er kunnen redenen zijn om locations samen te stellen. Beëindigde projects worden bijvoorbeeld toegevoegd aan de historische location. Er kan besloten worden om subprojects samen te stellen tot een one-roof project. Dan kan het efficiënt zijn om pools te combineren. Creëren splitsen en samenstellen kan op de volgende manier: Een pool location moet eerst zijn gecreëerd voordat een drawer ernaar kan verwijzen. Dit komt vermoedelijk neer op een simpele creatie van een folder en wat lege files in een file system. We gaan ervan uit dat een drawer de location kent van zijn pools, Als van een drawer zijn verwijzing naar een location wijzigt dan behelst de wijziging een update van de pools van de nieuwe location. We gaan ervan uit dat een location en al zijn drawers bij tijd en wijle gezamenlijk toegankelijk zijn om garbage collection uit te voeren op de pools. Hierbij is het uiteraard vereist dat de lijst van drawers compleet is. Bijwerken van pools Er kunnen alleen elements worden toegevoegd aan package pools. (Met uitzondering van een garbage collection process waarbij ook elements kunnen worden verwijderd). Kin pools worden bijgewerkt zodra een nieuwe kin verschijnt in een drawer of envelope, en de version pool wordt bijgewerkt zodra een nieuwe version verschijnt in een drawer of envelope. De centrale pool wordt bijgewerkt bij iedere transfer van de ene pool naar de andere. Attribute wijzigingen kunnen een aanleiding zijn voor zo'n transfer. Regelmatig moet gecontroleerd worden of de attributes die centraal zijn opgeslagen recenter zijn dan de attributes in de pool, en regelmatig moet gecontroleerd worden of de attributes in working-tree of info-tree niet verouderd zijn ten opzichte van de pool. Envelope pools Deze pools horen bij een constellation, bij de center-drawer van de constellation. Als het blijft bij deze constatering, dan heeft dit de volgende consequentie: Zodra een version, of een nieuwe kin, wordt vermeld in de envelope, dan moet ook de betreffende package pool bijgewerkt worden. Dit zou kunnen betekenen dat de version pools van het center vervuild worden met allerlei voorlopige dingen die in de satellite ontstaan. Voorlopig houd ik het er maar op dat een personal computer, waarop satellites van een constellation voorkomen, een envelope pool heeft. De envelopes in deze pool en hun inhoud, zijn nog niet gepubliceerd. Dat gebeurt pas als ze verhuizen naar de constellation pool. In de status preparing kan een envelope dus voorkomen in de pc pool, in de constellation pool, of in beiden. Pool opdrachten voor envelopes: create: nieuw in een satellite pool publish: transfer naar de constellation pool. Dit kan op onderdelen, zodat bijvoorbeeld eerst base versions gepubliceerd zijn, en labored versions pas als de transfer van software plaatsvindt van satellite naar transfer-drawer, of naar center-drawer. Pagina: 186 / 230

187 2.8 Overige aspecten rework: copy naar de satellite pool In eenvoudige situaties is er slechts de constellation pool, maar geen PC gerelateerde pool en is er slechts de pool opdracht create. Pools voor other-focused files Deze pools horen bij een project, maar ook bij een package. Locations waarin deze pools kunnen voorkomen behoren tot een subproject. Het uitwisselen van other-focused files, vindt plaats binnen het master-project, maar wordt niet verwacht als sister-projects onderling gegevens uitwisselen. Pools op een PC zijn dan ook meestal voor één project, waar version pools bijvoorbeeld gebruikt kunnen worden voor meerdere projects. Misschien is het om te beginnen raadzaam om je te beperken tot snapshot-focused files en alleen own-drawer-focused filestrings te implementeren. Files die we niet willen overdragen vanuit een satellite zouden moeten refereren aan een tag die gebonden is aan die satellite, en die niet wordt overgedragen. Voorbeeld: een opgeslagen build result kan zijn vervaardigd voor een tag in de center-drawer. En daarna gedistribueerd naar satellites. Iemand maak voor zichzelf een build result op hetzelfde snapshot, waarin bijvoorbeeld enige logging wordt geactiveerd. Deze version mag niet gedistribueerd worden, dus zou de version niet mogen worden gemaakt op dezelfde tag, er is dus een nieuwe file nodig, refererend naar een nieuwe tag. Een probleem kan ontstaan als een overdracht heeft plaatsgevonden van de éne drawer naar de andere, bij drawers zonder gemeenschappelijke pool. Als daarna een version wordt vervaardigd voor een file in de file-string, of als een file ontstaat in de file-string, en de tag is reeds overgedragen dan komt de version of de file niet automatisch beschikbaar in de drawer die verwijst naar een andere pool location. Versions die wel automatisch zijn doorgevoerd moeten daarna nog hun weg vinden naar (virtual) info-tree of working-tree. Wijzigingen op other-focused file-strings worden doorgevoerd in een centrale pool, controle op wijzigingen kan dan gelaagd plaatsvinden, eerst wordt bepaald of de centrale pool gewijzigd is sinds de vorige keer, zo ja dan wordt bepaald of een geabonneerde file-string gewijzigd is, tenslotte of er nieuwe files of versions zijn. Dit kan periodiek unattended plaatsvinden, maar ook op het moment dat een (virtuele) info-tree of working-tree wordt gemaakt. De centrale pool bij wijzigingen in een center-drawer die doorgevoerd moeten worden in satellites is gerelateerd aan die centerdrawer. Bij wijzigingen die geëxporteerd worden is de centrale pool gerelateerd aan de exportdrawer. Pool operaties: create: in een location, met eventuele verwijzing naar de centrale location. Synchronize: indien een drawer ernaar gaat verwijzen door een location change wordt bepaald welke file-strings, files en versions erin opgenomen moeten worden en uit de oorspronkelijke pool moeten worden gekopieerd. Synchronize: om de pool periodiek, of incidenteel, bij te werken vanuit de centrale location. Tot nu toe spreken we over pool, alsof de verzameling filestrings vrij ongestructureerd is. Maar het Pagina: 187 / 230

188 2.8 Overige aspecten ziet ernaar uit dat de pool stevig gestructureerd kan zijn, en een tree structuur zoals een drawer kan hebben, zodat derived files in andere folders komen dan test-reports, die weer ergens anders staan als baseline-documents. Dat zou betekenen ze in wezen een drawer structuur kunnen hebben, of dat de drawers zelf de filestrings bevatten. Dan is het ook nog maar de vraag of de filestring reference blijft bestaan, zodat er onderscheid is tussen het raadplegen of gebruiken van de data via de reference en het onderhouden ervan, rechtstreeks in de filestrings. Ik moet daar nog maar eens goed over nadenken Importeren, Exporteren Eén revision control system voor allen is onhaalbaar, zelf een team moet soms opereren met meerdere systemen: één per klant. Zelfs is het zo dat verschillende teams verschillende merken revision control systems gebruiken. Wat ik hier heb gespecificeerd is nu niet bepaald compatibel met andere systemen. 1. Binnen Climbexion. Snapshots van drawers en packages kunnen worden geëxporteerd en geïmporteerd met references naar kins, en versions, en met overige attributes. References naar envelopes worden niet geëxporteerd. Gegeven de pools behoeven versions en kins niet in stream geïmporteerd of geëxporteerd te worden: ze worden gekopieerd als ze nodig zijn in een work of info-tree, of in een lokale subpool. Een snapshot van een drawer of een package zoals dat in de drawer is opgeslagen wordt als een stream verzonden en ontvangen. Uiteraard kunnen er import en export limitations gelden, of speciale regels. Die moeten natuurlijk in acht worden genomen. Voor adopt merge geldt bijvoorbeeld de volgende query: We selecteren package S, export limitations gelden niet, we willen geen mutaties van name course en folder reference course tenzij het element nieuw binnenkomt, we hoeven geen other-focused files, geen classification-sets en classification-anchors, geen inner-reach van test folders. We willen een filetype controle op compatibiliteit, niet slechts als waarschuwing, nee, incompatible files moeten echt niet geïmporteerd worden. Ook willen we geen event items die aangeven dat een element niet meer bestaat. Exact copy. Gegeven bijvoorbeeld: laatste overgenomen snapshot tag_a. Het over te nemen snapshot is tag_b. De source drawer is in beide gevallen drawer S, de destination drawer is in beide gevallen drawer D. We gaan er even van uit dat export limitations niet gerealiseerd zijn middels een aparte drawer. De import/export limitations nu op het moment van query ild, els. De gang van zaken kan als volgt zijn: destination drawer D vraagt drawer S om de betreffende set event items: Query snapshot=tag-b, importlimitations=ild De source drawer S bepaalt: export = ild (els (snapshot(drawer(s), tag_b))) en stuurt export over naar D in de vorm van een set nieuwe event items. De destination drawer plaatst een subset van export als succession in zijn tip. De verzameling event items: Pagina: 188 / 230

189 2.8 Overige aspecten exclude = intersection (export,snapshot(drawer(d), tip)) wordt niet aan de tip toegevoegd, maar slechts de set changeset = export\exclude. De destination drawer D controleert of er nieuwe kins en nieuwe versions in zijn (lokale) pools moeten worden geplaatst en nieuwe elements in zijn drawer. De grootste compactheid wordt waarschijnlijk bereikt als er een diff programma bestaat voor een filetype. Dan behoeven voor de betreffende tag-b versions slechts de delta's te worden verstuurd ten opzichte van tag-a versions. De query wordt nu: Query snapshot=tag-b, importlimitations=ild,lastsnapshot=tag-a De drawer D software zoekt voor iedere nieuwe version de id van de tag-a version, en maakt de delta's. Er is misschien een samenloop van omstandigheden waardoor deze version in de pool van D niet voorkomt dan wordt de volledige version gekopieerd. Delta's of volledige versions bevatten uiteraard alle metadata om de nieuwe version lokaal in de pool te zetten, inclusief zijn originele valid time timestamp. Een error log vermeldt de filetype conflicten en incompatibiliteiten. Een optie bepaalt of een error een uitschieter is, of moet worden geaccepteerd. De subset courses in D die hierdoor gewijzigd wordt wordt volledig bepaald door de events die in de set export worden overgestuurd. Een volledige vervanging eist dat alle courses worden beëindigd, waarvan de tip behoort tot de set elements: elements(snapshot(drawer(d),tip))\elements(export). Als een package U moet worden vervangen dan geldt dat alle courses moeten worden beëindigd waarvan de tip behoort tot de set: elements elements(snapshot(package(d,u),tip))\elements(export) Uiteraard moet export dan als volgt tot stand zijn gekomen: export = ild(els(snapshot(package(s,u),tag_b))). In principe kun je werken op een gehele drawer of op een package met 3 soorten limitations: import limitations van Destiny: ild. Dit kan een combinatie zijn van vaste drawer en package gerelateerde limitations en van adhoc limitations. export limitations van Source: els. replacement limitations van Destiny: rld. Dit is de verzameling courses die vervangen moeten worden door export, of anders beëindigd. We nemen aan dat geldt: elements (ild (snapshot(f(d),tip))) elements (rld (snapshot(f(d),tip))) We gaan er bij deze methode vanuit dat sinds de vorige keer er wijzigingen kunnen zijn geweest in els en ild. Als limitations geen rol spelen, of als ze niet gewijzigd zijn, kunnen we uitgaan van de course van de changesets in de source drawer, de wijzigingen die "live" zijn in de reeks changesets van tag-a naar tag-b kunnen worden vastgesteld en vormen de export, eventueel na toepassing van els en ild. Adopt merge. De source drawer is een merge-import-drawer, destination is een satellite van de teamdrawer. original is het snapshot waarmee de vorige keer een exact copy is uitgevoerd vanuit een sister-project in de merge-import-drawer. neighbor is de tip van deze drawer, die ontstaan is uit een recente exact copy, mogelijk gevolgd door een aantal undo changesets. Als je gaat kijken in de merge-import-drawer dan zie je daar de volgende Pagina: 189 / 230

190 2.8 Overige aspecten sequentie van tags:, Rn (baseline tag), Un(undo tag), Rn+1(baseline tag), Un+1(undo tag). Rn specificeert het original, en Un+1 specificeert de neighbor. Destination drawer is een team-drawer satellite, waarin met exact copy de tip of tip-tag van een team-drawer is geplaatst: dit is een snapshot dat de base omvat. Mogelijk geldt er een import limitation: il, die geldt voor het original, en de neighbor en de base. Er is natuurlijk een kans dat il gewijzigd is sinds Rn werd geïmporteerd, dan geldt dat Rn opnieuw moet worden geïmporteerd, en krijg je bijvoorbeeld de volgende sequentie van tags, Rn (baseline tag snapshot geïmporteerd met il_oud), Un(undo tag), Rn(baseline tag, snapshot geïmporteerd met il), Rn+1(baseline tag geselecteerd met il), Un+1(undo tag). Nu moet de meest recente tag Rn gekozen worden om original te specificeren. We nemen aan dat tussen dit en het sister-project geen export limitations gelden, anders zou je ook nog moeten checken of die een wijziging op Rn teweeg zouden brengen. We zijn natuurlijk slim en gebruiken voor het importeren uit het sister-project de merge-import limitation mil. Als relatie (ilt,ri) (i= 1..n) de verzameling original snapshots voorstelt die in een project geselecteerd worden voor adopt merge vanuit de merge-importdrawer, en er geldt: (ilt,ri), ilt(ri) mil(ri) waarbij i = (1..n) dan hoeven we geen 2 imports te plegen van dezelfde baseline. Voor merge hebben we dan enige vrijheid om ilt een beetje te variëren zonder een baseline opnieuw te importeren. Heerlijk dit orakelen met wiskunstige symbolen. Hoe merge verloopt is te vinden in Exact copy bij de start van het oplossen van een work-item. Als je ervan uitgaat, dat je een satellite kunt gebruiken voor het achtereenvolgens oplossen van een reeks work-items, dan kun je exact copy optimaliseren. Het betreft hier het synchroniseren van de satellite met de tip-tag van de team-drawer. In principe hebben we bij exact copy te maken met ild, els en rld. We gebruiken mogelijk geen els binnen een team. Voor rld kiezen we: alle courses in de satellite: elke course wordt ofwel beëindigd, ofwel de tip wordt uitgebreid, ofwel de tip wordt bevestigd door de geïmporteerde changeset. Uiteraard wordt ook de working-tree up-to-date gebracht. Merge copy bij het opnieuw synchroniseren. Voor de merge list is de vorige exact copy de verzameling originals. Het begint met commit van de gewijzigde files. De nu ontstane tips worden de neighbors in de merge list, tenminste als de version afwijkt van de base version. Dan exact copy met de tip-tag van de teamdrawer, dit wordt de verzameling bases in de merge list. Bij het uitvoeren van de merge worden de resultaten geplaatst in de working-tree. ild en rld blijven normaal hetzelfde gedurende het werk aan een work-item. In de merge list komen alleen die elements waarvan een neighbor is bepaald. De laatste merge copy plaatst alleen elements uit de envelopes in de merge list, en pleegt exact copy met de tip van de transfer-drawer. 2. Exporteren naar andersoortige repositories. Archief-files (bijvoorbeeld zipfiles, of tarballs) van working-trees of info-trees worden geëxporteerd, of mogelijk slechts packages hieruit. Mogelijk wordt elk element voorzien van een property sheet file met attributes (metadata). Bijvoorbeeld: element helloworld.c wordt begeleid door helloworld.c.prop. Ik moet eens nagaan of hiervoor standaards zijn bedacht. Deze property sheets komen wat mij betreft in een schaduw folder structure, zodat ze op voorhand gescheiden zijn Pagina: 190 / 230

191 2.8 Overige aspecten van de files, en folders. zijn, Middels een tool kunnen ze verenigd worden in de course van een element, of in de version. Een Climbexion tool moet deze property sheets genereren. 3. Importeren van andersoortige repositories. Ook hier gebruiken we archief-files. De allereerste keer beginnen we met een lege satellite en working-tree, of een lege package hierin. Daarna prepareren we de satellite en zijn working-tree met de vorige versie. We vervangen de working-tree of het package in de working-tree door de archieffile. Een exact copy van working-tree naar de tip (en envelope) importeert de archief-file in de satellite. Meta data, indien aanwezig, worden ingevoerd met hulp van een Climbexion tool dat er de satellite mee wijzigt, en de envelope bijwerkt, en dat de version pool en kin pool bijwerkt. Als files verplaatst zijn, of een andere naam hebben gekregen dan betekent dit een breuk in de course van die files, tenzij de metadata voorziet in het behouden van de course, bijvoorbeeld door kins op te nemen als attribute. Climbexion baselines De software voor de diverse implementaties van Climbexion moeten compatible zijn. Een Climbexion subsystem voor pool onderhoud moet compatibel zijn met het subsystem voor drawers. Climbexion op servers moet compatibel zijn met Climbexion op Pc's. Climbexion systems binnen een master project moeten onderling compatibel zijn enzovoort Virtualisatie Dit is niet iets dat vanaf het begin in Climbexion geïmplementeerd wordt. De "body" van Climbexion wordt gevormd door de opgeslagen versions. Al het andere: folders, courses, names, is "registratie en structurering"van een subset uit die body. Nu zijn er wel veel registraties van versions in drawers en hun satellites, in verschillende subprojects, en ze zijn overal "ongeveer" hetzelfde. Kan die registratie niet compacter, met minder redundancy. Bijvoorbeeld de importdrawer, moet die alle baselines bevatten van alle packages in een project, of hoeft die slechts verwijzingen te bevatten, naar de baselines in de export-drawers van andere teams? Voor de gebruikers kan het "paradigma"van de import-drawer intact blijven, De referentie is een "verborgen" registratie, die samen met een retrieval procedure de suggestie wekt van een "bevattende" opslag-methode. De methode kan gebruikt worden in import -, export -, team drawers, satellites enzovoort. Bij de start van een drawer, dat wil zeggen: ik denk bij de start van de meeste drawers, wordt een snapshot gekopieerd uit een andere drawer. Dit geldt in ieder geval voor het merendeel van satellites. In plaats van kopiëren zou een reference opgenomen kunnen worden naar het snapshot in de andere drawer. Iets soortgelijks zou kunnen gebeuren in een satellite bij tussentijds opnieuw een base bepalen, of bij import-drawers bij het binnenhalen van een baseline. Hiermee zou je de DAG terugkrijgen. Als dit ooit geïmplementeerd wordt denk ik dat je weloverwogen moet besluiten om te kopiëren of te refereren. Net als bij clones geldt: wil je afhankelijk zijn van de beschikbaarheid van de andere drawer of van de performance van de verbinding of niet. Binnen de afdeling van NXP was er een uitstekend intranet met goede beschikbaarheid en goede performance. Maar de verbindingen met andere teams waren significant trager. Door de tijdsverschillen kon je soms niemand bereiken als remote repositories niet bereikbaar waren. Thuis en onderweg werken gold op ieder moment slechts voor enkelen, vanwege de afhankelijkheid van hardware, maar maar het gold Pagina: 191 / 230

192 2.8 Overige aspecten altijd wel voor sommigen. En ook hier geldt als je kiest voor reference, dan wordt je afhankelijk van het internet. Mijn oorspronkelijke idee was dat iemand één of misschien twee satellites nodig zou hebben, later vond ik dat je een satellite moest hebben voor ieder probleem dat je oplost. Zo'n satellite kan beginnen met een reference naar een snapshot van een andere satellite, gevolgd door een exact copy vanuit een team-drawer, waarbij slechts verschillen hoeven te worden gekopieerd. Maar als je oude satellites verwijderd, dan moeten gerefereerde snapshots alsnog gekopieerd worden in de nieuwere satellites. Voor ongewijzigde elements moet het algoritme mogelijk een keten van references volgen. Local pools eisen dat je van alles dat je wilt zien een lokale kopie hebt. Je kunt iets maken met pool reeksen: eerst wordt lokaal gekeken of daar de kopie voorkomt, dan meer centraal, en misschien zelfs super centraal. Een nieuw exemplaar wordt om te beginnen zo lokaal mogelijk opgeslagen, maar verhuist, naarmate de kring van gebruikers toeneemt. Daardoor zou minder opslag van kopieën nodig zijn, en zouden sommige acties korter duren, maar andere weer langer. Verder geldt ook hier, wil je afhankelijk zijn van beschikbaarheid en performance van verbindingen, of toch een lokale cache gebruiken. Er is wel een trend om je altijd en overal afhankelijk te maken van digitale verbindingen. Info-trees, hoeven geen fysieke folders te zijn op disks in lokale pc's, of in file servers. Er kan een virtual file system gemaakt worden dat info-trees zichtbaar maakt als een folder, terwijl er slechts een script met query's (een voorschrift voor het samenstellen van de info-tree) echt bestaat. Zo'n info-tree kan niet gewijzigd worden: als je wilt wijzigen dan moet de info-tree gekopieerd worden in het lokale file system. Een dergelijk overzicht moet geleverd kunnen worden door Climbexion, al hoeft de virtuele info-tree niet per se zichtbaar te worden gemaakt met hulp van een virtual file system. Climbexion moet eerst maar eens werken voordat virtualisaties worden geïmplementeerd. Naast virtualisatie kunnen de paradigma mogelijk zelf herzien worden om te komen tot een systeem dat leaner en meaner is dan het prototype. Bijvoorbeeld: importeren in een import-drawer is overbodig, exporteren vanuit een export-drawer is overbodig. Voor al deze optimalisaties geldt: Don't do it now Begrenzen? Package Feature (Requirement) List Een subproject maakt zo'n feature lijst voor ieder package dat in het subproject wordt bijgehouden. Dit is een goed uitgangspunt voor het verdere plan van aanpak, en het structureren van tests. Waarschijnlijk is ook dit een deel van SCM, immers dank zij zo'n list onderscheidt het package zich, ten opzichte van hetzelfde package in een ander subproject, dat een andere feature list heeft. Een belangrijke maar voorlopig vage eis is, dat de feature lists onderling vergelijkbaar zijn. Samen met een subproject tree, waarin te zien is hoe feature lists van elkaar zijn afgeleid, is dit best interessante informatie. De feature list, zelf kan als file worden opgeslagen binnen Climbexion, maar zijn editor, en de software voor de overzichten maken er geen deel van uit. Tijdens development is een dergelijk overzicht nuttige informatie voor stakeholders. De informatie is waarschijnlijk bruikbaar voor integrators bij de start van een nieuw (design-in) subproject, om te bepalen welk subproject het initiële package levert voor het nieuwe project. NXP heeft gedurende Pagina: 192 / 230

193 2.8 Overige aspecten een bepaalde tijd zo'n systeem bijgehouden, in één van zijn teams. Toen de projects van dat team teneinde waren en het team is opgeheven, is het systeem waarschijnlijk niet overgenomen door andere teams. In de oorspronkelijke opzet werd één enkel MS Access bestand gebruikt over alle subprojects. Door deze opzet werd de informatie van een subproject niet bij het subproject in het revision control system geplaatst. In feite was er een een Access file per publieke component, dus niet per package. In de team organisatie was er een architect die verantwoordelijk was voor het hele package, en software engineers (de component owners) die verantwoordelijk waren voor de publieke componenten in een package. Feature lists werden bijgehouden per publieke component. Deze opdeling ontlaste de architect die als spil in het geheel fungeerde. Een Climbexion element is vaak een file. De basis entiteit van het feature list gebeuren is een lijst per subproject per component. Het ligt voor de hand om zo'n basis entiteit in een file te stoppen, en zo gebruik te maken van Climbexion voor opslag, distributie en identificatie. Voor de Feature List software betekent dit dat de subproject tree wordt samengesteld uit de files in de verschillende subprojects. Project documentatie Philips standaards zijn voortgekomen uit een IEEE standaard voor project documentatie. Reden om de documenten op te nemen in het revision control system: uniformiteit en beschikbaarheid: er is één plaats waar deze informatie wordt bijgehouden en beschikbaar is. Het revision control system wordt zo een zo volledig mogelijke gegevensbank waarin analyses kunnen plaatsvinden ten behoeve van project-evaluaties, en ter lering en vermaak. Normaliter is een project zo gestructureerd dat er een overall project is, dat bestuurd wordt namens de client van het project, en subprojects, één per team, of mogelijk, één voor een party. Ik zal nu niet bestuderen hoe de eventuele functionaliteit van Climbexion kan worden uitgebreid ten behoeve van het beheer van project documentatie. Climbexion is bedacht voor het opslaan van software, maar je kunt er misschien ook project documentatie in opslaan. Het ook gehalte is mogelijk niet al te best. Tools Als de tool beheerders behoren tot een team in het project, dan is er sprake van een gewoon package, ik heb het hier over tools waarvan het beheer op afstand staat van het project, met een onafhankelijke ontwikkeling. Opslag van tools is nuttig. Soms moet je terug in de ontwikkeling om bepaalde problemen te reproduceren, een andere keer wordt een package van een oud project het origineel in een nieuw project. In die gevallen moet je mogelijk terugvallen op het oude tool. Ook kun je in een team werken aan verschillende projects, die ieder een andere generatie van een tool gebruiken, of een tool van verschillende leveranciers. Toch zijn er grenzen. Een oud operating system, of een oude internet browser kun je terughalen uit een beëindigd project. Maar het lijkt onverstandig om het uit te voeren vanwege de veiligheidsrisico's. Ook als je werkelijk oud materiaal terugzet, dan kan het zijn dat het niet meer werkt of Pagina: 193 / 230

194 2.8 Overige aspecten bouwt in enige beschikbare hardware/software omgeving. Een andere grens is er omdat er tools zijn die die niet in beheer zijn bij een project maar bij de staande organisatie. Bijvoorbeeld office en communicatie pakketten. Zelfs onderdelen van ontwikkelomgevingen zijn vaak niet project gebonden. Tools die bijgehouden worden buiten de drawer zijn potentieel een bron van problemen als een oud project wordt teruggezet. Bijvoorbeeld voor het repareren van een probleem bij een eindgebruiker van de TV is de toenmalige compiler met linker, en bibliotheek met standaard software nodig. Tool problemen bij het terugzetten van snapshots uit oude projects kunnen worden veroorzaakt door ongedocumenteerde variables en values in registries, environment tables of configuration files die nodig zijn voor een de build van een executable voor een specifiek hardware platform. Het is aan te bevelen om in zo'n geval de variable in te bedden in een specifiek script waarmee de build voor het platform wordt uitgevoerd. Het script is dan in ieder geval te vinden in een tools folder. En het script werkt environment variables en registries bij. Tools kunnen worden opgeslagen in een tarball of zipfile, als hun installatie weinig méér inhoud dan de folder met inhoud op een PC plaatsen. Tools kunnen opgeslagen worden als een installatie pakket als de installatie meer inhoudt en er ook registries of environment variables moeten worden bijgewerkt, of als delen van de software moeten worden geïnstalleerd in systeem folders. Ook een combinatie is mogelijk: een folder structuur in een archief file, en een script file om de omgeving aan te passen. Als tools worden opgeslagen als installatie pakket, dan moeten eventuele patches mogelijk afzonderlijk worden opgeslagen, zodat je eerst installeert en dan patches aanbrengt. Dit zal niet altijd gemakkelijk zijn, bijvoorbeeld als de patches worden aangebracht door internet update procedures, waarna ze niet meer zijn te lokaliseren. Als een tool wordt opgeslagen in het revision control system, dan moeten er wat dit betreft goede afspraken worden gemaakt met de leverancier. Soms werk je voor diverse projects. Als je werkt aan het ene project en je switcht naar het andere, dan wil je eigenlijk dat je slechts een andere folder in je filebrowser moet moet selecteren, of een andere drawer in je revision control tool en dan ben je over. Maar soms kunnen tools en hun omgevingseisen maken dat je een scripts moet uitvoeren als je switcht. Bijvoorbeeld omdat het niet mogelijk is om tegelijkertijd twee releases van één tool op één PC te gebruiken. In Climbexion komen in het begin geen extra voorzieningen voor tools. Build tools en uitbreidingen van IDE's. Voorlopig worden build tools niet geïntegreerd met Climbexion. Er zijn diverse build tools en IDE's die geïntegreerd zijn met een revision control system, met faciliteiten om een working-tree te synchroniseren, en wijzigingen met commit in te lijven. In het begin kunnen we bestaande tools gebruiken, en separate Climbexion software voor de diverse soorten synchronisatie, commit, envelope onderhoud en transfer. Testplek, kabinet, board, equipment administratie De redenen om deze administratie bij het revision control system op te nemen zijn dezelfde als die van project documentatie. Pagina: 194 / 230

195 2.8 Overige aspecten De beschikbaarheid van de registratie betekent primair dat iemand kan vaststellen wat de meest geschikte testplek is voor de sessie die hij wil starten. Verder geldt ook nog dat, mocht het nodig zijn om een bepaalde configuratie opnieuw op te zetten, dat je dan kan zien in de administratie hoe dat moet, omdat een expert het ooit heeft voorgedaan. Een configuratie op een bepaalde tijd van een testplek beschrijft in feite wat er nodig was voor bepaalde test - of analyse - of debug - sessie. Uiteindelijk is dit een schat aan informatie, zeker als dit verband óók wordt vastgelegd. Bijvoorbeeld door een verwijzing naar de configuratie gegevens toe te voegen aan de log van een work-item. Om zo'n administratie goed up-to-date te laten houden zou je equipment (meestal signaal generatoren) mogelijk moeten uitrusten met RFID chips, zodat ieder op elk moment kan vaststellen waar het zich bevindt, en er niet naar hoeft te lopen zoeken. Daarnaast zou van equipment moeten worden geregistreerd in welke opstelling ze gebruikt wordt, misschien door automatisch vast te stellen in welk cluster stopcontacten het is ingeplugd. Deze en andere maatregelen zouden uiteindelijk moeten leiden tot een situatie waarin iemand zijn plaats niet hoeft te verlaten, om een testplek te kiezen, en de inrichting ervan te plannen. De software die in de testplek geladen is op een zeker moment behoort zeker tot de informatie die zou moeten worden geregistreerd. Tenslotte is er de registratie van audio en video streams, dvd's cd's en video tapes, patterns voor pattern generators die gebruikt worden in specifieke tests. Van dvd's cd en video tapes wil je graag weten waar ze uithangen, van patterns wil je weten door welke generators ze kunnen worden gegenereerd, van streams in welke folder ze staan, en van al deze dingen waarvoor ze geschikt zijn. Ook is het interessant om te weten wanneer in welke opstelling en waarvoor ze gebruikt zijn. Als je kans ziet om deze registratie goed voor elkaar te krijgen, betrouwbaar, actueel en zonder teveel overhead, dan rest nog het probleem van de kabels, snoertjes, plug adapters enzovoort. Bij het geschikt maken van een opstelling zou je hier niet naar moeten zoeken, of ze roven van een andere opstelling. Het hangt een beetje af van de laatste reorganisatie. Soms valt het middelen beheer onder de staande organisatie, dan weer wordt het beheer aangestuurd door een projectmanager voor de subprojects die onder zijn verantwoordelijkheid vallen. Project management zoals ik dat vroeger ooit geleerd heb (een cursus van Twynstra Gudde eind jaren 80), heeft te maken met fasering en met beheersing, en met voortgangsbeslissingen. Beheersaspecten, leerde ik, zijn: tijd, geld, kwaliteit, organisatie en informatie. Tegenwoordig zie je dat bijvoorbeeld risico beheersing een apart continu beheersaspect is (PMBoK in Wikipedia). In de TV software projects zou het middelen beheer ook wel in aanmerking kunnen komen om tot apart aspect te worden verheven. En in het overall project is het maken van prototypes en tv's voor testen, proef productie opstellingen reeds een bron van activiteiten. Dit is een separaat systeem. In Climbexion komen geen voorzieningen om aan te sluiten op dit systeem, trouwens verwijzingen naar specifieke hardware en testplek configuraties zouden eerder thuishoren in work-items, dan in envelopes. Installatie software In het verlengde van het build proces is er de installatie van software op een target system. Pagina: 195 / 230

196 2.8 Overige aspecten Er zijn source systems waaruit files geselecteerd worden, een medium waarmee de geselecteerde files als package verzonden worden naar een target system. Working-trees of info-trees maken deel uit van de source systems. Op het target system moet worden gecontroleerd of de te installeren software er kan draaien, en zo ja dan moeten de files geheel of gedeeltelijk op het target systeem worden geplaatst. Soms moet de juiste variant van een onderdeel van het package worden geselecteerd. Misschien is de opslagstructuur afhankelijk van het target. Mogelijke referenties naar files of file inhoud moeten worden bijgehouden, en misschien moeten configuratie files en parameters worden aangepast. Bij CE werd reeds rekening gehouden met de trend om eindgebruikers of dealers gewijzigde software te sturen. De installatie software gebruikte dan ook security methoden zoals encryptie, en elektronische handtekening. Installatie software kan een package zijn binnen climbexion, Verder is er geen relatie met climbexion. Expertise database Het vinden van de juiste persoon voor een functie in een project, voor het toekennen van een werkopdracht, of voor hulp bij het uitvoeren van een werkopdracht, het vinden van zo'n persoon is niet altijd eenvoudig. Een database met de bekwaamheden van een persoon is dan ook gewenst. De database kan deels handmatig worden bijgehouden, deels automatisch door iemands bijdragen aan projects, packages, en work-items te monitoren. Ook de beschikbaarheid van iemand, zou vastgelegd moeten worden. Bijvoorbeeld: consultancy beperkt zich tot een team, een (master) project, een party, of is (tijdelijk) niet mogelijk. Recepten boek Hoe maak je een test script, hoe ziet een Koala pd file eruit, hoe zet je een debug sessie op tussen een PC en een TV, wat is Horcom, alles over aspect ratio: kijk in het recepten boek, gemaakt door iedereen voor iedereen. De lokale Wikipedia. Allereerst is een redactie nodig. Verder is een goed hypertekst programma onontbeerlijk. Aangezien een dergelijk systeem door iedereen wordt bijgehouden, ligt het voor de hand om een revision control system te gebruiken voor distributie, en onderhoud en status beheer. Het onderhoud van een dergelijk systeem is geen case study geweest bij het bedenken van Climbexion. Bijvoorbeeld: ik kan in dit hele epistel niets vinden over overleg pagina's. Het is daarom raadzaam om te kiezen uit voorhanden version control systems, aan de hand van een checklist, of om een hypertekst tool te kiezen, met een ingebouwd revision control system. Eén van de aandachtspunten is het selecteren van een context. Bijvoorbeeld: Tijdschrijven wordt in elke afdeling gedaan, maar overal net iets anders Debuggen in het ene project werkt met een andere debugger dan in het andere Als je dit systeem gebruikt is het misschien raadzaam om een profiel van de gebruiker en het gebruik op te geven alvorens te zoeken op een onderwerp als tijdschrijven of debuggen. Dank zij het profiel wordt je vraag naar debugger vertaald in: de debugger van project X. Je hoeft dan niet te vragen naar debugger D. Het recepten boek vertelt je dan om te beginnen, dat je debugger D moet hebben. Pagina: 196 / 230

197 2.8 Overige aspecten De structuur van Climbexion is waarschijnlijk niet adequaat, er zijn diverse onderwerpen die niet gerelateerd zijn aan packages, teams en subprojects. In de periferie van dit systeem, bereikbaar via links bevinden zich de cursussen, presentaties, manuals en zo, die zouden mogelijk ook in een revision control system horen, dit pleit weer voor een onafhankelijk versie-beheer systeem, los van het hypertekst tool. Dit tool maakt geen deel uit van Climbexion. Een volledig en volwassen Climbexion zou misschien uiteindelijk ook de Wikipedia soort samenwerking moeten kunnen faciliteren. In NXP en in Philips-CE wordt een dergelijk systeem bijgehouden. Communicatie Mail, chat, twitter, blogs, web pages, chatrooms, audio/visual telefoneren en vergaderen: dit maakt geen deel uit van Climbexion Gebruikersvriendelijke? id's Party, Team, Project NXP heeft een probleem: de ontwikkelingen in design teams en design-in teams in Eindhoven vinden plaats in één gebouw. Ook alle vertegenwoordigers van clients worden ontvangen in dit gebouw, en een aantal van hen moet soms toegang hebben tot de test plekken waar hun televisies staan opgesteld. Het is niet de bedoeling dat ze daar bij NXP op de hoogte worden gebracht van de activiteiten en ontwikkelingen van hun concurrenten. Tot mijn achtste jaar heb ik gewoond in de Lijsterbesstraat. Dit is een klein kronkelig straatje dat begint bij het kruispunt met de Essenstraat links, en de Glaslaan rechts, en de Kastanjelaan ertegenover. Het straatje komt uit in de Philips de Jonghlaan. We woonden tegenover de bakkerij. Wat geeft nu de naam Lijsterbesstraat precies aan informatie prijs? Wel als je Lijsterbesstraat" tegen mij zei wist ik het precies: het was de straat waar ik woonde, niet al te ver van het spoor en de glaspoort van het Philips complex "Strijp I". Een Eindhovenaar weet dat het waarschijnlijk in het Philipsdorp ligt, net als de Iepenlaan en de Acasiastraat. Maar de meeste mensen zegt het niets. Je kunt vermoeden dat er lijsterbessen groeien, maar dat hoeft niet per se. Aan de naam kun je niet zien dat er een bakkerij gevestigd was, of dat ik er gewoond heb. Het feit dat het een straat is en geen laan zegt wel iets, misschien niet over de huidige status, maar wel de status van de weg toen de naam bedacht werd. Ondanks het feit dat het hier een "niet zinvolle naam" betreft (behalve dan het woord straat ) is iedereen tevreden met de naam, en degenen die het aangaat weten wat ermee bedoeld wordt. Stel je noemt een project: Sony Pnx315Chip USA, dan hebben we het over een zinvolle naam. Je ziet wie de client is, welke chip gebruikt wordt en dat het project bedoelt is om een televisie in de Verenigde Staten van Noord Amerika in de markt te zetten. Misschien is er nog wel een zinvollere naam te bedenken die nog meer informatie bevat. Pagina: 197 / 230

198 2.8 Overige aspecten In een omgeving waar discretie vereist is is het maar beter om een niet zinvolle naam te gebruiken, zodat Beste Pleegbaas, rondslingerende informatie niet meteen alles prijsgeeft aan niet Het doet mij genoegen u mede te delen dat het project ingewijden. Een thema naam is dan LG-EU-MidRange-Internet-SuperSharp morgen klaar een lichtgewicht bijdrage aan de is discretie, en een laatste barrière als de geëigende maatregelen falen. Voor Groeten, projects kies je bijvoorbeeld mieren inhuurkracht Henk als thema. De projects heten dan: Formica rufa (Rode bosmier, Typisch rondslingerende informatie beeldmerk: een rode mier in het bos), Lasius Flavus (Gele weidemier), Myrmica rubra (Knoopmier). Voor teams kies je namen uit een ander thema (ook voor de teams van andere parties) en zelfs voor parties kun je je bedienen van thema namen. Geen naam geeft iets prijs behalve dat het een project, een team, of een party betreft. Dit kan natuurlijk alleen als je systemen en tools dergelijke namen toestaan. Climbexion moet nog gemaakt worden, dus ik ga ervoor zorgen dat het kan. Eindhoven, 5 december Stel je kiest nummers voor teams, projects, en parties. Dan bestaat er toch een kans dat zingeving in de identifiers sluipt. Team leest dan bijvoorbeeld als 18_315_02: 18: Toshiba, 315: chip PNX315, 02: Mips. Dergelijke names worden het best uitgegeven door een party. Er zijn dan diverse names in omloop voor hetzelfde project, hetzelfde team, en dezelfde party. Iemand kent alleen de betekenis van de names waarmee hij te maken heeft: men kent elkaars aanduidingen voor zover nodig. Climbexion moet in staat zijn om met dergelijke synoniemen te werken. In een team ziet je dan uitsluitend de eigen codering van projects, parties en teams. Ook kan het zijn, dat bepaalde gegevens in bijvoorbeeld envelopes zoals herkomst informatie niet beschikbaar worden gesteld buiten het eigen team. Als een thema verveelt kun je overstappen op een ander thema, ook de synoniemen die uit een dergelijke overgang voortkomen mogen geen probleem zijn voor Climbexion. Snapshots Bij snapshots heb je te maken met een drawer (of een package), en de inner-reach van die drawer (of dat package). Je kunt het snapshot nader specificeren met een timestamp of ook aanduiden met een baseline name of een tag name. Timestamps zijn nogal lang ten opzichte van tag names en baseline names. Ieder is vrij om names te bedenken voor Tags en Baselines: het zijn element names. Ze zijn net zo zinvol en kort als je wenst. Toevoegingen als drawer, package en project aan de name zijn overbodig want die hebben reeds de context bepaalt, waarin de snapshot aanduidingen gebruikt worden. Bijvoorbeeld als je vraagt: wat is de laatste baseline van package S in masterproject MP, dan verwacht je als antwoord: baseline 3.2, maar niet: Package S, Masterproject MP Baseline 3.2 Snapshot aanduidingen hoeven dus niet globally unique te zijn. Pagina: 198 / 230

199 2.8 Overige aspecten Timestamp: Tag Baseline 10 augustus 2008, 18:12:31 (27): 10 augustus 2008, A.M: Week R3.2 erg veel redelijk Kort, maar een vertaalslag naar gregoriaanse kalender is nodig voor veel mensen Nog korter, in principe een niet zinvolle naam, maar voor ingewijden betekenisvol. 3: laatst bereikte officiële mijlpaal, 2: volgnummer Een timestamp als snapshot is uitsluitend geldig voor de drawer, maar baselines en tags zijn overdraagbaar van de ene naar de andere drawer. Echter om bruikbaar te zijn buiten de original drawer moet de target drawer gesynchroniseerd zijn met een query waarin de baseline of tag gebruikt is. Voor de weergave van datum en tijd van een timestamp wordt de default van de betreffende desktop of laptop gebruikt. Misschien kun je kiezen voor een file system met een nauwkeuriger timestamp dan de huidige één seconde. Events en Course items Events kunnen worden aangeduid met een timestamp. De items die door een event toegevoegd worden aan de course van een element krijgen een additioneel nummer. Als tweede identifier voor zo'n item kan een sequence number gebruikt worden. Item sequence nummers kunnen dan gebruikt worden ter oriëntatie in de course van een element. Voor oriëntatie in een drawer kan men zich immers al bedienen van snapshot aanduidingen. De nummering vindt plaats per element (per kin per drawer) Kins Kins worden geïdentificeerd met behulp van een global unique identifier. Dit is niet erg gebruikersvriendelijk. Maar referentie vindt indirect plaats. De name van een element in een folder in een working-tree geeft bijvoorbeeld toegang tot de kin, maar je moet wel een Climbexion tool gebruiken om de working-tree te benaderen. Kin referenties blijven intact omdat projects uit elkaar ontstaan, door packages of hele drawers te kopiëren vanaf design projects, of vanaf design-in projects van dezelfde client. Kins van packages worden opgenomen in de eigen pools, en hebben in ieder geval een referentie in de administrator database. Elements Een element wordt geïdentificeerd door een drawer en een kin. Maar toegang krijg je door het gebruik van een name in een folder in een working-tree, of info-tree of snapshot (virtual info-tree). In feite door middel van een path-name. Pagina: 199 / 230

200 2.8 Overige aspecten Versions Voorlopig houdt ik het er maar op het volgende : ze worden geïdentificeerd met een eigen identifier. Voor de eigen identifier wordt tegenwoordig een cryptografische hash van hun inhoud genomen. Ik meen dat Monotone hiermee is begonnen. Er is een traditie om deze files op te slaan in de vorm van delta's ten opzichte van hun voorganger in een verzamel tekst file, tenminste ik meen dat ik dat ooit gezien heb bij PVCS. Voor een eerste aanzet van Climbexion is deze compressie techniek nog niet nodig, en misschien wel nooit. In één package kunnen in een snapshot identieke versions voorkomen in verschillende files, die niet tot dezelfde kin behoren. Deze worden dus maar één keer opgenomen, immers hun hash is hetzelfde. Door de inhoud uit te breiden met de kin id en ook daarover de hash te bepalen kan dit vermeden worden, maar de vraag is of dat nodig is. Een rare consequentie kan zijn, dat je een version vastlegt in je satellite, en prompt krijgt hij een andere timestamp last changed, omdat hij gelijk is aan een bestaande version. De vraag is of je dat moet vermijden door de inhoud uit te breiden met de timestamp: er kan een merge door worden uitgelokt, die feitelijk overbodig is. Bij versions hoort metadata in de vorm van attributes. Deze attributes zoals timestamp en user-id zouden niet moeten bijdragen aan de hash, zodat er geen overbodige kopieën worden opgenomen in de pool. versions worden als volgt gekozen: via de course van een file. Door het gebruik van een name in een folder in een snapshot, of working-tree. Door referentie vanuit een envelope. Drawers Hun duiding: een type aanduiding zoals team-drawer, import-drawer, export-drawer, expose drawer full, expose drawer restricted. Dit alles is niet eenduidig. Een project name hoort erbij, en soms een package name. Die project name betreft dan het subproject waar deze name betrekking op heeft. Satellites worden aangeduid met hun center en een additionele (user) name, of door een center een additionele name en een reference naar een work-item. Drawers zijn waarschijnlijk een file of een folder of beide. Als zodanig worden ze ook geïdentificeerd door een URL. Drawer type aanduiding en subproject samen specificeren de constellation. Envelopes Envelopes krijgen een sequence number. Samen met een constellation is dit een unieke aanduiding. External envelopes Binnen het master project krijgen ze een sequence number Losse eindjes Opslag en afvinken van merge conflict lijstjes. Opslag van scripts (bijvoorbeeld voor Import limitations). Opslag van templates. Opslag van definities en data betreffende filetypes, file subtypes, file extensies, file gerelateerde Pagina: 200 / 230

201 2.8 Overige aspecten tools, backward en forward compatibility. Vastleggen van entiteiten en entiteitsvertalingen. Structureren van Other-focused file pools. Pagina: 201 / 230

202 2.9 Slotopmerkingen 2.9 Slotopmerkingen Het gebruik van locations: Het is de bedoeling dat dit de security bevorderd, maar ook dat het extensible en flexible is. En dat het de mogelijkheid creëert om te werken met abonnementen op bestaande database servers en file servers, of om als organisatie deze servers aan te schaffen. Voor de file servers waarin versions zijn opgeslagen geldt: een directory structuur is niet per se nodig, maar support van de security die Climbexion vereist moet geïmplementeerd zijn. Ook is support van file forks gewenst om metadata te implementeren. Voor drawers, en pools van kins, en van envelopes geldt waarschijnlijk dat een database server volstaat. Compressie technieken van de file server kunnen misschien wenselijk zijn, bijvoorbeeld als de hoeveelheid software en data harder groeit dan de hoeveelheid opslagruimte, als die dan duur en/of schaars wordt. Climbexion kent de base waaruit een nieuwe version is ontstaan, In het begin wordt deze informatie niet vastgelegd in het filesysteem. in de toekomst zou een filesysteem met delta compressie in principe mogelijk zijn, als daarin voor elke successor één of alle bases worden vastgelegd. Toestaan dat wijzigingen van name en folder membership mogelijk zijn binnen een kin, en zelfs binnen een course, is zo'n beetje een uitdaging. In dergelijke gevallen een nieuwe kin beginnen is natuurlijk te simpel. Voor een tool dat folder structures synchroniseert zoals robocopy of voor commander software en directory compare software is dit mogelijk een probleem. Voor de ontwikkeling van Climbexion betekent dit dat je niet zomaar een van deze programma's kan pakken, en dan de inputs en outputs ervan vervang door access op drawer snapshots en tips. Voor de gebruiker betekent het dat er meer vrijheid is om namen of indelingen te wijzigen, terwijl de methode om te synchroniseren intact blijft. In Climbexion ligt de grens bij het package, als je een element verhuist buiten het package, dan moet er een nieuwe kin komen. De log die bijgehouden wordt door de course van een envelope is in de eerste plaats bedoeld om bij te houden wat er is nodig geweest om een oplossing volledig in de repository te krijgen. Ook kun je daarin nagaan hoe het verloop van een changeset is geweest door de overdrachten heen. Deze informatie kan van pas komen voor het verbeteren van procedures, maar ook voor het vinden van een fout-oorzaak. De courses van eigen elements in de eigen drawers zijn uitgebreider dan de courses in die waarin de elements zijn gedistribueerd en overgedragen. Deels komt dit de zakelijkheid ten goede, deels de besproken discretie want dit verbergt mogelijk enig inefficiënt handelen, dat iemand niet aan de grote klok wil hangen. Evaluaties ten behoeve van product-verbeteringen zijn uitvoerbaar in drawers met geëxposeerde elements. Voor evaluaties ten behoeve van werkwijze (of gedrag) verbeteringen gebruik je meer lokale drawers en satellites. Ze staan ten dienste van degenen die hun eigen werkwijze willen of moeten verbeteren. Dit principe wil ik er eigenlijk wel inhouden, bij herzieningen van de paradigma. Bij proces of gedrag moet je bijvoorbeeld denken aan tekenen van besluiteloosheid: de envelope wordt wel/niet/wel ingevoerd; of tekenen van halve oplossingen: een envelope is in drie fasen gewijzigd, voordat de oplossing klaar was; of transfer problemen: regelmatig komt het voor dat de daily build mislukt, of de acceptatie test. Dezelfde gegevens die dienen voor werkwijze verbeteringen kunnen van belang zijn om de oorzaak van een fout te achterhalen. Als blijkt dat iets is fout gegaan door een wijziging van Lagus, dan kan Lagus met hulp van zijn satellite mogelijk de oorzaak van de fout achterhalen. Zelfs als de oorzaak Pagina: 202 / 230

203 2.9 Slotopmerkingen niet direct is af te leiden, dan kan de registratie in de satellite het geheugen opfrissen en zo bijdragen aan inzicht in de oorzaak. Als de oorzaak bekend is kan dat aanleiding zijn tot een verbetering van de kennis van Lagus, of tot verbetering van de manier waarop hij werkt, of de manier waarop in het algemeen wordt gewerkt, en tot een inschatting van mogelijk andere fouten. Er is nogal nadruk gelegd op discretie en geheimen en gentleman agreements en zo, maar ja dat hoort een beetje bij de aard van de elektronica industrie: de organisaties zijn rivalen, vaak moeten ze samenwerken en soms treffen ze elkaar als ze aan het shoppen zijn, bijvoorbeeld bij dezelfde chip fabrikant. Soms krijg je de indruk dat ze werken met patent genererende machines, een paar honderd per dag of zo, voor patenten waarvoor ze geen licentie verstrekken, om zo de concurrentie te dwarsbomen. Effecten kunnen zijn dat een nieuwkomer met nieuwe ideeën geweerd wordt en dat idee over idee niet gerealiseerd wordt. Dit zijn twee bijdragen aan innovaties, en dus aan omzet. Voor de branch als geheel en daarom ook voor individuele competitors is openheid en licentie verstrekking waarschijnlijk beter, en product en fabricage geheimen zouden niet lang moeten duren. De synchronisaties die ik heb geschetst: initieel synchroniseren van een satellite, tussentijds bij synchroniseren van een satellite als een ontwikkeling wat lang duurt, synchronisaties vlak voor een transfer van een satellite naar een center-drawer, synchroniseren van een package uit een ander project. Deze synchronisaties vragen om een goede set commando's en hun parameters om precies weer te geven wat de bedoeling is. Deze en andere commando's behoren tot de human computer interface van het systeem, en moeten ontworpen worden in de fase methodische probleem beschrijving. Wat kan een prototype van Climbexion opleveren? Methoden als Problem frames en Orm/Niam worden gebruikt voor een niet triviaal systeem op een manier die gepubliceerd kan worden, en wie weet misschien moeten ze er een beetje voor aangepast worden. Het structureren van de informatie voorziening met in acht neming van eisen van discretie volgens het model van Dorothy Denning: dit is fun voor de liefhebbers, als het tenminste niet te triviaal blijkt te zijn Enige ervaring met temporele problemen kan worden opgedaan. De software die mogelijk voortkomt uit mijn analyses is in principe niet (universeel) bruikbaar: ze is immers niet gebaseerd op een gedegen markt onderzoek. Het is dedicated software, voor een bedrijf dat lijkt op NXP's tv competence centers, en klanten die lijken op één van hun klanten ten tijde van pakweg , en gebaseerd op enkele schetsen van werkwijzen. Mogelijk is het verleidelijk om zo te structureren dat delen ervan hergebruikt kunnen worden voor domeinen waarvoor andere eisen gelden dan ik beschreven heb. Maar persoonlijk ben ik een beetje allergisch voor het woord ook. Het klinkt naar slechtzittende tweedehands kleding: Het pak is gemaakt voor Jan, maar Piet kan het ook aan. Binnen NXP heb ik gewerkt in een drietal teams. Waarschijnlijk is Climbexion geschikt binnen die teams. Voor de teams waarmee we samenwerkten en voor de andere teams in NXP gelden andere interne werkwijzen, en dus zijn er mogelijk andere varianten van een revision control system nodig. Voor de gegevens-uitwisseling zou het wel prettig zijn als opslag en transport gestandaardiseerd zijn, maar werkwijzen moeten kunnen variëren: er is mogelijk een zeer lange weg te gaan om te komen tot een commercieel product. Pagina: 203 / 230

204 2.9 Slotopmerkingen Vlak voor ik met pensioen ging (2008) gaf CE de Amerikaanse markt op, dat wil zeggen, dat ze de tv's lieten ontwikkelen door een Taiwanese firma. Het lukte NXP niet om zijn chip te verkopen aan die firma, dus dat was gevoelig verlies van marktaandeel. In 2011 kwam het bericht dat Philips CE helemaal ophield met de eigen fabricage van televisies. Het is best wel speculatief wat ik er hier over zeg. De aanpak met gemeenschappelijk ontwikkelen was goed en gaf een voorsprong toen er van scratch af aan begonnen moest worden, toen alles nog moest worden ontwikkeld en geïntegreerd. Later, toen er meer onderlinge zakelijkheid en plug en play vereist werd, zagen ze misschien geen kans die overgang te maken. Om in de gekozen cooperation projects toch een plug en play packages op te leveren is niet triviaal. Immers zonder harde verificatie is er geen garantie dat software aan een bepaald criterium voldoet: je moet er voortdurend op controleren, en de gevonden problemen oplossen, zoals bij gewone bugs. Bij samenwerken is het verdelen van werk vaak een kwestie van onderhandelen. UHAPI alleen lijkt onvoldoende en CE heeft ook te maken met allerlei applicaties. Climbexion is, omdat het voornamelijk is gebaseerd product families en op samenwerking (zonder veel plug en play), misschien slechts optimaal bruikbaar in een zeer specifieke situatie. De les: in de pionier fase moet je reeds veel meer ontwikkelen voor plug en play en independent deployment in de volgende fasen. De werkwijze toen, kan veranderen. Bijvoorbeeld als independent deployment bereikt wordt, is minder samenwerking nodig. Als de programmeer taal C wordt opgevolgd door een moderne taal, dan zal dit mogelijk de teams kleiner maken, de betrouwbaarheid van de software vergroten, en zo de werkwijze veranderen. Iets soortgelijks geldt als men overgaat op vernieuwde best practices. Er is binnen NXP een trend gesignaleerd om steeds meer computers en processors te gebruiken in het moderne elektronische speelgoed, en niet slechts één steeds krachtiger. De werkwijze en mogelijk de samenwerking verandert als er met zeer veel computers gewerkt gaat worden. Voor digitale televisies geldt ook nog dat die in het begin veel innovaties vereisten, maar naarmate de tijd voortschrijdt wordt het meer van hetzelfde, alleen goedkoper. Al deze veranderingen kunnen de behoefte aan bepaalde karakteristieken van een version control system veranderen. Kortom zonder goed empirisch onderzoek wordt het nooit wat, maar blijft het een hobby. Trouwens, als je met een tool wilt komen voor een bepaalde commerciële branch, zoals consumenten elektronica, dan zullen er standaards moeten worden afgesproken. Er zal moeten worden geparticipeerd door de ondernemingen in een commissie of zo, die de samenwerking en de tools die daarbij horen specificeert, en mogelijk de software tools uitgeeft. Ik denk wel dat dit open standaards en vrije software tools kunnen zijn, waardoor ze gemakkelijk en goedkoop beschikbaar zijn voor onderwijs, voor instappers, en buiten de branche. Een bedreiging van software revision systemen lijkt de ontwikkeling van de bestandssystemen ZFS en Btrfs / CRFS te zijn. Het lijkt erop dat dergelijke systemen met snapshots en branches rechtstreeks de opslag methode van revision control systems kunnen zijn. Voor Climbexion zou dan het drawer/pool opslag systeem uit de tijd raken. Ook het working-tree / view-tree idee zoals wij dat kennen gaat dan op de schop. Het prototype is zeker niet praktisch bruikbaar. Er zijn omissies zoals splitsen of samenvoegen van packages, opvolging van een package door een andere, integratie met een IDE en zo. Verder heeft een prototype een belabberde performance denk ik. Pagina: 204 / 230

205 2.9 Slotopmerkingen Het werk van een kamergeleerde Er is het gezegde: het eerste huis bouw je voor je vijand, het tweede voor je vriend, en het derde voor jezelf. Zoiets zal ook wel gelden voor een software systeem. Het eerste huis zouden sommige bestaande revision control systemen kunnen zijn. De eerste officiële versie van Climbexion, als het ooit zover komt, is voor een vriend. Je moet natuurlijk wel jezelf aan banden leggen, tenminste als je één van de wetten van Brooks wilt overwinnen: Het huis voor jezelf, of misschien reeds dat voor je vriend, komt nooit af, want je wilt het te goed doen en te mooi maken. Maar ja aan de andere kant, dit is ook voor studie, en wat mij betreft voor de lol, en om de tijd te doden. Door andere bezigheden werk ik slechts 3 dagen per week enkele uren aan dit stuk. Voor een ruwe schets van het revision control system en het gebruik ervan heb ik tot nu toe drie jaar doorlooptijd besteed. Nu begint een meer formele probleem beschrijving, met methoden waarmee ik nog niet eerder heb gewerkt. Als ik dat tenminste niet nog een jaar uitstel, ik zie nogal op tegen het formeel beschrijven. Ik ben waarschijnlijk te oud en te blasé om mij nog een methode eigen te maken zodanig dat ik ermee kan lezen en schrijven. Het lezen van een boek, en daarna in je eentje achter de PC ermee werken is niet meer de juiste manier voor mij om me de stuf eigen te maken. Uiteindelijk lukt mij slechts een informele beschrijving. Desalniettemin hoop dat u aan dit epistel enig plezier hebt beleefd. Zoals uit het plaatje blijkt is de pleister vooral bruikbaar voor lijf en leden van echte mensen Wat ik wilde maken was een speeltuin waarin wat gespeeld kan worden met methodisch ontwikkelen van niet triviale systemen. Tot nu toe zat ik in mijn eentje achter mijn PC. In je eentje, dat kan uiteindelijk niet de bedoeling zijn van een speeltuin. Pagina: 205 / 230