diff --git a/doc/devel/meeting_summary/2012-09-12.txt b/doc/devel/meeting_summary/2012-09-12.txt new file mode 100644 index 000000000..4211cad3a --- /dev/null +++ b/doc/devel/meeting_summary/2012-09-12.txt @@ -0,0 +1,130 @@ +2012-09-12 Lumiera Developers Meeting +===================================== +:Author: Christian Thaeter +:Date: 2012-09-12 + +Sep 12, 2012 on #lumiera 20:00 - 23:40 UTC + + +__Participants__ + + * cehteh + * ichthyo + * mfisher31 + + +_Summary written by cehteh_ + + + +RFCs +---- + +It was not clear what state +http://lumiera.org/documentation/devel/rfc.html[RFCs] have in our +documentation structure. The question was if they should, after +becoming finalized integrated into some other document or stay first +class and be referenced from other documents. + +_Ichthyo_ points out that RFCs and doxygen comments alone aren't +sufficient and that there is the need for summarizing technical +documentation pages. There is agreement that we want to avoid multiple +redundant point for one and the same thing. When things evolve and are +implemented they are documented elsewhere, thus multiple places for +the same thing but at different states come up. + +Conclusion +~~~~~~~~~~ +So we define the following procedure: + + * RFC's are first class citizens, _cehteh_ already made some relevant + changes to the RFC system to provide static paths (the states are + now symlinks to a pool) + * If some more detailed design or implementation documentation arises + then it should link back to the relevant RFC's + * We add links to the RFC's themselves to link to any further + Documentation describing details thereof + * _cehteh_ will write an RFC about this Documentation workflow itself + + + +Upgrade to Wheezy/GTK-3 +----------------------- + +*Debian 7* (wheezy) is in the freeze, we considered in the previous +meeting to bump our _reference platform_ to wheezy and by that switch +over to GTK-3. + +_mfisher31_ did some work, fixing some bugs gcc4.7 pointed out and +compile Lumiera with GTK-3. There are some issues remaining: + +. There is some library loading glitch, after building Lumiera won't + start but on the next boot it works fine. +. It is not clear what effort is actually necessary to switch to GTK-3 +. Theming is completely different in GTK-3, only using cairo rendering, + Lumiera with GTK-3 has only the default theme right now. +. The video player widget is broken +. There is no libgdlmm3 debian package in wheezy. + +Nevertheless we agree on the following... + +Roadmap +~~~~~~~ + +- The devel server will be upgraded to wheezy +- Builddrone v2 will be deployed there (see below) +- The master branch will stay with GTK-2 and made compilable on wheezy + (apply the gcc4.7 fixes) and then be frozen. +- We will provide a custom gdlmm3 package as we did before +- Work progresses on GTK-3 and we merge that back to the master + branch when it is in par with what the GTK-2 looks alike already (no + regressions) + + + +Workflow between the Master and the Documentation repository +------------------------------------------------------------ + +There was some confusion how the master and the documentation +repository relate to each other. + +We agreed on merging back and forth between in a bidirectional way, +but doing this lazy on demand. + +(_cehteh_ will document this in a RFC) + + + +Builddrone v2 +------------- + +A complete rewrite of Builddrone (a continuous integration system) is +now (almost) finished and will be deployed on our build server within +the next days. It has numerous improvements over the old one. More +information and documentation will appear at +http://builddrone.pipapo.org/ soon. Stay tuned. + +Thanks to Lenny for helping with the documentation and Simon for the +Logo. + + + +Trac +---- + +Trac is broken somehow, resetting passwords doesn't work anymore, +don't loose your cookies or you are lost. Manually resetting the +password by an admin works though. We could not figure out whats +wrong, will see next time what to do and fix it. + + + +Git Commit Message Format +------------------------- + +To ease automatic processing (builddrone, quaterly news, +changelogs,..) we agreed and finalized a +link:{rfc}/GitCommitMessageFormat.html[RFC GitCommitMessageFormat] +defining some formalism about commit messages. + + + diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 06b15df36..74fee8b4a 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -12,8 +12,25 @@ Anyone interested in Lumiera development is also encouraged to read mailing list archives and other documentation. +12 Sep 2012 +----------- + +Topics +~~~~~~ + * RFCs + * Upgrade to Wheezy/GTK-3 + * Master and the Documentation repository + * Builddrone v2 + * Trac problems + * Git Commit Message Format + +Summary +^^^^^^^ + * link:2012-09-12.html[Summary (by cehteh)] + + ************************ -During Summer 2011 again the regular monthly meethings +During 2012 again the regular monthly meethings were mostly informal detail discussions plus some organisational planning. Not much to account for. ************************ diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index 3446ff87d..1d8de328b 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -46,10 +46,10 @@ only knows about these. .Header The Header is free form text explaining the purpose of the commit in a few -words. It may start with one uppercased keyword and a colon if appobiate directly +words. It may start with one uppercased keyword and a colon if appropriate directly followed by some (optional, defined elsewhere) metadata. This Keywords are -optional but recommended since automatic processing acts upon them. Normal commits -need these keywords and are just free form text. +optional but recommended since automatic processing acts upon them. +Normal commits don't need these keywords and are just free form text. To be exact, here is a regex matching valid Headers: @@ -72,7 +72,7 @@ Legal headers are for example: leading commits are WIP: 'FIX:':: - Bugfix. The Text should explain what error got fixed. A referenence to + Bugfix. The Text should explain what error got fixed. A reference to a bug number is not optional and not needed. 'RFC:':: @@ -141,34 +141,6 @@ in a short form. Think that anyone else reading only the commit message should understand whats going on. -Tasks -~~~~~ -// List what needs to be done to implement this Proposal: -// * first step ([green]#✔ done#) -// * second step [,yellow]#WIP# - - -Discussion -~~~~~~~~~~ - -Pros -^^^^ -// add a fact list/enumeration which make this suitable: -// * foo -// * bar ... - - - -Cons -^^^^ -// fact list of the known/considered bad implications: - - - -Alternatives -^^^^^^^^^^^^ -//alternatives: explain alternatives and tell why they are not viable: - Rationale