Thanks Chip. I'll let you know if I think of anything specific regarding UI sanity checks. The most important parts unique to UI are ensuring all new input fields are validated for security, strings are properly localized, etc. -- along with ensuring 3rd party libraries are present. I'll elaborate more on the wiki page.
-Brian On Feb 14, 2013, at 12:51 PM, Chip Childers <[email protected]> wrote: > On Thu, Feb 14, 2013 at 10:41:00AM -0800, Brian Federle wrote: >> Chip, >> >> First off, I apologize for not seeing your e-mail. I waited ~24hrs with only >> one response, and unfortunately I missed your post when I already merged to >> master. I think I forgot to read the full thread of what I was responding to >> there, so I'll be more careful in the future. >> >> However, there really needs to be more clarification about the merging >> procedure/protocol. I thought that waiting a day would be sufficient, and >> considering the lack of responses (and the one positive from Rohit) I read >> that as an OK to proceed the push. Despite this, I can't effectively follow >> proper procedure by sifting through hundreds of mails in the list to try and >> figure out what everyone else is doing. Can we please have a wiki page setup >> with clear instructions? I'm really not trying to break any rules, but I'm >> sort of in the dark here and still need to get the features I'm working on >> out in a timely manner. >> >> Let me hear your thoughts -- I just really need clarification here. >> >> Thanks, >> Brian > > So you are the second person to ask for us to have a "formal merge > process" documented. I'll take a crack at it in the next few days, and > would welcome help in getting it in shape to reflect consensus on the > topic. I'd actually ask for you to pay attention for that thread. I > think that the UI layer will have some slightly different implementation > specifics for things line ensuring tests are good before a merge. > Looking forward to getting your thoughts... > > As for missing my email, I know you didn't mean it. I agree that the > list is high volume, I was just frustrated because I believe that our > first principle for code changes should be "do no harm to master". > To me, that means not rushing to push changes, and being careful about > how they are discussed and consensus is reached. Given the time and a > clean diff, I might have even caught the require.js licensing issue in > a review as well, saving us from having a broken build (or I might not > have). > > So moving on from this, I have to say that I love the feature. This is > going to be a great addition to CloudStack's capabilities! > > -chip
