Jak to bude dál s vývojem Nette Frameworku

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
David Grudl
Nette Core | 8133
+
0
-

To, že končím s vývojem Nette, nebyl Silvestrovský vtip. Myslím to zcela vážně. Jde o krok, který by měl frameworku pomoci ho znovu-nastartovat. A jsem přesvědčen, že to vyjde.

Je to samozřejmě razantní změna. Nicméně ve chvíli, kdy krmíte krávu, ostatní ji dojí, a trendy nenasvědčují, že by se to mohlo změnit, ba právě naopak, je nutné razantní krok udělat.

Vývoj tak velkého projektu, jakým je dnes Nette Framework, vyžaduje kromě programátora také schopného managera, přispívající komunitu a vizionáře (hrozné slovo, brrr). A těch rolí je ve skutečnosti ještě více.

Přičemž nemá smysl jednotlivé pravomoci uměle rozdávat nebo snad někoho volit. Kdo je ve které oblasti dobrý se buď už dávno ukázalo, nebo časem ukáže. Nejlepší věci vznikají organicky.

Taktéž není potřeba vymýšlet, jak by měl vývoj probíhat, protože od toho dávno tu máme RFC na fóru nebo Pull Requesty. Dostanou 100% prostor a budou se přísněji vyžadovat testy a taktéž odpovídající komity do dokumentace. Test a dokumentace je kolikrát nejlepší argument, proč PR či RFC schválit.

Pozice managera, neboli Nette Bosse, bude putovní. Historicky prvním Nette Bossem bude Vítek Ježek.
Schvalování příspěvků do kódu má v tuto chvíli pod palcem Hrach (pro Nette Database), Acci (pro FileJournal), Milo (pro Nette Tester), já (pro zbytek – což věřím se brzy dál rozdělí) a celá řada dalších členů komunity schvaluje příspěvky do dokumentace.

Programátoři, diskutéři a tvůrci dokumentace jste vy. Tak do práce!

hrach
Člen | 1834
+
0
-
  • co obnasi pozice Nette Bosse? (sekundarne, co to znamena pro me jako mergatora)
  • jako nejzasadnejsi pro budouci vyvoj vidim upravu infrastruktury aspol. dostane k tomu nekdo pristup?
    • nette addons portal: …
    • slibovane rozdeleni nette do balicku: …
  • s infrastrukturou souvisi taky release managment. naprosto zasadni. kdo kdy a jak.

Editoval hrach (6. 1. 2014 15:53)

David Grudl
Nette Core | 8133
+
0
-

Úkolem bosse je rozdělit úkoly a dohlížet na jejich plnění, což je například i spuštění addons portálu atd. Do práce mergatora nijak nezasahuje.

Na rozdělení Nette do balíčků by mělo vzniknout RFC, kde se vyřeší, jak to prakticky provést. Každopádně příští velká verze by takto už být rozdělena měla.

Release management budeme řešit až v druhé fázi, vzhledem k čerstvému vydání nových verzí to není třeba řešit hned.

hrach
Člen | 1834
+
0
-

Na rozdělení Nette do balíčků by mělo vzniknout RFC, kde se vyřeší, jak to prakticky provést. Každopádně příští velká verze by takto už být rozdělena měla.

Před 10 mešísici jsem napsal malý „RFC“ jak s tím začít. Zůstalo bez odpovědi. (Stejne jako tak navrhy a myslenky jinych). https://forum.nette.org/…ych-projektu?p=3

Release management budeme řešit až v druhé fázi, vzhledem k čerstvému vydání nových verzí to není třeba řešit hned.

To je přesně největší chyba. Release managment se musí řešit hned, respektive kontinuálně, a ne jen když „už by to chtělo“.

Jan Tvrdík
Nette guru | 2595
+
0
-

Jn, pointa (jedna z mnoha) release managementu je, že se už dlouho dopředu ví, kdy nastane feature freeze a kdy vyjde nová verze. Třeba u 2.1 nikdo (AFAIK) nevěděl, jestli finální verze vyjde v listopadu 2013 nebo v březnu 2014. To je míra nejistoty, se kterou se extrémně špatně pracuje. Třeba u PHP 5.6 už teď vím, že 16. března 2014 nastává feature freeze a 16. června 2014 vychází stabilní verze.

David Grudl
Nette Core | 8133
+
0
-

Diskuzi o Git workflow jsem přesunul sem, jelikož byla OT. Podobu repozitáře není třeba měnit a zmíněný problém s cherry-pickováním je snadno řešitelný (místo vyhazování z Composeru a dělání vlastních větví stačilo říct, třeba formou PR do release větve).

Z hlediska vývoje jako nejdůležitější krok vidím rozdělení na menší části. Samozřejmě se budou řešit bug-reporty a lze doplňovat drobnosti, ale příštím krokem musí být rozdělení. K tomu vývoj dlouhodobě směřoval a po vydání 2.1 máme čistý stůl a možnost to provést.

Stejně tak důležité jsou věci mimo kód a to zejména doplňky a dokumentace. To, že dokumentace byla dlouhé roky plně editovatelné ji nijak nevylepšilo, kusy jí chybí (a to myslím ve 2.0) nebo jsou popsány nevhodně, nesrozumitelně, zastarale. Přechod na GIT navíc způsobil, že nyní nelze editovat a přidávat doplňky.

