You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Craig Russell <ap...@gmail.com> on 2018/01/06 20:02:56 UTC
Re: Actions from board meeting
Moving this thread to dev@whimsical...
> On Jan 6, 2018, at 11:46 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On 1/6/18 2:17 PM, Craig Russell wrote:
>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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.
[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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> 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
>>>>>> clr@apache.org http://db.apache.org/jdo
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> clr@apache.org http://db.apache.org/jdo
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Actions from board meeting
Posted by Craig Russell <ap...@gmail.com>.
> On Jan 6, 2018, at 12:02 PM, Craig Russell <ap...@gmail.com> wrote:
>
>>>> 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.
>>
I think it might be good to use the real LDAP instance for testing. That way we know that the changes will really work.
I know that sebb has been testing using a test apache id.
How about adding a test_pmc and test_podling to the LDAP service, and adding test_clr and test_sebb as users? We can then test adding/removing/changing chairs/making members/etc.
Craig
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Actions from board meeting
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jan 8, 2018 at 7:21 PM, sebb <se...@gmail.com> wrote:
> On 9 January 2018 at 00:12, Craig Russell <ap...@gmail.com> wrote:
>>
>>> On Jan 8, 2018, at 1:25 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On 8 January 2018 at 21:21, Craig Russell <ap...@gmail.com> wrote:
>>>>
>>>>> On Jan 8, 2018, at 12:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>
>>>>> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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.
That's not the problem. In particular, the react/app.js is not
included in Vue application which is being tested.
Nor it the module structure particularly relevant. Not all of the
code will be used to construct any one page. More importantly, some
of the code may be used multiple times to construct a page.
I suspect that the problem here is that the action items list is
included multiple times in a page, for example on the shepherd's page.
That doesn't mean that all of the code in the action items page will
be used to construct the page - there may be if statements or other
conditional statements involved.
- Sam Ruby
Re: Actions from board meeting
Posted by sebb <se...@gmail.com>.
On 9 January 2018 at 00:12, Craig Russell <ap...@gmail.com> wrote:
>
>> On Jan 8, 2018, at 1:25 PM, sebb <se...@gmail.com> wrote:
>>
>> On 8 January 2018 at 21:21, Craig Russell <ap...@gmail.com> wrote:
>>>
>>>> On Jan 8, 2018, at 12:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>
>>>> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>>>>>>
>>>>>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net>
>>>> 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 <ru...@intertwingly.net>
>>>> 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
>>>>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>>>>> Craig L Russell
>>>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>>> Craig L Russell
>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>> Craig L Russell
>>>>>>> Secretary, Apache Software Foundation
>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> clr@apache.org http://db.apache.org/jdo
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org http://db.apache.org/jdo
>>>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>
Re: Actions from board meeting
Posted by Craig Russell <ap...@gmail.com>.
> On Jan 8, 2018, at 1:25 PM, sebb <se...@gmail.com> wrote:
>
> On 8 January 2018 at 21:21, Craig Russell <ap...@gmail.com> wrote:
>>
>>> On Jan 8, 2018, at 12:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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?
>>
>> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>>>>>
>>>>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net>
>>> 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 <ru...@intertwingly.net>
>>> 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
>>>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>>>> Craig L Russell
>>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>> Craig L Russell
>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>> Craig L Russell
>>>>>> Secretary, Apache Software Foundation
>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> clr@apache.org http://db.apache.org/jdo
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
>>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Actions from board meeting
Posted by sebb <se...@gmail.com>.
On 8 January 2018 at 21:21, Craig Russell <ap...@gmail.com> wrote:
>
>> On Jan 8, 2018, at 12:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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?
>
> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>>>>
>>>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net>
>> 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 <ru...@intertwingly.net>
>> 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
>>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>>> Craig L Russell
>>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>> Craig L Russell
>>>>>>> Secretary, Apache Software Foundation
>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> clr@apache.org http://db.apache.org/jdo
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org http://db.apache.org/jdo
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>
Re: Actions from board meeting
Posted by Craig Russell <ap...@gmail.com>.
> On Jan 8, 2018, at 12:32 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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"},
./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
./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)
Any idea where this element is defined?
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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>>>
>>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net>
> 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 <ru...@intertwingly.net>
> 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
>>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>>> Craig L Russell
>>>>>>>> Secretary, Apache Software Foundation
>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>> Craig L Russell
>>>>>> Secretary, Apache Software Foundation
>>>>>> clr@apache.org http://db.apache.org/jdo
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> clr@apache.org http://db.apache.org/jdo
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Actions from board meeting
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jan 8, 2018 at 3:15 PM, Craig Russell <ap...@gmail.com> 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?
> ........................
>
> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>>
>>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net>
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 <ru...@intertwingly.net>
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
>>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>>> Craig L Russell
>>>>>>> Secretary, Apache Software Foundation
>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> clr@apache.org http://db.apache.org/jdo
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org http://db.apache.org/jdo
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>
Re: Actions from board meeting
Posted by Craig Russell <ap...@gmail.com>.
After bundle update:
[MacBook-Pro-9:www/board/agenda] clr% rake test
rm test/work/data/board_minutes_2015_02_18.yml
cp test/board_minutes_2015_02_18.yml test/work/data/board_minutes_2015_02_18.yml
/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
* SVN board : /Users/clr/apache/git/whimsy/www/board/agenda/test/work/board
* Agenda work: /Users/clr/apache/git/whimsy/www/board/agenda/test/work/data
#<IO:0x007f7f6b09eb00>
phantomjs is not available in PATH, not loading poltergeist
..................................F....element div: validity error : ID updateStatusForm already defined
........................
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
Craig
> On Jan 6, 2018, at 12:16 PM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net> wrote:
>>>
>>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> 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
>>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>>> Craig L Russell
>>>>>> Secretary, Apache Software Foundation
>>>>>> clr@apache.org http://db.apache.org/jdo
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> clr@apache.org http://db.apache.org/jdo
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Actions from board meeting
Posted by Sam Ruby <ru...@intertwingly.net>.
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 <ru...@intertwingly.net> wrote:
>>
>> On 1/6/18 2:17 PM, Craig Russell wrote:
>>>> On Jan 6, 2018, at 10:42 AM, Sam Ruby <ru...@intertwingly.net> 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 <ru...@intertwingly.net> 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 <ru...@intertwingly.net> 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
>>>>>>> clr@apache.org http://db.apache.org/jdo
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> clr@apache.org http://db.apache.org/jdo
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> clr@apache.org http://db.apache.org/jdo
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>