On Mon, Jun 15, 2020 at 7:50 PM Craig Russell <apache....@gmail.com> wrote: > > Thanks for that. Now, to test this thing. > > I didn't find any way to do local testing of a cgi script in the officers' or > members' area of whimsy/www. (I'm currently using rackup to test the > roster-emeritus code).
Either of the following will set you up to be able to run cgi scripts locally: https://github.com/apache/whimsy/blob/master/SETUPMYMAC.md https://github.com/apache/whimsy/blob/master/MACOSX.md > So is the best approach here to simply create the coi.cgi in www/officers/ > and test using the live instance? If so, do I have to wait for Godot each > time I commit code until something catches up? Best approach is to invest the time to get things working locally. Second best approach is running the CGI scripts from the command line. Example: ruby www/members/proxy.cgi proxy="Sam%20Ruby" Third best approach is to test using the live instance. Things are set up to auto-deploy. Best case for CGI scripts is that this happens in seconds. Taking a minute or three, however, is not uncommon. Worst case, installation happens the next time puppet runs, which, if I remember correctly, is every half hour. > Thanks, > Craig - Sam Ruby > > On Jun 12, 2020, at 2:00 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > > > $:.unshift '/srv/whimsy/lib' > > require 'whimsy/asf' > > > > committees = ASF::Committee.officers + ASF::Committee.nonpmcs > > > > chairs = committees.map do |committee| > > committee.chairs.map {|chair| chair[:id]} > > end > > > > ids = (chairs.flatten + ASF::Service['board'].members.map(&:id)).uniq > > > > puts ids.map {|id| ASF::Person.find(id)}. > > sort_by {|person| person.public_name.split.rotate(-1)}. > > map {|person| person.public_name} > > > > - Sam Ruby > > > > On Tue, Jun 9, 2020 at 1:05 AM Craig Russell <apache....@gmail.com> wrote: > >> > >> Here's how I'd like to have the COI affirmation tool work. Once the > >> discussion here nears consensus, I'll share the plan with the board. > >> Unless anyone thinks that the tool should have a wider discussion on > >> board@... > >> > >> The tool is protected by officer login and the credentials are sent to the > >> server so that only officers can see the results. > >> > >> The tool executes one GET to retrieve: > >> - the current COI document from foundation/officers/COI/fy2020/template.txt > >> - the current list of officers who are required to affirm their agreement > >> with the COI foundation/officers/COI/fy2020/signatories.txt > >> - the current list of officers and their status (whether they have already > >> affirmed) > >> > >> If the user is required to affirm, and has not done so already, the > >> current COI document modified with the officer's availid and date is > >> presented to the officer in a scroll window along with two buttons: > >> (Cancel) and (Affirm) > >> > >> If the user is not required to affirm, or has already done so, or (Cancel) > >> is pressed, the list of officers and their signing status is displayed. > >> > >> If Affirm is pressed: > >> - the officer's availid and timestamp is sent to the server via POST > >> - POST processing: > >> -- the COI document with the officer's availid and date is written to the > >> file called foundation/officers/COI/fy2020/availid.txt > >> -- the list of officers and their signing status is displayed > >> > >> Open questions: > >> - how to manage the list of officers required to affirm? one possibility > >> is to create a file: foundation/officers/COI/fy2020/officers.txt which is > >> created by secretary/chair at the beginning of each fiscal year. > >> > >> - is officer credentials sufficient for the purpose of this tool, or > >> should the tool be restricted to those officers required to affirm? > >> > >> Feedback? > >> > >> Craig Russell > >> Director, Apache Board > >> apache....@gmail.com > >> > >> > >> > >> > > Craig L Russell > c...@apache.org >
