<musicmatze>
Vor allem fördert es den git workflow. Also den richtigen. Mit patches und request-pull mails.
<musicmatze>
Dieses ganze "merge button klicken" skaliert halt irgendwann einfach nicht mehr
fendor has quit [Ping timeout: 272 seconds]
fendor has joined #nixos-de
<palo>
lol :D
<musicmatze>
war nicht als Witz gemeint :-/
<palo>
echt?
<musicmatze>
Ironie? :-)
<palo>
ne mail patches sind einfach unterirdisch
<palo>
deswegen mach ich ja auch kaum was im krebsco repo
<palo>
brauch da immer tv oder lassulus neben mir weil kein prozess definiert ist
<musicmatze>
was findest du denn so schlimm daran?
<musicmatze>
mit patchmails kann man wunderbar workflowen und wenns zu viel wird macht man request-pull
<palo>
am ende mach ich dann einfach nen pull-request in gogs und schick lassulus oder tv den link
<palo>
find ich ja nicht so knaller mit mail.
<musicmatze>
warum nicht?
<palo>
Ich empfinde mails als sinnvoll für announcments, aber sehr schlechte platform zum diskutieren
<musicmatze>
okay... bis jetzt hast du aber keinen konkreten Grund genannt ;-)
<palo>
spamfilter ?
<palo>
:D
<musicmatze>
In wiefern ist das ein Grund?
<MichaelRaskin>
Spamfilters fressen Emails wenn es gibt zu viele Emails. Es gibt viele Emails um Nixpkgs…
<musicmatze>
das ist dann aber eine Fehlkonfiguration/Fehlverhalten ... das hat nicht konkret was mit dem workflow an sich zu tun, oder? Ich hab keinen Spamfilter und es ist alles wunderbar... und "viele mails" ist auch nur ein Problem wenn der Mailreader langsam ist, oder?
<palo>
ich habe nichts gegen mail-patches, aber finde sieh sehr anstrengen gegenüber webguis, da muss ich nur einen knopf drücken, kann sachen kommentieren etc. und bei nem mail patch muss ich die patch file runterladen, das repo selber auschecken, mergen push, ... das mir alles zu anstrengne.
<musicmatze>
patchfile runterladen?
<palo>
Die zeit die ich mich mit einem patch beschäftigen muss, möchte ich so effektiv wie möglich nutzen.
<palo>
musicmatze: jo IMAP
<musicmatze>
wenn das als Anhang kommt muss das direkt rejected werden.
<musicmatze>
patches müssen inline sein
<musicmatze>
dann shortcut für reply und los gehts...
<MichaelRaskin>
Das ist nicht besser!
<musicmatze>
sehr viel schneller als Maus bewegen, warten bis der Browser geladen hat ...
<musicmatze>
pushen sowieso erst wenn man alle patches durch hat, also O(1)-Aufwand.
<palo>
lol das ja noch schlimmer dann muss ich den patch aus dem text rauskopieren und erstmal ne datei erstellen.
<musicmatze>
was?
<musicmatze>
Nein!
<musicmatze>
Einfach nach `git am` pipen und fertig
<palo>
same same
<musicmatze>
ich hab das Gefühl es liegt einfach nur am tooling ..
<palo>
klar wir reden ja auch über tooling
<palo>
ich will tooling das mir arbeit abnimmt
<musicmatze>
wenn ich ne patchmail bekomme schreibe ich "|git am" und fertig is.
<palo>
sowas gibts in thunderbird nicht
<musicmatze>
Wenn ich alle patches durch hab mach ich "Ctrl-Z" und "git push <argumete>" und feritg
<musicmatze>
aaaah ja... da kommen wir dem Problem auf den Grund.
<musicmatze>
gibts da kein Tooling für?
<palo>
keine ahnung,
<palo>
hab ich nie geschaut.
<musicmatze>
sekunde ich hab evtl was
<palo>
aber ganz ehrlich warum sollte ich mir so nen tooling drauf schaffen, um eine simplen arbeitsschritt einfach nur anders zu machen?
<musicmatze>
hmh okay der kernel guide hat auch keinen workflow wie man das mit thunderbird macht
<musicmatze>
mir gehts ja nicht darum dir vorzuschreiben wie du arbeiten sollst, nur darum dir zu zeigen dass es evtl Möglichkeiten gibt wie du schneller arbeiten kannst.
<musicmatze>
aber ohne ein entsprechendes tooling für thunderbird wird das natürlich weniger einfach :-)
<MichaelRaskin>
musicmatze: wenn du willst Emails, du kann alle Notifications von Github in Email bekommen
<musicmatze>
ja ich weiß, aber da sind dann keine diffs dabei normalerweiße
<MichaelRaskin>
Schriebt dich ein eins-Linie Script
<musicmatze>
oder nicht "normalerweise" sondern einfach nur "da sind keine diffs dabei"
<MichaelRaskin>
Es gibt ein URL für PR…
<musicmatze>
ja ich weiß
<MichaelRaskin>
« | git am » oder « | gh-git-am », kleiner Unterschied
<musicmatze>
aber alles nur fixes für das Symptom. Am besten wäre einfach kein github verwenden, sondern sowas wie sourcehut. Dann können die Leute, die ein Web-UI haben wollen mit der website arbeiten und der Rest kann mail machen... alle sind happy.
<palo>
musicmatze: hehe, ja
<palo>
aber ich bekomme eigentlich nie mail-patches
<musicmatze>
ich seh ja ein dass nicht jeder einen mail-based workflow haben will... deswegen ist das sourcehut projekt ja so geil :-)
<musicmatze>
palo: ich leider auch nicht.
<musicmatze>
:-(
<palo>
stimmt, das was ich von sourcehut gelesen habe war ziemlich überzeugend
<palo>
:{
<musicmatze>
ich glaube^tm dass ich bei nixpkgs sehr viel mehr contributen würde wenn a) ein gescheiter Workflow vorhanden wäre und b) ich meinen mailclient verwenden könnte zum contributen
<palo>
ich hab nach dem nixcon vortrag von dem mozilla typen gesucht, der hat vor ein paar jahren erzählt wie nixos abgehoben ist seit die github nutzen.
<palo>
aber youtube vergisst schnell
<musicmatze>
jo.
<lassulus>
mozilla? garbas?
<palo>
ja glaub schon der franzose
<musicmatze>
Ist ja nicht so dass man nen gescheiten workflow nicht auch mit github abbilden könnte...
<musicmatze>
da könnte ich mich noch damit abfinden dann
<palo>
der hat irgendwann mal vor jahren ein vortrag gehalten warum nixos noch nicht das geilste os ist
<palo>
musicmatze: jo das stimmt,
<palo>
der prozess könnte ein wenig nicer sein.
<lassulus>
naja, was wäre denn nicer?
<musicmatze>
ich würde sogar release-maintaining machen wenn es eben einen gescheiten workflow gäbe... aber "jeder pushed auf master wie er will" ist halt beschissen (sorry für language, aber so isses nunmal)
<palo>
lassulus: zum beispiel eine einfache entscheidungsmatrix ob ich (als pull-request steller) einen backport pull-request stellen sollte oder nicht
<musicmatze>
1. Niemand pushed auf master, nur hydra
<musicmatze>
2. es gibt (wie beim kernel) subsystem-maintainer die sich um verschiedene topics kümmern
<musicmatze>
3. es gibt pro "topic" einen branch auf den Leute PRs stellen
<musicmatze>
4. die werden alle paar Tage (wöchentlich?) gemerged, aber eben nur wenn sie "grün" sind
<musicmatze>
"topics" könnte man sogar mit mehreren repos abbilden
<musicmatze>
5. es gibt maintainer für "topics", evtl auch mehrere
<lassulus>
aber das würde doch alles nur langsamer machen? und die PRs die ein explizites topic haben sind auch kein problem sondern die, die viele dinge berühren wie glibc updates, systemd updates
<musicmatze>
6. bei größeren topics (z.b. infra-änderungen) gibt es einen gescheiten RFC-Review prozess
<palo>
btw ich finde *DAS* sind genau die dinge die auf einer NixCon besprochen und entschieden werden sollen.
<MichaelRaskin>
Wir haben sogar mehr «weit-weg» Effekten wie Linux Kernel
<musicmatze>
lassulus: im gegenteil! Das würde alles schneller machen und vor allem Kompetenzen ordentlich zuordnen
<lassulus>
naja, es klingt mehr debian artig in meinen ohren
<lassulus>
macht halt sachen langsamer und man hat mehr kompetenzen die verteilt werden müssen
<lassulus>
dafür ist alles strukturierter
<palo>
aber struktur bekommst du auch anders rein, dazu musst du nicht alles festlegen.
<lassulus>
aber ich sehe nicht, dass wir ein organisations problem haben, sondern eher, dass wir viel zu viel zeug machen für die wenigen maintainer die wir haben
<palo>
ich bin ja ein grosser fan von handregeln
<lassulus>
und unser maintainer zu output ratio ist schon ziemlich gut
<musicmatze>
wieso langsamer? Paketupdates können ja dann täglich gemerged werden zum Beispiel,... neue Pakete alle 3 Tage... größere Änderungen und refactorings wenn sie fertig sind...
<palo>
jo wir haben zu wenig maintainer
<musicmatze>
Zentraler Punkt ist eben: topics werden gemerged wenn sie bauen und zwar dann automatisch und nicht weil jemand meint auf master pushen zu müssen
<lassulus>
na aber der testaufwand ein topic zu mergen ist sehr viel höher als ein PR
<musicmatze>
aber es gibt weniger PRs!
<musicmatze>
Dadurch sinkt der build-pressure!
<musicmatze>
wenn ein topic branch "package-updates" nicht baut, wird er nicht gemerged
<lassulus>
na wieso gibts weniger PRs? es gibt ja trotzdem einzelne PRs wegen nginx, glibc, systemd usw.
<musicmatze>
nicht "diese 150 package updates müssen gebaut werden, einzeln, und wenn sie dann alle von jemand gemerged werden bricht master weil sie nicht zusammenspielen"
<lassulus>
na es gibt ja staging, aber macht man halt nicht gerne, weil das alles komplizierter macht
<lassulus>
und dein vorschlag wären ja mehrer stagings für verschiedene topics
<musicmatze>
im Endeffekt ja. Dann kann man die 50 python-package updates die jeden Tag rein kommen alle gesammelt einmal bauen und wenn die durchbauen dann macht das CI automatisch einen merge.
<lassulus>
na aber unsere testabdeckung ist ja nicht hoch genug, dass man automatisch mergen könnte
<lassulus>
zumindest bei den meisten paketen
<lassulus>
da muss quasi noch fast immer jemand manuell draufschauen
<musicmatze>
das ist weniger Aufwand für alle, weil: reviewen muss man trotzdem, dann wird aber alles applied und gepushed, dann wird alles gesammelt einmal gebaut als wenn es gemerged werden würde (also mit auto-merge branch) und wenn das tut wird master fast-forwardded
<lassulus>
na ich review aber lieber ein package bump als ein staging branch mit 20 commits
<musicmatze>
siehe bors/homu ...
<musicmatze>
natürlich, machst du dann ja auch
<MichaelRaskin>
Kernel hat mehr «subsystem-maintainer» als Nixpkgs hat aktive «committer»
<musicmatze>
du guckst dir aktuell 20 package-bumps an. Machst du dann auch noch. Nur dass du dann diese 20 patches nicht einzeln "Merge" klickst nachdem das CI drüber gelaufen ist, sondern alle auf einen branch zusammen. Und wenn dann was failed kann das CI dir direkt sagen welcher bricht, du kannst den reverten/whatever und wieder das CI anschmeissen
<musicmatze>
-> CI aufwand reduziert sich auf O(log n)
<musicmatze>
siehe homu oder bors (bors-ng) wie gesagt
<musicmatze>
MichaelRaskin: das Argument hör ich dauernd. Das zieht nicht. Kernel hat auch mehr subsysteme als wir topics hätten. Ausserdem sagt ja niemand das nicht eine Person bei 2 oder 3 topics helfen könnte..
<musicmatze>
topics wären (IMO): staging (größere Änderungen), package-bumps (sha+version update only), lib/infra und dann die einzelnen Sprachen
<lassulus>
aber das was bors macht haben wir doch schon mit hydra/
<MichaelRaskin>
Wir haben nicht genug committer Leute. Aber manche Leute sag wir haben zu viel committer Leuter zu trauen
<lassulus>
nur ist unser master deren staging
<lassulus>
und deren master unser nixpkgs-unstable
<lassulus>
oder nixos-unstable
<palo>
lassulus: das knüpft ungefähr an meinen punkt mit dem backporting an.
<palo>
Es ist noch nicht ganz klar wo pkgs "kaputt" sein dürfen, und wie stable verifiziert wird, und wie es in den stable branch kommt
<palo>
=> das ist für mich der "workflow" den ich vermisse
<lassulus>
naja, stable sollte halt keine grossen änderungen reinbringen, meistens nur security fixes, aber neue pakete können theoretisch keinen schaden verursachen
<lassulus>
und api von nixos sollte sich halt nicht ändern
<lassulus>
also was in der configuration.nix steht
<lassulus>
sonst kann auch alles gebackportet werden, aber dafür könnte das tooling auf jedenfall besser sein
<lassulus>
cool wäre so ne checkbox bei github
<lassulus>
jemand sollte vl mal das PR template bearbeiten
<palo>
cool wäre, wenn das irgendwo beschrieben ist, damit ich das verlinken kann wenn ich mit leuten in pull-requests diskutiere, und wir nicht über gefühle und meinungen, sondern über abmachungen reden. Und das du meine Pull-requests nicht grossartig anders behandelst als jemand anderes der pull-requests merged
<musicmatze>
lassulus: "theoretisch keinen schaden"... ja. Aber stable sollte auch stable sein... also auch keine libreoffice minor release bumps IMHO
<lassulus>
na wenns security ist
<musicmatze>
palo: ! genau.
<musicmatze>
lassulus: klar, security fixes ja
<musicmatze>
aber "dieses neue feature haben wir in 'x.(y+1).z' released" ... nein!
<palo>
lassulus: ach ja ich meine das nicht als ranting sondern als konstruktiven input.
<musicmatze>
stable sollte IMHO nur security fixes bekommen
<musicmatze>
und es ist auch fragwürdig ob gcc 8.1.0 -> gcc 8.2.0 ein "security fix" ist...
<palo>
ich schreibe gerne diese dokue auch wenn ich dieses docbook aus der hölle dafür "lernen" muss.
<musicmatze>
ich hatte sogar mal angefangen einen RFC zu formulieren wie man das alles machen könnte mit dem Workflow.
<MichaelRaskin>
musicmatze: das fordert _viel_ mehr Leute zu machen
<musicmatze>
Aber aus verzweiflung und "die community is so festgefahren dass sich das sowieso nie ändert" aufgegeben
<lassulus>
palo: na dann mach mal nen RFC zu backports, aber imho sind nicht zu viele backports das problem sondern eher zu wenige
<MichaelRaskin>
Soll man «fixes» und «features» in Firefox trennen?