2. Ahogy eddig ütemeztük a kiadásokat

A FreeBSD 5.X verziójának fejlesztése és kiadása során sok-sok olyan tapasztalatot szereztünk, amelyek csak utólag váltak világossá számunkra. Az 5.X-es vonal célkitűzései meglehetősen agresszívek voltak és magukban foglalták a következőket:

• Az SMP (Symmetric MultiProcessing) rendszerek támogatása

• A teljesítmény növelése a kernelen belüli erőforrás-kiosztás egy új stratégia szerinti átdolgozásával

• Számos új processzor architektúra támogatása

• Egy új szálkezelési modell bevezetése

• Egy új ütemező bevezetése

• Új technológiák, mint például az energiagazdálkodás, támogatása (különösen laptopok esetén); és ami a legfontosabb:

• Addig nem tekintjük ezt a vonalt STABLE-nek, amíg az imént felsorolt feladatok be nem fejeződnek.

Ez egy olyan helyzet kialakulásához vezetett, ahol évek teltek el a 4.X vonal STABLE és az 5.X vonal STABLE kiadásai között. Ez magával hozott néhány tényleges kellemetlenséget:

• Az egyszerre kivitelezendő újításokhoz kapcsolódó módosítások nagy száma jelentős mértékben megnehezítette az egyes módosítások elkülönítését és beolvasztását a STABLE ágba.

• Ez pedig azt jelentette, hogy azok a felhasználók, akiknek igazán szüksége volt bizonyos újításokra (például, hogy képesek legyenek futattni a rendszer egy modern hardveren), kényszerűen átálltak (mondjuk) a FreeBSD 5.2.1-es verziójára, annak ellenére, hogy az kifejezetten egy fejlesztői kiadás volt, és hogy CURRENT kiadás lévén nem felelt meg teljes egészében minden igényüknek.

• A beolvasztások során a fejlesztők néha olyan helyzetbe kerültek, ahol olyan verzión kellett az újításaikat támogatniuk, amelyeket nem elsődleges fejlesztői platformként használtak.

• A késés továbbá azt jelentette, hogy mire az 5.3 végre STABLE szintű kiadássá válhatott, az időközben felgyülemlett módosítások terhe kínszenvedéssé tette a frissítési folyamatot.

Úgy szólván senki sem volt elégedett ezzel az eredménnyel.

A következőket tanultuk mindezekből:

• A főbb kiadásoknak kevesebb újítást kell tartalmazniuk és gyakrabban kell megjelenniük.

• A lehető legjobban el kell szigetelni egymástól a különböző újításokhoz kapcsolódó módosításokat. (Ez egyben arra is utal, hogy bizonyos fejlesztéseket nem az aktív forrásokon belül végezni, és majd csak akkor beolvasztani őket, ha már nem veszélyeztetik egyik párhuzamos fejlesztést sem.)

• A főbb kiadások határidejét inkább időben kell megszabni, nem pedig az újítások mértékében. Ha az egyes újítások nem készülnek el időre, akkor ki kell őket kapcsolni és meghagyni egy későbbi kiadásra.

Kevesebb újítással és gyakoribb megjelenéssel remélhetőleg csökkeni fog az egyes módosítások beolvasztásához szükséges idő a HEAD ágból a legfrissebb STABLE ágba (és ezáltal nem csak egyetlen fejlesztési vonalban maradnak támogathatók). Továbbá, mivel ezek az módosítások kellőképpen elszigeltek egymástól, az integrálás során keletkező hibák kockázata is csökken.

Sőt, az időben megkötött határidőknek köszönhetően végre könnyebben tervezhetnek előre a felhasználók, a külső alkalmazások fejlesztői és maguk a FreeBSD fejlesztői is egyaránt.

Nem más operációs rendszerek verzióival történő versenyfutás, hanem ezek a megfontolások indokolják a szándékot, hogy a jövőben az ütemezésünket átszervezzük.