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