CHANGE MERGE POLICY

[wwwutz]

Können wir die Policy zum mergen von pull-request überdenken ?

Momentane Policy: Wer einen PR macht ist für INSTALL verantwortlich

1. Ich erstelle PR
2. Du klickst [merge]
3. Ich kriege Mail und muss auf deinemuddah installieren
4. Irgendwas kommt dazwischen, die Mail scrollt raus
5. PR verschwindet in is:pr is:closed

Bislang ging das so halbwegs gut, holperte aber manchmal. Manuelles abgleichen findet Diskrepanzen, irgendwann stimmt wieder alles.

Das kann sich aber zu einem Problem entwickeln: Wenn man Pakete deinstalliert, meist mehrere in einem PR, Beispielsweise cdrtools. Da wurde smake disabled, die tools neu gebaut und der PR berinhaltet ein bee remove und ein bee update.

Jetzt wird gemerged, der PR verschwindet und in der mail steht: cdrtools und "Merged #xxx into master."

Also ab auf deinemuddah, bee update cdrtools und der remove smake wird vergessen.
Der nächste build/configure findet dann smake wieder und nutzt den. Und wieder eine Abhängigkeit drin, die man loswerden wollte.

Lösung:

Neue Policy: Wer einen PR macht, ist fur MERGE und INSTALL verantwortlich.

... und wer einen PR abnickt macht das durch Label. zB [merge] / siehe dieses Issue.

Vorteil: wer PR macht weiss was er tut und es bleibt aktuell in der Liste.

[donald]

Finde ich nicht so gut. Gegenvorschlag:

Ich sehe mir ja gelegentlich die "Unterlassungen" an:

# ( eventuell ) ssh deinemuddah
cd git/bee-files/
# ( eventuell ) git checkout master
git pull
scripts/check-installed 
# package in system but not in git: brasero-3.0.0-1.x86_64
# package in system but not in git: libfilezilla-0.13.0-0.x86_64
# package in system but not in git: memcached-1.4.15-0.x86_64
# package in system but not in git: mono-4.4.0.148-1.x86_64
# package in git but not in system: libfilezilla-0.13.0-1.x86_64 (libfilezilla.be0)
# package in git but not in system: memcached-1.4.15-1.x86_64 (memcached.be0)
# package in git but not in system: xfig-3.2.5b-1.x86_64 (xfig-3.2.5b-1.bee)

und mach es dann selber oder schreibe Meckermail oder beides. Ich kann anbieten, die Liste der Diffs jeden Morgen an diejenigen rauszusenden, die Erinnerungen brauchen. Wer dann seine PRs wiedererkennt kann es dann ja machen. Vermutlich könnte ich auch zuordnen, zu welchem PR das gehört und von wem der ist und nur den zuständigen nur mit seinem Kram anmailen.

Automatisches installieren nach merge wäre auch denkbar. Aber manche Installationen brauchen mehr als bee update, da muss man vielleicht einen Service restarten oder irgendwas.

[wwwutz]

seems to work now for all