Release Meeting: 15 Sep 2014

 
  Conversation with #foswiki-release at Mon 15 Sep 2014 08:47:11 AM EDT on gac410@chat.freenode.net (irc)

   (09:03:42 AM) gac410: Hi all... Thanks for attending.
   (09:05:09 AM) gac410: I think for the "git postmortem" unless there are any new discoveries / concerns, that can drop off the agenda for future meetings.
   (09:06:15 AM) gac410: "mirror" of the repo is running - every 4 hours it checks for changes and updates mirror for changed repositories.
   (09:06:45 AM) gac410: The Item specific branch code should be working okay. ... Michael, any concerns?
   (09:09:32 AM) gac410: Yes / No ??? Are we in good shape on git? Next agenda item?
   (09:10:05 AM) gac410: Hi andreli thanks for joining
   (09:10:31 AM) andreli: Please welcome
   (09:12:06 AM) gac410: Not a very talkative group today I guess :)
   (09:12:35 AM) andreli: Oh, I am only here to get an idea, when we can start using 1.2.
   (09:12:45 AM) ModAcOst: Sorry, Iʼve had very little time lately and nothing really to contribute.
   (09:13:41 AM) gac410: So no responses on git. Lets move on to Configure. That has been extremely painful for me. I just discovered CDot had deleted large portions of code that he didn't think was necessary. :(
   (09:14:17 AM) gac410: I reverted a bunch of stuff last night to restore the extension installer at least from the cli. Web based installer is still not usable.
   (09:14:34 AM) Lynnwood: grettings all
   (09:14:42 AM) gac410: Howdy Lynnwood
   (09:15:32 AM) Lynnwood: i'm monitoring to see what i might do to help
   (09:15:55 AM) gac410: Has anyone else tried the bootstrap code / "Install from no LocalSite.cfg" process?
   (09:18:35 AM) gac410: The new configure is probably the biggest blocker to a usable 1.0 IMO. And I really can't work on it, since it's all now client side javascript, and I am utterly clueless
   (09:18:42 AM) gac410: Er. Usable 1.2
   (09:19:29 AM) gac410: I'm fixing what I can from the perl side. But things like the Extension installer are hopeless from my perspective.
   (09:20:35 AM) Lynnwood: The extension installer is non-functioning currently?
   (09:21:04 AM) ***Lynnwood looks at Item12952
   (09:21:23 AM) gac410: From the Configure web gui. Yes. not working at all. Code not even written. It puts up an extensions list, and a bunch of buttons that do nothing. Javascript "to be written"
   (09:21:50 AM) MichaelDaum: argh, now I am here physically
   (09:22:23 AM) gac410: All of the features others build for 1.2 and 1.1 for that matter, are ALL gone. No "simulate" no "dependency check" no nothing. Just a list of non-functional buttons.
   (09:22:38 AM) MichaelDaum: "item specific branch code" ... have to check, will give you feedback once I come back to those items working on them
   (09:22:57 AM) gac410: Okay MichaelDaum I did "replay" your checkins and they updated the tasks okay.
   (09:23:16 AM) MichaelDaum: gac410, thanks a lot for implementing this. yay.
   (09:24:16 AM) MichaelDaum: Iʼve been working on ConfigurePlugin recently. Did not pull your latest changes and reapplied my changes, gac410.
   (09:24:45 AM) gac410: What I discovered last night. CDot deleted Configure::Util, and ConfigureTests as well, so I didn't even know it was gone, until I tried to install an extension from the shell.
   (09:25:02 AM) MichaelDaum: ah ok
   (09:25:22 AM) MichaelDaum: canʼt say much about the server side of configure
   (09:25:28 AM) gac410: I reverted and put back Configure::Util, and restored and renamed ConfigureTests to be ExtensionInstallerTests. And got that part working.
   (09:25:41 AM) MichaelDaum: excellent
   (09:26:37 AM) gac410: On ConfigurePlugin, I added a %DEPENDENCYREPORT% macro and a System.DependencyReport topic. So we can now see a summary of core + extensinos dependencies.
   (09:26:48 AM) MichaelDaum: well from what I can say reading configure.js and types.js .... it doesnʼt really let me customize the interface unless much of the UI related code gets a rewrite.
   (09:27:09 AM) MichaelDaum: quite messy the code
   (09:27:49 AM) ***gac410 is totally lost with configure now.
   (09:28:09 AM) MichaelDaum: I am pretty worried about the way the UI is depending on the notion of "nodes" being rendered in a generic way
   (09:28:32 AM) MichaelDaum: i.e. not every node should be rendered equally ... though the code does right that
   (09:28:50 AM) ***gac410 doesnʼt even know what nodes are.
   (09:29:13 AM) MichaelDaum: a node is a piece of UI being loaded based on a part of the specs
   (09:29:33 AM) gac410: From a "end user" perspective, new configure seems to be working fine ... for what is there.
   (09:30:08 AM) MichaelDaum: "Lost in Tabs"
   (09:30:28 AM) MichaelDaum: the most worrying part is Extensions
   (09:30:46 AM) MichaelDaum: lots of tabs, lots of nested tabs.
   (09:30:47 AM) gac410: So one hole I've found. If you install an extension (pseudo-install) AFTER foswiki is up and configured, the configure UI picks up the extension settings metadata, but doesn't get any defaults.
   (09:31:11 AM) MichaelDaum: the same extension being listed in distinct parts of the ui: configure tab vs enable switch
   (09:31:47 AM) gac410: Yeah. The Enable switch ... it was missing the {Module} setting. too. I fixed that from the perl side.
   (09:32:11 AM) MichaelDaum: I wasnʼt able to have a non-tabish interface for the outermost tabpane
   (09:32:36 AM) gac410: That separation of enable from setings, that's the way the old configure worked as well. So I'm not too woried about that.
   (09:32:48 AM) MichaelDaum: I wasnʼt able to make the forms look nice unless I recoded all of the node-to-ui procedures
   (09:33:00 AM) andreli: You are painting a frightening picture regarding the state of configure. Wouldnʼt it be correct to wait until CDot is back, to explain his actions, in the hope, everything is on a good track?
   (09:34:44 AM) MichaelDaum: andreli, not a meeting where we exchange flowers
   (09:35:36 AM) MichaelDaum: actually it was configure that made me look at way to ease further customization of a SPA app like this one
   (09:35:47 AM) andreli: Yeah, sure, but CDor is not present
   (09:36:04 AM) andreli: I mean CDot
   (09:36:25 AM) gac410: CDot's parting words were he wanted me to fix the extension installer. But it
   (09:37:02 AM) gac410: But it's all in javascript and I don't know where to even begin. I'm a html / perl guy. I am utterly totally lost,.
   (09:37:08 AM) MichaelDaum: CDot did a massive job so far. But big parts of it are really dirty still.
   (09:37:43 AM) MichaelDaum: what we have now is jquery DOM plumbing ... not the way to write a SPA
   (09:38:05 AM) MichaelDaum: there are a few options to consider
   (09:38:08 AM) gac410: Heck I just wanted to add a simple input field to the save dialog. ... <input ... comment > and don't know how to get an input field into the dialog.
   (09:38:20 AM) gac410: What's a SPA
   (09:38:22 AM) MichaelDaum: gac410, right. the current code doesnt allow you to do that
   (09:38:26 AM) MichaelDaum: SPA = Single Page App
   (09:38:30 AM) gac410: Ah.
   (09:39:02 AM) MichaelDaum: there isnt a way to customize the ui other than change some spec file
   (09:39:33 AM) gac410: When I asked CDot, he pointed me at the Extensions wizard where it added the <button> elements, but that didn't help They are just buttons to nowhere. They don't submit anything.
   (09:39:59 AM) MichaelDaum: what we need is a better way of templating
   (09:40:02 AM) MichaelDaum: on the client side
   (09:40:21 AM) gac410: I'm thinking now for the extension installer. That we make it a plain old wiki application. With a JQuery autocomlete box to search the extensions list.
   (09:40:35 AM) MichaelDaum: this is currently done using jQuery&#700;s append, insert, etc functions ... hard-coded into configure.js
   (09:40:41 AM) Lynnwood: MichaelDaum: you had posted recently something about a framework for just this kind of thing.
   (09:40:52 AM) MichaelDaum: Lynnwood, right
   (09:41:03 AM) MichaelDaum: but I am not in favor of using it for configure atm
   (09:41:08 AM) Lynnwood: ok
   (09:41:23 AM) MichaelDaum: angular.js is too much of a paradigm shift
   (09:41:28 AM) MichaelDaum: atm
   (09:41:38 AM) Lynnwood: ok
   (09:41:47 AM) MichaelDaum: what we really need is client side templating ... that angular.js comes with among other things
   (09:42:01 AM) gac410: Given that the jsonrpc setcfg functions can really be used anywhere, Can we move "pretty" elements from configure into System.TopicPages
   (09:42:30 AM) MichaelDaum: gac410, I&#700;d move them into temlates/ ... but well structured
   (09:43:14 AM) gac410: Ugh. Templates another area that I tip over into disfunctional
   (09:43:55 AM) MichaelDaum: what we have currently is jquery.tmpl and jquery.tmpl-loader
   (09:44:20 AM) gac410: Ah... yet another template? I thought you meant templates directory.
   (09:44:27 AM) MichaelDaum: alas, jquery.tmpl is unmaintained and been superseded by its author by jsrender
   (09:45:01 AM) MichaelDaum: jquery.tmpl-loader allows you to use foswiki&#700;s template mechanism to deliver jquery.tmpl templates to the client side
   (09:45:59 AM) gac410: So... do we table Configure until CDot gets back and focus on remaining blockers for 1.2.
   (09:46:08 AM) MichaelDaum: these are blocks that look like this: <script type="type/x-jquery-tmpl"> html {{json.property}} ... </script>
   (09:46:51 AM) gac410: Oh cool .... So you can expand json into a html layout. Exactly what I was looking for with extensino installer.
   (09:47:06 AM) MichaelDaum: righdo
   (09:47:27 AM) MichaelDaum: you can even loop over props of a json obj and call more templates in a nested way
   (09:47:32 AM) gac410: So the "html" piece could be the display of an extensino version, and the buttons to " check dependencies, install, etc."
   (09:48:17 AM) gac410: I *think* CDot's plan was to move the more complicated parts of configure into System topic pages. that become drivers of jsonrpc setcfg / getcfg ... etc.
   (09:48:51 AM) MichaelDaum: http://trunk.foswiki.org/System/JQueryTmpl gives a short example of how this works out
   (09:49:33 AM) gac410: One think I really wanted to do was change the extension installer to identify the dependencies BEFORE actually doing the install. So the user could choose which deps to install rathern than having the
   installer "just do it"
   (09:49:49 AM) MichaelDaum: it takes (a) a jquery.tmpl and (b) a json object and applies (a) on (b) to render html
   (09:50:04 AM) gac410: Right, I've got it.
   (09:50:10 AM) gac410: (I think) :)
   (09:50:41 AM) MichaelDaum: only problem: we have to move to jsrender, the successor of jquery.tmpl ... which comes with slslslightly different syntax, but not too different.
   (09:50:52 AM) Lynnwood: y, i get the drift. I'm interested in studing example.
   (09:51:00 AM) gac410: I was about to ask that.
   (09:51:15 AM) gac410: about jsrender that is
   (09:52:03 AM) MichaelDaum: I was going to propose this: deprecate jquery.tmpl and add jsrender to JQueryPlugin... this is a kind of prerequisite to come to a sensible foundation for configure.js as far as I can see
   (09:52:46 AM) gac410: So with my RM hat on. We were trying very hard to get a 1.2 ready for release in a short timeframe. This configure change has completely destroyed that plan IMO. f
   (09:53:01 AM) MichaelDaum: yea f.
   (09:53:18 AM) gac410: (well the f was a typo ... but rather appropriate :D )
   (09:53:19 AM) MichaelDaum: but imho we can&#700;t go with current configure as it is right now
   (09:53:48 AM) gac410: Right, And CDot felt very strongly that Timothe's configure was in the same state. Way too heavy and would have killed the project
   (09:54:03 AM) MichaelDaum: I see. Yea maybe.
   (09:54:34 AM) gac410: He stated outright that fw was dead if we released 1.2 with configure as it was before his changes.
   (09:55:01 AM) gac410: Which is why he just "did it" - no feature proposals
   (09:55:08 AM) MichaelDaum: things that I am NOT about to propose are: add jsviews (the small cousin of jsrender) to JQueryPlugin as well .... nor rewrite configure.js using angular.js (thats going to boil people)
   (09:55:28 AM) gac410: Thanks.
   (09:55:55 AM) MichaelDaum: jsviews is in alpha state for years; angular.js is the way to go looong term
   (09:56:32 AM) gac410: So deprecate jstmpl move to jsrender due to upstream deprecation Stay the course with CDot's changes?
   (09:57:23 AM) MichaelDaum: jsrender is small yet powerful: the right amount of tech that we can handle atm
   (09:57:37 AM) MichaelDaum: yes stay on course - no reverting
   (09:57:45 AM) Lynnwood: Am i right in understanding that if we go the jsrender route, that once we get basic framework defined then much of the work would be in re-coding configure sections to match it?
   (09:57:47 AM) MichaelDaum: however lots of client side rewrite
   (09:58:10 AM) gac410: With my current developer skills, if we want 1.2 out quickly I just revert back to before CDot's megachanges. I'm not going to be much help I'm afraid due to my lack of skills.
   (09:58:48 AM) Lynnwood: If the client side rewriting follows a consistent pattern, i'm willing to dig in on it.
   (09:59:15 AM) MichaelDaum: gac410, to be honest: we are far away from being able to release 1.2 on the current code base.
   (09:59:18 AM) gac410: But I agree with you. Stay the course, no reverting ... except for pieces that cdot accidentally (i hope) lost like the shell extensinos installer.
   (10:00:12 AM) gac410: Until configure, I thought there were only a couple of blockers that unfortunately really needed cdot to help with ... wysiwyg corruption issue.
   (10:00:21 AM) MichaelDaum: the current configure plugin is in alpha1 state at best. alpha2 would see a massive code change even.
   (10:01:09 AM) gac410: agreed ... our current state has probably fallen back 6 months ... assuming anyone knows how to fix it. I'm not capable.
   (10:01:49 AM) MichaelDaum: the other positive effect of starting to use client side templating using jsrender is that people get used to this kind of stuff ... paving the way for an AngularSkin/Plugin
   (10:02:19 AM) gac410: yeah. I certainly have a huge learning curve to crawl my way up.
   (10:02:32 AM) MichaelDaum: even though that jsrender and angluar are quite different wrt templating
   (10:02:47 AM) MichaelDaum: me too wrt angular. just ordered a book to read up.
   (10:03:16 AM) ***MichaelDaum wonders where it is ... should have arrived on Friday.
   (10:03:33 AM) gac410: So do we agree. 1.2 is pushed way back and we focus on fixing CDot's configure rewrite?
   (10:05:21 AM) MichaelDaum: +1
   (10:05:42 AM) gac410: Other choice is I branch Release01x02 from master 9e4c133c0af37ae8965473a463aeb6ffd3086409 and let the configure rewrite continue on master while we try to polish up the blockers from a 1.2.
   (10:06:18 AM) gac410: That is ... "git log" grep for "phew" and branch 1.2 from just prior to that commit.
   (10:07:53 AM) MichaelDaum: hm, I&#700;d do that when the code base is ready for a beta
   (10:08:10 AM) Lynnwood: +1
   (10:09:24 AM) MichaelDaum: are you d&#700;accord with: deprecate jquery.tmpl and add jsrender to JQueryPlugin?
   (10:09:36 AM) gac410: +1
   (10:10:57 AM) Lynnwood: +1
   (10:12:25 AM) MichaelDaum: okay
   (10:12:53 AM) gac410: So branching Release01x02 from 9e4c133c0 would be saying we release 1.2 with Timothe's configure and let CDot's configure move to 1.3 or 2.0. That would be the only way to get 1.2 out this fall I suspect.
   (10:14:26 AM) gac410: I'm not sure which is worse for the project. Delaying 1.2 another 6 months, or Releasing 1.2 with a behemoth known as configure.
   (10:16:27 AM) gac410: Now that we are on GIT, I think we should propose that all "feature" related changes be done using a branch / merge strategy, never checkin new features into master.
   (10:17:10 AM) gac410: Merge to master only happens once a feature is beta quality.
   (10:17:57 AM) MichaelDaum: sounds good ... but more because it is convenient to have an item/dev branch for a feature
   (10:18:06 AM) ModAcOst: +1
   (10:18:13 AM) MichaelDaum: sounds not so good to make it a hard requirement
   (10:18:28 AM) MichaelDaum: like: there&#700;s one atomic checkin that nails it
   (10:19:38 AM) gac410: What I'd like to avoid is a "partial rewrite that disables master" situation. Aka the current configure mess. Try to keep master as solid alpha / beta quality.
   (10:20:01 AM) gac410: That seems to be the general operating model with git.
   (10:20:19 AM) MichaelDaum: I am all for this mode of operation on a _stable_ branch
   (10:21:02 AM) gac410: So yes it's developer choice, not a hard/fast rule.
   (10:21:04 AM) MichaelDaum: breakage on master is actually steering a rush of quick fixes to get back to a so-la-la state where other devs can continue work at least.
   (10:22:33 AM) gac410: master is the "public face" when someone clones from github. So breaking master is ugly and embarrassing to the project. It's way too easy to avoid by using an Item branch.
   (10:23:42 AM) gac410: Either that or we change github "Default branch" to be Release01x01
   (10:23:47 AM) MichaelDaum: umpf
   (10:23:56 AM) MichaelDaum: master = bleeding edge ... everywhere
   (10:24:16 AM) MichaelDaum: if it breaks, you bleed
   (10:25:00 AM) MichaelDaum: in practice we were quite okay on svn/trunk in the past without a branching rule for new features
   (10:25:04 AM) gac410: It breaks due to a bug... yes. It breaks because I got about half way done and want to save my work Not so.
   (10:25:22 AM) MichaelDaum: hey there&#700;s alway git blame
   (10:25:48 AM) gac410: Right, but on svn, branching is a very high cost - git branches are really really lightweight. Just a pointer.
   (10:26:05 AM) MichaelDaum: I&#700;ve been constantly using trunk for years and never had a monster disaster
   (10:26:38 AM) MichaelDaum: I am not expecting massive breakage on git master either, other than some areas not quite working well
   (10:26:55 AM) gac410: But you're the one arguing for Item*** branches. which I agree with btw.
   (10:26:58 AM) MichaelDaum: (massive breakage = data loss)
   (10:27:47 AM) gac410: To me, configure was a massive breakage. Major stuff missing, totally non-functional. Even after weeks, still major stuff missing,
   (10:27:51 AM) MichaelDaum: item branches make a helluffa sense for extensions where the amount of different features being implemented all over the repo is comparrably low
   (10:28:52 AM) MichaelDaum: on our foswiki/distro big repo we would see lots of item branches overlapping. lots of loose ends of different branches not being merged on or the other way.
   (10:29:30 AM) MichaelDaum: howerver you are right actually
   (10:30:13 AM) MichaelDaum: some never-really-finished work on svn/trunk would never have been merged back if it was done in a separate branch ... as its developers wandered off
   (10:30:22 AM) gac410: I guess I'm still pretty upset about configure changes. But I'm not handling like Lavr would have, that's for sure. Revert and be done with it. :)
   (10:31:04 AM) gac410: Yeah. That's been one of my bigger rm concerns about the state of trunk/master. The partially completed stuff. I have no idea what's in what state.
   (10:31:29 AM) MichaelDaum: yea
   (10:32:26 AM) MichaelDaum: if we were on git before those code changes, Sven would have created a branch, I guess.
   (10:32:50 AM) gac410: Generally, I think we should encourage branching for Feature Requests. When feature is complete, we "Merge to core" and remove the branch.
   (10:33:03 AM) MichaelDaum: agreed
   (10:33:21 AM) MichaelDaum: it even is called "merged to core" in the FR form
   (10:33:41 AM) gac410: I know I'm guilty of it ... Some of the logger changes are in questionable state.
   (10:35:08 AM) MichaelDaum: +1 on "branch for features"
   (10:35:44 AM) gac410: Well anyway... I don't see any need to go through the blockers. Let's close the release meeting. Decisions: We stay on track with CDot's configure, 1.2 is delayed probably some months, MD will deprecate
   JQueryTmpl and move to jsrender
   (10:36:13 AM) MichaelDaum: any other decisions for the protocol?
   (10:36:23 AM) gac410: protocol?
   (10:36:27 AM) MichaelDaum: logs
   (10:37:23 AM) gac410: I don't think so. Regardless of "like to see" feature branching, I think that requires a proposal?
   (10:38:34 AM) MichaelDaum: Just docu it on how to use git
   (10:38:55 AM) gac410: :) Okay
   (10:39:18 AM) MichaelDaum: thanks guys
   (10:39:47 AM) Lynnwood: thanks all
   (10:39:56 AM) gac410: yes Thanks everyone. Sorry that we've taken a step backwards on 1.2 release plan.
   (10:40:07 AM) Lynnwood: i'll be interested in seeing how the configure revision takes shape.
   (10:40:43 AM) gac410: One thing everyone can do.... Please try the bootstrap process, especially if you run other than linux/apache
   (10:41:16 AM) gac410: There is also a TestBootstrapPlugin in git that can run on a 1.1.x system and report what the 1.2 bootstrap will do once you get there.