Release Meeting: 12 Dec 2016

Details

1. Urgent Task review

No new urgent tasks

2. Development Discussion

  • Wrap-up of tasks for 2.1.3.
  • 2.1.3 plans - Beta start around 20 Dec, after mod_expires times out. (Reduced from 11 days on 8 Dec)
  • General discussion of backlog features for 2.2.0.
  • Discussion of Configure UI deficiencies especially related to Extension installer
  • Feature freeze for 2.2.0, April 15, 2017
  • Somewhat deep discussion of possible Mapper / Login / Auth redesign.

3. Next release

Patch release 2.1.3

  • Release from: Release02x01
  • Beta start: 20 Dec 2016
  • Release target: Jan 2017

Feature release 2.2.0

  • Feature Freeze: 17 Apr 2017
  • Release from: master
  • Beta start: 1 Jun 2017
  • Release target: 1 Jul 2017

Next meeting - - Monday 09 Jan 2017 1300Z — ReleaseMeeting02x02_20170109

Happy Holidays everyone. This was the last meeting for 2016. Meetings will start back up on Monday Jan 9th 2017.

IRC Log

08:00:40 AM gac410 Hello everyone.
08:00:57 AM MichaelDaum Hi there.
08:02:21 AM gac410 how about with you MichaelDaum ... catching up with the year end work. I saw the commits ... yay
08:03:43 AM gac410 anyway ... lets wrap up 2.1.3 first if that's okay
08:03:53 AM MichaelDaum I am fine. lots of work to finish before end of year.
08:04:02 AM MichaelDaum yes lets go ahead
08:04:20 AM gac410 those last few fixes. On the caching of ajax, You actually removed the feature?
08:05:08 AM gac410 gac410 has to doctor the task summary lines to be more descriptive or less in some cases) for the release notes.
08:05:34 AM MichaelDaum yes. it was not worth it.
08:05:59 AM MichaelDaum rarely used if at all & not working correctly anyway.
08:06:33 AM gac410 Okay, So Item14251, I'll change task to "Remove non-functioning ajax dialog cache"
08:06:48 AM MichaelDaum it now fetches the dialog afresh from the backend...which is recommended in 99.99% of all cases anyway
08:07:04 AM MichaelDaum ah ok. much better wording.
08:07:42 AM gac410 For everyone ... that would be helpful in general. when you write a task - or fix a task, make the summary have reasonably correct grammar and actually describe what is being fixed.
08:08:03 AM gac410 Except for security tasks - those go the other way ... vague is good wink
08:08:52 AM gac410 So I think then with these last commits, I'm ready to build 2.1.3 and get it installed on Foswiki.org. and announce a beta
08:09:26 AM gac410 Did you have anything else left to go Michael?
08:09:50 AM vrurg Hi
08:09:57 AM MichaelDaum gac410, checking ...
08:10:45 AM MichaelDaum gac410, no, only 2.2 stuff
08:10:50 AM gac410 Okay great!
08:11:31 AM MichaelDaum doc fixes for jquery.loader
08:11:41 AM gac410 Looks like 2.1.3 will have 45 fixes and 20 enhancements.
08:12:30 AM gac410 Is the JQueryPlugin change log completed? The check_extensions shows a bunch of tasks missing
08:13:07 AM MichaelDaum checking
08:14:40 AM MichaelDaum I guess so
08:15:28 AM gac410 14172 173, 226, 227, 228, 229, 230, 250, and 251 are not in the History
08:21:41 AM gac410 Schedule for 2.1.3 ... I'll try to get it built in the next day or so. Will install on foswiki.org once the cache expires is expired. probaby around the 20th.
08:22:14 AM gac410 As there are bootstrap changes, it would be really helpful for people to test install
08:23:02 AM gac410 But that's best requested in the main channel I guess.
08:24:27 AM gac410 So this will hopefully be the last 2.1.x release ... assuming no urgent security issues pop up
08:26:39 AM gac410 For 2.2 ... Mid-April feature freeze? Or do we scrap 2.2, and look towards a very disruptive 3.0
08:27:58 AM JulianLevens I have 2 items being prepared for 2.2
08:28:21 AM JulianLevens Locale changes and QueryBackLinks
08:28:26 AM gac410 I've got a few small ones too that I've been letting slide
08:28:52 AM gac410 The biggest lists were Michael's and Crawfords.
08:29:18 AM MichaelDaum I've got stuff for 2.2 as well
08:29:39 AM JulianLevens I think they are needed for 2.2 as it is I've slimmed down the locale changes - leaving more for 3.0
08:29:46 AM MichaelDaum 1) TopicTitle feature, 2) extend USERINFO, 3) new NatEdit
08:29:59 AM gac410 Michael, Julian, do you think they would be ready for a April freeze / beta start?
08:30:09 AM MichaelDaum +1
08:30:17 AM JulianLevens +1
08:30:55 AM gac410 There are a lot more features commtited for 2.2 on https://foswiki.org/Development/ReleasePlan
08:31:01 AM gac410 committed
08:31:50 AM MichaelDaum ah yea. the no-proxy one is on my list as well.
08:32:01 AM gac410 Michael, you also had ConfigurableURLIncludes, RegistrationToken
08:32:20 AM MichaelDaum RegistrationToken is 2) extend USERINFO
08:32:22 AM gac410 And a HomeWebName
08:32:31 AM gac410 Ah...okay
08:33:43 AM MichaelDaum I also hope to fix some pattern skin issues.
08:34:01 AM gac410 If we could just get a bit of CDots time to polish up his changes - they are pretty much ready to merge, but had some last minute changes iirc
08:34:06 AM MichaelDaum though the bulk is non core plugins
08:34:46 AM MichaelDaum oh and there is another itchy thing: configure's extensions interface sux
08:34:56 AM gac410 I was going to add converting PatternSkin to use AddToZone for css - I made some good progress there in some non-published cached changes
08:35:36 AM MichaelDaum the extensions shouldn't be using tabpanes as a way to list them. Instead it should be a table. more like wordpress does it.
08:36:03 AM gac410 That one addtozone) doesn't really rise to a feature request though, as it's more refactoring than a design change.
08:36:07 AM MichaelDaum checking for updates and then doing the upgrade is a pita.
08:36:45 AM gac410 Y. I'd like it to ONLY list pending updates, rathern than needing to do an eye-scan of the list.
08:37:16 AM MichaelDaum at least lines should use different background colors based on the extensions' state
08:38:01 AM MichaelDaum then, once you've scanned the list, the "upgrade" button is scrolled out of sight. wtf.
08:38:02 AM gac410 y, the little bit of bold text is hard to spot. Also, the UI is poor in that after you scoll to bottom, you have to go back to the top to apply the update. If you just hit enter it cancels
08:38:23 AM gac410 Yeah exactly. There is a task or that one. Vicki was prettty upset about it iirc
08:38:37 AM MichaelDaum then, once you hit the "upgrade" button another dialog pops up on top ... and never closes ... even though the upgrade has finished.
08:38:50 AM MichaelDaum She's damn right
08:39:34 AM MichaelDaum anyway, we will have to deal with this.
08:39:36 AM gac410 Yeah, still, CDot did some amazing work getting the ui to the point that it is.
08:40:36 AM MichaelDaum the process of creating the new configure somewhat slipped through the cracks. while we were all happy with the new approach, it fails some fundamental ux checks.
08:40:49 AM gac410 Anyway between the 3 of us it sounds like we have a really decent 2.2 in the pipe
08:41:04 AM gac410 Y. TimotheLitt did a +
08:41:28 AM MichaelDaum nother one: buttons to action upon the configure page are spread here and there: 1) toggle expert settings 2) save changes 3) go back to site ... these should be organized in a consistent way.
08:41:54 AM gac410 did a great job ajaxing it, but it was unusably slow, and cdot did hero development, making it reasonably responsive. ... and burned himself out over it.
08:42:19 AM MichaelDaum gac410, right. it seems obvious that we need to concentrate on these things more before we can deal with 3.0, frankly
08:42:50 AM gac410 Maybe for the Foswiki association, we really need to think about how to engage some more help. Especially on the fringes - getting extensions updated, etc.
08:43:18 AM MichaelDaum organize a Foswiki Hackatron n such.
08:43:45 AM MichaelDaum though, only the same faces tend to show up ... drowning in fruitless discussions.
08:44:02 AM gac410 The critical mass is slipping away. No real "project" problems - more just normal attrition. We've lost Jast - he changed employers.
08:44:17 AM MichaelDaum did he
08:44:22 AM MichaelDaum where is he now?
08:44:47 AM gac410 y, he left modell-aachen Not sure where he went. But no longer uses foswiki in his daily life.
08:45:20 AM gac410 So we are left with the support@m-a for any translation server help. Hopefully it will keep running.
08:46:03 AM MichaelDaum his xing profile says he left mac and went to https://www.userlike.com two months ago.
08:46:29 AM MichaelDaum modell aachen forked foswiki
08:46:35 AM gac410 y, he let me know when he made the transition. Right. frown, sad smile
08:46:54 AM MichaelDaum they barely share code they distribute.
08:47:39 AM gac410 y, but I don't want to go down that rat hole here wink
08:47:49 AM MichaelDaum there are a couple of bug items where communication with them has stalled for a while now.
08:48:21 AM MichaelDaum it is a rat hole
08:48:42 AM gac410 y. They were pretty knowledgeable w/ LDAP and some serious issues in mapping that we have yet to address.
08:48:53 AM MichaelDaum I am pretty disappointed about their engagement in foswiki after these years.
08:49:14 AM JulianLevens https://github.com/modell-aachen quite a bit is shared here, but it will still take effort to examine all of that
08:49:17 AM MichaelDaum y. the user mapper. code to be redesigned from scratch
08:49:36 AM MichaelDaum I once went thru their repos on github
08:49:53 AM MichaelDaum yet still the sum of all repos does not add up to qwiki
08:50:26 AM gac410 As with most open source projects, there is not much in the way of leverage for us.
08:50:29 AM MichaelDaum i.e. you can't download the qwiki source code
08:50:58 AM JulianLevens No, I realise that, I wouldn't quite expect that - more hoping for all fixes sent upstream
08:51:05 AM JulianLevens Plus enhancements
08:51:11 AM gac410 well lets not start anything until we have a solution for translate.f.o big grin
08:51:20 AM MichaelDaum well foswiki still is gpl
08:51:30 AM MichaelDaum all forks have to be so too
08:51:47 AM MichaelDaum as you said a rat hole
08:52:35 AM MichaelDaum the situation - no matter what legal issues there might be - is disappointing.
08:52:39 AM gac410 and it would be an expensive rat hole unless some benefactor had deep pockets to sponsor legal action. As I said, we have no leverage. And for now need them to keep t.f.o functional. frown, sad smile
08:53:31 AM MichaelDaum I tried to explain to them in amsterdam that their business model towards foswiki is at least ... unethical
08:54:20 AM MichaelDaum it is exactly this situation - modell aachen milking foswiki - that demotivates my own contributing
08:54:54 AM MichaelDaum anyway
08:55:10 AM MichaelDaum there is zero way to force them into contributing back
08:55:32 AM gac410 Anyway ,.. 2.1.3 beta . Dec 20th or thereabouts. Need some serious bootstrap testing, especially in areas of foswiki behind proxy, and non-linux platforms
08:55:57 AM gac410 Feature freeze for 2.2.0 lets say April 15th,
08:56:18 AM MichaelDaum okay. I'll update the Foswiki Calendar with these dates. So everybody knows.
08:56:25 AM gac410 Great thanks
08:56:59 AM gac410 Then we really need to figure out some ways of encouraging contributions. Maybe some well crafted emails to the announce list?
08:57:19 AM MichaelDaum we need to blog about it as well
08:57:36 AM gac410 The github move has encouraged some small amount of contributions. But we need more. New OpenID contrib ... did you see?
08:59:52 AM gac410 I don't have anything else for the agenda today ... vrurg, do you have anything you want to bring up?
09:00:06 AM MichaelDaum yes I did. awesome. didnt check it out though.
09:01:27 AM gac410 I'm guessing it does a small part of what Jast was trying to do in the UnifiedAuthContrib ... but gets it done. Little bites rather than a 7-course feast
09:01:30 AM vrurg gac410: Nothing really. The new specs turns out to be way more job than previously expected.
09:02:18 AM vrurg The configure will need to be adapted too but that's where I'll most sure will need community support.
09:02:29 AM gac410 Yeah I was reading that between the lines. Might have been better to stick with what you had rather than biting off another bit chunk ???
09:02:29 AM MichaelDaum gac410, these auth systems need to be unified indeed, but not without the core user code being redesigned substantially
09:02:42 AM gac410 right
09:03:56 AM gac410 the whole cuid process especially now with unicode is making a real hash of things.
09:05:13 AM gac410 Some sort of random uuid would have been much better than an intelligent encoding of IDs
09:05:16 AM MichaelDaum a redesign would start at creating a User class, and adjust apis to pass a user ref instead of a tripple of cuid/login/wikiname, which call getmapper all the time.
09:06:16 AM MichaelDaum a user object contains the mapping already. no need to re-guess it again and again by asking each auth systems in a row whether they are responsible for a cuid.
09:06:39 AM gac410 Maybe it should be part of 3.0 ... it's already breaking pretty much everything wink
09:07:11 AM MichaelDaum there is a problematic error in Users.pm right now: falling Foswiki::Func::getWikiName() with the wrong parameters will pollute the internal cache nother cache) in Users.pm with wrong values.
09:07:34 AM gac410 Though we need to be VERY cautious to guard against the Foswiki 1.2.x trunk syndome where it just kept getting bigger and bigger with pieces of incomplete features.
09:07:39 AM MichaelDaum this happens when you change {AllowLoginNames} midway, while you ve already created content
09:07:59 AM gac410 "Dont' worry .. trunk will fix it" was the mantra for years Waddamess
09:09:01 AM MichaelDaum while I definitely agree with you on preserving compatibility - we have been famous for it - some issues need an exhumation
09:09:23 AM gac410 People will not be happy to lose human readable ID's in META, but I really believe it needs to be a UUID to disconnect content from any backend changes
09:10:07 AM MichaelDaum john2e_doe isn't human readable already, imo
09:10:10 AM vrurg gac410: UUID might include human-readable part too.
09:10:23 AM gac410 That way the UUID identity would be stable be it using login names, wiki names, fingerprints or other anatomy big grin
09:11:22 AM MichaelDaum y
09:11:26 AM vrurg MichaelDaum: but it's human-readable enough to recognize the person.
09:12:14 AM MichaelDaum vrurg, I like your idea more: adding a human readable part ... but in a more controlled way to how it is now done sprintf hex yadda)
09:12:19 AM gac410 Well the issue is it's john_2eadam which is indistinguishable from john_adam
09:12:36 AM MichaelDaum or john.adam
09:13:30 AM MichaelDaum I am not 100% convinced what people looking at %META:TOPICINFO are expecting
09:13:36 AM gac410 I started a "requirements" topic for Jast - ... Need to accomodate things like MarySmith gets married and becomes MaryJones ...
09:13:54 AM JulianLevens That's a different problem
09:14:08 AM JulianLevens A unique id in META is critical
09:14:34 AM MichaelDaum for now this id is changing if you change {AllowLoginNames} ... and this s.u.x.
09:14:42 AM JulianLevens But if e.g. AD is changes behind FW's back then you may well end up with two users
09:14:48 AM gac410 well it stems from the same thing. The id in meta should NOT be "intelligent" then the back end can deal with marriage, divorce, sex changes, etc
09:15:02 AM MichaelDaum xactly
09:15:57 AM JulianLevens y, and the ability to recognise many existing unique ids as being the same - i.e. married name two users created, now recognise as one
09:16:32 AM MichaelDaum "many existing unique ids being the same"?
09:16:53 AM MichaelDaum either an id is unique or not
09:17:17 AM MichaelDaum within the realm of foswiki
09:17:19 AM gac410 Right. I have to find my old requirements topic. I tried to cover all those bases. Trying to convince Jast that this needed to be figured out before he coded the unified auth
09:17:19 AM vrurg And anyway, META is generally not for reading directly. Especially if some day it gets separated from topic and migrates into separate storage.
09:17:42 AM JulianLevens y, real world, someone get's married, has a new login-name, therefore this one unique person now has two login-ids and two ids in META
09:18:21 AM JulianLevens This is 'fixed' by the admin a month or two later to 'merge' these into one logically)
09:18:32 AM MichaelDaum JulianLevens, the UUID within foswiki should stay stable. only does a new foreign id map onto it.
09:18:49 AM gac410 Also the case of merging two identities. Aliases / cloaks. My Github identity, my OpenID identity ...
09:18:56 AM JulianLevens y, but if LDAP does not spot the change
09:19:36 AM JulianLevens LdapContrib
09:19:38 AM gac410 need some way to say that these external ideneites are really the same person.
09:19:41 AM MichaelDaum depends on what exactly is used to identify AD-wise. most of the time this is the samaccountname ... if this changed, well, then a new mapping rule is require to point it to the old foswiki UUID
09:20:28 AM JulianLevens Basically that's what I mean
09:20:49 AM gac410 Then there is the other issue. When I started at Nortel, there were something like a dozen GeorgeClark identites in the LDAP ... JohnSmith even has it worse big grin )
09:20:51 AM MichaelDaum the foswiki uuid will then list all foreign ids of authentication providers
09:22:03 AM MichaelDaum it might even list multiple foreign ids of the same auth provider
09:23:04 AM gac410 IIRC we used the employer ID nortel called it a "Global ID" ) as the cUID in our custom mapper on twiki at the time) That was guaranteed to be stable.
09:23:52 AM MichaelDaum gac410, this is fine as long as you only have one auth provider.
09:23:57 AM gac410 right.
09:24:46 AM gac410 As soon as there are multiples you probably need manual intervention with some mapping of duplicates, etc. At some point a human needs to decide that these two things are really the same person.
09:25:06 AM gac410 It really is a difficult problem
09:25:56 AM vrurg It is unsolvabale problem without end user interaction.
09:26:24 AM MichaelDaum strictly speaking, we already have at least two auth providers = mappers). BaseMapper and TopicMapper. An LDAP or OpenID will add yet another. And thats why the current code is such as mess.
09:26:24 AM JulianLevens y, and that last bit is in some ways the hardest - some of this we can only 'fix' with good documentation
09:26:26 AM vrurg Eventually, a user would need to add another external ids to its fw account.
09:26:45 AM MichaelDaum vrurg, right.
09:26:46 AM JulianLevens More likely an admin in this case
09:27:37 AM MichaelDaum auth code should do one simple thing: take a foreign user id and get foswiki's own uuid for it.
09:28:00 AM gac410 Anyway, this is definitely a post 2.2 issue ... maybe 3.0, but probably a 3.x / 4.0 challenge.
09:28:50 AM vrurg Another matter – I don't think multiple external ids would be a problem of big numbers. Eventaully, most users use single id like Facebook or openid, but rarely both simultaneously.
09:28:53 AM gac410 need to avoid making 3.0 too big. It probably ought to already be in "feature freeze" and focus on just getting it fully functional and stable.
09:28:59 AM MichaelDaum still, these release meetings are a good time to brainstorm...no matter where it leads us to
09:29:33 AM vrurg gac410: If it doesn't make into 3.0 – then its 4.0, no doubt. And it won't be in 3.0.
09:29:50 AM gac410 Yes. it's a good discussion. Though sometimes I think we should move these discussions to the main channel. To get a wider participation
09:30:06 AM MichaelDaum agreed. a new user code will heavily benefit from the core being moosified.
09:30:25 AM vrurg gac410: As to the feature freeze – planned for after the new specs are ready.
09:31:03 AM gac410 okay great vrurg ... Though we will have to keep merging master features in to 3.0
09:31:26 AM vrurg y
09:32:05 AM vrurg MichaelDaum: I would put it more not on moosification as this is nothing but a tool. What I put my hope into is the new extensions.
09:32:07 AM gac410 I probably ought to try to do another merge. The backlog is getting large again frown, sad smile
09:32:58 AM vrurg With the new specs I'd like to have a demo of how they work in real life by implementing different spec formats by an extension.
09:33:08 AM gac410 well in this case vrurg, we truly need to re-architect the internal mapper implementation. I think it really would be beyond what the new extensions could do with class overrides
09:33:35 AM MichaelDaum vrurg, well, a new user code would definitely be designed more with an oo-hat on. if it still was using the current 2.x base, then the very same new old-style-oo code would have to be ported to Moo. somethign I'd rather like to avoid.
09:33:47 AM vrurg gac410: This is true.
09:35:19 AM gac410 Another one probably post 3.0 is to redesign / unify the MetaCache and InfoCache and move them out of search and into Meta / Store somehow.
09:36:00 AM gac410 For the life of a transaction, A topic should be read and de-serialized at most once.
09:36:18 AM MichaelDaum oh yea. only then will moving META:TOPICINFO out of the txt file make sense.
09:36:38 AM vrurg gac410: I have splitting of topic/meta in mind for post 3.0 but not even having 3.0 in direct sight this is yet too early to talk about.
09:37:00 AM MichaelDaum if we moved META:TOPICINFO out without a proper MetaCache...then performance breaks down even more.
09:37:50 AM gac410 Y. There also the bogus META:CREATEINFO that was added in to 1.2, and then removed from 2.0, ... but without removing the documentation frown, sad smile
09:37:54 AM vrurg Actually, this is where fw can benefit from PSGI. Caches could be shared among different application instances.
09:38:15 AM MichaelDaum right now _readMetaKey or what is it called) makes up a significant time processing a request. it is the most expensive operation performed in a single place ... according to NYTProf
09:38:45 AM gac410 That's the de-serialization right?
09:38:49 AM MichaelDaum y
09:39:43 AM gac410 TBH I think we are really at some exciting times for upcoming foswiki releases. But we really need a "bigger bench" of devs to work on this.
09:40:18 AM MichaelDaum which brings us to sexyness of F.O.
09:40:28 AM MichaelDaum or rather the lack of it
09:41:34 AM gac410 At the same time, it really needs to reflect what you get OOB with foswiki. Makes no sense to sexy-up f.o, and leave users with a stale OOB experience
09:42:29 AM MichaelDaum there is a lengthy trail of missed opportunities here
09:43:34 AM gac410 If we were to move to natskin on f.o, we'd need to make the whole ecosystem part of the release and that would really hinder you Michael I suspect.
09:44:01 AM gac410 F.O really needs to be WYSIWYG .... or it' becomes a bit of a bait and switch
09:44:12 AM MichaelDaum I am not proposing to move to natskin at all.
09:44:21 AM gac410 oh okay
09:44:30 AM MichaelDaum even with current pattern skin there is a whole lot of things we can improve
09:45:05 AM gac410 gac410 is just not really much of a CSS developer. Whenever I touch css, it goes downhill wink
09:45:57 AM gac410 And frustration level is the "equal and opposite" reaction with my CSS experience
09:46:06 AM MichaelDaum let me list two issues: 1) get the diff of the last change -> needs you to click on ">" at the bottom of the page -> try this on your phone 2) more.tmpl needs to be split up into separate dialogs, some of them modal presumably
09:46:54 AM gac410 yes More is a real mess. Indeed needs cleanup. And agree with the > as well. Fat fingers don't work well wink
09:47:13 AM MichaelDaum it is these things that we need to weed out
09:47:40 AM gac410 The more actions - settings editor - should be a nat edit tab. Which I think you have in the real nat skin, right?
09:48:11 AM MichaelDaum only the most interestign settings, not a general topic settings editor.
09:48:46 AM gac410 Still it needs to be less obscure than a button beneath a link
09:49:41 AM gac410 Oh... that brings me to a design issue I found. There is no way to use a topic setting as a template only. You have to put it in a %STARTSECTION ... can't use meta settings.
09:50:32 AM gac410 We probably need to extend META settings with a template only flag, ... or add a new META setting for template-only settings.
09:54:17 AM gac410 Item14128
09:54:39 AM gac410 Anyway everyone. We are at the 2-hour mark. Lets wrap up.
09:54:56 AM gac410 Thank you all for coming
09:55:16 AM JulianLevens Thank You
09:55:18 AM gac410 I think that this should be the last Release meeting for 2016. next one would be day after Christmas
09:55:21 AM vrurg Thanks!
09:55:49 AM JulianLevens Next meeting 2nd or 9th Jan?
09:55:53 AM gac410 Hopefully we'll have a shiny new Beta 2.1.3 to play with under the tree.
09:56:22 AM gac410 Maybe we ought to start back up on the 9th. Does that sound reasonable? Take a few weeks off for the holidays
09:56:37 AM gac410 The 2nd will be hangover-recovery-day big grin
09:56:39 AM JulianLevens y, makes sense to me
09:57:57 AM gac410 MichaelDaum: When you fix the calendar could you handle that one as well. Meetings start bi-weekly as of January 9th
09:59:59 AM gac410 Anyway everyone, Happy Chanukah, Happy Quanza, Merry Christmas, Happy New Year ... Did I miss anyone? big grin
10:01:00 AM gac410 and of course we must not forget "Festivus for the rest of us"
10:02:17 AM vrurg Heppy... everything! smile
10:17:28 AM MichaelDaum Frohes Fest
11:07:33 AM MichaelDaum updated the calendar. took out the 26th dec
11:08:30 AM gac410 Thanks MichaelDaum

Topic revision: r1 - 13 Dec 2016, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy