On 9 January 2018 at 00:12, Craig Russell <[email protected]> wrote:
>
>> On Jan 8, 2018, at 1:25 PM, sebb <[email protected]> wrote:
>>
>> On 8 January 2018 at 21:21, Craig Russell <[email protected]> wrote:
>>>
>>>> On Jan 8, 2018, at 12:32 PM, Sam Ruby <[email protected]> wrote:
>>>>
>>>> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <[email protected]> wrote:
>>>>> phantomjs is not available in PATH, not loading poltergeist
>>>>
>>>> Install phantomjs from here: http://phantomjs.org/download.html
>>>>
>>>> This information probably should be added to:
>>>> https://github.com/apache/whimsy/blob/master/config/board-agenda.md
>>>>
>>>>> ..................................F....element div: validity error : ID
>>>> updateStatusForm already defined
>>>>
>>>> That's probably a bug. It is saying that there is a page with two elements
>>>> with id="updateStatusForm" on one of our pages. This should be easy to find
>>>> and fix. Care to take a stab at it?
>>>
>>> clr% grep -r updateStatusForm .
>>> ./public/react/app.js: {id: "updateStatusForm", color:
>>> "commented"},
>>
>> AFAICT it's defined above
>>
>>> ./public/react/app.js: jQuery("#updateStatusForm").on("shown.bs.modal",
>>> function() {
>>> ./public/react/app.js: jQuery("#updateStatusForm").modal("show");
>>> ./public/react/app.js:
>>> jQuery(self.refs.updateStatusForm).modal("hide");
>>> ./views/pages/action-items.js.rb: _ModalDialog id:
>>> 'updateStatusForm', color: 'commented' do
>>
>> also defined above
>>
>>> ./views/pages/action-items.js.rb: jQuery('#updateStatusForm').on
>>> 'shown.bs.modal' do
>>> ./views/pages/action-items.js.rb:
>>> jQuery('#updateStatusForm').modal(:show)
>>> ./views/pages/action-items.js.rb:
>>> jQuery(~updateStatusForm).modal(:hide)
>>
>> Not sure about '~', but '#' is a reference, not a define
>>
>>> Any idea where this element is defined?
>
> I guess I wasn't explicit enough. I get that updateStatusForm is defined in
> both app.js and action-items.js.rb.
>
> So why is this considered to be defined twice?
JS does not have modules.
So all the js code ends up in a single file.
>>>
>>> Craig
>>>
>>>>
>>>>> ........................
>>>>>
>>>>> Failures:
>>>>>
>>>>> 1) navigation should navigate to the Cocoon report and back
>>>>> Failure/Error: visit '/2015-02-18/Clerezza'
>>>>>
>>>>> Capybara::DriverNotFoundError:
>>>>> no driver called :poltergeist was found, available drivers: :rack_test,
>>>> :selenium, :selenium_chrome, :selenium_chrome_headless
>>>>> # ./spec/navigate_spec.rb:11:in `block (2 levels) in <top (required)>'
>>>>>
>>>>> Finished in 1 minute 0.84 seconds (files took 1.17 seconds to load)
>>>>> 63 examples, 1 failure
>>>>>
>>>>> Failed examples:
>>>>>
>>>>> rspec ./spec/navigate_spec.rb:8 # navigation should navigate to the
>>>> Cocoon report and back
>>>>>
>>>>> /usr/local/Cellar/ruby/2.3.1/bin/ruby
>>>> -I/usr/local/lib/ruby/gems/2.3.0/gems/rspec-support-3.7.0/lib:/usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.7.1/lib
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.7.1/exe/rspec --pattern
>>>> spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
>>>>
>>>> This failure should be fixed by installing phantomjs.
>>>>
>>>>> Craig
>>>>>> On Jan 6, 2018, at 12:16 PM, Sam Ruby <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/6/18 3:02 PM, Craig Russell wrote:
>>>>>>> Moving this thread to dev@whimsical...
>>>>>>>> On Jan 6, 2018, at 11:46 AM, Sam Ruby <[email protected]> wrote:
>>>>>>>>
>>>>>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>> Infra has their own tools. Feel free to evolve this tool as you wish
>>>> to match your requirements.
>>>>>>>>>>
>>>>>>>>>> I believe that the current state is that if all goes well, the board
>>>> agenda tool does everything that is needed. If there is a problem, and the
>>>> board agenda tool partially did its job, and then the problem is then later
>>>> fixed, this can leave things in a half done state.
>>>>>>>>>>
>>>>>>>>>> My adding function that picked up work that Brent used to do has
>>>> meant that we have had to do cleanup. This function is only really tested
>>>> once a month. Whether this is the last month with problems or not is
>>>> something we will only find out after the next board meeting.
>>>>>>>>> I wonder if there is a way to unit test the new functionality in
>>>> agenda. If the tricky part is editing committee-info and updating ldap, a
>>>> function like ASF::Module.change_pmc_chair(project, chair) that does both
>>>> ASF::Committee.change_pmc_chair(project, chair) and ASF::LDAP.bind.
>>>>>>>>> I realize I'm helping design something that I know almost zero about,
>>>> but that's what you get with retired people. ;-)
>>>>>>>>
>>>>>>>> I encourage you to look at the current test suite for the board agenda
>>>> tool. While the test you describe above is most emphatically NOT an example
>>>> of the first test I would suggest you add, there undoubtedly are quite a
>>>> number of simpler tests that could be added.
>>>>>>>>
>>>>>>>> Running the tests is a matter of:
>>>>>>>>
>>>>>>>> cd whimsy/www/board/agenda
>>>>>>>> rake test
>>>>>>> pretty close but no. Do I need to upgrade software versions? I'm
>>>> running OS X El Capitan 10.11.6.
>>>>>>
>>>>>> You shouldn't need to update your OS, but you will need to install the
>>>> necessary dependencies. See:
>>>> https://github.com/apache/whimsy/blob/master/DEVELOPMENT.md#running-whimsy-applications-car
>>>>>>
>>>>>> Hint: all that is needed is to run 'bundle install'. Or better yet,
>>>> 'bundle update' which will ensure that you are running the latest
>>>> compatible version of every dependency.
>>>>>>
>>>>>> - Sam Ruby
>>>>>>
>>>>>>> [MacBook-Pro-9:www/board/agenda] clr% rake test
>>>>>>> rm -rf board
>>>>>>> A board/board_agenda_2015_01_21.txt
>>>>>>> A board/board_agenda_2015_02_18.txt
>>>>>>> A board/board_minutes_2015_01_21.txt
>>>>>>> Checked out revision 1.
>>>>>>> cp ../data/board_agenda_2015_01_21.txt
>>>> ../data/board_agenda_2015_02_18.txt ../data/board_minutes_2015_01_21.txt
>>>> board
>>>>>>> svn: warning: W150002:
>>>> '/Users/clr/apache/git/whimsy/www/board/agenda/test/work/board/board_agenda_2015_01_21.txt'
>>>> is already under version control
>>>>>>> svn: warning: W150002:
>>>> '/Users/clr/apache/git/whimsy/www/board/agenda/test/work/board/board_agenda_2015_02_18.txt'
>>>> is already under version control
>>>>>>> svn: warning: W150002:
>>>> '/Users/clr/apache/git/whimsy/www/board/agenda/test/work/board/board_minutes_2015_01_21.txt'
>>>> is already under version control
>>>>>>> svn: E200009: Could not add all targets because some targets are
>>>> already versioned
>>>>>>> svn: E200009: Illegal target for the requested operation
>>>>>>> /usr/local/Cellar/ruby/2.3.1/bin/ruby
>>>> -I/usr/local/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib:/usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/exe/rspec --pattern
>>>> spec/\*\*\{,/\*/\*\*\}/\*_spec.rb
>>>>>>>
>>>> /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:120:in
>>>> `require': cannot load such file -- erubis (LoadError)
>>>>>>> from
>>>> /usr/local/Cellar/ruby/2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:120:in
>>>> `require'
>>>>>>> from /Users/clr/apache/git/whimsy/www/board/agenda/main.rb:23:in `<top
>>>> (required)>'
>>>>>>> from
>>>> /Users/clr/apache/git/whimsy/www/board/agenda/spec/spec_helper.rb:12:in
>>>> `require_relative'
>>>>>>> from
>>>> /Users/clr/apache/git/whimsy/www/board/agenda/spec/spec_helper.rb:12:in
>>>> `<top (required)>'
>>>>>>> from
>>>> /Users/clr/apache/git/whimsy/www/board/agenda/spec/actions_spec.rb:6:in
>>>> `require_relative'
>>>>>>> from
>>>> /Users/clr/apache/git/whimsy/www/board/agenda/spec/actions_spec.rb:6:in
>>>> `<top (required)>'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/configuration.rb:1435:in
>>>> `load'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/configuration.rb:1435:in
>>>> `block in load_spec_files'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/configuration.rb:1433:in
>>>> `each'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/configuration.rb:1433:in
>>>> `load_spec_files'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/runner.rb:100:in
>>>> `setup'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/runner.rb:86:in
>>>> `run'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/runner.rb:71:in
>>>> `run'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib/rspec/core/runner.rb:45:in
>>>> `invoke'
>>>>>>> from
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/exe/rspec:4:in
>>>> `<main>'
>>>>>>> /usr/local/Cellar/ruby/2.3.1/bin/ruby
>>>> -I/usr/local/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib:/usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/lib
>>>> /usr/local/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.3/exe/rspec --pattern
>>>> spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
>>>>>>>>
>>>>>>>> Note: these tests are hooked up to run after every push to github; so
>>>> any failure will result in emails.
>>>>>>>>
>>>>>>>> The current tests run the range from simple unit tests to tests that
>>>> run against a local subversion repository to tests that run against a local
>>>> web server to tests that actually run inside a headless browser to test
>>>> javascript.
>>>>>>>>
>>>>>>>> There are no current tests which update LDAP. We would have to figure
>>>> out a strategy on how to do that. This could be as simple as having
>>>> ASF::LDAP.bind change the @ldap instance variable to point to an object
>>>> that mocks out the add and modify functions when ASF::LDAP.bind is called
>>>> in test mode (i.e., ENV['RACK_ENV'] == 'test').
>>>>>>>>
>>>>>>>> But again, I wouldn't start there.
>>>>>>>>
>>>>>>>> The question is: which YAK do you want to shave first? :-)
>>>>>>>>
>>>>>>>>> Craig
>>>>>>>>>>
>>>>>>>>>> - Sam Ruby
>>>>>>>>>>
>>>>>>>>>> On 1/6/18 12:46 PM, Craig Russell wrote:
>>>>>>>>>>>> On Jan 6, 2018, at 9:14 AM, Sam Ruby <[email protected]>
>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/6/18 11:56 AM, Craig Russell wrote:
>>>>>>>>>>>>> Hi Sam,
>>>>>>>>>>>>> Does this thread belong on dev@whimsical now?
>>>>>>>>>>>>
>>>>>>>>>>>> Sure.
>>>>>>>>>>>>
>>>>>>>>>>>>> The tooling should allow for double checking that --rm does not
>>>> remove an active chair. There would have to be a function that given a
>>>> person, looked at all that person's PMC membership and made sure that the
>>>> person is not the chair.
>>>>>>>>>>>>> There must be such a function in agenda but I can't find it atm.
>>>>>>>>>>>>
>>>>>>>>>>>> ASF::Committee.pmcs.map(&:chair).uniq will return a list of people
>>>> who should be in pmc chairs.
>>>>>>>>>>>>
>>>>>>>>>>>> ASF.pmc_chairs will return a list of people who are currently in
>>>> the list.
>>>>>>>>>>>>
>>>>>>>>>>>> Subtracting one list from the other will give you either the list
>>>> of people who should be added, or should be removed.
>>>>>>>>>>> You got just a bit ahead of me here. I was going to suggest that
>>>> removal of pmc chairs from ldap should be "automatic" when adding pmc
>>>> chairs.
>>>>>>>>>>> Then there should be a prompt confirming the removal since the
>>>> script might be buggy, or the checked-out version of committee-info is out
>>>> of date, or other untoward conditions.
>>>>>>>>>>> Then I thought that if you run pmc_chairs --rm with no ids, the
>>>> tool would suggest entries to remove.
>>>>>>>>>>> And then I stopped shaving the yak.
>>>>>>>>>>>>
>>>>>>>>>>>> Warning: this can become a Yak shaving exercise if you let it. The
>>>> next step would be to show these differences and let you act on them. In
>>>> fact, that could have a web interface. In fact, that function should be
>>>> integrated with https://whimsy.apache.org/roster/group/pmc-chairs ...
>>>>>>>>>>> Stepping back a bit here. This exercise is to overcome a deficiency
>>>> in the agenda adjournment process. So it does not have to be perfect.
>>>>>>>>>>> I believe that agenda adjournment already does suggest the list of
>>>> people who should be removed according to the algorithm above. So I was not
>>>> planning on doing any manual removals.
>>>>>>>>>>> In conclusion, the new tool to manually add to pmc_chairs is
>>>> probably sufficient to the task. And I don't know if we want to have the
>>>> tool manually remove from pmc_chairs, given the discussion above. If it's
>>>> useful to infra, fine, but without really tight controls I doubt its
>>>> utility.
>>>>>>>>>>> Craig
>>>>>>>>>>>>
>>>>>>>>>>>>> Craig
>>>>>>>>>>>>
>>>>>>>>>>>> - Sam Ruby
>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jan 6, 2018, at 5:43 AM, Sam Ruby <[email protected]>
>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/5/18 11:38 PM, Craig Russell wrote:
>>>>>>>>>>>>>>> ASF.bind { chairs.add(people) }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My bad. Should have been ASF::LDAP.bind.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've roughed in a script:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>> https://github.com/apache/whimsy/blob/27e591b9d6350d89bd3c3aca058ff57e7070d342/tools/modify_pmcchairs.rb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Sam Ruby
>>>>>>>>>>>>> Craig L Russell
>>>>>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>>>>>> [email protected] http://db.apache.org/jdo
>>>>>>>>>>> Craig L Russell
>>>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>>>> [email protected] http://db.apache.org/jdo
>>>>>>>>> Craig L Russell
>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>> [email protected] http://db.apache.org/jdo
>>>>>>> Craig L Russell
>>>>>>> Secretary, Apache Software Foundation
>>>>>>> [email protected] http://db.apache.org/jdo
>>>>>
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> [email protected] http://db.apache.org/jdo
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> [email protected] http://db.apache.org/jdo
>>>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> [email protected] http://db.apache.org/jdo
>
