benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/doc/devel/meeting_summary/2011-04-13.txt
Ichthyostega 82ca6ef7ea add subsections, further tidying of the transcript 
Signed-off-by: Ichthyostega <prg@ichthyostega.de>
2011-05-15 03:58:44 +02:00

642 lines
36 KiB
Text
Raw Blame History

2011-04-13 Lumiera Developers Meeting
=====================================
:Author: Ichthyostega
:Date: 2011-4-14
April 13, 2011 on #lumiera 20:00 - 23:47 UTC +
__Participants__
* cehteh
* ichthyo
* fsiddi
* skangas
_Protocol written by Ichthyo_
.organisational
- IRC meeting summaries will be moved into the main Git tree, below 'doc/devel'
- mostly shortened and tidied IRC logs, plus summary of conclusions \+ decisions
- ``winter quarterly coding news'': this time just paste _Ichthyo's_ contribution into the website
- the next ``coding news'' probably in May?
New Website Page Layout
-----------------------
_Francesco Siddi_ has augmented his Layout proposal and already built up two page templtes to
cover most of the layout needs of the Lumiera website and documentation resources. However,
some points with the code generated by Asciidoc turned out to be problematic.
In a link:http://permalink.gmane.org/gmane.comp.video.lumiera.general/2330[message preceeding the meeting],
today _ichthyo_ highlighted some general concerns which might need further discussion and maybe
a decision.
utilising horizontal space
~~~~~~~~~~~~~~~~~~~~~~~~~~
Resolution of displays has been largely increased, especially on desktop computers, with
a tendency towards ``widescreen'' aspect ratio. While, on the other hand, text content
is still mostly vertically oriented. This leads to the question how to make use
of this additional space in horizontal direction, while still also supporting
the not-so large displays.
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-13 22:55:35] <ichthyo> so my idea was just to let us discuss how we could use that additional space, when its available
[2011-04-13 22:56:08] <ichthyo> I mean, just lets discuss open ended -- what possibilities do we see for that?
[2011-04-13 22:55:42] <cehteh> if the screen is wide enough they should make 'some' use of it .. maybe just using biggier fonts
[2011-04-13 22:56:46] <ichthyo> using 2 columns would be one possibility, but that is tough and demading to get to work properly
[2011-04-13 22:57:02] <fsiddi> there are basically 2 ways
[2011-04-13 22:57:18] <fsiddi> 1 is to use liquid layout
[2011-04-13 22:57:49] <ichthyo> liquit layout means, that the content area just expands, right?
[2011-04-13 22:57:56] <fsiddi> like wikipedia yes
[2011-04-13 22:58:14] <cehteh> http://slashdot.org/ scales reasonable well with different screen sizes
[2011-04-13 22:58:52] <ichthyo> wikipedia is also an interesting example, because they use lots of floating block content
[2011-04-13 22:58:57] <ichthyo> tables, images, additional infos
[2011-04-13 22:59:20] <fsiddi> yes the mediawiki software is very powerful
[2011-04-13 22:59:38] <fsiddi> another *very* well done documentation is http://developer.apple.com/library/mac/navigation/
[2011-04-13 22:59:52] <fsiddi> (from a design point of view)
[2011-04-13 22:59:54] <fsiddi> :)
[2011-04-13 23:00:01] * cehteh likes (or rather demands) that browser zoom (ctrl-+) works well on the lumiera page
---------------------
using a »liquid layout«?
^^^^^^^^^^^^^^^^^^^^^^^^
.-- liquid ⟺ not liquid --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-13 23:05:14] <fsiddi> ok, so apart from that, the discussion is liquid vs not liquid
[2011-04-13 23:05:31] <ichthyo> and also what possibilities there are
[2011-04-13 23:05:43] <fsiddi> ichthyo: what do you mean?
[2011-04-13 23:05:56] <ichthyo> e.g. just expanding the content area
[2011-04-13 23:06:04] <ichthyo> or also using a script to increase the font
[2011-04-13 23:06:13] <ichthyo> or using floating blocks in the sidebar
[2011-04-13 23:06:38] <ichthyo> (asciidoc has several elements which could float into the sidebar)
[2011-04-13 23:07:09] <ichthyo> and if we know that the site layout supports that, then we'll likely make use of that
when writing documentation
[2011-04-13 23:07:10] <cehteh> when you have a page with a lot (many sideful) of content then a side menu
(also footer/header) must be floating or can be left out
[2011-04-13 23:07:31] <cehteh> there is no point in having a side-menu only visible for 3% of the content
[2011-04-13 23:07:45] <ichthyo> ah yes, thats another point, i.e. how to treat the vertical scrolling
[2011-04-13 23:08:07] <ichthyo> it is possible e.g. to have the scrollbars on the content area
[2011-04-13 23:08:08] <cehteh> imo we need 2 classes of pages .. small ones and huge ones
[2011-04-13 23:08:22] <cehteh> scrollbars inside are inconvinient
[2011-04-13 23:08:18] <fsiddi> http://wiki.blender.org/index.php/Doc:Manual
[2011-04-13 23:08:37] <fsiddi> it has scrolling sidebar
[2011-04-13 23:09:08] <cehteh> but with js again
[2011-04-13 23:09:19] <cehteh> i seen that as CSS only solution i think
[2011-04-13 23:09:37] <cehteh> otherwise yes, thats an option ..
[2011-04-13 23:10:02] <ichthyo> cehteh: yes, you can get that just with CSS
[2011-04-13 23:10:23] <fsiddi> actually you need js to trigger the class to make it floating
[2011-04-13 23:10:27] <cehteh> back to my statement, do you agree that we need this 2 kinds of classes?
[2011-04-13 23:10:36] <fsiddi> i don't think so
[2011-04-13 23:10:42] * ichthyo neither
[2011-04-13 23:10:56] <fsiddi> cehteh, i think it will overcomplicate the backend
[2011-04-13 23:11:03] <ichthyo> because I guess 90% of the documentation pages will get into the "large, much content" category
[2011-04-13 23:11:05] <cehteh> really?
[2011-04-13 23:11:12] <cehteh> yes
[2011-04-13 23:11:19] <ichthyo> so we *do* have two templates already
[2011-04-13 23:11:22] <fsiddi> i think it's better to keep it flexible
[2011-04-13 23:11:26] <cehteh> and does this documentation need a sidebar?
[2011-04-13 23:11:26] <fsiddi> yes
[2011-04-13 23:11:35] <fsiddi> we use 2 templates
[2011-04-13 23:12:16] <ichthyo> one is the "top level", with the horizontal menu
[2011-04-13 23:12:24] <cehteh> this boils down to one for the general pages and one for documentation
[2011-04-13 23:12:25] <ichthyo> and the second one is the documentation template, right
[2011-04-13 23:12:44] <ichthyo> while those "general" pages are a handful
[2011-04-13 23:12:45] <fsiddi> yes
[2011-04-13 23:12:55] <cehteh> yes
[2011-04-13 23:12:56] <ichthyo> while the documentation pages will go into the hundred and more
[2011-04-13 23:14:08] <ichthyo> so I draw the conclusion, that the documentation pages are optimised for much content
[2011-04-13 23:14:19] <fsiddi> yes
[2011-04-13 23:13:30] <cehteh> ok .. settled
...
[2011-04-13 23:13:54] <fsiddi> i propose to keep the layout not liquid also in that pages
[2011-04-13 23:14:35] <fsiddi> if you prefer i can make them larger
[2011-04-13 23:14:49] <fsiddi> but for the moment i'd like to keep the same width
[2011-04-13 23:14:48] <ichthyo> what are the problems you see with a liquid layout?
[2011-04-13 23:15:08] <fsiddi> mostly a readability issue
[2011-04-13 23:15:29] <fsiddi> if a page is too large, it's unreadable
[2011-04-13 23:15:39] <ichthyo> well, I second that statement
[2011-04-13 23:15:53] <ichthyo> if a page goes over a certain amount of characters per line
[2011-04-13 23:16:10] <fsiddi> ichthyo: that's what i mean
[2011-04-13 23:15:53] <cehteh> can you scale the font on huge screens with css?
[2011-04-13 23:16:10] <ichthyo> cehteh: not in css2
[2011-04-13 23:16:15] <cehteh> ok
[2011-04-13 23:16:24] <ichthyo> java script would work
[2011-04-13 23:16:42] <cehteh> i opt for a reasonable big max size as already proposed
[2011-04-13 23:16:47] <ichthyo> well, but if we manage to limit those number of characters per line
[2011-04-13 23:16:55] <fsiddi> i can implement that
[2011-04-13 23:16:58] <cehteh> but dont make this too small
[2011-04-13 23:17:05] <ichthyo> then liquid layout might be more reasonable
[2011-04-13 23:17:33] <fsiddi> ok
[2011-04-13 23:17:36] <ichthyo> I am not 100% sure, but I recall having seen a layout, just based on CSS,
which achieved exactly that,
[2011-04-13 23:18:03] <ichthyo> i.e. limiting the maximum width, but allowing some liquid expansion below that
[2011-04-13 23:17:55] <fsiddi> i'm not sure that just CSS is possible
[2011-04-13 23:18:20] <ichthyo> If I recall right, it used several nested containers
---------------------
Regarding the handling of *vertical scrolling*, the conclusion was to stick to the defaults
as much as possible. Especially, scrollbars should rather be left to the browser, not added
to the content area. We might consider to fix the navigation block relative to the browser window
though, if that is doable with too much complications. Moreover, this navigation block, holding
the (vertical) tree-like menu, should be made sufficiently large in vertical direction, but might
show scrollbars in case of overflow.
Navigation menu
^^^^^^^^^^^^^^^
we still need to find a way how to make the new +JQuery+ based navigation menu open and highlight
the _current_ page automatically. _fsiddi_ and _ichthyo_ will work out a solution in a separate meeting
on IRC next week.
Colour scheme
^^^^^^^^^^^^^
.gray shades or using a colour scheme?
[caption="☉Transcript☉ "]
----------------------------
[2011-04-13 23:28:23] <ichthyo> I'd like to bring up the question regarding color
[2011-04-13 23:28:36] <ichthyo> and I'll ask especially you, fsiddi
[2011-04-13 23:28:44] <ichthyo> you know, colours are a matter of taste
[2011-04-13 23:29:15] <ichthyo> thus I'd say, as you did the general layout, you have an important say in that
[2011-04-13 23:28:59] <fsiddi> ah yes colors
[2011-04-13 23:29:11] <fsiddi> i try to keep it neutral
[2011-04-13 23:29:25] <ichthyo> you you would popose to stick to just gray shades?
[2011-04-13 23:29:34] <ichthyo> what is with the links?
[2011-04-13 23:29:39] <ichthyo> currently they are slate blue
[2011-04-13 23:29:45] <cehteh> thats ok for me
[2011-04-13 23:29:47] <fsiddi> i still have to work in them
[2011-04-13 23:29:55] <fsiddi> yes I did not color the links
[2011-04-13 23:30:13] <ichthyo> generally speaking, we should always try to limit the number of colours in a layout, IMHO
[2011-04-13 23:30:18] <cehteh> i dont think we shall use any fancy colors and maybe/if required then we add colors as markup
[2011-04-13 23:30:29] <ichthyo> but we could think of one or two "leading colours"
[2011-04-13 23:30:35] <fsiddi> i want to
[2011-04-13 23:30:43] <fsiddi> but did not put them in the css yet
[2011-04-13 23:30:53] <fsiddi> i'll do that soon
[2011-04-13 23:31:38] <fsiddi> so this is also for review soon :)
[2011-04-13 23:32:07] <cehteh> but colors are fixable and we dont have an official lumiera color (do we need one?)
[2011-04-13 23:32:22] <ichthyo> well... we could think about that
[2011-04-13 23:32:19] <fsiddi> i'll try to make up one
[2011-04-13 23:32:28] <cehteh> dunno :)
[2011-04-13 23:32:37] <ichthyo> according to my experience
[2011-04-13 23:32:47] <ichthyo> it helps a lot when you set a clear style guide early
[2011-04-13 23:33:41] <ichthyo> ok
---------------------
Webserver upgrade and the »reference distribution«
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.-- Server upgrade discussion --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 00:25:59] <cehteh> ok next point:
[2011-04-14 00:26:07] <cehteh> - Webserver update to squeeze (new asciidoc, keep ichthyos hand
[2011-04-14 00:26:07] <cehteh> installed trac)
[2011-04-14 00:26:07] <cehteh> - Do we want to bump our 'reference' distribution to squeeze too?
[2011-04-14 00:26:19] <cehteh> ... webserver .. as soon as possible, but no urge
[2011-04-14 00:26:34] <cehteh> reference .. i just wanted to bring this up, imo there is no need
[2011-04-14 00:26:46] <ichthyo> personally, I will upgrade soon, next 2 weeks hopefully
[2011-04-14 00:27:13] <cehteh> yes i am on squeeze and even with backports already
[2011-04-14 00:27:29] <cehteh> so its prolly even better to have the reference on the devel server a bit behind
[2011-04-14 00:27:28] <ichthyo> I would propose to bump the "reference" the moment when we actually upgrade the
devserver + builddrone
[2011-04-14 00:27:51] <cehteh> well the devserver will be upgraded when we bump the reference
[2011-04-14 00:28:10] <cehteh> builddrone will be upgraded sometime next but thats not related to the reference
[2011-04-14 00:28:12] <ichthyo> but for now there is no problem also supporting lenny, but with the note that we'll
drop that support once we run into serious problems
[2011-04-14 00:28:22] <cehteh> yes
[2011-04-14 00:28:30] <cehteh> iirc that would be the reason to bump it
[2011-04-14 00:29:05] <ichthyo> well, IMHO, when we both are on squeeze, then effectively the reference is bumped :-P
[2011-04-14 00:29:40] <cehteh> nah .. the reference is about what builddrone reports to us too
[2011-04-14 00:29:15] <cehteh> i'd stay with lenny as long as we can so .. or maybe if the next stable gets froozen
then we can go to squeeze
[2011-04-14 00:29:51] <cehteh> and what skangas and other gui coders need also
[2011-04-14 00:30:15] <cehteh> i expect that gavl and gui dependencies will be a cause for a bump
[2011-04-14 00:32:50] <cehteh> summarize: bump it someday .. as need arises?
[2011-04-14 00:33:26] <cehteh> or even better. .. no decision yet .. we'll see when its time
---------------------
Website licensing and legal questions
-------------------------------------
.-- Discussion regarding the Web content license --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-13 23:54:14] <skangas> For the record, I agree with what ichthyo said in his first e-mail.
[2011-04-13 23:54:55] <skangas> That "dual licensing under GPL and something comparable" is the best choice.
[2011-04-13 23:55:03] <skangas> Probably CC-BY-SA.
[2011-04-13 23:55:10] <ichthyo> my thinking too
[2011-04-13 23:56:05] <ichthyo> that is, for the web content, and the documentation
[2011-04-13 23:57:00] <ichthyo> cehteh: would that be ok for you too?
[2011-04-13 23:59:29] <cehteh> [23:58] <cehteh> mhm?
[2011-04-13 23:59:31] <cehteh> .. any answers beyond that?
[2011-04-13 23:59:55] <ichthyo> seems we had a short split or so
[2011-04-14 00:00:07] <ichthyo> skangas and myself just talked about licenses
[2011-04-14 00:00:09] <cehteh> i got completely disconnected
[2011-04-14 00:00:41] <ichthyo> [23:57] <ichthyo> cehteh: would that be ok for you too?
[2011-04-14 00:01:29] <cehteh> CC-BY-SA means?
[2011-04-14 00:01:47] <ichthyo> Creative commons 3.0 attribution share alike
[2011-04-14 00:02:39] <ichthyo> cehteh: CC-BY-SA is considered "equivalent in spirit" with the GPL
[2011-04-14 00:01:50] <cehteh> copyleft .. attribution .. share-alike?
[2011-04-14 00:02:25] <cehteh> this dualcicensing would be ok for me .. but a note
[2011-04-14 00:02:48] <cehteh> how about putting the documentation under a non-commercial license?
[2011-04-14 00:03:03] <ichthyo> that would throw us out of debian main
[2011-04-14 00:03:13] <cehteh> that is no one can use the lumiera docs for release printed docs and make profit from it
[2011-04-14 00:03:14] <ichthyo> debian considers such a license "non-free"
[2011-04-14 00:03:49] <ichthyo> well, I am not so much concerened about that
[2011-04-14 00:04:03] <ichthyo> because, the docs still remain available
[2011-04-14 00:04:16] <ichthyo> and if someone really goes through all the pain of creating printed stuff
[2011-04-14 00:04:31] <ichthyo> and does it well, then he deserves to make profit from that, IMHO
[2011-04-14 00:04:25] <cehteh> but i dislike the idea that someone makes profit with no work and no giving back
[2011-04-14 00:04:48] <ichthyo> I am sure that *does require* substantial amount of work
[2011-04-14 00:05:03] <ichthyo> if that person wants any chance to sell something
[2011-04-14 00:05:23] <ichthyo> just print a crappy web dump won't make anyone sell much copies, IMHO
[2011-04-14 00:04:59] <cehteh> then its ok for me
[2011-04-14 00:05:33] <cehteh> but i've seen publisher which just took the free docs do *little* editing and formating
and sell it for a lot money
[2011-04-14 00:05:53] <ichthyo> and, will he make substantial turnover with that?
[2011-04-14 00:06:15] <skangas> Yeah, I think the point here is that poor quality high prices do not sell.
[2011-04-14 00:06:16] <cehteh> btw GPL only would prevent that too .. the publisher has to release his tex,
m$ -word or whatever sources then
[2011-04-14 00:06:36] <cehteh> does -sa prevent that too?
[2011-04-14 00:06:36] <ichthyo> making modifications available under the same conditions, yes.
[2011-04-14 00:06:46] <cehteh> besides, he needs to point out *within* that printed docs, that the license is free
[2011-04-14 00:07:44] <cehteh> but possibly some people get upset when they contribute a lot and someone else makes the profit
[2011-04-14 00:07:44] <skangas> I do not see how it would damage our goals.
[2011-04-14 00:08:06] <skangas> It would be more in the spirit of not allowing the free-loaders easy access.
[2011-04-14 00:08:20] <cehteh> well as i saied, that was just a note/idea .. i am fine with the dual-licensing
[2011-04-14 00:08:39] <ichthyo> well... here is the standard argument: if someone creates additional value on top of what
we provide, i.e. make a quality print, process orders, ship the copies,
then fine for me, if he/she makes turnover with that
[2011-04-14 00:09:01] <cehteh> yes
[2011-04-14 00:09:08] <skangas> I do not care much for that argument.
[2011-04-14 00:09:16] <skangas> For me, it is more about getting into Debian main.
[2011-04-14 00:09:59] <skangas> And the fact that I do not care if some marginal publisher makes a bit of money off
of the Lumiera documentation.
[2011-04-14 00:09:10] <ichthyo> the online docs will always be more acurate, more up-to-date
[2011-04-14 00:09:13] <skangas> Not even if a big one does it; that would only mean more attention to the project.
[2011-04-14 00:09:32] <cehteh> i would like this if we even can point to him and announce that as the offical lumiera book
[2011-04-14 00:10:10] <cehteh> but there are so much publishers which just try to make money without being really involved
[2011-04-14 00:10:31] <skangas> cehteh, Yes, even publishers which only print Wikipedia articles.
[2011-04-14 00:10:46] <ichthyo> and btw, what is more realistic, given that lumiera becomes a real, professional app,
then maybe someone will provide lectures and training
and that is much more apt to create a good turnover and benefit
[2011-04-14 00:11:14] <cehteh> ichthyo: lectures and training involves work .. thats ok
[2011-04-14 00:11:42] <cehteh> anyeays ... dual license gpl and cc-by-sa
[2011-04-14 00:11:46] <cehteh> ok for me
[2011-04-14 00:11:55] <ichthyo> fine, seems case is settled
[2011-04-14 00:12:04] <cehteh> eh which gpl ? gpl2+ .. same as lumiera
[2011-04-14 00:12:08] <ichthyo> yes
[2011-04-14 00:12:15] <ichthyo> thats important
[2011-04-14 00:12:32] <cehteh> and we may bump lumiera to gplv3 when we release it (and we know all its dependencies)
[2011-04-14 00:12:39] <ichthyo> so you can move code / doc in both directions without problems
[2011-04-14 00:12:42] <skangas> GPLv2+ not GPLv2, right?
[2011-04-14 00:12:48] <cehteh> skangas: yes
[2011-04-14 00:12:51] <skangas> OK. Great.
[2011-04-14 00:13:14] <cehteh> we only use gplv2 now because we dont want to rule out to use external libs which may be v2 only
[2011-04-14 00:13:25] <ichthyo> and a rather firm promise to bump it to gpl3 when this works and we're approaching a release
[2011-04-14 00:13:40] <cehteh> or gplv4 :P
[2011-04-14 00:13:47] <ichthyo> yay!
[2011-04-14 00:13:51] <cehteh> btw duke nukem is delayed
[2011-04-14 00:14:02] <ichthyo> ouch, I'm surprised
---------------------
Conclusion
~~~~~~~~~~
* Website content and documentation will be dual-licensed GPL 2+ and CC-3.0-BY-SA
* _Ichthyo_ will clarify the actual licenses used on the ``license'' page
* moreover he'll care to add an _Impressum_ -- as required by german law
Trac spam
---------
After an increasing amount of Spam tickets in the link:http://issues.lumiera.org[Trac],
_Ichthyo_ installed the Trac antispam plugin (which required an upgrade to Trac 0.12,
actually repackaging a current version into an pre-release debian package, as the
official debian package isn't on the required level). After a bit of training,
the Bayesian filter successfully blocked any further spam tickets.
The remaining problem are spam user accounts though. To deal with that problem, _Ichthyo_
designed a custom SQL query based on some obvious heuristics, which seems to pinpoint
all spurious accounts. We'll try to execute that SQL for some time manually, and --
in case it behaves sane -- automate that cleanup as a cronjob in some months.
_Cehteh_ points out that this new policy should at least be anounced on the Mailinglist.
Recurring Topic: Design process entries
---------------------------------------
Discussion of open link:/documentation/devel/rfc.html[design process] drafts.
Since some time, no further discussion happened regarding the currently _pending_
RfC entries. Agreement is that we should again return to the former routine and
revisit the relevant design process entries in each developer meeting.
.-- the Application Install proposal --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 00:48:25] <cehteh> http://lumiera.org/documentation/devel/rfc_pending/ApplicationInstall.html
[2011-04-14 00:48:40] <ichthyo> maybe only pick out some interestin ones or some which are quick to decide
[2011-04-14 00:49:06] <cehteh> well i want to go over all pending .. then we can put notes there "boring for the next meeting"
[2011-04-14 00:49:42] <cehteh> for example this application install .. is boring .. you did a lot work, imo you can finalize it
[2011-04-14 00:50:04] <cehteh> (i dint read it in detail now)
[2011-04-14 00:50:25] <cehteh> maybe we want another state "accepted" ..
[2011-04-14 00:50:44] <cehteh> that is the interesting things which we know we will not drop but which are not finalized yet
[2011-04-14 00:54:29] <cehteh> the application install came first... we need it, you did it well .. it could be 'finalized' or
rather that would be some 'acceepted' candidate ..
[2011-04-14 00:53:25] <ichthyo> I think, the existing states are enough
[2011-04-14 00:53:44] <ichthyo> either really discuss something and then decide, or just leave it in draft
[2011-04-14 00:54:05] <ichthyo> lets just postpone the application install and leave it in draft!
---------------------
Delectus Shot Evaluator
~~~~~~~~~~~~~~~~~~~~~~~
Agreement to _park_ it until someone else comes up to advance this topic further.
Clip Cataloging System
~~~~~~~~~~~~~~~~~~~~~~
similarily to _park_ until someone cares....
DesignParamAutomation
~~~~~~~~~~~~~~~~~~~~~
Keep _pending_ -- _ichthyo_ will expand on that
Lumiera Forward Iterator
~~~~~~~~~~~~~~~~~~~~~~~~
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 00:58:39] <cehteh> pending
[2011-04-14 00:58:48] <ichthyo> well, this is entirely an C++ topic
[2011-04-14 00:58:58] <ichthyo> I for my part vote for accepting it now
[2011-04-14 00:59:11] <ichthyo> I use this concept now since almost a year and it worked out well
[2011-04-14 00:59:25] <cehteh> yeah i think its more a trac ticket than a rfc
[2011-04-14 00:59:55] <ichthyo> well, it *is* something which would need discussion if there where more than one C++ developer
[2011-04-14 01:00:14] <cehteh> but if it works for you, i put it on 'maybe finalize' .. means i read through it and finalize it
when i have no objections
[2011-04-14 01:00:24] <ichthyo> yes, agreed
---------------------
Design the Render Nodes interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:01:04] <cehteh> thats definitely pending .. needs discussion
[2011-04-14 01:01:33] <ichthyo> yes
[2011-04-14 01:01:54] <cehteh> maybe we park it to get rid of it for now since this is months ahead?
[2011-04-14 01:02:28] <ichthyo> we could even drop it, but parking is ok
[2011-04-14 01:02:44] <ichthyo> that RfC basically sais: PLING PLING PLING, we need to discuss that
[2011-04-14 01:02:53] <cehteh> well, I wont drop it, its a nice place to document the intention about the design
[2011-04-14 01:03:10] <ichthyo> ok, so lets park it
---------------------
Developer Documentation Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--> see link:http://issues.lumiera.org/ticket/763[Ticket #763]
.-- Discussion of details --
[caption="☉Transcript☉ "]
---------------------
[2011-04-14 01:03:23] <cehteh> i check that, bring it up to date and finalize it?
[2011-04-14 01:03:36] <ichthyo> i have some objections against that, see my comment
[2011-04-14 01:04:00] <ichthyo> I think, the current structure is better than what that RfC proposes
[2011-04-14 01:04:05] <cehteh> yes .. thats what i meant with bring it up to date
[2011-04-14 01:04:39] <cehteh> i can keep it pending .. and then we can finalize it when you agree
[2011-04-14 01:04:49] <ichthyo> ok, so you will update it?
[2011-04-14 01:05:32] <cehteh> yes .. maybe not for next time but i put it on todo
---------------------
Engine Interface Overview
~~~~~~~~~~~~~~~~~~~~~~~~~
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:05:50] <cehteh> pending .. there is lot to do?
[2011-04-14 01:06:02] <ichthyo> sort of
[2011-04-14 01:06:10] <ichthyo> basically that is a high level outline
[2011-04-14 01:06:19] <cehteh> this is a rather big thing maybe we drop it in favor of smaller rfc's
[2011-04-14 01:06:23] <ichthyo> it doesn't contain details
[2011-04-14 01:06:27] <cehteh> but for now leave it pending
[2011-04-14 01:06:45] <ichthyo> at the time I wrote that, you said it looks okish for you
[2011-04-14 01:06:58] <cehteh> yes .. quite possible
[2011-04-14 01:06:55] <ichthyo> this one would be really important to discuss soon
[2011-04-14 01:07:11] <cehteh> i need to catch up first ..duh
[2011-04-14 01:07:23] <ichthyo> note: it doesnt go into details, just sets a very high level outline how the overall process works
[2011-04-14 01:07:39] <ichthyo> I think *that one* is really needed to be accepted/ reworked soon
[2011-04-14 01:07:43] <cehteh> yes .. lets talk next meeting about that (or some time else)
[2011-04-14 01:07:57] <ichthyo> ok
[2011-04-14 01:08:05] <cehteh> so pending for now
---------------------
Feature Bundle
~~~~~~~~~~~~~~
Expected to be very important in the far future, but we don't have the
resources to work on that right now, so _park_ it.
Marble Mode
~~~~~~~~~~~
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:08:51] <ichthyo> this is also a high level one
[2011-04-14 01:08:57] <ichthyo> I am much in favour of that
[2011-04-14 01:09:09] <ichthyo> but its really kind of conceptual
[2011-04-14 01:09:20] <cehteh> me too ... but its too early to finalize it or?
[2011-04-14 01:09:52] <cehteh> that would be a 'accepted' candidate too :)
[2011-04-14 01:09:55] <ichthyo> well, I would accept it...
[2011-04-14 01:10:23] <ichthyo> but I wrote it so you (and others) also think that over
[2011-04-14 01:10:27] <cehteh> i think 'final' should somethnig which wont be changed or discussed anymore unless we see problems
[2011-04-14 01:10:40] <cehteh> thats why i am thinking we may need an 'accepted' state
[2011-04-14 01:11:07] <cehteh> and this marble mode certainly needs a lot more discussion and work to be final
[2011-04-14 01:11:51] <ichthyo> mhm, but that RfC just proposes to go for that direction, not how to do all the details
[2011-04-14 01:11:58] <cehteh> or we just finalize it as 'concept' we want no matter how we implement it finally
[2011-04-14 01:12:05] <cehteh> yes ok then
[2011-04-14 01:12:10] <ichthyo> yes, ok then
---------------------
Normalized Device Coordinates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
still very rough, but basically agreed. +
While it needs more work, it's a bit out of focus right now, so _park it.
Proc High Level Model and Placement concept
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That's rather final by now. This link:http://lumiera.org/documentation/devel/rfc/ProcHighLevelModel.html[proposal]
meanwhile documents the existing design; it's up to date and didn't see significant
additions since almost two years. Generally agreed upon, so it's _final_ now.
The same holds true for the
link:http://lumiera.org/documentation/devel/rfc/ProcPlacementMetaphor.html[Placement] proposal
Render Optimizer, Resource Management and Profiling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:17:19] <cehteh> park
[2011-04-14 01:17:32] <ichthyo> accept for me
[2011-04-14 01:17:56] <ichthyo> that is so much our common understanding meanwhile
[2011-04-14 01:18:02] <ichthyo> so, maybe just polish a bit
[2011-04-14 01:18:18] <cehteh> yes park because it needs some polishing before final
[2011-04-14 01:18:24] <ichthyo> (remove the "pro and con") and then we could accept it right away
[2011-04-14 01:18:28] <cehteh> i can put a note that its basically accepted
[2011-04-14 01:18:38] <cehteh> parking isnt neccessary bad :P
[2011-04-14 01:18:46] <ichthyo> ResourceManagement
[2011-04-14 01:18:49] <cehteh> (well again that would be a 'accept' candidate)
[2011-04-14 01:18:53] <ichthyo> needs some more work
[2011-04-14 01:19:01] <cehteh> that are 2 things .. yes
[2011-04-14 01:19:10] <cehteh> profiling and budgeting ..
[2011-04-14 01:19:21] <cehteh> i think i will implement them and then see how it works
[2011-04-14 01:19:40] <cehteh> (unless someone else shows better alternatives)
[2011-04-14 01:19:47] <ichthyo> if you change that and e.g. remove the code sample and make it really short and high level,
then we could accept it as a concept; but the implementation details need certainly more work
[2011-04-14 01:20:17] <cehteh> hey that code is the code i lost with the hdd crash .. i am happy that i put it there
[2011-04-14 01:20:27] <cehteh> yes it was a very rough idea
[2011-04-14 01:20:37] <cehteh> and not on schedule to implemented soon
[2011-04-14 01:20:45] <cehteh> i just sketched some code down
[2011-04-14 01:21:04] <cehteh> so pending or park?
[2011-04-14 01:21:08] <ichthyo> as said, would it be ok for you to remove that sketch and just leave it on that level of the
first sentences, because then we could accept it right away
[2011-04-14 01:21:45] <cehteh> ok pending for now .. i dont want to work on this currently .. other things are more important
[2011-04-14 01:21:47] <ichthyo> we both pretty much agree that we *want* some kind of budget managing and resource usage
---------------------
Roadmap
~~~~~~~
The link:http://lumiera.org/documentation/devel/rfc/Roadmap-first.html[Roadmap document]
was erroneously not marked as final; +
Seemingly it was decided upon in 2009 already ...
Stream Type System
~~~~~~~~~~~~~~~~~~
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:24:06] <ichthyo> very important for me -- my vote is for accept
[2011-04-14 01:24:16] <cehteh> we had some discussion how to maintain metadata ..
[2011-04-14 01:24:40] <cehteh> i vote for accept too but this metadata (which may decribe the type) needs work
[2011-04-14 01:24:49] <ichthyo> well, this one is really a heavyweight conceptual RfC
[2011-04-14 01:25:00] <ichthyo> it is not about *how* to maintain metadata
[2011-04-14 01:25:05] <cehteh> yes
[2011-04-14 01:25:08] <cehteh> so accept
[2011-04-14 01:25:18] <ichthyo> but it really contains far reaching decisions
[2011-04-14 01:25:27] <ichthyo> and terminology
[2011-04-14 01:25:51] <ichthyo> please see, I would be glad if there was some discussion about that
[2011-04-14 01:26:36] <ichthyo> but well, at the moment I am the only one thinking into more details of this whole topic
[2011-04-14 01:26:24] <cehteh> shall i leave it pending just to nag us?
[2011-04-14 01:26:50] <ichthyo> yes, leave it pending
[2011-04-14 01:27:10] <cehteh> i was thinking too about this .. but not consistently ...
[2011-04-14 01:27:24] <ichthyo> as said, I vote for accept, but I would really ask you to think it over
[2011-04-14 01:27:38] <cehteh> i think that needs some time to settle to the right point [tm]
[2011-04-14 01:27:43] <ichthyo> I'm not right away implementing it, but the implementation is rather trivial
[2011-04-14 01:27:48] <ichthyo> so leave it pending
---------------------
Threads Signals and important management tasks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 01:28:33] <cehteh> we need to work together to implement this on the main .. but generally i think this can be
accepted with some refinements
[2011-04-14 01:28:14] <ichthyo> some time ago, we had a short discussion about that
[2011-04-14 01:28:55] <ichthyo> The bottom line was: I am in favour of that, but I rather would like not to build it
directly into that main thread, but have a dedicated thread for it
and at that time you said, that would not be a fundamental problem
[2011-04-14 01:29:30] <cehteh> i wonder why not the main thread .. but its ok for me
[2011-04-14 01:29:53] <ichthyo> my argument is keeping the code simple and dedicated to one purpose
[2011-04-14 01:30:05] <cehteh> the main thread is a kindof 'service thread' right?
[2011-04-14 01:30:09] <ichthyo> the main thread's purpose is to wake up and shut down the system
[2011-04-14 01:30:25] <ichthyo> and I'd prefer to let him do only that and nothing else
[2011-04-14 01:30:26] <cehteh> i dont want the cinelerra fail .. opening a thread for every purpose
[2011-04-14 01:30:58] <ichthyo> generally yes, but for the more fine grained things we have the scheduler
[2011-04-14 01:31:08] <cehteh> well ok .. from my pov the main thread is more than just that but a general sheepheard
[2011-04-14 01:31:39] <cehteh> not only starting and shutdown but also control the direction
[2011-04-14 01:32:08] <cehteh> but really this isnt much a difference, if you want an extra thread then let it be so
[2011-04-14 01:32:46] <ichthyo> I see the code complexity. It would just look okish for me if we split it into these two
[2011-04-14 01:33:26] <cehteh> there is not much complexity, the main thread waits currently ..
[2011-04-14 01:34:02] <cehteh> and it can get woken by signals or condvar (convars return when a signal arrives)
[2011-04-14 01:34:29] <cehteh> actually having an extra thread wont make the code simpler because then the main thread
needs to be rigged to ignore the signals. All other threads are created by us and can
implicitly be rigged in this way
[2011-04-14 01:34:53] <ichthyo> main thread handles that already, if I recall correct
[2011-04-14 01:35:05] <ichthyo> because it loops on the condition and goes to sleep again
[2011-04-14 01:35:29] <cehteh> yes but you didnt add any sigmask handling / signal blocking right?
[2011-04-14 01:35:44] <ichthyo> ah I see, thats still todo
[2011-04-14 01:35:51] <cehteh> anyways .. i accept it .. implementation pending
[2011-04-14 01:37:38] <cehteh> signal handling becomes a 'subsystem' then ... :)
[2011-04-14 01:37:46] <ichthyo> yes, thats what I mean
---------------------
Session structure -- Timelines, Sequences, Output
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This link:http://lumiera.org/documentation/devel/rfc_pending/TimelineSequenceOutput.html[proposal]
can be considered definitively final. Key point is: we have multiple timelines and a sequence can be used
in multiple timelines. We pretty much agree on that, thus it counts as _finalised_ now.
Use Cases
~~~~~~~~~
This is an heavyweight proposal regarding the high-level design and general handling of the
Application. This would be really a topic to be discussed in conjection with the ``Workflow''
-- the idea was to have a working group focussed these topics entirely, but there is no one
in charge of that right now. Thus _park_ it for the time being.
Version Number Scheme
~~~~~~~~~~~~~~~~~~~~~
The proposal for link:http://lumiera.org/documentation/devel/rfc_pending/VersionNumberScheme.html[Version numbering]
is _accepted_ -- it's considered close to common practice and _ichthyo_ relied on it for the debian
package already.
'''''''''''''
Next meeting
------------
The next meeting will be as usual, at Wednesday May 11, 20:00 UTC
Reference in a new issue View git blame Copy permalink