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 |
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. |
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 |
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 |
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. |
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 |
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 |
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 ) |
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 |
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 |
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 |
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 |
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 |
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? |
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! |
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 |