Image 0.2.3

[Christian Fenzl]

Prof.Mobilux


Hi Michael,
ist es schwierig, LB direkt als 0.2.3 als Image anzubieten?
Lg, Christian

[Prof.Mobilux]

Hallo Christian,

prinzipiell nicht - ich müsste mich wieder etwas "reindenken", da ich lange kein Image mehr gebaut habe. Ich wollte mich aber mit dem 0.2'er eigentlich gar nicht mehr beschäftigen. Der Herbst/Winter steht vor der Tür und mein größtes Ziel ist es diesen Herbst den 0.3'er endlich fertig zu stellen. Vielleicht noch nicht der ganz große Wurf mit neuem Templatesystem etc,., aber mit den vielen kleinen Verbesserungs-Wünschen, die aufgelaufen sind, der neuen Plugin-Schnittstelle und vor allem den LoxBerry-Libraries. Danach will ich dann eigentlich am Statistik-Plugin weitermachen.

Im Moment - bei den letzten Sonnenstrahlen - hat aber der Garten/Freizeit Priorität :-)

[Christian Fenzl]

Mir geht's genauso.
Für 0.3 wäre ein Task Plan cool, dann könnten wir die Arbeit aufteilen.

[Prof.Mobilux]

Gute Idee! Vielleicht kann man dazu die GIT-Funktionen verwenden. Ich hatte schon einmal einen Milestone angelegt und alles, was in 0.3.0 realisiert werden soll, entsprechend markiert: https://github.com/mschlenstedt/Loxberry/milestone/1

Kannst Du mal probieren, ob Du selbst einen "Assignee" bei einem issue zuweisen kannst oder ob nur ich das kann, z. B. hier wärst Du das ja: https://github.com/mschlenstedt/Loxberry/issues/173

Ansonsten könnte man auch die Funktion "Projects" nutzen und verschiedene Projekte anlegen, z. B.:

- Basissystem/Image
- Install-Assistenten
- Libraries
- Templates
- Plugin-Schnittstelle

Jeder könnte dann ein projekt bearbeiten.

[Christian Fenzl]

So wie ich das lese (https://help.github.com/articles/ass...-github-users/), geht das nur, wenn ich collaborator bin?
Ich hab dich mal als collaborator beim squeezelite eingeladen, kannst probieren, was du damit darfst.

Das mit den Projects find ich nicht so schlecht, da kann man schnell per D&D was zusammenstellen, was zusammengehört. Bei jedem Issue steht dann auch dabei, in welchem Project das ist.
Hab ich grad mal beim squeezelite ausprobiert.

[Prof.Mobilux]

Ah, cool - als Collaborator kann man die Issues editieren. Auch Labels etc. pp. Ich habe Dich auch mal eingeladen :-)

Testweise habe ich ein Projekt "LoxBerry Library" angelegt. Da müsstest Du jetzt Issues zuordnen können (hoffe ich). Leider kann man ein Projekt nicht einer person zuordnen, sodass man die Issues nochmal manuell jeweils dem Projekt und dem Bearbeiter zuordnen muss.

[Christian Fenzl]

Yesss, funzt. Hab mir mal den LoxBerry::System issue assigned.

[svethi]

Hi Ihr Beiden ... wenn Ihr da fertig seid mit spielen :-) und ich das ganze verstanden habe, dann können wir uns ja laaaangsam auf die Entwickler-Saison vorbereiten. Werde mir das auch mal ansehen. Vllt verstehe ich das dann besser :-)

Gruß Sven

[Christian Fenzl]

Sehr interessanter Artikel über's Organisieren eines Projekts mit GitHub.

http://www.ianbicking.org/blog/2014/03/use-github-issues-to-organize-a-project.html

[Prof.Mobilux]

Guter Artikel. Ich habe gestern auch noch ein bisschen mit Projekten herumgespielt. Damit kann man sich auch ganz gut organisieren.

Ich habe jetzt den svethi auch mal als Collaborator eingeladen Als Collaborator kann man - wenn ich es richtig verstanden habe - auch direkt ins Repository pushen. Man braucht dann anscheinend nicht mehr den Umweg über Fork und Pull Request zu gehen.

Ich schlage mal folgende Regeln vor (Kommentare willkommen ):

Milestones / Versionen:

1. Jeder "Issue" bekommt einen Label: "Bug", "Enhancement" oder "Question". Damit ist erst einmal grob kategorisiert um was es sich handelt.
2. Die Issues mit "Bug" oder "Enhancement" werden immer einem Milestone zugeordnet.
3. Es gibt einen Milestone für die nächste Entwicklerversion (jetzt: 0.3.0) und die nächste Stable Version (jetzt: 0.4.0)
4. Es gibt einen Milestone für zukünftige Versionen mit Namen: "Blue Sky". Da kommt alles rein was noch nicht in die nächste Version kommen wird, "aber irgendwann später einmal" realisiert werden könnte. Wenn 0.4.0 draussen ist kann man alle diese Dinge durchschauen und dann gegebenenfalls auf den nächsten offiziellen Milestone (z. B. 0.5.0) schieben. Damit geht es aber nicht verloren.
5. Für jede Entwicklerversion gibt es eine Roadmap, was dort realisiert werden soll (siehe nächstes Posting)
6. Für jeden Punkt in der Roadmap erstellen wir ein Projekt zur Organisation und zum Überblick. Die Issues werden dann den Projekten zugeordnet.
7. Jeder, der ein "Issue" bearbeiten will, der setzt sich als "Assignee" ein. Damit sieht man auch sofort, was schon bearbeitet wird.
8. Wenn die Entwicklerversion geschlossen wird (Abstimmung/Diskussion aller Collaborators), kommen nur noch Bugfixes in die Stable Version, keine neuen Features mehr.

Organisation:

1. Das LoxBerry Kernteam wird als Collaborator eingeladen, aktuell habe ich Christian Fenzl , svethi und Wörsty eingeladen. Das waren die, die an der aktuellen Version mitgearbeitet haben. Alle anderen müssen den Umweg über Fork -> Pull Request gehen, wobei neue Colaborators jederzeit hinzugefügt werden können.
2. Allgemeine Diskussionen hier im Forum, die Issues werden nur zur Aufgabenverwaltung verwendet.

Anmerkungen?

[Prof.Mobilux]

Roadmap 0.3.0:

1. Bugfixes: https://github.com/mschlenstedt/Loxb...%20label%3Abug
2. LoxBerry Libraries
3. Plugin-Schnittstelle V2.0 (z. B.: Automatischer Reboot, PHP anstelle Perl)
4. Image-Upgrade auf Debian Stretch
5. Verbesserungen Basis-System (z. B. ReadOnly, Autom. Sicherheitsupdates)
6. Verbesserungen LoxBerry Konfiguration (z. B. mehr Konfigurationsmöglichkeiten)

Roadmap 0.5.0

1. Umbau Templatesystem auf HTML::Template
2. Multilanguage analog Plugins Christian Fenzl

[Christian Fenzl]

• Allgemeine Diskussionen hier im Forum, die Issues werden nur zur Aufgabenverwaltung verwendet.

Anmerkungen?

Ich hätte Issue-bezogene Diskussionen schon im Issue gemacht (Bezug), und am Schluss den Issue-Startthread entsprechend dem Ergebnis editiert (oder einen neuen Issue dafür geöffnet und den alten geschlossen). Sonst verliert man den Faden.

Code für das alte Template-System und Multilanguage ist teilweise jetzt schon in LoxBerry::Web (http://www.loxwiki.eu/display/LOXBER...Berry%3A%3AWeb).

Außer bei den LoxBerry-Libraries hab ich noch keinen Überblick, wie ich wo helfen kann. Das ergibt sich hoffentlich noch, wenn die einzelnen Roadmap-Punkte weiter aufgebrochen werden. (hab aber auch noch nie den ganzen Code angeschaut). Wird spannend!