Lumiera Developers Meeting ========================== :Author: Stefan Kangas :Date: 2011-03-09 March 9, 2011 on +#lumiera+ + ^20:00 GMT - 23:30 GMT^ //Menu: label 2011-03-09 __Participants__ * Christian Thaeter (cehteh) * Francesco Siddi (fsiddi) * Hermann Voßeler (ichthyo) * Odin Hørthe Omdal (Velmont) * Raffaella Traniello (raffa) * Stefan Kangas (skangas) The New Website --------------- The new website is finally online. How do we proceed with the graphical layout? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21:37 the template code is not ready yet 21:37 and there are some incorrect uses of tags in the current one 21:37 so i will go on coding a static html layout 21:38 then will submit it to your critique and then we can make a template out of it ... 21:50 fsiddi: I liked the way you provided a slightly larger content area for the tutorial part image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"] image:{img}/meetings/2011-03-09-mockup_dev_2.jpg["Website Proposal Mockup number 2", width=128, link="{img}/meetings/2011-03-09-mockup_dev_2.jpg"] Discussion about the IFrame ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The only serious alternative to IFrames seems to be SSI, since we want to keep generating pages with asciidoc, and not have to regenerate the entire website just because one page changed. Conclusion was that we will stick with IFrames for now and change later when/if that becomes a problem. Old stuff in the repository ~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is a folder /attic on the website. This information is supposed to be merged with the rest of the website, and then deleted from its current location. This work is on-going and considered a "background task". IRC Logs -------- A discussion was brought up about how to handle IRC logs. For privacy reasons we do not want to save them routinely in public locations. If we put them on the web they will most probably be kept by Google until the sun burns out. *robots.txt* might be respected by Google or not. Surely some other search engines will not respect it. Private logs or other logs not publically available are fine though. 22:40 well ... IRC should *not* be for persistent documentation .. we shall force/educate ourself to document things (and decisions) properly, irc should be volatile ... 22:41 in the past, sometimes we had very "contentful" dicussions 22:41 in that cases we just saved a transcript ... 22:44 so personally I prefer to make transcripts of the *really* contentful discussions and put them in the public documentation 22:44 "transcript" means cleaned up irc log 22:44 yes 22:45 so for meetings we should prolly do that 22:47 not further edited but just leave all join/parts/noise and silly comments out 22:47 (and also rants and stuff) 22:48 only conclusions and most important arguments shall stay 22:48 maybe reorder it a bit as it happens that we talk about 2 things at the same time 22:48 but also not too much work on it 22:49 and more importantly: document decisions and proposals in a more offical way: that is 'rfc' 22:49 Agreed. It is more important to preserve information in an accessible way for the future than focusing on mundane details like join/part/order/ranting etc. 22:50 This means I personally always prefer shorter summaries of a discussion to IRC logs, given that they do not leave anything important out. VoIP discussions over Mumble? ----------------------------- There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux. It was decided that while the idea is nice, it will not be used for developer meetings. We might use it for developer discussions outside meetings if we feel the need though. This will probably be more common as the number of developers increase. Also, the point was brought up that GNU Emacs has really nice support for several people sharing the same session. Everyone gets their own point, and with some hacks it is even possible to color them differently. This needs to be done on an untrusted remote server though -- Emacs can do anything and it is thus highly insecure. Version numbering ----------------- Hermann has written an rfc for version numbers. 23:19 so in my words: we will have a usuall major.minor.patch for releases 23:20 and major+1~develtag for devel snapshots 23:20 where develtag is a timestamp 23:20 and we *could* make a stream of development versions 23:21 YYYYMMDD should suffice 23:21 or maybe just monotonic increading from 1 23:21 well... optional suffix+ number 23:21 for the rare cases that you roll two releases a day ... 23:20 and the third idea of my proposal: *not* use major.minor.patch before 1.0 23:24 i.e. in the whole alpha... beta range 23:24 we just do 0.01 0.02 ... 0.99 23:25 Does it go without saying that minor versions can go on above 1.9.0 to 1.10.0 etc? 23:25 yes, I didn't mention that, but thats important 23:26 its not nice, and usually you get a major first, but it can happen 23:27 so i'd say, we have discussed it now, we could comment on it and then revisit it next time (and maybe decide on the proposal then) 23:27 Do we want a stable version and a development version? 23:28 e.g. 1.0 is stable and 1.1 is unstable 23:28 I am thinking about the scheme that wine and linux is using. 23:28 i think linux won a lot with abadon this odd/even practice 23:28 regarding stable versions 23:28 personally, I don't like that idea 23:29 cehteh: I did not know they had abandoned it. 23:29 skangas: linux dont use that anymore 23:29 since 2.6 years ago 23:29 because they tend to rot 23:29 ichthyo: The stable versions? 23:29 you just make a release and done .. everything after that is for the next version 23:29 yes 23:29 the only thing to discuss is how you count there 23:30 also, it is more in line with the "extreme programming" style 23:30 i.e. don't do too disruptive changes 23:30 if you want 'pre' or 'rc' 23:30 but rather refactor often 23:30 OK. 23:31 there is onre concern though 23:31 there *needs* to be some stability then 23:31 releases get only bugfixes and *maybe* you can declare some release as LTS ... but for lumiera i would think really hard about that and likely deny that 23:31 because people are working with the software 23:31 but we want to have that with our compatibility scheme 23:31 (our interface system should provide backward compatibility) 23:31 yes 23:31 but anyway, it *might* turn out that we fail with that promise 23:32 and then we'll have to reconsider a "stable" line 23:32 so maintaining some LTS while having another development branch will suck developer resources 23:32 yes 23:32 so I'd really try hard to avoid that 23:33 well a stable line yes ... that is 'stable' until the next stable release is there .. and then 'maintained' as in adding important bugfixes for some (but not excessive) time 23:33 we need to care for a stable for sure 23:33 indeed, but it shouldnt digress too much from the active development 23:33 but we dont want some really old release to get permanent updates and care because we declared it as LTS 23:33 ichthyo: Is your RFC open to editing/additions? 23:34 yes 23:34 please go ahead, just add comments etc. 23:34 use the rfc.sh comment function :) 23:34 I was just thiking about writing this down in some way, that we specifically do not want this. 23:23 also do we want 'rc' releases? 23:23 or do we just declare certain devel snapshots as rc (i like the later) 23:23 yes, thats what I'd prefer too 23:24 devel snapshots should be automatic buildable by builddrone 23:25 I would like to make builddrone an automatic staging system 23:25 add some 'rules' there .. 23:26 if build and testsuite succeeds and test-install works and latests commit doesnt contain WIP: then stage a devel snapshot 23:27 (eventually or maybe we might even put tests/bugs there which prevent certain staging actions, finally all integration and complete releases could be automatized) 23:26 remember in test.sh i reserved the 90-99* area for 'bugs' 23:26 we may put some blocking tests there which prevent staging Next meeting ------------ The next meeting will be at Wednesday April 13 20:00 UTC.