kaffe.make og OMG

[arnested]

kaffe.make indholder et antal patches.

Det spiller ikke super med OMG da vi ikke får de patches noteret i YML-filer.

Løsningsforslag:

• Drop patches i make-filen og rul dem på med bandaid senere i lav/kaffe.
• Præprocesser der omskriver drush makes PATCHES.txt til YML-filer.

Andre ideer, @troelslenda, @naxoc, @danquah, @xendk?

[danquah]

Put dem på med bandaid bagefter, så er vi sikre på at yml-filen matcher whatever version af bandaid der bliver brugt.

Alternativt udvid bandaid med funktionalitet til at spise en PATCHES.txt og konvertere...

[arnested]

Helst ville jeg helst at bandaid hookede sig ind i drush make og lavede en YAML-fil samme sted(ish) som PATCHES.txt skrives, men drush make er nærig med hooksene... Og Moshe er nærig med at smide dem ind.

[kasperg]

Drop patches i make-filen og rul dem på med bandaid senere i lav/kaffe.

:+1: - tilføj også gerne en kommentar i make filen vedr. håndtering af patches.

[naxoc]

Jeg synes også det giver god mening at bruge bandaid senere i forløbet.

[gielfeldt]

Foreløbig løsning: #7

[arnested]

Bestemt en god start. Eventuelle rekursive make-filer med patches kommer så ikke med. Men stadig bedre end ingenting.

[kasperg]

Har vi overhovedet rekursive make filer i lav?

[arnested]

Nej, det har vi ikke p.t. Men vi hiver en del moduler i "seneste releasede version" så vi har ikke nogen garantier for vi ikke pludselig har det.

[kasperg]

vi hiver en del moduler i "seneste releasede version"

Så kan vi så diskutere om det er en god idé ift. Lav Kaffe. Det er jo ikke noget vi ville gøre ift. normale projekter.

[xendk]

Vi kan også diskutere om vi istedet for make skulle have en drush dl <package-specs>.

[arnested]

Så kan vi så diskutere om det er en god idé ift. Lav Kaffe. Det er jo ikke noget vi ville gøre ift. normale projekter.

Lige præcis i Lav Kaffe synes jeg det er fint.

Det er jo et engangsbyg. Når du har oprettet sitet er der ikke længere versioner der er ude af din kontrol. Alternativet er hele tiden at sidde og teste og opdatere på selve Lav Kaffe.

[naxoc]

Enig med @arnested . Her er et af de få steder hvor en make file giver mening. Men drush dl vil også virke fint for mig. Det ville give nyeste på samme måde som make.

[kasperg]

Det er jo et engangsbyg. Når du har oprettet sitet er der ikke længere versioner der er ude af din kontrol. Alternativet er hele tiden at sidde og teste og opdatere på selve Lav Kaffe.

Det forstår jeg godt og jeg er ikke 100% uenig. Problematikken opstår hvis et team skal sidde og gennemteste deres default byg ved opstart af et nyt projekt, hvis de nu skal være sikre på at alle delene stadigvæk virker.

Alternativer:

1. Automatisk opgradering og aktiv brug/bedre dækning ift. test cases
2. At teams selv opdaterer contrib, hvor der er behov, og fører opdateringen tilbage til lav.

[xendk]

Det er urealistisk at tests redder dagen ved 1. Det er usandsynligt at den standard-funktionalitet vi vil teste for i lav er den der brækker. Det er ude i edge-cases som vi først kommer ud til når vi begynder at implementere et nyt site.

1. er bare for besværligt.

Men nu er det jo kun en engangsbyg, så jeg tror ikke at det er det store problem bare at bygge med det nyeste og gå igang. Så kan det godt være at vi engang imellem render ind i at panelizer fucker menu_block, eller hvad har vi, men det opdager man så når man sætter det op. 1. ville ikke fange det medmindre vi har en voldsom stor test suite, og 2. ville man alligevel først finde det efter at man havde opdateret lav.

[kallehauge]

Jeg fik opdateret patchene som bliver applied til pReload og tidligere merged Gille's feature branch ind. Jeg lukker derfor dette issue :)