add the September dev meeting summary (by cehteh)
This commit is contained in:
parent
f41d3221c8
commit
7327b1ffb0
3 changed files with 152 additions and 33 deletions
130
doc/devel/meeting_summary/2012-09-12.txt
Normal file
130
doc/devel/meeting_summary/2012-09-12.txt
Normal file
|
|
@ -0,0 +1,130 @@
|
|||
2012-09-12 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Christian Thaeter <ct@pipapo.org>
|
||||
: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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
************************
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue