Homepage Wiki Forum Buy

GNUBLIN embedded GNU/Linux

Open source learning and training plattorm for embedded GNU / Linux
A projects from Hochschule Augsburg and embedded projects GmbH

Project homepage: http://www.gnublin.org
Wiki: http://wiki.gnublin.org
Aktuelle Zeit: Mi 22. Nov 2017, 09:07

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Sa 14. Apr 2012, 10:09 
Offline

Registriert: Sa 14. Apr 2012, 09:39
Beiträge: 1
Hi durch eine Diskussion auf Mircocontoller.net bin ich auf das denn wikiartikel

http://wiki.gnublin.org/index.php/Kerne ... stallieren

Aufmerksam gemacht wurden. Ich finde denn workflow der dort beschrieben ist extrem umständlich und wenig entwickler freundlich. Ich wollte in diesen Thread einfach mal ein paar vorschläge gießen wie man denn Workflow verbessen kann.

im schritt "Kernel holen von " steht unter anderen :
git checkout 093e9d2f7f730dee86d6734f7a66fc573bcd7027

ich fände es besser wenn dort steht :
git checkout -b gnublin 093e9d2f7f

vielleicht auch noch
git tag gnublin-start1

Dann würden die gnublin patchs auf einen eigenen Branch landen und wenn der lpclinux.com master bran ch weiter wandert sind die gnublin Anderungen nicht im weg denn neuen master auszuchecken. und mit denn tag hätten wir einen Namen für den punkt wo unser devel branch denn master verlässt.

Im teil "Patch downloaden " wird es richtig crude:
das erste ist relativ einfach downloaden, ja aber von wo kann man Hier nicht einfach ein link einbauen ?

die Empfhelung denn patch mit
patch -p1 < 001-mmc-card-detect.patch
zu applizieren, finde ich auch nicht so gut. Wir haben git auf den Rechner! also wenigsten
git apply 001-mmc-card-detect.patch

noch besser wäre es wenn die Entwickler der patch auf Ihren devel branch comitten und mit
git format-patch -s -o ../patchs gnublin-start1

vernünftige patchs erzeugen, wie alle anderen Linux Entwickler auch. Das erzeugen dieser patchs ist echt leicht, nur will ich das nicht machen, denn git nennt den als Author welcher denn patch commited, es sei denn man sagt git was anders aber das kann nicht nicht denn ich kenn den Autor nicht und es ist nicht meine Art sich als Autor für die Patchs auszugeben wenn ich es nicht bin.

Wenn die Format patchs exestieren, dann kann man ins Wiki schrieben das die patchs mit
git am -i ../patchs/00*
appliziert werden und die leute welche nach denn wiki vorgehen haben nicht ein haufen von "untracked Changes" in Ihren git repo welche eine hürde dastellen wenn anfänger erste Änderungen versuchen zu commiten.


Nach oben
 Profil  
 
BeitragVerfasst: So 15. Apr 2012, 13:53 
Offline
Moderator

Registriert: So 8. Apr 2012, 09:01
Beiträge: 108
Hi imon,

Danke für deine offene Kritik.

Zunächst einmal ist jeder eingeladen an unserem Wiki mitzuwirken. :D

Das Verwalten das Kernel und der Patches ist noch nicht optimal.
Ich stelle mir ein Kernel Team vor das neue Patches und Änderungen prüft und sie anschließend freigeben kann.
So das man immer einen stable (Produktiv) und einen unstable (Entwicklung) Kernel hat.

Das im Moment die volle Leistungsfähigkeit von Git nicht genutzt wird ist schaden, aber auch hier können wir uns noch verbessern.

Ich hoffe diese Antwort ist erst einmal ausreichend.

Gruß KubuntuFan

_________________
Lieber ein Pinguin der läuft, als ein Fenster, das hängt...


Nach oben
 Profil  
 
BeitragVerfasst: Do 3. Mai 2012, 22:46 
Offline

Registriert: Di 10. Apr 2012, 12:23
Beiträge: 35
Hallo imon,

ich kann mich Deiner Kritik nur anschliessen, das mit der Verwaltung des
Gnublin Kernels muss besser werden. Ich habe mal ein eigenes Git
Repository fuer den Gnublin Kern angelegt, das man mit folgendem
Kommando holen kann:

git clone git://elk.informatik.fh-augsburg.de/srv ... 2.6.33.git

Es hat zwei Branches, den "master" und den "gnublin" Branch. Nach dem Klonen wechselt man
in das Verzeichnis und schaltet auf "gnublin" um:

cd gnublin-linux-2.6.33
git checkout gnublin

Darin sind dann schon alle Patches enthalten, siehe "git log".
Tags gibt es darin noch nicht, aber das kann ja noch werden.

Es ist auch eine .config Datei drin, die allerdings vielleicht eine
individuelle Anpassung braucht. Um herauszufinden, wie sich zwei
.config Dateien (Eure und meine) unterscheiden, verwende ich gerne
"meld <Datei1> <Datei2>" oder "gvim -d <Datei1> <Datei2>".

Es gibt auch ein Web-Interface:

http://elk.informatik.fh-augsburg.de/cg ... ;a=summary

Ich versuche auch mal, eine Anleitung fuer einen moeglichen "Workflow" zu schreiben, der die
Erstellung von Patches mit git umfasst.

Auf Anregungen und Kritik freue ich mich. Eine Anregung haette ich schon: Vielleicht sollte man
das Gnublin Kernel Repository auf einen oeffentlichen Git Dienst legen, z.B. github oder gitorious,
damit die Sache nicht von einer klapprigen Kiste bei mir abhaengt.

Viele Gruesse,

Hubert


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 3 Beiträge ] 

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
cron
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de