On Fri, Aug 16, 2013 at 5:28 PM, Chris Geer <[email protected]> wrote: > On Fri, Aug 16, 2013 at 2:13 PM, Erin Noe-Payne > <[email protected]>wrote: > >> On Fri, Aug 16, 2013 at 4:00 PM, Chris Geer <[email protected]> wrote: >> > On Fri, Aug 16, 2013 at 12:56 PM, Matt Franklin < >> [email protected]>wrote: >> > >> >> On Fri, Aug 16, 2013 at 3:33 PM, Erin Noe-Payne < >> [email protected] >> >> >wrote: >> >> >> >> > On Fri, Aug 16, 2013 at 3:18 PM, Matt Franklin < >> [email protected] >> >> > >> >> > wrote: >> >> > > On Fri, Aug 16, 2013 at 3:15 PM, Gornstein, Daniel S. >> >> > > <[email protected]>wrote: >> >> > > >> >> > >> Matt, >> >> > >> >> >> > >> What is the upside of merging the branch into trunk before it is >> done >> >> or >> >> > >> more complete? >> >> > >> >> >> > >> >> >> > > IMO, working off of trunk makes it more "real" for everyone. I >> think >> >> it >> >> > > should only be done if we are within 1-2 months of it being >> releasable. >> >> > > >> >> > >> >> > That feels like an ambitious schedule to me. I see 1 month as no >> >> > chance, and 2 months as very tight at best. >> >> > - There is a lot of outstanding api work to fill in missing or >> >> > incomplete endpoints >> >> > - We need to make changes to some models so that transitions (f.e. >> >> > moving widgets between regions and pages) become state-based >> >> > >> >> >> >> Can you what you mean by this a little more? >> >> Say I want to move a regionWidget from one page to another. A >> regionWidget does not have a pageId property, so I can not make a >> change to its state and save to a restful endpoint. Similar problem >> for re-ordering portal pages. So we need to either update the models >> to have these references and then ensure that the controller / service >> layer detects the state changes and propagates accordingly, OR we need >> to implement special "action" rest endpoints on these models like >> /regionWidgets/1/move. I prefer the former but either will work. >> > > Wouldn't you update the page and add the regionWidget to a region on a > page, and remove it from another one? >
I guess that's true. I'm guess I was just thinking there should be one atomic operation. >> >> >> >> >> >> >> > - We need to harden the service layer to protect against data >> corruption >> >> > >> >> >> >> Yes, but we currently have this in trunk... >> >> >> >> I don't think we do? I sent an email to the dev list a few days ago >> about how the page service will let you set a null layout code. I >> think there are more examples if you start to dig, but that is all in >> trunk. >> >> >> >> >> > - We need to re-implement all of the front end as angular apps >> >> >> >> >> >> What is the state of this re-implementation? >> >> >> >> The portal is roughly 1 week in progress. Profile, widget store, admin >> panel, login, and anything else you can think of are not started. >> Progress will accelerate but each context will still have its share of >> custom work. >> >> >> >> >> > - We need to solve some pretty major architecture questions like... >> >> > - The entire authentication / authorization model >> >> > >> >> >> >> Authentication I agree, while the current authorization model is not >> >> optimal, it should still work, right? >> >> >> >> Yes but it should be better and I think we will start to feel the pain >> when we think hard about generic contexts instead of just the two >> cases we have in place currently, so it's on my mind. >> >> >> >> >> > - How we will now handle internationalization >> >> >> >> >> >> The client messages js endpoint should still work, right? >> >> >> >> Essentially, but it will need to be expanded because much of the >> messaging that used to be in jsp's and was never added to client >> messages will now happen in angular. Having said that, require and >> angular both have built in internationalization support, so it may >> make more sense to go with the grain and use one of those than roll >> our own. >> >> >> >> >> > - How are we going to handle client-side view composition to keep >> >> > it from being to chatty >> >> > >> >> >> >> +1 >> >> I have a concept here for an angular service that works in the spirit >> of requirejs, in which any directive, service, etc can declare its >> 'view dependencies', which can then be requested en mass via a server >> side endpoint and cached. But that's conceptual only at this point. >> >> >> >> >> Fair enough. I haven't seen much discussion of state of the branch >> except >> >> for Jira tickets, so this helps. IMO, some of these things feel a lot >> like >> >> they need to be solved by V1, but not necessarily before branch merge. >> >> >> >> Of course; the merge can happen once 0.23 is released. This list is >> with respect to 1-2 months until angular is releasable. >> >> > >> > Matt brings up a good point here. I know there is a lot of work going on >> > but I'm assuming that since the JIRA tickets are pretty lean (not much >> > detail) you are using other methods to coordinate work between people. Is >> > there other communications that can be moved to the list so we can all >> stay >> > abreast of what's going on? >> > >> >> Work on the angular branch started in earnest on monday - previous >> that the focus has been entirely on trunk and apis. This list of >> issues has not really been discussed beyond what has shown up on the >> list - it's mostly just a brain dump of what I have been thinking >> about. >> >> There has been some discussion off the list about the tasking for the >> angular tickets - I will be more transparent in tasking and discussion >> going forward. >> >> >> >> >> >> >> > >> >> > > >> >> > > >> >> > >> This causes people to not be able to use snapshot, and not release >> any >> >> > bug >> >> > >> fixes into trunk if you find something which needs attention right >> >> away. >> >> > >> >> >> > > >> >> > > Good point, but if we absolutely have to, we can release bugs out >> of a >> >> > > branch that we create from 0.23 tag. >> >> > > >> >> > > >> >> > >> >> >> > >> Thanks, >> >> > >> Daniel Gornstein >> >> > >> >> >> > >> -----Original Message----- >> >> > >> From: Matt Franklin [mailto:[email protected]] >> >> > >> Sent: Friday, August 16, 2013 3:09 PM >> >> > >> To: [email protected] >> >> > >> Subject: 0.23 Release & Angular Merge >> >> > >> >> >> > >> We are coming up on the end of the month and IMO, it would be a >> good >> >> > idea >> >> > >> to do a Rave release for 0.23 that includes the requirejs and >> Shindig >> >> > 2.5 >> >> > >> final changes. >> >> > >> >> >> > >> To support this, I have been committing minor bug fixes as I find >> >> them, >> >> > but >> >> > >> it would be good to get everyone who is able checking the current >> >> state >> >> > and >> >> > >> logging anything that needs to be fixed. >> >> > >> >> >> > >> I also see that Erin has been very active on the angular branch. >> >> Given >> >> > >> that it is now the major thrust of the project, what would everyone >> >> > think >> >> > >> about merging that branch back to trunk after the 0.23 release? We >> >> > would >> >> > >> then wait to do a 0.24 release until after the Angular code is >> ready. >> >> > >> >> >> > >> >> >>