Ohledně rozdělení Nette, řešme to tady. Pokud jde o ostatní věci, nějaké úkoly jsme si rozdali už před prázdninami, takže asi není třeba o tom opět diskutovat a úplně by stačilo to prostě udělat.

romiix.org
Člen | 343
+
0
-

Prihováram sa za sémantické verzovanie a release management. Bolo by fajn presne definovať dátumy feature freeze, RC1, RC2 a release. Myslím, že to nie je nutné dodržovať na 100%, ale aspoň orientačne by to bolo fajn.

David Grudl
Nette Core | 8133
+
0
-

ad sémantické verzování: to jest ideál aplikovatelný na ideálně se vyvíjející projekty. Praxe je vždycky kompromisem.

Nelze třeba aplikovat sémantické verzování v případě, že relativně stabilní projekt obsahuje mladou část s jiným vývojovým cyklem (což v případě Nette 2.0 bylo Database a DI (a vyjmout ani jedno skutečně nešlo)). Ideální by bylo z pohledu SV vydávat feature verzi každého půl roku, což ale na druhou stranu znamená hotové drobné featurky až půl roku zdržovat, přičemž třeba současné stabilní API Database je relativně čerstvé. A na větší feature co půl roku nemělo Nette vývojáře, což se snad zlepší.

Takže jestli bych zpětně něco změnil, tak jen to, že bych loni vydal 2.1 kvůli Database, s tím, že je to opět non-stable, ale aby nebylo třeba věnovat tolik úsilí uživatelům 2.0. Nic jiného bych neměnil.

Totiž, nejsem si ani vědom neustále přetřásaných BC breaků (krom NDB a asi některých nutností). Z mého pohledu tam nejsou. Chápu, že když jsi ve skupině lidí, kde na ně narážíte, tak máte pocit, že je snad dělám naschvál a že to musí každý vidět, viz, ale to je iluze, skutečně o tom nemám páru a když pak narazím na podobné diskuse, docela žasnu.

Pozitivní na tom je, že BC break v setinkové verzi je trestem za neschopnost zformulovat svůj požadavek do kódu či alespoň výstižného popisu na githubu :-)

David Grudl
Nette Core | 8133
+
0
-

@romiix.org teď je potřeba nastartovat vývoj. Fakt nemá smysl určovat datumy, když nebude co releasovat. Když do Nette budou novinky proudit, bude release management diametrálně odlišný od toho, když občas někdo fixne typo v phpDoc. Tedy místo přimlouvání se vyvíjej ;)

hrach
Člen | 1834
+
0
-

@dg teď je potřeba nastartovat vývoj. Fakt nemá smysl určovat datumy, když nebude co releasovat.

A to není vůbec pravda. Dokud nebude aspoň nějaký plán, tak prostě ten vývoj je nahodilý. Typicky si vezměme třeba Nette\Database: loni před prázdninami jsem se snažil všechno dofixovat, aby to mohlo být vydáno. Povedlo se. Kdybych věděl, že je před námi více jak 6 měsícu, některý věci překopu a mohli být už ve stablu. Byly by otestované. Proč? Půl roku pro early-adopters & kdyby se dodrželo, že od RC se neBCbreakuje a neimplementují nové feature, tak to může každý otestovat na svém projektu a po vydání stablu jen updatnout bez dalších „dodělávek“. To v tuto chvíli vůbec nefunguje.

Všichni víme, že takhle to v Nette doteď nebylo. Příkladem je např. safeUrl – super hafo feature, která musela být ve stablu a naprosto neotestovaná. Aktuálně má 3 bugy:

  • nefunguje na obrazky, ktery stripne
  • stripuje, ikdyz {$var} je až v části URL, typicky „?var={$var}“
  • vyžaduje skrytou závislost za HelperLoaderu. To jsem objevil včera.

Všechno jsou to nepříjmené chyby a zatím neopravené. Tím neříkám, že je máš opravit ty, ale je opravdu těžký po open-source komunitě vyžadovat okamžité reakce pro vydání bugfixu.

David Grudl
Nette Core | 8133
+
0
-

Ale jistě, mít plán je důležité, nakonec už pár dní něco takového sepisuju. Reagoval jsem čistě na ty datumy. Ty mějme jako vodítko k vzájemné synchronizaci, ale nemá smysl je zveřejňovat.

safeUrl je feature, za kterou si stojím, ?var={$var} je tak jako tak chyba, že stripne obrázky je účel a koexistenci s |datastream (nebo i s těmi obrázky) lze vyladit v setinkových verzích. Nevidím v tom nic nestandardního.

David Grudl
Nette Core | 8133
+
0
-

Jak to vypadá s Nette aktuálně – 10. ledna jsme měli mnohahodinovou schůzku cca v desíti lidech a probrali všechny otázky dalšího vývoje Nette.

Výsledkem je řada úkolů, návrh jak psát a schvalovat RFC a RC a plány, kudy se bude ubírat další vývoj. Podrobnější informace tu postupně doplníme.

Soudě dle Githubu, vývoj běží aktivněji než dříve a účast na nejbližší Poslední sobotě bude hodně vysoká. Takže vše vypadá velmi slibně!