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 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.
☉Transcript☉ — Discussion of details --
[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 pageusing a »liquid layout«?
☉Transcript☉ — liquid ⟺ not liquid --
[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 containersRegarding 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
☉Transcript☉ gray shades or using a colour scheme?
[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> okWebserver upgrade and the »reference distribution«
☉Transcript☉ — Server upgrade discussion --
[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 timeWebsite licensing and legal questions
☉Transcript☉ — Discussion regarding the Web content license --
[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 surprisedConclusion
-
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 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 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.
☉Transcript☉ — the Application Install proposal --
[2011-04-14 00:48:25] <cehteh> link:{ldoc}/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
[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, agreedDesign the Render Nodes interface
☉Transcript☉ — Discussion of details --
[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 itDeveloper Documentation Structure
-→ see Ticket #763
☉Transcript☉ — Discussion of details --
[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 todoEngine Interface Overview
☉Transcript☉ — Discussion of details --
[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 nowFeature 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
☉Transcript☉ — Discussion of details --
[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 thenNormalized 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 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 Placement proposal
Render Optimizer, Resource Management and Profiling
☉Transcript☉ — Discussion of details --
[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 usageRoadmap
The Roadmap document
was erroneously not marked as final;
Seemingly it was decided upon in 2009 already …
Stream Type System
[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 pendingThreads Signals and important management tasks
☉Transcript☉ — Discussion of details --
[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 meanSession structure — Timelines, Sequences, Output
This 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 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