Re: editing committer fields using the roster tool
On Sun, Feb 28, 2016 at 1:55 PM, sebb wrote: > That looks nice. > > However it takes too long for changes to propagate. > I changed my score in id.a.o and it still has not been updated in > Whimsy several minutes later. > I tried restarting the browser and using a different browser. > Whereas I can see the new score using ldapsearch immediately. I've commited a change that should address this. > Also there are now two places where changes can be made; Whimsy and id.a.o. > This ought to be resolved so people can be given one place to go. My impression is that the infrastructure team are actively looking for a replacement for id.a.o; and are looking to either Syncope or Whimsy as being that replacement. The resolution to https://issues.apache.org/jira/browse/INFRA-9250 is consistent with that impression. As always, replacing a tool that is maintained only when absolutely necessary with one that is maintained by a single individual is not necessarily an improvement. Please do consider contributing to one or more of the three (id, syncope, whimsy) efforts. - Sam Ruby > On 28 February 2016 at 18:33, Sam Ruby wrote: >> I've updated the roster tool based on the discussion and resolution of >> the following issue: >> >> https://issues.apache.org/jira/browse/INFRA-9250 >> >> --- >> >> Usage: >> >> First find and navigate to your committer page: >> >> https://whimsy.apache.org/roster/committer/ >> >> Scroll down to the Spam Assassin Score line and double click on it and >> you will see a form. Change the value and click submit. >> >> --- >> >> This field is probably not the one of highest value. The flow for >> editing other fields. First the field needs to be extracted on the >> server: >> >> https://github.com/apache/whimsy/blob/master/www/roster/models/committer.rb >> >> Next, the field must be displayed with provisions for both a simple >> display and a form: >> >> https://github.com/apache/whimsy/blob/master/www/roster/views/committer.js.rb >> >> Finally, the updates need to be applied when the form is submitted: >> >> https://github.com/apache/whimsy/blob/master/www/roster/views/actions/committer.json.rb >> >> --- >> >> For more information on running scripts and applications on your machine, >> see: >> >> https://github.com/apache/whimsy/blob/master/DEVELOPMENT.md#running-scriptsapplications
Re: PGP keys should display one per line
Whatever is blocking you from testing this change is the bug I would like
to work on.
On Feb 28, 2016 2:21 PM, "sebb" wrote:
> I have two PGP keys which display concatenated.
>
> I think the following patch will fix it, but cannot test it:
>
>
> diff --git a/www/roster/views/committer.js.rb
> b/www/roster/views/committer.js.rb
> index 93ac1af..27856d2 100644
> --- a/www/roster/views/committer.js.rb
> +++ b/www/roster/views/committer.js.rb
> @@ -104,8 +104,12 @@
>
>if @committer.pgp
> _tr do
> - _td 'PGP key'
> - _td @committer.pgp
> + _td 'PGP keys'
> + _td do
> +_ul @committer.pgp do |key|
> + _li {key}
> +end
> + end
> end
>end
>
Re: PGP keys should display one per line
So you went straight for the advanced instructions. Cool.
Did you try rake server?
Which index page are you referring to? The problem looks to be one that
can be solved be the use of relative URLs. If you tell me which index
page, I'll take a look when I get back home.
I do have a vagrant image and a docker image that you can spin up locally.
But you shouldn't need to install the whole site to get one tool working.
That's why I suggest you look at rake server first.
On Feb 28, 2016 4:07 PM, "sebb" wrote:
> On 28 February 2016 at 20:11, Sam Ruby wrote:
> > Whatever is blocking you from testing this change is the bug I would like
> > to work on.
>
> I cannot get Whimsy working locally.
>
> I have got as far as seeing the index page but nothing else works.
>
> e.g.
>
> The requested URL /roster/committer/ was not found on this server.
>
> I added what I thought was the correct config and restarted Apache:
>
> Alias /whimsy/roster/committer/ /srv/whimsy/www/roster/committer
>
> PassengerBaseURI /whimsy/roster/committer
> PassengerAppRoot /srv/whimsy/www/roster/committer
> PassengerAppEnv development
> Options -Multiviews
>
>
> ==
>
> It was a lot easier when there was a test installation.
> I think we should consider having a shared test installlation which is
> auto-updated from a different Git branch.
> Anything else is going to be a big barrier for new developers.
>
> > On Feb 28, 2016 2:21 PM, "sebb" wrote:
> >
> >> I have two PGP keys which display concatenated.
> >>
> >> I think the following patch will fix it, but cannot test it:
> >>
> >>
> >> diff --git a/www/roster/views/committer.js.rb
> >> b/www/roster/views/committer.js.rb
> >> index 93ac1af..27856d2 100644
> >> --- a/www/roster/views/committer.js.rb
> >> +++ b/www/roster/views/committer.js.rb
> >> @@ -104,8 +104,12 @@
> >>
> >>if @committer.pgp
> >> _tr do
> >> - _td 'PGP key'
> >> - _td @committer.pgp
> >> + _td 'PGP keys'
> >> + _td do
> >> +_ul @committer.pgp do |key|
> >> + _li {key}
> >> +end
> >> + end
> >> end
> >>end
> >>
>
Re: PGP keys should display one per line
On Sun, Feb 28, 2016 at 4:56 PM, sebb wrote:
> On 28 February 2016 at 21:28, Sam Ruby wrote:
>> So you went straight for the advanced instructions. Cool.
>>
>> Did you try rake server?
>
> No.
>
> I did not understand what constituted a Rack application.
> But I see that www/roster has a Rakefile so I have just tried
>
> cd /www/roster
> rake server
>
> and I can now see the roster index and can use the committers page
Sweet!
>> Which index page are you referring to? The problem looks to be one that
>> can be solved be the use of relative URLs. If you tell me which index
>> page, I'll take a look when I get back home.
>
> The main one, i.e. whimsy.apache.org
Now I understand. Should you ever want to set up the whole site to
run under Apache httpd, you would need to follow the instructions to
configure the rack applications (now that you know how to identify
them) using Phusion Passenger. Meanwhile, running individual
applications when you need them is much easier.
>> I do have a vagrant image and a docker image that you can spin up locally.
>> But you shouldn't need to install the whole site to get one tool working.
>
>> That's why I suggest you look at rake server first.
>> On Feb 28, 2016 4:07 PM, "sebb" wrote:
>>
>>> On 28 February 2016 at 20:11, Sam Ruby wrote:
>>> > Whatever is blocking you from testing this change is the bug I would like
>>> > to work on.
>>>
>>> I cannot get Whimsy working locally.
>>>
>>> I have got as far as seeing the index page but nothing else works.
>>>
>>> e.g.
>>>
>>> The requested URL /roster/committer/ was not found on this server.
>>>
>>> I added what I thought was the correct config and restarted Apache:
>>>
>>> Alias /whimsy/roster/committer/ /srv/whimsy/www/roster/committer
>>>
>>> PassengerBaseURI /whimsy/roster/committer
>>> PassengerAppRoot /srv/whimsy/www/roster/committer
>>> PassengerAppEnv development
>>> Options -Multiviews
>>>
>>>
>>> ==
>>>
>>> It was a lot easier when there was a test installation.
>>> I think we should consider having a shared test installlation which is
>>> auto-updated from a different Git branch.
>>> Anything else is going to be a big barrier for new developers.
>>>
>>> > On Feb 28, 2016 2:21 PM, "sebb" wrote:
>>> >
>>> >> I have two PGP keys which display concatenated.
>>> >>
>>> >> I think the following patch will fix it, but cannot test it:
>>> >>
>>> >>
>>> >> diff --git a/www/roster/views/committer.js.rb
>>> >> b/www/roster/views/committer.js.rb
>>> >> index 93ac1af..27856d2 100644
>>> >> --- a/www/roster/views/committer.js.rb
>>> >> +++ b/www/roster/views/committer.js.rb
>>> >> @@ -104,8 +104,12 @@
>>> >>
>>> >>if @committer.pgp
>>> >> _tr do
>>> >> - _td 'PGP key'
>>> >> - _td @committer.pgp
>>> >> + _td 'PGP keys'
>>> >> + _td do
>>> >> +_ul @committer.pgp do |key|
>>> >> + _li {key}
>>> >> +end
>>> >> + end
>>> >> end
>>> >>end
>>> >>
>>>
Re: PGP keys should display one per line
On Sun, Feb 28, 2016 at 7:41 PM, sebb wrote: > On 29 February 2016 at 00:17, Sam Ruby wrote: >> On Sun, Feb 28, 2016 at 4:56 PM, sebb wrote: >>> On 28 February 2016 at 21:28, Sam Ruby wrote: >>>> So you went straight for the advanced instructions. Cool. >>>> >>>> Did you try rake server? >>> >>> No. >>> >>> I did not understand what constituted a Rack application. >>> But I see that www/roster has a Rakefile so I have just tried >>> >>> cd /www/roster >>> rake server >>> >>> and I can now see the roster index and can use the committers page >> >> Sweet! >> >>>> Which index page are you referring to? The problem looks to be one that >>>> can be solved be the use of relative URLs. If you tell me which index >>>> page, I'll take a look when I get back home. >>> >>> The main one, i.e. whimsy.apache.org >> >> Now I understand. Should you ever want to set up the whole site to >> run under Apache httpd, you would need to follow the instructions to >> configure the rack applications (now that you know how to identify >> them) using Phusion Passenger. > > I thought I *had* configured www/roster; see my posting from 21:07 > (else-thread) > > How should I have done it? I went back and looked closer. You configured www/roster/committer, not www/roster. Here's my config: PassengerBaseURI /whimsy/roster PassengerAppRoot /var/whimsy/www/roster PassengerAppEnv development Options -Multiviews # CheckSpelling Off Alias /whimsy/roster/ /var/whimsy/www/roster >> Meanwhile, running individual >> applications when you need them is much easier. > > So why would one need to set up the whole site for development? I actually had not done that myself until I wrote up the instructions. Now I've found I like it. If you are working primarily on one tool, or even only expect to work on one tool at a time, then starting and stopping that tool as needed is easy and requires little setup. As somebody who might be working on one tool and want to put that work aside for a moment when a bug report comes in on another tool, having all of the tools ready to be spun up at will by simply visiting the URL is handy. A few days ago, Brett reported a bug in the board agenda tool, so I went to my local copy, saw the problem there, made a fix, saw it worked, committed and pushed it. All without worrying about whether or not I had another server using port 3000. [snip] >>>>> The requested URL /roster/committer/ was not found on this server. >>>>> >>>>> I added what I thought was the correct config and restarted Apache: >>>>> >>>>> Alias /whimsy/roster/committer/ /srv/whimsy/www/roster/committer >>>>> >>>>> PassengerBaseURI /whimsy/roster/committer >>>>> PassengerAppRoot /srv/whimsy/www/roster/committer >>>>> PassengerAppEnv development >>>>> Options -Multiviews >>>>> Note the inclusion of /committer in the AppRoot. The smallest possible Rack application contains two directories and one file: https://github.com/apache/whimsy/tree/master/www/racktest - Sam Ruby
Re: PGP keys should display one per line
On Sun, Feb 28, 2016 at 8:28 PM, sebb wrote: > On 29 February 2016 at 01:04, Sam Ruby wrote: >> On Sun, Feb 28, 2016 at 7:41 PM, sebb wrote: >>> >>> I thought I *had* configured www/roster; see my posting from 21:07 >>> (else-thread) >>> >>> How should I have done it? >> >> I went back and looked closer. You configured www/roster/committer, >> not www/roster. Here's my config: >> >> >> PassengerBaseURI /whimsy/roster >> PassengerAppRoot /var/whimsy/www/roster >> PassengerAppEnv development >> Options -Multiviews >> # CheckSpelling Off >> >> >> Alias /whimsy/roster/ /var/whimsy/www/roster > > Still does not work. > > I get > > The requested URL /roster/committee/ was not found on this server. > > The requested URL /roster/committer/ was not found on this server. > > For http://my.whimsy/roster/ I get a directory listing of www/roster I'm clearly not getting that. Note that I access my copy of whimsy as http://localhost/whimsy, so I would access the roster application as http://localhost/whimsy/roster. If you are trying to 'mount' the roster application at the root of your webserver, your setup would look something like this: Alias /roster/ /srv/whimsy/www/roster/committer PassengerBaseURI /roster PassengerAppRoot /srv/whimsy/www/roster/committer PassengerAppEnv development Options -Multiviews Should that not work... have you ever run Docker or Vagrant before? I probably can quickly set up one or the other. My thoughts are that once you have a working system that you can compare against, spotting the difference with your current setup would be much easier. And that could lead to updates to the documentation to help others. - Sam Ruby
Re: PGP keys should display one per line
On Mon, Feb 29, 2016 at 5:35 AM, sebb wrote: > > I'm using virtual hosts for different apps (projects, reports, etc) Makes sense. Let's plan to update the "Advanced configuration" section of DEVELOPMENT.md to be based on a vhost. I've attached the current puppet generated vhost definition that is on whimsy-vm2. I suspect with only minimal changes it would work as is on your machine - complete with authentication. Perhaps a "vhost generator" CGI script would be helpful? First it presents a form with a few fields that can be used to customize the result, and then after you click submit it presents a file you can download and drop into your "sites-available" directory? > I guess this is closer to what I need. > >> Alias /roster/ /srv/whimsy/www/roster/committer >> >> PassengerBaseURI /roster >> PassengerAppRoot /srv/whimsy/www/roster/committer >> PassengerAppEnv development >> Options -Multiviews >> > > Doesn't work. > > However this does: > > Alias /roster/ /srv/whimsy/www/roster > > PassengerBaseURI /roster > PassengerAppRoot /srv/whimsy/www/roster > PassengerAppEnv development > Options -Multiviews > > > Yay! Comparing that to what is deployed on whimsy-vm2, I missed a "/public" on the Alias line. >> Should that not work... have you ever run Docker or Vagrant before? I > > I have got Docker; don't think I have used Vagrant. Unless you are a Linux user, Vagrant is better in my opinion. You get a real VM that you can ssh into with full sudo access. With Docker, you get a container, which can only be hosted by Linux at the moment, and that means that for Mac OS/X users you will be putting it into a VM anyway. Since you are up and running, I'll put this on the back burner for now, but it is a good thing to have. >> probably can quickly set up one or the other. My thoughts are that >> once you have a working system that you can compare against, spotting >> the difference with your current setup would be much easier. And that >> could lead to updates to the documentation to help others. > > I think it would help to document what the paths represent, and for > file paths, what one would expect to find there. > > e.g. I assume PassengerAppRoot is a local path, and need to point to a > rake app, i.e. a whimsy directory containing config.ru. > > This should make it easier to check the settings are correct. The best way would be to base the settings on what is actually deployed. The instructions to produce those settings are in infrastructure-puppet, but making the generated results visible and helping you tailor them would be even better. Would you agree? - Sam Ruby
Vhost generator (was: PGP keys should display one per line)
On Mon, Feb 29, 2016 at 10:05 AM, sebb wrote: > On 29 February 2016 at 12:22, Sam Ruby wrote: >> On Mon, Feb 29, 2016 at 5:35 AM, sebb wrote: >>> >>> I'm using virtual hosts for different apps (projects, reports, etc) >> >> Makes sense. Let's plan to update the "Advanced configuration" >> section of DEVELOPMENT.md to be based on a vhost. I've attached the >> current puppet generated vhost definition that is on whimsy-vm2. I >> suspect with only minimal changes it would work as is on your machine >> - complete with authentication. > > Attachment was stolen en route to me ... I blame gnomes. Try this: https://whimsy.apache.org/test/vhost-generator >> Perhaps a "vhost generator" CGI script would be helpful? First it >> presents a form with a few fields that can be used to customize the >> result, and then after you click submit it presents a file you can >> download and drop into your "sites-available" directory? > > I don't have a sites-available directory; I'm using > /etc/apache2/extra/httpd-vhosts.conf > > I think a fixed template would be just as good, together with comments > as to what to edit if necessary. > That would help people understand the config. The template I'm using is live data from the actual deployment. If you have improvements in mind for the template, please contribute them to infrastructure-puppet. But I would like to go further. I believe that the edits can be automated. Once this generator produces a file that you can actually use, I'll go back and update my setup to use a vhost too. At that point, we will have something that two people are using. If others want to follow, at least they won't be trailblazing. > But it would be helpful to have a script to check that the file paths > used in the template contained the expected contents. > >>> I guess this is closer to what I need. >>> >>>> Alias /roster/ /srv/whimsy/www/roster/committer >>>> >>>> PassengerBaseURI /roster >>>> PassengerAppRoot /srv/whimsy/www/roster/committer >>>> PassengerAppEnv development >>>> Options -Multiviews >>>> >>> >>> Doesn't work. >>> >>> However this does: >>> >>> Alias /roster/ /srv/whimsy/www/roster >>> >>> PassengerBaseURI /roster >>> PassengerAppRoot /srv/whimsy/www/roster >>> PassengerAppEnv development >>> Options -Multiviews >>> >>> >>> Yay! >> >> Comparing that to what is deployed on whimsy-vm2, I missed a "/public" >> on the Alias line. >> >>>> Should that not work... have you ever run Docker or Vagrant before? I >>> >>> I have got Docker; don't think I have used Vagrant. >> >> Unless you are a Linux user, Vagrant is better in my opinion. You get >> a real VM that you can ssh into with full sudo access. With Docker, >> you get a container, which can only be hosted by Linux at the moment, >> and that means that for Mac OS/X users you will be putting it into a >> VM anyway. Since you are up and running, I'll put this on the back >> burner for now, but it is a good thing to have. > > Yes. > > If Vagrant is still OK for Linux, then potentially there is no need > for Docker as well. > >>>> probably can quickly set up one or the other. My thoughts are that >>>> once you have a working system that you can compare against, spotting >>>> the difference with your current setup would be much easier. And that >>>> could lead to updates to the documentation to help others. >>> >>> I think it would help to document what the paths represent, and for >>> file paths, what one would expect to find there. >>> >>> e.g. I assume PassengerAppRoot is a local path, and need to point to a >>> rake app, i.e. a whimsy directory containing config.ru. >>> >>> This should make it easier to check the settings are correct. >> >> The best way would be to base the settings on what is actually >> deployed. The instructions to produce those settings are in >> infrastructure-puppet, but making the generated results visible and >> helping you tailor them would be even better. Would you agree? > > Definitely. Cool. See above. - Sam Ruby
Re: Beta test: LDAP updates via whimsy
On Mon, Feb 29, 2016 at 1:34 PM, Rene Gielen wrote: > To follow-up my own report: as it turns out, the addition done through > whimsy was actually succesful. Checked with list_committee.pl and by > reloading https://whimsy-test.apache.org/roster/committee/struts page. > > Seems like the 500 was mis-leading. Thanks for reporting it! It was a recent regression. I've pushed a fix. After it completed the change, there was a bug in the code that collected updated results to be sent back as a response. That's now fixed. > Thanks, > René - Sam Ruby > Am 29.02.16 um 19:31 schrieb Rene Gielen: >> Hi, >> >> the Apache Struts PMC has a new member, Greg Huber (ghuber). >> >> I tried to make the update with whymsy-test. I found ghuber by availid, >> chose "Add to PMC only", and confirmed it in the following dialog. The >> result was HTTP status 500. I'm going to use minotaur now, just wanted >> to let you folks know. >> >> Cheers, >> - René >> >> >> Am 15.02.16 um 23:44 schrieb Sam Ruby: >>> The current plans are for shell access to be phased out. This affects >>> PMC chairs who are responsible for updating LDAP access, something that >>> is currently done via running Perl scripts: >>> >>> https://www.apache.org/dev/pmc.html#SVNaccess >>> https://reference.apache.org/pmc/acreq#SVNaccess >>> >>> PMC chairs (as well as those in the secretary group as well as people >>> with root access) can now make LDAP updates via a web interface: >>> >>> https://whimsy-test.apache.org/roster/committee/ >>> >>> At the moment, this is *just* a replacement for those scripts. Planned >>> additions include: >>> >>> * sending out emails to the PMC when changes are made >>> >>> * updating committee-info.txt >>> >>> Please direct bug reports, feature requests, and pull requests to: >>> >>> dev@whimsical.apache.org >>> https://issues.apache.org/jira/browse/WHIMSY/ >>> https://github.com/apache/whimsy >>> >>> - Sam Ruby >>> >> > > -- > René Gielen > http://twitter.com/rgielen
Re: https://whimsy.apache.org/incubator/podlings/by-age - reverse sort?
On Mon, Feb 29, 2016 at 4:31 PM, sebb wrote: > It might be better to list podlings by reverse order of age so the > newer ones get more exposure? The original purpose of this page was to draw attention to podlings that needed a little push. > Also the links to the podling sites could open in a new window? That's an age old controversy: https://annevankesteren.nl/2004/09/new-window Given that all browsers provide the ability to open a page in a new tab/window (via control, command, or middle - click), I tend to agree that pages should behave consistently, and leave it up to the user to decide. - Sam Ruby
Re: Problems with podlings pages
On Mon, Feb 29, 2016 at 4:40 PM, sebb wrote: > On 29 February 2016 at 21:37, sebb wrote: >> Main page lists a link for: >> >> https://whimsy.apache.org/incubator/podlings/by-age >> >> This lists 50 PPMCs >> >> https://whimsy.apache.org/roster lists How did you get to this page? It should have a trailing slash. Do we need to add the following to infrastructure-puppet/data/nodes/whimsy-vm2.apache.org.yaml RedirectMatch ^/roster$ /roster/ >> 51PodlingsActive podlings at the ASF => >> https://whimsy.apache.org/podlings => 404 >> >> Not sure where the link is supposed to go > > Found it at > > https://whimsy.apache.org/roster/podlings > > However this repeats the information in, and indeed links to, > http://incubator.apache.org/projects/#current Apparently not. One has 50 and one has 51. :-) > Not sure why there is a need for this duplication. > Why not just link to the incubator site? I do link to the incubator site when you click on an individual podling. The index pages has counts, and can sort in various ways by clicking on the headings. I'm not sure what cross-checks may be useful, but an example where cross-checks find authorizations associated with retired podlings can be found on the groups page. >> or why the pages disagree on >> the number of podlings Nope. I would have thought that the two pages were derived from the same data source. - Sam Ruby
Re: Problems with podlings pages
Feel free to add a link on the main whimsy page, re-order columns, capitalize headings, etc. I also forgot to mention that it is my intent to make the roster tool fully read/write over time... people with the appropriate permissions should be able to make updates from these pages. The ability to edit the SpamAssassin score, and to add/remove committers are just an examples of what possibilities are there. So there may be other read-only views out there. The phone book is an example. I'm personally skeptical of it's functionality to do cross-checks. Not that it duplicates functionality that has been present for a long time in the roster tool (that's fine with me, after all, it has a different target audience). But that it tells the wrong audience (the general public) this information, and does not provide the means to correct it. - Sam Ruby On Mon, Feb 29, 2016 at 5:13 PM, sebb wrote: > On 29 February 2016 at 21:56, Sam Ruby wrote: >> On Mon, Feb 29, 2016 at 4:40 PM, sebb wrote: >>> On 29 February 2016 at 21:37, sebb wrote: >>>> Main page lists a link for: >>>> >>>> https://whimsy.apache.org/incubator/podlings/by-age >>>> >>>> This lists 50 PPMCs >>>> >>>> https://whimsy.apache.org/roster lists >> >> How did you get to this page? > > I typed it in, because it's not linked from the main page. > Perhaps it should be added above the list of its sub-pages? > >> It should have a trailing slash. Do we >> need to add the following to >> infrastructure-puppet/data/nodes/whimsy-vm2.apache.org.yaml >> >> RedirectMatch ^/roster$ /roster/ > > Probably not. > >>>> 51PodlingsActive podlings at the ASF => >>>> https://whimsy.apache.org/podlings => 404 >>>> >>>> Not sure where the link is supposed to go >>> >>> Found it at >>> >>> https://whimsy.apache.org/roster/podlings >>> >>> However this repeats the information in, and indeed links to, >>> http://incubator.apache.org/projects/#current >> >> Apparently not. One has 50 and one has 51. :-) >> >>> Not sure why there is a need for this duplication. >>> Why not just link to the incubator site? >> >> I do link to the incubator site when you click on an individual podling. >> >> The index pages has counts, and can sort in various ways by clicking >> on the headings. > > Did not realise that; it's not immediately obvious. > I think the Status column should be between the Name and Description > (and IMO they would be more obvious if they were capitalised). > >> I'm not sure what cross-checks may be useful, but an >> example where cross-checks find authorizations associated with retired >> podlings can be found on the groups page. > > Current podlings may have a non-LDAP group (for SVN auth); this should > disappear when the podling graduates (it's replaced by an LDAP > committee group) or retires (it should be removed). > >>>> or why the pages disagree on >>>> the number of podlings >> >> Nope. I would have thought that the two pages were derived from the >> same data source. > > They should both be derived from podlings.xml, but maybe they > interpret it differently. > Or maybe they are using different copies - there's the original SVN, > then maybe a staging copy and the deployed copy. > If a change has not been fully pushed there could be discrepancies. > >> - Sam Ruby
Re: Problems with podlings pages
On Mon, Feb 29, 2016 at 4:37 PM, sebb wrote: > Not sure [snip] why the pages disagree on > the number of podlings quarks - Sam Ruby
Re: Access to single SVN items - implement caching?
On Wed, Mar 2, 2016 at 8:09 AM, sebb wrote: > Some of the code needs access to a single file in SVN, e.g. > > https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml > > AFAIK there are no other items needed in the same part of SVN. > > Yet one has to checkout the parent directory and keep it updated. > > This is a nuisance for testing purposes. > > For SVN files that don't need authentication, it is easy enough to > fetch the file using HTTP(S) and cache it locally. For subsequent > requests, the cache date can be used in an If-Modified request. > The last checked date can also be saved to avoid checking the file too often. > > This technique has been used in reporter.a.o for checking the chair > index in foundation/index.mdtext: > > https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk/scripts/parsepmcs.py > > Might be worth cosidering re-implementing the python caching code used there. As very few of the resources accessed by whimsy are public, that would only solve a small part of the problem. Given that the resources needed are declared in https://github.com/apache/whimsy/blob/master/repository.yml, perhaps a more complete solution would be to use the 'svn:update' task defined in https://github.com/apache/whimsy/blob/master/Rakefile#L66 ? At the moment, that task is assuming that you do *NOT* override :svn: in your .whimsy config file. Perhaps it should handle that case? - Sam Ruby
Re: Access to single SVN items - implement caching?
On Wed, Mar 2, 2016 at 9:22 AM, sebb wrote: > On 2 March 2016 at 13:52, Sam Ruby wrote: >> On Wed, Mar 2, 2016 at 8:09 AM, sebb wrote: >>> Some of the code needs access to a single file in SVN, e.g. >>> >>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml >>> >>> AFAIK there are no other items needed in the same part of SVN. >>> >>> Yet one has to checkout the parent directory and keep it updated. >>> >>> This is a nuisance for testing purposes. >>> >>> For SVN files that don't need authentication, it is easy enough to >>> fetch the file using HTTP(S) and cache it locally. For subsequent >>> requests, the cache date can be used in an If-Modified request. >>> The last checked date can also be saved to avoid checking the file too >>> often. >>> >>> This technique has been used in reporter.a.o for checking the chair >>> index in foundation/index.mdtext: >>> >>> https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk/scripts/parsepmcs.py >>> >>> Might be worth cosidering re-implementing the python caching code used >>> there. >> >> As very few of the resources accessed by whimsy are public, that would >> only solve a small part of the problem. > > Which in itself is an issue - should we be encouraging downloading all > these resources for testing purposes? > > In particular, it seems wrong to have to download all the ICLAs. Ideally, applications would only make optional use of such repositories - and would check to see if ASF::SVN returned nil or not. >> Given that the resources needed are declared in >> https://github.com/apache/whimsy/blob/master/repository.yml, perhaps a >> more complete solution would be to use the 'svn:update' task defined >> in https://github.com/apache/whimsy/blob/master/Rakefile#L66 ? >> >> At the moment, that task is assuming that you do *NOT* override :svn: >> in your .whimsy config file. Perhaps it should handle that case? > > Better would be to have a function to report which entries are > missing, so the user can decide which they want to download based on > what they are testing. > > Maybe also with a function to report which are out of date. I've roughed in such a tool. You will need to do a "bundle update" or otherwise get the latest Wunderbar (1.0.21) to test it out locally. Then run: ruby www/status/svn.cgi And then visit http://localhost:4567/ Checkout is not yet implemented (it would need to prompt you for a destination). This tool is deployed on whimsy, where it runs in read-only mode: https://whimsy.apache.org/status/svn > It might be useful if ASF::SVN raised an error instead of returning > nil when it cannot find the location. > It's not always easy to debug the errors that occur when the SVN dir > is not found. So... it would be helpful if there were two versions of the method to find an SVN directory, one where it is important that the directory is found, and one where the directory is optional (per above). I've now made ASF::SVN.find! and ASF::SVN.find (with and without an exclamation point) methods, and made the [] operator call the find! method for now. - Sam Ruby
Re: Access to single SVN items - implement caching?
On Thu, Mar 3, 2016 at 3:50 PM, sebb wrote: > On 3 March 2016 at 13:28, Sam Ruby wrote: >> On Wed, Mar 2, 2016 at 9:22 AM, sebb wrote: >>> >>> Better would be to have a function to report which entries are >>> missing, so the user can decide which they want to download based on >>> what they are testing. >>> >>> Maybe also with a function to report which are out of date. >> >> I've roughed in such a tool. You will need to do a "bundle update" or >> otherwise get the latest Wunderbar (1.0.21) to test it out locally. >> Then run: >> >> ruby www/status/svn.cgi >> >> And then visit http://localhost:4567/ > > That's very cool. > > I'd like to add the local path details if not in read-only mode. > Would that be OK? Local path details are already there :-) Go to https://whimsy.apache.org/status/svn and hover over any text in the first column. I did it this way so that super-wide screens aren't required. - Sam Ruby
Re: Access to single SVN items - implement caching?
On Thu, Mar 3, 2016 at 4:35 PM, sebb wrote: > On 3 March 2016 at 21:12, Sam Ruby wrote: >> On Thu, Mar 3, 2016 at 3:50 PM, sebb wrote: >>> On 3 March 2016 at 13:28, Sam Ruby wrote: >>>> On Wed, Mar 2, 2016 at 9:22 AM, sebb wrote: >>>>> >>>>> Better would be to have a function to report which entries are >>>>> missing, so the user can decide which they want to download based on >>>>> what they are testing. >>>>> >>>>> Maybe also with a function to report which are out of date. >>>> >>>> I've roughed in such a tool. You will need to do a "bundle update" or >>>> otherwise get the latest Wunderbar (1.0.21) to test it out locally. >>>> Then run: >>>> >>>> ruby www/status/svn.cgi >>>> >>>> And then visit http://localhost:4567/ >>> >>> That's very cool. >>> >>> I'd like to add the local path details if not in read-only mode. >>> Would that be OK? >> >> Local path details are already there :-) >> >> Go to https://whimsy.apache.org/status/svn and hover over any text in >> the first column. > > I see, that's useful. > > However one cannot copy the hover text nor search it except by looking > at the source. OK, so how about a column that only shows if the window is wide enough? https://github.com/apache/whimsy/commit/c26dbfdd4b0a258b3fdbdb7f122d0da4e6b606c6 >> I did it this way so that super-wide screens aren't required. >> >> - Sam Ruby - Sam Ruby
Re: Access to single SVN items - implement caching?
On Fri, Mar 4, 2016 at 10:03 AM, sebb wrote: > On 4 March 2016 at 00:19, Sam Ruby wrote: >> On Thu, Mar 3, 2016 at 4:35 PM, sebb wrote: >>> On 3 March 2016 at 21:12, Sam Ruby wrote: >>>> On Thu, Mar 3, 2016 at 3:50 PM, sebb wrote: >>>>> On 3 March 2016 at 13:28, Sam Ruby wrote: >>>>>> On Wed, Mar 2, 2016 at 9:22 AM, sebb wrote: >>>>>>> >>>>>>> Better would be to have a function to report which entries are >>>>>>> missing, so the user can decide which they want to download based on >>>>>>> what they are testing. >>>>>>> >>>>>>> Maybe also with a function to report which are out of date. >>>>>> >>>>>> I've roughed in such a tool. You will need to do a "bundle update" or >>>>>> otherwise get the latest Wunderbar (1.0.21) to test it out locally. >>>>>> Then run: >>>>>> >>>>>> ruby www/status/svn.cgi >>>>>> >>>>>> And then visit http://localhost:4567/ >>>>> >>>>> That's very cool. >>>>> >>>>> I'd like to add the local path details if not in read-only mode. >>>>> Would that be OK? >>>> >>>> Local path details are already there :-) >>>> >>>> Go to https://whimsy.apache.org/status/svn and hover over any text in >>>> the first column. >>> >>> I see, that's useful. >>> >>> However one cannot copy the hover text nor search it except by looking >>> at the source. >> >> OK, so how about a column that only shows if the window is wide enough? >> >> https://github.com/apache/whimsy/commit/c26dbfdd4b0a258b3fdbdb7f122d0da4e6b606c6 > > Great, though maybe it should be disabled for the read-only case i.e. > on the live system. I don't see the harm. > Maybe it could depend on whether the script was run directly or via > the webserver? > > If run under a webserver, one probably does not want the buttons either. I'm currently running it under a webserver with suexec enabled, and the buttons work for me. That being said, if/when you try out https://whimsy.apache.org/test/vhost-generator and it gets to the point where it works for you, I plan to switch to that. The secretary workbench is the only remaining application that updates files in the svn working directory (something that has proven to be problematic), and its eventual replacement (the secmail tool) will no longer do that. So I won't need suexec any more. In any case, you don't need my permission to make updates. >>>> I did it this way so that super-wide screens aren't required. >>>> >>>> - Sam Ruby >> >> - Sam Ruby - Sam Ruby
Re: [whimsy.git] [1/1] Commit 8e4446b: disable SMTP certificate verification
On Fri, Mar 4, 2016 at 6:03 PM, sebb wrote: > On 4 March 2016 at 22:11, Sam Ruby wrote: >> Commit 8e4446b542c6a69f2d754e4e53ced1860e82617b: >> disable SMTP certificate verification > > Why? The root cause is the procmail isn't configured with a proper certificate: https://github.com/apache/infrastructure-puppet/commit/e0ac1e61706e5651f6ea2c00549f9a5fc1d16b4c > This should be documented in the code. Unless it is fixed properly (which I'm not sure is worth it?), this applies to every bit of code that will be sending email from whimsy. Other locations where this code currently appears (and appeared on the previous whimsy-vm): www/board/agenda/views/actions/feedback.json.rb www/board/agenda/views/actions/send-reminders.json.rb As the number of places where email will be sent is only likely to go up over time, perhaps the right place to document in one of the *.md files in the root directory? - Sam Ruby >> Branch: refs/heads/master >> Author: Sam Ruby >> Committer: Sam Ruby >> Pusher: rubys >> >> >> www/roster/main.rb | + >> >> 5 changes: 5 additions, 0 deletions. >> >> >> >> diff --git a/www/roster/main.rb b/www/roster/main.rb >> index 084d675..0c16b19 100755 >> --- a/www/roster/main.rb >> +++ b/www/roster/main.rb >> @@ -20,6 +20,11 @@ >> require_relative 'banner' >> require_relative 'models' >> >> +# Disable smtp certificate verification >> +Mail.defaults do >> + delivery_method :smtp, openssl_verify_mode: 'none' >> +end >> + >> get '/' do >>if env['REQUEST_URI'].end_with? '/' >> @committers = ASF::Person.list
Re: [whimsy.git] [1/1] Commit 8e4446b: disable SMTP certificate verification
On Fri, Mar 4, 2016 at 6:52 PM, sebb wrote: > On 4 March 2016 at 23:35, Sam Ruby wrote: >> On Fri, Mar 4, 2016 at 6:03 PM, sebb wrote: >>> On 4 March 2016 at 22:11, Sam Ruby wrote: >>>> Commit 8e4446b542c6a69f2d754e4e53ced1860e82617b: >>>> disable SMTP certificate verification >>> >>> Why? >> >> The root cause is the procmail isn't configured with a proper certificate: >> >> https://github.com/apache/infrastructure-puppet/commit/e0ac1e61706e5651f6ea2c00549f9a5fc1d16b4c >> >>> This should be documented in the code. >> >> Unless it is fixed properly (which I'm not sure is worth it?), this >> applies to every bit of code that will be sending email from whimsy. >> Other locations where this code currently appears (and appeared on the >> previous whimsy-vm): >> >> www/board/agenda/views/actions/feedback.json.rb >> www/board/agenda/views/actions/send-reminders.json.rb >> >> As the number of places where email will be sent is only likely to go >> up over time, perhaps the right place to document in one of the *.md >> files in the root directory? > > An alternative would be to extract the e-mail code into a library routine. > This would simplify updates and make it easier to mock it for testing. Excellent suggestion. Done: https://github.com/apache/whimsy/commit/c407730a9c0babdc34200be691470b7b63937be5 - Sam Ruby
Re: /usr/bin/ruby1.9.1 => /usr/bin/ruby
On Sun, Mar 6, 2016 at 6:19 PM, sebb wrote: > About half the ruby script files use /usr/bin/ruby and the others use > /usr/bin/ruby1.9.1 > > I'm not sure it makes sense to force the use of a specific ruby > version in this way. > > Would it not be better to omit the version suffix, and document the > required ruby version(s) elsewhere? Forcing the version of Ruby was more important on whimsy-vm1 which was based on Ubuntu 12.04. The default Ruby on 12.04 was Ruby 1.8.7 which was pre-utf-8 days (similar to the Python 2=>3 transition, just less dramatic). whimsy-vm2 is based on Ubuntu 14.04, with $ ls -l /usr/bin/ruby lrwxrwxrwx 1 root root 9 Feb 15 2014 /usr/bin/ruby -> ruby1.9.1 So feel free to fix this. At the moment, the passenger/rake applications are running Ruby 2.3.0, which has a better garbage collection mechanism, more suited to long running applications. - Sam Ruby
Re: committers: r66267 - /committers/board/committee-info.txt
On Sun, Mar 6, 2016 at 5:51 PM, sebb wrote: > On 6 March 2016 at 01:38, wrote: >> Author: rubys >> Date: Sun Mar 6 01:38:39 2016 >> New Revision: 66267 >> >> Log: >> whimsy += humbedooh >> >> Modified: >> committers/board/committee-info.txt >> >> Modified: committers/board/committee-info.txt >> == >> --- committers/board/committee-info.txt [utf-8] (original) >> +++ committers/board/committee-info.txt [utf-8] Sun Mar 6 01:38:39 2016 >> @@ -4436,6 +4436,7 @@ NOTE: >> Brett Porter [2015-05-20] >> Chris Mattmann [2015-05-20] >> Craig L Russell >> [2015-12-14] >> +Daniel Gruno [2016-03-05] > > What's the time zone for the starting date? > Perhaps it should be UTC? whimsy-vm2 is running on UTC, so those that use the deployed version would work as expected. This test was run on my machine, which is EST. In any case, good catch, and I've pushed a fix. [2015-05-20] >> Jim Jagielski >> [2015-05-20] - Sam Ruby
Re: /usr/bin/ruby1.9.1 => /usr/bin/ruby
On Mon, Mar 7, 2016 at 6:33 AM, sebb wrote: > On 7 March 2016 at 00:24, Sam Ruby wrote: >> On Sun, Mar 6, 2016 at 6:19 PM, sebb wrote: >>> About half the ruby script files use /usr/bin/ruby and the others use >>> /usr/bin/ruby1.9.1 >>> >>> I'm not sure it makes sense to force the use of a specific ruby >>> version in this way. >>> >>> Would it not be better to omit the version suffix, and document the >>> required ruby version(s) elsewhere? >> >> Forcing the version of Ruby was more important on whimsy-vm1 which was >> based on Ubuntu 12.04. The default Ruby on 12.04 was Ruby 1.8.7 which >> was pre-utf-8 days (similar to the Python 2=>3 transition, just less >> dramatic). >> >> whimsy-vm2 is based on Ubuntu 14.04, with >> >> $ ls -l /usr/bin/ruby >> lrwxrwxrwx 1 root root 9 Feb 15 2014 /usr/bin/ruby -> ruby1.9.1 >> >> So feel free to fix this. > > Done. > >> At the moment, the passenger/rake applications are running Ruby 2.3.0, >> which has a better garbage collection mechanism, more suited to long >> running applications. > > It occurs to me now that maybe > > A) #!/usr/bin/env ruby [1] > or > B) #!/usr/local/bin/ruby > > would be better, especially for MacOSX El Capitan which locks down /usr/bin. > AIUI this is because OSX uses ruby and needs to ensure a consistent > version, so even though one can in theory update /usr/bin/ruby, it's > not a good idea. > There may be other OSes to which this applies. > > Option A) requires the appropriate PATH to be set, so this can be vary > between different environments, making it harder to debug. > Option B) is simpler to follow and administrate, but less flexible > (though more flexible than /usr/bin/ruby!) I'm OK with A, and it works on whimsy-vm2, my Ubuntu machines, and my Mac machines. Whereas B doesn't work currently on any of those machines. It would require a symlink to be set up. So... if you want to proceed with A, that's fine with me. Let's reserve 'B' for any case where a specific version of Ruby is called for, e.g., /usr/local/bin/ruby2.3.0. - Sam Ruby > S. > [1] https://en.wikipedia.org/wiki/Env > >> - Sam Ruby
Re: Problems with gem library path when using bundle
On Mon, Mar 7, 2016 at 10:41 AM, sebb wrote: > I have two ruby installations on MacOSX; 2.3.0 (/usr/local/bin/ruby) > and 2.0.0 (/usr/bin/ruby) > > Since installing 2.3.0 and making it the default, ruby can no longer > find most of the gems. > > This is because the gem environment is different for 2.3.0. > > I tried using bundle install, but that does not seem to take any > notice of the gem environment. > > Any idea how to fix it so bundle picks up the correct environment? It is not clear to me how you installed 2.3.0, or what your intent is. So I'll give multiple answers, pick the one that works best for you. :-) 1) I would like everything on Whimsy to be able to work with the default version of Ruby on popular environments like Mac OS/X and Ubuntu. So 1.9.3(*) or above should be fine for now. Deployment is a different matter; 2.3.0 has better garbage collection so should do better for long running tasks. 2) If you really want to have multiple Rubies and switch between them, you really should look into rvm or rbenv (I prefer rvm, but most Mac users tend to gravitate to rbenv). 3) You indicated that you want to make 2.3.0 your default. That should be fine, but apparently you haven't updated gems? Some commands to try: $ which gem $ gem env $ ruby -e "p Gem.paths.home" $ ruby -e "p Gem.default_path" - Sam Ruby (*) Note Ubuntu refers to this as 1.9.1 for bizarre historical reasons. Whimsy-vm2 is running ruby 1.9.3p484.
Re: RECOVERY: whimsy.apache.org (whimsy.apache.org (https)) is back up!
On Mon, Mar 7, 2016 at 2:14 PM, Jim Jagielski wrote: > Does it make sense to filters these auto messages? I don't believe that LDAP failover, for example, should generate a message. I've suggested two solutions: not use "warning" for that, or changing it so that warning doesn't generate a message. I leave it up to Sebb to decide which is best for the tools that he has been primarily focused on: i.e., public_json. - Sam Ruby >> On Mar 4, 2016, at 7:23 AM, Ping My Box wrote: >> >> >> Hello, >> The https service at whimsy.apache.org (whimsy.apache.org (https)) seems to >> be back in working order again. >> >> With regards, >> Ping My Box - https://www.pingmybox.com/ >
Re: Perhaps I ought to step down as PMC Chair after-all
On Wed, Feb 17, 2016 at 8:23 PM, Mattmann, Chris A (3980) wrote: > My rationale is that the chair also makes sense to be someone > heavily vested in the project’s success which of course you are > Sam. We don’t have to worry about BDFL here. You’re the opposite > and someone we trust. > > Beyond that, if someone else really comes up in Whimsy (like Sebb > is doing), maybe at some point he steps in as chair.. OK, the board meeting is coming up in a little over a week. I guess I should submit a chair change resolution? - Sam Ruby > ++ > Chris Mattmann, Ph.D. > Chief Architect > Instrument Software and Science Data Systems Section (398) > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 168-519, Mailstop: 168-527 > Email: chris.a.mattm...@nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Associate Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ > > > > > > -Original Message- > From: on behalf of Sam Ruby > Reply-To: "dev@whimsical.apache.org" > Date: Wednesday, February 17, 2016 at 12:08 PM > To: "dev@whimsical.apache.org" > Subject: Re: Perhaps I ought to step down as PMC Chair after-all > >>On Wed, Feb 17, 2016 at 1:51 PM, Mattmann, Chris A (3980) >> wrote: >>> +1 thank you for your service Ross. >>> >>> Sam prepared the report this month - any objections to him >>> being the chair? >> >>I'm not opposed to the workload, but if there is anybody else >>willing/able to take this role, I think it would help ensure that >>there were multiple eyes on the project. I think that was part of the >>thinking behind Ross's original volunteering for this role; but (quite >>understandably given his workload), it didn't quite work out as hoped. >> >>- Sam Ruby >
Re: Podling reminder emails
On Tue, Mar 8, 2016 at 7:14 AM, John D. Ament wrote: > Hi, > > So, I'm following up on the podling reminder emails. I know I was looking > at this a long time ago, but decided I needed to learn a bit about ruby > (the language) before trying my hands at coming up with a replacement > script. > > So I was wondering, if I do get a script created would whimsy be able to > run it on a monthly basis in favor of the marvin script? I'll give two answers, short term and long term. --- Short term, what would be most helpful to start is a detailed description of the current (manual) process, complete with examples or templates of the emails that are sent out. With that in place, I (or others) can code up something that you can initially run on your own machine. I trust that you will find that tweaking a running program where you can see the outputs instantly to be a less daunting task than writing an entirely new program in a language that you are not familiar with. Once it is working, it can be hooked up to either run as a cron job or as needed, with a a push of a button. To see an example of the latter, enable your javascript console in your browser, go to https://whimsy.apache.org/board/agenda/2016-03-16/missing, click on one of the buttons at the bottom, then click on Dry Run. --- Longer term, I feel that the current board agenda treatment of the incubator items to be suboptimal - it displays them as a single report. Splitting them into separate pages that can be navigated through would be a good start. If there were separate pages per incubator item, then people could use those pages to submit reports, and features like mentor signoff and enabling comments and discussions on individual reports would be a possibility. Should there be interest in this longer term vision, that might influence how the short term step was implemented. > John - Sam Ruby
Re: Podling reminder emails
On Tue, Mar 8, 2016 at 7:36 AM, John D. Ament wrote: > On Tue, Mar 8, 2016 at 7:30 AM Sam Ruby wrote: > >> On Tue, Mar 8, 2016 at 7:14 AM, John D. Ament >> wrote: >> > Hi, >> > >> > So, I'm following up on the podling reminder emails. I know I was >> looking >> > at this a long time ago, but decided I needed to learn a bit about ruby >> > (the language) before trying my hands at coming up with a replacement >> > script. >> > >> > So I was wondering, if I do get a script created would whimsy be able to >> > run it on a monthly basis in favor of the marvin script? >> >> I'll give two answers, short term and long term. >> >> --- >> >> Short term, what would be most helpful to start is a detailed >> description of the current (manual) process, complete with examples or >> templates of the emails that are sent out. With that in place, I (or >> others) can code up something that you can initially run on your own >> machine. I trust that you will find that tweaking a running program >> where you can see the outputs instantly to be a less daunting task >> than writing an entirely new program in a language that you are not >> familiar with. Once it is working, it can be hooked up to either run >> as a cron job or as needed, with a a push of a button. >> >> To see an example of the latter, enable your javascript console in >> your browser, go to >> https://whimsy.apache.org/board/agenda/2016-03-16/missing, click on >> one of the buttons at the bottom, then click on Dry Run. >> >> --- >> >> Longer term, I feel that the current board agenda treatment of the >> incubator items to be suboptimal - it displays them as a single >> report. Splitting them into separate pages that can be navigated >> through would be a good start. If there were separate pages per >> incubator item, then people could use those pages to submit reports, >> and features like mentor signoff and enabling comments and discussions >> on individual reports would be a possibility. >> >> Should there be interest in this longer term vision, that might >> influence how the short term step was implemented. >> > > I think we'll need to look long and hard at what the IPMC's report is vs > what is all of the podling reports. It may be a better use of time to > allow the IPMC to flag podling reports and make comments over the board, > just because of chain of authority. I'm not being paid to do this, so don't worry too much about my time :-) Imagine what could be placed at https://whimsy.apache.org/incubator/reports. What should the ACLs be? What actions do people do today via "svn update; use favorite editor; svn commit" where a push of a button might be easier? Imagine not only mass mailings, but a button on every podling report that will make it easy for you to email just that podling. And with a dropdown on that page that lets you navigate quickly to prior reports. These are but a few things that board members have access to. Things that might make the job of those that actively participate in the incubator easier. All without interfering with those that prefer to update the files in subversion or elsewhere directly. > This would be an interim solution where a simple script could be run to > generate the email. A template would follow what Marvin (the person) > usually sends out > > http://mail-archives.apache.org/mod_mbox/incubator-kudu-dev/201512.mbox/%3C20151230220215.0C02B189F5%40minotaur.apache.org%3E A template is just one part of the process. Deciding which podlings need to be reminded, and where to send those reminders is also important. In particular, what are the exceptions. This very mailing list is an exception, where the name does not match the PMC for ASF infrastructure implementation reasons. > John - Sam Ruby
Re: Podling reminder emails
On Tue, Mar 8, 2016 at 7:54 AM, Sam Ruby wrote: > > A template is just one part of the process. Deciding which podlings > need to be reminded, and where to send those reminders is also > important. In particular, what are the exceptions. This very mailing > list is an exception, where the name does not match the PMC for ASF > infrastructure implementation reasons. To facilitate discussion, I tossed together a quick and dirty cross reference of active podlings vs mailing lists: https://whimsy.apache.org/incubator/maillist In particular, look for the gaps. I'm confident that this can be easily corrected, but this is the types of problems than need looking into. And an example of the types of problems that trip up automated jobs, either causing them to fail outright; or worse to silently fail. For those interested, the source is here: https://github.com/apache/whimsy/blob/master/www/incubator/maillist.cgi - Sam Ruby
Re: RECOVERY: whimsy.apache.org (whimsy.apache.org (https)) is back up!
On Mon, Mar 7, 2016 at 6:02 PM, sebb wrote: > On 7 March 2016 at 19:25, Sam Ruby wrote: >> On Mon, Mar 7, 2016 at 2:14 PM, Jim Jagielski wrote: >>> Does it make sense to filters these auto messages? >> >> I don't believe that LDAP failover, for example, should generate a >> message. I've suggested two solutions: not use "warning" for that, or >> changing it so that warning doesn't generate a message. I leave it up >> to Sebb to decide which is best for the tools that he has been >> primarily focused on: i.e., public_json. > > I don't think PMB needs to report on warnings. > However equally I don't think they should be lost to history once the > next job runs or the next warning occurs. > This means keeping some kind of log of the events; PMB has been > performing that role so far, though it's not ideal. > > At present we keep only the current log, and archive it if there is a > warning or higher. > This only preserves the latest warning for each job. If you want to use a mailing list as a log, perhaps it would be best to have a separate one? https://infra.apache.org/officers/mlreq - Sam Ruby >> - Sam Ruby >> >>>> On Mar 4, 2016, at 7:23 AM, Ping My Box wrote: >>>> >>>> >>>> Hello, >>>> The https service at whimsy.apache.org (whimsy.apache.org (https)) seems >>>> to be back in working order again. >>>> >>>> With regards, >>>> Ping My Box - https://www.pingmybox.com/ >>>
Re: [whimsy.git] [1/1] Commit 9abe73d: Extract podling groups etc from asf-authorization-template
I've modified public_nonldap_groups.rb to reuse the existing
authorization parsing in whimsy/asf.
Since this merits discussion before merging, I put it into a pull request:
https://github.com/apache/whimsy/pull/5
There also are 'pit-' groups that can be handled the same way.
Feel free to merge or delete the branch. Or to make improvements to
the underlying ASF::Authorization class:
https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/auth.rb
- Sam Ruby
On Sat, Jan 23, 2016 at 7:34 PM, Sebastian Bazley wrote:
> Commit 9abe73d558a1a5fffe38759797e4a57845e35b12:
> Extract podling groups etc from asf-authorization-template
>
>
> Branch: refs/heads/master
> Author: Sebb
> Committer: Sebb
> Pusher: sebb
>
>
> www/roster/public_nonldap_groups.rb | +
>
> 65 changes: 65 additions, 0 deletions.
>
>
>
> diff --git a/www/roster/public_nonldap_groups.rb
> b/www/roster/public_nonldap_groups.rb
> new file mode 100644
> index 000..28e4f5d
> --- /dev/null
> +++ b/www/roster/public_nonldap_groups.rb
> @@ -0,0 +1,65 @@
> +# Not all authorization groups are defined in LDAP, for example podlings
> +# Extract these from asf-authorization-template
> +#
> +# We use the Git copy rather than the SVN version:
> +# - it is available without needing auth
> +# - the groups don't take effect unless the Git copy is updated
> +# - the SVN copy is due to be retired (one day)
> +# Unfortunately the Git HTTP server does not support If-Modified-Since or
> ETag
> +#
> +# Output looks like:
> +# {
> +# "git_info": "5623ad5 2016-01-23 16:26:01 -0500",
> +# "groups": {
> +# "batchee": [
> +# "uid",
> +# ...
> +# ]
> +#},
> +#
> +
> +require 'bundler/setup'
> +
> +require 'whimsy/asf'
> +
> +require 'net/http'
> +require 'json'
> +require 'open3'
> +
> +GITINFO = ASF.library_gitinfo rescue '?'
> +
> +file =
> '/apache/infrastructure-puppet/deployment/modules/subversion_server/files/authorization/asf-authorization-template'
> +http = Net::HTTP.new('raw.githubusercontent.com', 443)
> +http.use_ssl = true
> +body = http.request(Net::HTTP::Get.new(file)).body
> + .sub(/^.*\[groups\]\s*$/m,'')
> + .sub(/^\[\/\].*/m,'')
> +
> +groups = {}
> +
> +# find the locally defined groups
> +body.scan(/^(\w[^=\s]*)[ \t]*=[ \t]*(\w.*)$/) do |grp, mem|
> + groups[grp] = mem.gsub(/\s/,'').split(/,/).sort.uniq
> +end
> +
> +info = {
> + # There does not seem to be a useful timestamp here
> + git_info: GITINFO,
> + groups: groups,
> +}
> +
> +# format as JSON
> +results = JSON.pretty_generate(info)
> +
> +# parse arguments for output file name
> +if ARGV.length == 0 or ARGV.first == '-'
> + # write to STDOUT
> + puts results
> +elsif not File.exist?(ARGV.first) or File.read(ARGV.first) != results
> +
> + out, err, rc = Open3.capture3('diff', '-u', ARGV.first, '-', stdin_data:
> results)
> + puts out if err.empty? and rc.exitstatus == 1
> +
> + # replace file as contents have changed
> + File.write(ARGV.first, results)
> +end
Re: Podling reminder emails
On Tue, Mar 8, 2016 at 9:23 AM, Sam Ruby wrote: > On Tue, Mar 8, 2016 at 7:54 AM, Sam Ruby wrote: >> >> A template is just one part of the process. Deciding which podlings >> need to be reminded, and where to send those reminders is also >> important. In particular, what are the exceptions. This very mailing >> list is an exception, where the name does not match the PMC for ASF >> infrastructure implementation reasons. > > To facilitate discussion, I tossed together a quick and dirty cross > reference of active podlings vs mailing lists: > > https://whimsy.apache.org/incubator/maillist > > In particular, look for the gaps. I'm confident that this can be > easily corrected, but this is the types of problems than need looking > into. And an example of the types of problems that trip up automated > jobs, either causing them to fail outright; or worse to silently fail. First level analysis: 1) old podlings which had mailing lists created using a different (more difficult to graduate) infrastructure implementation: blur, wave 2) new podlings that don't yet have a mailing list: gearpump, mnemonic 3) podlings whose mailing lists are hosted by their sponsoring project: log4cxx2 4) podlings whose mailing lists are named differently: odftoolkit Thoughts? - Sam Ruby
Re: [whimsy.git] [1/1] Commit 7d81d25: try harder to strip whitespace
On Thu, Mar 10, 2016 at 10:58 AM, sebb wrote: > On 10 March 2016 at 12:57, Sam Ruby wrote: >> Commit 7d81d25a38dcc6afba6ef82f87b1e029a69eb714: >> try harder to strip whitespace >> I'll admit that I can see no reason why this should be necessary, and >> yet it seems to occur in log files. ¯\_(ツ)_/¯ > > Thanks, that seems to have fixed it. > > It's rather odd that this only started happening recently. > > AFAICT that piece of code has not been changed for ages; perhaps the > git client has been updated? > The only other possibility I can think of is that $/ has been changed > somewhere? Beats me. FWIW, I can't reproduce on Whimsy either: www-data@whimsy-vm2:/srv/whimsy$ irb irb(main):001:0> `git show --format="%h %ci" -s HEAD`.chomp => "7d81d25 2016-03-10 07:57:37 -0500" irb(main):002:0> ¯\_(ツ)_/¯ - Sam Ruby
Re: Add PMC to subject? (was: ASF Board Report for March 2016 is now due)
On Thu, Mar 10, 2016 at 10:51 AM, sebb wrote: > I think it might be useful to customise the Subject with the PMC name? > > This would certainly help with GMail threading. The files that would need to be updated are here: https://github.com/apache/whimsy/tree/master/www/board/agenda/data - Sam Ruby > On 10 March 2016 at 11:30, Brett Porter wrote: >> This email was sent on behalf of the ASF Board. >> >> According to board records, you are listed as the chair of a committee that >> is due to submit a report this month. These reports are now due and should >> be submitted to the board as soon as possible but no later than >> Wed Mar 9th. >> >> The meeting is scheduled for Wed, 16 Mar 2016 at 10:30 PDT. >> Times in other time zones: >> >> http://timeanddate.com/s/2yr0 >> >> Full details about the process and schedule are in [1]. >> >> The report should be committed to the meeting agenda in the board directory >> in the foundation repository, trying to keep a similar format to the others. >> This can be found at: >> >> https://svn.apache.org/repos/private/foundation/board >> >> Reports can also be posted using the online agenda tool: >> >> https://whimsy.apache.org/board/agenda/2016-03-16/Whimsy >> >> Your report should also be sent in plain-text format to bo...@apache.org >> with a Subject line that follows the below format: >> >> Subject: [REPORT] Whimsy - March 2016 >> >> Cutting and pasting directly from a Wiki is not acceptable due to formatting >> issues. Line lengths should be limited to 77 characters. >> >> Chairs may use the Apache Reporter Service [3] to help them compile and >> submit a board report. >> >> As always, PMC chairs are welcome to attend the board meeting. >> >> Thanks, >> The ASF Board >> >> [1] - >> https://svn.apache.org/repos/private/committers/board/committee-info.txt >> [2] - https://svn.apache.org/repos/private/committers/board/templates >> [3] - https://reporter.apache.org/ >> >> >> Resolutions >> --- >> >> There are several templates for use for various Board resolutions. >> They can be found in [2] and you are encouraged to use them. It is >> strongly recommended that if you have a resolution before the board, >> you are encouraged to attend that board meeting.
Re: [whimsy.git] [1/1] Commit ac22751: More checks for icla presence
On Sun, Mar 13, 2016 at 9:52 AM, Sebastian Bazley wrote: > > - if person.asf_member? > + if person.asf_member? # TODO is this the correct check? it includes > people in members unix group > member[:info] = person.members_txt In this particular case, I think so. It will only include information from members.txt in the view if you have read access to members.txt. - Sam Ruby
Re: [whimsy.git] [1/1] Commit ac22751: More checks for icla presence
On Sun, Mar 13, 2016 at 10:36 AM, sebb wrote: > On 13 March 2016 at 14:16, sebb wrote: >> On 13 March 2016 at 14:09, Sam Ruby wrote: >>> On Sun, Mar 13, 2016 at 9:52 AM, Sebastian Bazley wrote: >>>> >>>> - if person.asf_member? >>>> + if person.asf_member? # TODO is this the correct check? it includes >>>> people in members unix group >>>> member[:info] = person.members_txt >>> >>> In this particular case, I think so. It will only include information >>> from members.txt in the view if you have read access to members.txt. >> >> Yes, but not everyone in the members unix group is an actual ASF >> member with info in members.txt. >> e.g. pono and other contractors >> >> Have a look at >> >> https://whimsy.apache.org/roster/committer/pono > > More to the point, the member_nomination details are only set up if > the person is not a person.asf_member. > > I.e. had pono been nominated, the code would assume he was already a > member and not show the info. > > I wonder whether ASF::Person::asf_member?() should include Unix members at > all. > Or perhaps there need to be two methods: > asf_isMember? > asf_hasMemberKarma? I'm fine with these changes, though I would probably leave the original name in for a period of time as an alias. I would prefer if pages such as pono's continued to reflect his status as being a part of the members group but not being listed in members.txt. - Sam Ruby
Re: Access to whimsy http logs?
On Sun, Mar 13, 2016 at 11:48 AM, sebb wrote: > It would be very useful to have access to the Whimsy error log when > app errors occur. > > Probably also the access log. > > Since the log may contain relatively private info, this should > probably be restricted to members, in which case I think it can be > achieved by using a suitable symlink under one of the member-only > directories. > > WDYT? Agreed. The following pull request should do the trick: https://github.com/apache/infrastructure-puppet/pull/72 Once that's merged and deployed, I would think a link from the bottom of http://whimsy.apache.org/status/ would be in order. - Sam Ruby
Re: Collate Minutes cannot find ASF::Podling
On Sun, Mar 13, 2016 at 9:43 PM, sebb wrote: > The collate_minutes job is failing with: > > collate_minutes.rb:61:in `': uninitialized constant ASF::Podling > (NameError) > > *** Exception NameError : collate_minutes.rb:61:in `' > uninitialized constant ASF::Podling *** > > I don't get that problem when running it in a command shell. Like me, you probably have RUBYLIB set. :-( I broke this with https://github.com/apache/whimsy/commit/6f93a5273fec0706433531a9406ca040cfc0e77d > The podlings code was added relatively recently; perhaps the > environment which runs the script has not been updated with the latest > whimsy gem? Correct. But I would rather fix the code so that it doesn't depend on the gem: https://github.com/apache/whimsy/commit/f3ae7af285be0d4aa54319c01e8e9ced2fa077d0 That code is the functional equivalent of setting the RUBYLIB environment variable. > Would it help to use bundler in the script? That would also work. > And/or I notice that some Gemfiles check for asf.version and if so use > a local whimsy-asf > Maybe they all should? The tools/Gemfile does not use a local whimsy AFAICT. I'd like to continue to phase out the gem. At this point, they all should use a local version. Unconditionally. - Sam Ruby
Re: Wunderbar logger wrapper level and formatter changes
On Mon, Mar 14, 2016 at 10:10 AM, sebb wrote: > On 14 March 2016 at 12:55, sebb wrote: >> It would be useful to be able to initialise the default log level but >> still allow CLI over-ride. >> >> I've found a hacky fix: >> >> Wunderbar.log_level = 'info' unless Wunderbar.log_level == 'debug' # >> don't override command-line level >> >> however that relies on knowing that debug (and only debug) is more >> verbose than info. > > I can improve that with: > > Wunderbar.log_level = 'info' unless Wunderbar.logger.info? > > however this still overrides a CLI arg of --warn etc. > > I tried another hack: > > ARGV.unshift '--info' > > at the start of the script, but that does not work properly because > Wunderbar does not process ARGV in order. > But even if it did, updating the args would be a hack. > > So I think there needs to be a way to override the default level. I just pushed out a change to wunderbar that adds that: https://github.com/rubys/wunderbar/commit/3e9472f811b616c190bc94d23606c4864ee104cc > It would also be useful to be able to override the default output > stream; $stderr is not always suitable. If you need more interfaces, they can be added to wunderbar. Also, you can create your own logger: http://ruby-doc.org/stdlib-2.3.0/libdoc/logger/rdoc/Logger.html You can even make wunderbar use that logger: Wunderbar.logger = your_custom_logger >> Also modifying the formatter message is a bit messy; it would be >> useful if this could be specified when creating the logger. >> >> I don't know how to do this in Ruby - if it's even possible? - Sam Ruby
Re: Wunderbar logger wrapper level and formatter changes
On Mon, Mar 14, 2016 at 11:09 AM, sebb wrote: > On 14 March 2016 at 14:22, Sam Ruby wrote: >> On Mon, Mar 14, 2016 at 10:10 AM, sebb wrote: >>> On 14 March 2016 at 12:55, sebb wrote: >>>> It would be useful to be able to initialise the default log level but >>>> still allow CLI over-ride. >>>> >>>> I've found a hacky fix: >>>> >>>> Wunderbar.log_level = 'info' unless Wunderbar.log_level == 'debug' # >>>> don't override command-line level >>>> >>>> however that relies on knowing that debug (and only debug) is more >>>> verbose than info. >>> >>> I can improve that with: >>> >>> Wunderbar.log_level = 'info' unless Wunderbar.logger.info? >>> >>> however this still overrides a CLI arg of --warn etc. >>> >>> I tried another hack: >>> >>> ARGV.unshift '--info' >>> >>> at the start of the script, but that does not work properly because >>> Wunderbar does not process ARGV in order. >>> But even if it did, updating the args would be a hack. >>> >>> So I think there needs to be a way to override the default level. >> >> I just pushed out a change to wunderbar that adds that: >> >> https://github.com/rubys/wunderbar/commit/3e9472f811b616c190bc94d23606c4864ee104cc > > Thanks; that works provided the default is set before any logging takes place. > Also it can only be invoked once; subsequent invocations are silently ignored. I thought that was sufficient to meet your needs? Or at least I did, until you mentioned stderr. >>> It would also be useful to be able to override the default output >>> stream; $stderr is not always suitable. >> >> If you need more interfaces, they can be added to wunderbar. > > I'm not sure that's an option for the output stream. > The default_log_level method instantiates the logger; it's then too > late to change the stream as there is no public API in Logger to do > so. > It would require creating a new Logger and copying across the existing > config. Messy. > > Also it's not as efficient as providing them in Wunderbar itself. > I don't think the enhancements are particularly esoteric. Agreed. Issues and/or patches welcome. Testing changes to wunderbar is simply a matter of cloning the repository and setting RUBYLIB or updating the Gemfile. >> Also, >> you can create your own logger: >> >> http://ruby-doc.org/stdlib-2.3.0/libdoc/logger/rdoc/Logger.html >> >> You can even make wunderbar use that logger: >> >> Wunderbar.logger = your_custom_logger > > Yes, but that needs code that basically repeats the existing > constructor; seems wasteful. At times I've thought that the right layering was that whimsy/asf would have its own logger, and would provide it to Wunderbar to deal with applications that use that library. I felt this way as it always felt strange that applications that don't otherwise use the wunderbar library make calls to it to set up logging. I never fully explored what it would take to do that. In any case, I'm quite open to updating wunderbar >>>> Also modifying the formatter message is a bit messy; it would be >>>> useful if this could be specified when creating the logger. >>>> >>>> I don't know how to do this in Ruby - if it's even possible? >> >> - Sam Ruby - Sam Ruby
Re: [whimsy.git] [1/1] Commit 6c2b651: to_h is relatively new; allow code to run on older Ruby versions
On Tue, Mar 15, 2016 at 12:10 PM, Sebastian Bazley wrote:
> Commit 6c2b651834355a5e677906b939449e43fb6b38e3:
> to_h is relatively new; allow code to run on older Ruby versions
Looks messy. :-) I propose the following as a cleaner implementation:
https://github.com/apache/whimsy/commit/a8acbc8b6f7a64a1372348cc62b8c796c7f077c8
- Sam Ruby
> Branch: refs/heads/master
> Author: Sebb
> Committer: Sebb
> Pusher: sebb
>
>
> www/roster/models/group.rb | ---
>
> 22 changes: 16 additions, 6 deletions.
>
>
>
> diff --git a/www/roster/models/group.rb b/www/roster/models/group.rb
> index acc40e9..0015b1d 100644
> --- a/www/roster/models/group.rb
> +++ b/www/roster/models/group.rb
> @@ -8,16 +8,26 @@ def self.list
> groups = ASF::Group.list.map(&:id)
> groups -= ASF::Committee.list.map(&:id)
> groups.map! {|group| [group, "LDAP group"]}
> -
> # add services...
> groups += ASF::Service.list.map {|service| [service, "LDAP service"]}
>
> # add authorization (asf and pit)
> -groups += ASF::Authorization.new('asf').to_h.
> - map {|id, list| [id, "ASF Auth"]}
> -
> -groups += ASF::Authorization.new('pit').to_h.
> - map {|id, list| [id, "PIT Auth"]}
> +begin
> + groups += ASF::Authorization.new('asf').to_h.
> +map {|id, list| [id, "ASF Auth"]}
> +rescue # in case to_h does not work
> + ASF::Authorization.new('asf').each do |id,list|
> +groups += [[id, "ASF Auth"]]
> + end
> +end
> +begin
> + groups += ASF::Authorization.new('pit').to_h.
> +map {|id, list| [id, "PIT Auth"]}
> +rescue # in case to_h does not work
> + ASF::Authorization.new('pit').each do |id,list|
> +groups += [[id, "PIT Auth"]]
> + end
> +end
>
> groups.sort
>end
Re: [whimsy.git] [1/1] Commit 6c2b651: to_h is relatively new; allow code to run on older Ruby versions
On Tue, Mar 15, 2016 at 1:06 PM, sebb wrote: > Thanks - I keep learning new ways to work with Ruby... Keep doing what you are doing. You are doing fine. If I see something broken, I'll fix it. If I see a better way, I'll mention it. After all, you've done the same for me on both counts. - Sam Ruby
Re: Podling reminder emails
Rich Bowen asked a reasonable question in reviewing the Whimsy board report. My reply turned out to be longer than comment length, so I decided to post it here. Once it hits the archives, I'll add a link to this message in the board report. --- Once upon a time there was a bot named Marvin that sent out reminders. It handled both board and incubator reminders. Bots, by their very nature, have to run in a hostile environment and human peccadilloes. Marvin (the bot) often misfired, and was often criticized. Ultimately, it was discontinued. I took on the task of re-implementing board reminders. I took advantage of pre-existing functions in Whimsy. I split out other pieces. This isn't yet automated, but the code for the automation is written, it is simply waiting for Brett's input on whether or not it is ready, and/or whether or not it should be automated (most likely the answer to the latter is yes, and the former is "it is close"). On the incubator side, Marvin (the person) took over sending reminders. There are a number of advantages to it being done by a person - error recovery and factoring in other knowledge are examples. The downside is that this can be labor intensive. Ultimately, this task is rotated, and John inquired here about automation. If there is interest, I would like to help. I answered questions, asked a few, and ultimately the discussion died off. This is not the first time that has happened. For my part, I'll be more than glad to develop either an initial prototype or even the final code -- provided there is somebody I can ask for requirements, and will evaluate and provide feedback on implementations. An example is provided below. There are a small number of exceptions to the names of podling mailing lists. I think I figured out most of them, but I would appreciate a review. - Sam Ruby On Thu, Mar 10, 2016 at 10:21 AM, Sam Ruby wrote: > On Tue, Mar 8, 2016 at 9:23 AM, Sam Ruby wrote: >> On Tue, Mar 8, 2016 at 7:54 AM, Sam Ruby wrote: >>> >>> A template is just one part of the process. Deciding which podlings >>> need to be reminded, and where to send those reminders is also >>> important. In particular, what are the exceptions. This very mailing >>> list is an exception, where the name does not match the PMC for ASF >>> infrastructure implementation reasons. >> >> To facilitate discussion, I tossed together a quick and dirty cross >> reference of active podlings vs mailing lists: >> >> https://whimsy.apache.org/incubator/maillist >> >> In particular, look for the gaps. I'm confident that this can be >> easily corrected, but this is the types of problems than need looking >> into. And an example of the types of problems that trip up automated >> jobs, either causing them to fail outright; or worse to silently fail. > > First level analysis: > > 1) old podlings which had mailing lists created using a different > (more difficult to graduate) infrastructure implementation: blur, wave > > 2) new podlings that don't yet have a mailing list: gearpump, mnemonic > > 3) podlings whose mailing lists are hosted by their sponsoring project: > log4cxx2 > > 4) podlings whose mailing lists are named differently: odftoolkit > > Thoughts? > > - Sam Ruby
Re: https://whimsy.apache.org/members/subscriptions/ fails
Both should be fixed within the hour. Both required cronjobs to be set up on hermes. Both will likely break (and possibly become obsolete) once the infrastructure deploys the new mail system. - Sam Ruby On Tue, Mar 15, 2016 at 8:22 PM, sebb wrote: > Similarly for https://whimsy.apache.org/incubator/moderators > I get > > # /home/apmail/subscriptions/incubator-mods> > /srv/whimsy/www/incubator/moderators.cgi:68:in `read' > > On 16 March 2016 at 00:14, sebb wrote: >> https://whimsy.apache.org/members/subscriptions/ fails with >> >> #> /home/apmail/subscriptions/members> >> /srv/whimsy/www/members/subscriptions.cgi:62:in `readlines' >> >> Is this expected?
Re: https://whimsy.apache.org/members/subscriptions/ fails
On Tue, Mar 15, 2016 at 9:28 PM, sebb wrote: > OK, thanks. > > Might be useful to have some dummy data for use in testing? > Just enough to allow the scripts to work... Why not real data? Perhaps something along the lines of: https://github.com/apache/infrastructure-puppet/commit/7bd764acbbd49425f6178bbf66fc02f6576fdd76 - Sam Ruby > On 16 March 2016 at 00:45, Sam Ruby wrote: >> Both should be fixed within the hour. Both required cronjobs to be >> set up on hermes. Both will likely break (and possibly become >> obsolete) once the infrastructure deploys the new mail system. >> >> - Sam Ruby >> >> On Tue, Mar 15, 2016 at 8:22 PM, sebb wrote: >>> Similarly for https://whimsy.apache.org/incubator/moderators >>> I get >>> >>> #>> /home/apmail/subscriptions/incubator-mods> >>> /srv/whimsy/www/incubator/moderators.cgi:68:in `read' >>> >>> On 16 March 2016 at 00:14, sebb wrote: >>>> https://whimsy.apache.org/members/subscriptions/ fails with >>>> >>>> #>>> /home/apmail/subscriptions/members> >>>> /srv/whimsy/www/members/subscriptions.cgi:62:in `readlines' >>>> >>>> Is this expected?
Re: [whimsy.git] [1/2] Commit 395987f: Don't insist on Ruby 2.3.0
This doesn't work, as you can see here:
https://whimsy.apache.org/status/passenger
The version of Ruby used must match the one specified in the apache config
(/etc/apache2/mods-enabled/passenger.conf on whimsy-vm2). This is
important in both places: in the call to Open3.capture3, and in the
call go Gem.bin_path.
- Sam Ruby
On Fri, Mar 18, 2016 at 12:53 PM, Sebastian Bazley wrote:
> Commit 395987f1782be77841275deaad5188e5d0925071:
> Don't insist on Ruby 2.3.0
>
> diff --git a/www/status/passenger.cgi b/www/status/passenger.cgi
> index 4ccefea..ecca2b7 100755
> --- a/www/status/passenger.cgi
> +++ b/www/status/passenger.cgi
> @@ -1,4 +1,4 @@
> -#!/usr/local/bin/ruby2.3.0
> +#!/usr/bin/env ruby
>
> require 'bundler/setup'
>
> @@ -15,8 +15,7 @@ unless user
>print "WWW-Authenticate: Basic realm=\"ASF Members and Officers\"\r\n\r\n"
>exit
> end
> -
> -output, error, status = Open3.capture3 '/usr/local/bin/ruby2.3.0',
> +output, error, status = Open3.capture3 'ruby',
>Gem.bin_path('passenger', 'passenger-status')
>
> _html do
Re: Auth required for status/passenger
On Thu, Mar 17, 2016 at 7:59 AM, sebb wrote: > The status page says that passenger status is restricted to "ASF > committer only", however the code uses the realm "ASF Members and > Officers". > > Which is correct? At, the moment, the code obviously. :-) Originally, passenger status was open, and authentication was only required when you clicked a button to restart a process. I got feedback that showing a button which a person could not use was not ideal. I don't have a strong opinion as to whether committers should be able to restart processes. At a minimum, I would like members to be able to do so. - Sam Ruby
Re: Does Whimsy really need to have a local Git workspace?
https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_computing I'd like the default for method calls in whimsy/asf to be quick and cached. I wouldn't have a problem with there being an option for opting for a slower but more up to date response. On Mar 18, 2016 5:45 PM, "sebb" wrote: > AFAICT the only Git files that Whimsy needs to be available locally at > runtime are asf-auth and pit-auth. > > The other Git file it uses (data/common.yaml) is read directly from the > server. > > So it seems a bit wasteful to keep a local clone. > One might as well just read the files directly; this will also ensure > that they are more up to date. >
Re: [OT] Wunderbar html - how to output HTML comment with variable content?
On Fri, Mar 18, 2016 at 11:07 AM, sebb wrote:
> On 18 March 2016 at 03:28, Sam Ruby wrote:
>> On Thu, Mar 17, 2016 at 4:19 PM, sebb wrote:
>>> The Wunderbar docs mention outputting text with markup:
>>>
>>> _{"hello!!!"}
>>>
>>> The following also works:
>>>
>>> _{""}
>>>
>>> However it does not seem to be possible to output an HTML comment
>>> which contains any variable text, e.g. a date.
>>>
>>> Is this possible?
>>
>> The indirect way (which I don't recommend):
>>
>> _{""}
>>
>> What that does internally is run an HTML parser on the string, extract
>> nodes, and do the equivalent of the following, which you can do
>> directly:
>
> That presumably explains the need for nokogiri.
> And perhaps the need to untaint.
>
> But I would expect wunderbar to include nokogiri itself or report an
> error if not available?
> Seems odd that the behaviour silently changes depending on what
> happens to be included somewhere in the app.
The history here is that it used to do the require for you at that
point, but when I turned on $SAFE=1, the require would fail, so the
require needs to happen earlier.
The need to untaint (and presumably validate) the input is documented here:
https://github.com/rubys/wunderbar#secure-by-default
What was not documented is that including nokogiri avoids the need to
validate/untaint the input. I've tried(*) to clarify that.
>> _.comment! "fixed comment with #{date}"
>
> I see.
>
> Perhaps that could be documented in the README?
That, too, was documented, albeit obtusely. I've added(*) an example:
https://github.com/rubys/wunderbar#methods-provided-to-wunderbarhtml
- Sam Ruby
(*)
https://github.com/rubys/wunderbar/commit/d025cbaa794d2369ef5588b394ee458b579c93a9
Re: [whimsy.git] [1/1] Commit 1e101ba: Easier to read
On Sat, Mar 19, 2016 at 5:17 AM, Sebastian Bazley wrote:
> Commit 1e101bab079f2cef778ddfe5099e494e21d4e0e9:
> Easier to read
If you are going to go for pretty, consider:
https://github.com/rubys/wunderbar/blob/master/demo/envdump.rb
Changing to html from plain text would enable things like 'redacted'
to be in a different font (e.g. italicized).
- Sam Ruby
>
> Branch: refs/heads/master
> Author: Sebb
> Committer: Sebb
> Pusher: sebb
>
>
> www/board/test.cgi | ++ -
> www/committers/test.cgi | ++ -
> www/members/test.cgi | ++ -
> www/test.cgi | ++ -
>
> 28 changes: 24 additions, 4 deletions.
>
>
>
> diff --git a/www/board/test.cgi b/www/board/test.cgi
> index 011c7f6..2116558 100755
> --- a/www/board/test.cgi
> +++ b/www/board/test.cgi
> @@ -2,4 +2,9 @@
>
> print "Content-type: text/plain\r\n\r\n"
>
> -print ENV.inspect
> +#print ENV.inspect
> +
> +ENV.sort.each do |k,v|
> + print "#{k} #{v}\n"
> +end
> +
> diff --git a/www/committers/test.cgi b/www/committers/test.cgi
> index 011c7f6..2116558 100755
> --- a/www/committers/test.cgi
> +++ b/www/committers/test.cgi
> @@ -2,4 +2,9 @@
>
> print "Content-type: text/plain\r\n\r\n"
>
> -print ENV.inspect
> +#print ENV.inspect
> +
> +ENV.sort.each do |k,v|
> + print "#{k} #{v}\n"
> +end
> +
> diff --git a/www/members/test.cgi b/www/members/test.cgi
> index 011c7f6..2116558 100755
> --- a/www/members/test.cgi
> +++ b/www/members/test.cgi
> @@ -2,4 +2,9 @@
>
> print "Content-type: text/plain\r\n\r\n"
>
> -print ENV.inspect
> +#print ENV.inspect
> +
> +ENV.sort.each do |k,v|
> + print "#{k} #{v}\n"
> +end
> +
> diff --git a/www/test.cgi b/www/test.cgi
> index 011c7f6..2116558 100755
> --- a/www/test.cgi
> +++ b/www/test.cgi
> @@ -2,4 +2,9 @@
>
> print "Content-type: text/plain\r\n\r\n"
>
> -print ENV.inspect
> +#print ENV.inspect
> +
> +ENV.sort.each do |k,v|
> + print "#{k} #{v}\n"
> +end
> +
Re: Does Passenger really need ruby 2.3.0? and in /usr/local/bin?
On Thu, Mar 17, 2016 at 7:20 AM, sebb wrote: > As the subject says. Depends on your definition of require. Ruby >= 2.2.0 will use less memory and be more responsive due to improvements in garbage collection: https://www.ruby-lang.org/en/news/2014/12/25/ruby-2-2-0-released/ For that reason, I'd like the deployed code to use a version of Ruby that has the improved GC. I would agree that that shouldn't be required for development/testing. I haven't investigated, but perhaps that could be expressed in Gemfiles using the group construct? http://yehudakatz.com/2010/05/09/the-how-and-why-of-bundler-groups/ - Sam Ruby > MacOS/X comes with 2.0.0 which seems to work for most if not all the code. > > So is it necessary to specify ruby 2.3.0 in status/Gemfile > and /usr/local/bin/ruby2.3.0 in passenger.cgi? > > In particular it seems wrong to specify that ruby is under > /usr/local/bin, even if 2.3.0 is required. > > I see that Gemfile does not support ruby version ranges (Why??), but > one can use the following work-round: > > raise 'Ruby version must be at least 2.0' unless RUBY_VERSION.to_f >= 2.0
Re: Whimsy committer search ideas
On 03/16/2016 09:06 AM, Nick Burch wrote: Go for it! One more request - for those who have it (so post-2008), could we also display the date that they became a committer (=createTimestamp) on the details page? That should be easy enough. Looks like my createTimestamp is 20090519192238Z. Thanks Nick On Wed, 16 Mar 2016, Sam Ruby wrote: Mind if I forward this to dev@whimsical? - Sam Ruby On 03/16/2016 07:36 AM, Nick Burch wrote: Hi Sam I'm currently trying to work out which past TAC recipients are / were committers, using https://whimsy.apache.org/roster/committer/ Few things that would help: * Button to clear the email address field, ready for pasting the next one in * Bulk interface, where I can upload a list of email addresses, and get back a list of people Alternate ideas: make this a textarea; and each time you press enter/return you get a new textarea, each with its own results. And with paste you will get as many textareas/results as you have lines in the input. Dunno if my needs are too specialised, but I thought I'd pass the ideas on all the same in case you agreed with any of them! Thanks Nick - Sam Ruby
Re: Auth required for status/passenger
On Thu, Mar 17, 2016 at 11:24 AM, sebb wrote: > On 17 March 2016 at 13:03, Sam Ruby wrote: >> On Thu, Mar 17, 2016 at 7:59 AM, sebb wrote: >>> The status page says that passenger status is restricted to "ASF >>> committer only", however the code uses the realm "ASF Members and >>> Officers". >>> >>> Which is correct? >> >> At, the moment, the code obviously. :-) >> >> Originally, passenger status was open, and authentication was only >> required when you clicked a button to restart a process. I got >> feedback that showing a button which a person could not use was not >> ideal. >> >> I don't have a strong opinion as to whether committers should be able >> to restart processes. At a minimum, I would like members to be able >> to do so. > > In which case maybe the code can check karma before displaying the button. > > This assumes that ASF Committers have a need to see the Passenger status. Initially it had no authentication, which made checking karma kinda difficult. - Sam Ruby
Re: [whimsy.git] [1/1] Commit 40b7a6a: Add some temporary debug
Something you might find handy at some point: https://whimsy.apache.org/test.cgi :-) - Sam Ruby On Fri, Mar 18, 2016 at 5:14 PM, Sebastian Bazley wrote: > Commit 40b7a6a9a728e626ea2227b798e15c9de94b2c9e: > Add some temporary debug > > > Branch: refs/heads/master > Author: Sebb > Committer: Sebb > Pusher: sebb > > > www/status/index.cgi | - > > 5 changes: 4 additions, 1 deletions. > > > > diff --git a/www/status/index.cgi b/www/status/index.cgi > index 66cc103..6038c19 100755 > --- a/www/status/index.cgi > +++ b/www/status/index.cgi > @@ -34,7 +34,10 @@ print <<-EOF > > > Whimsy Status > - > + > + > + > + > > >
Re: [OT] Wunderbar html - how to output HTML comment with variable content?
On Thu, Mar 17, 2016 at 4:19 PM, sebb wrote:
> The Wunderbar docs mention outputting text with markup:
>
> _{"hello!!!"}
>
> The following also works:
>
> _{""}
>
> However it does not seem to be possible to output an HTML comment
> which contains any variable text, e.g. a date.
>
> Is this possible?
The indirect way (which I don't recommend):
_{""}
What that does internally is run an HTML parser on the string, extract
nodes, and do the equivalent of the following, which you can do
directly:
_.comment! "fixed comment with #{date}"
- Sam Ruby
Re: New mailing list for recording various items
+1 - Sam Ruby On Fri, Mar 18, 2016 at 11:50 AM, sebb wrote: > There are various items logged in the cron jobs (and elsewhere?) that > it would be useful to track historically. > > For example, LDAP server issues, changes to LDAP files. > > At present the LDAP warnings are sent to the dev list by PMB. > These don't need immediate attention, so don't really need to go to > the dev list. > > Also the LDAP jobs generate diffs which are stored in the current log file. > This info is lost when the job next runs. > AFAIK there is no way to get the list of changes from LDAP itself, so > that is a waste of useful information. (e.g. when someone was added to > a group) > > It was suggested that a mailing list might be a good place to log these > events. > > I think a single list would be sufficient; there are unlikely to be > more than a few messages per day, mostly none. > > The list should probably have moderated subscription to prevent > unwanted postings. > > I suggest 'notifications' for the list name. > > WDYT?
Re: Update Whimsy to use Ruby 2.3.0 throughout?
+1 - Sam Ruby On Sun, Mar 20, 2016 at 5:14 AM, sebb wrote: > At present Passenger uses 2.3.0, but most of the other scripts use the > default Ruby which is 1.9.3. > > The Ruby 2.x versions have many improvements and new features (e.g. > __dir__ and to_h). > > It's likely that developers will be using a later version than 1.9.3. > This makes it harder to test whether the code is compatible with that > version without deploying it and seeing if it breaks... > > The simplest solution might be to link /usr/local/bin/ruby to ruby2.3.0. > It looks like /usr/local/bin is on the PATH ahead of /usr/bin so that > should just work. > > Might it be worth trying that?
TAC views (was: Whimsy committer search ideas)
Alternately, if the TAC information(*) were changed to be shared with a wider audience, this information could be displayed in a format with hypertext links and other stats merged. - Sam Ruby (*) Current ACLs: [/travel-assistance/past-recipients] @svnadmins = rw @tac-pmc = rw ea = rw * = On Wed, Mar 16, 2016 at 9:22 AM, Sam Ruby wrote: > On 03/16/2016 09:06 AM, Nick Burch wrote: >> >> Go for it! >> >> One more request - for those who have it (so post-2008), could we also >> display the date that they became a committer (=createTimestamp) on the >> details page? > > > That should be easy enough. Looks like my createTimestamp is > 20090519192238Z. > >> Thanks >> Nick >> >> On Wed, 16 Mar 2016, Sam Ruby wrote: >> >>> Mind if I forward this to dev@whimsical? >>> >>> - Sam Ruby >>> >>> On 03/16/2016 07:36 AM, Nick Burch wrote: >>>> >>>> Hi Sam >>>> >>>> I'm currently trying to work out which past TAC recipients are / were >>>> committers, using https://whimsy.apache.org/roster/committer/ >>>> >>>> Few things that would help: >>>> * Button to clear the email address field, ready for pasting the >>>> next one >>>> in >>>> * Bulk interface, where I can upload a list of email addresses, and >>>> get back a list of people > > > Alternate ideas: make this a textarea; and each time you press enter/return > you get a new textarea, each with its own results. And with paste you will > get as many textareas/results as you have lines in the input. > >>>> Dunno if my needs are too specialised, but I thought I'd pass the ideas >>>> on all the same in case you agreed with any of them! >>>> >>>> Thanks >>>> Nick > > > - Sam Ruby
Whimsy proxy tool
I think having a proxy web interface continues to be a good idea; but we need to come to a common understanding of the data format. Too late for this meeting, but I'm inclined to change to a JSON format for future meetings. Here's the relevant lines: https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163 Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost. This is clearly problematic. Suggestions welcome! - Sam Ruby
Re: Whimsy proxy tool
On Mon, Mar 21, 2016 at 3:14 PM, Jim Jagielski wrote: > Well, it looks like the format has been changing... so I > can see concerns. > > But really, I'm not sure why it needs to be so > "standardized" esp when it's mucking around with > stuff it has no reason to. It's adding a line, so > I don't see the reason why it has to "recreate" the > file in the 1st place. Either it finds where a new > proxy needs to go and adds it there, or find the > line that needs to be updated, and modified *that* > line, or it finds the line it needs to delete > and trashes it. > > If a tool is updating a file which is also mostly edited > by humans, it should be pretty lax about enforcing > a "format" imo. If it doesn't need to mess with > a line, it should leave it alone or output it > exactly as it was read... Originally, this was a sorted index of files in the associated proxies-received directory. I'm OK with the idea of requirements changing and/or this being a bug in the first place. None of us like the idea of single maintainer tools. In this case, what we have here is a small, standalone tool. After the dust settles (i.e., after the meeting is over), anybody want to take a crack at improving it? Note: improving it could mean rewriting in Python and moving to Steve, I don't care. What I do care about is having multiple maintainers. - Sam Ruby >> On Mar 21, 2016, at 3:02 PM, Sam Ruby wrote: >> >> I think having a proxy web interface continues to be a good idea; but we >> need to come to a common understanding of the data format. Too late for >> this meeting, but I'm inclined to change to a JSON format for future >> meetings. >> >> Here's the relevant lines: >> >> https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163 >> >> Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost. >> >> This is clearly problematic. >> >> Suggestions welcome! >> >> - Sam Ruby >
Re: Whimsy proxy tool
On Mon, Mar 21, 2016 at 4:38 PM, sebb wrote: > On 21 March 2016 at 20:32, Jim Jagielski wrote: >> I do, but I'm still unclear on dealing w/ the GH workflow. >> >> Can I just do it via svn, or even *our* git and not deal >> w/ GH at all? You can do it entirely using *our* git and not deal with GH at all. > You can certainly just work on a clone of our Git; no need to use > GitHub (once you are set up correctly). Nothing needs to be set up to use our git: https://git-dual.apache.org/repos/asf/whimsy.git Pushes there are automatically picked up. I've done it. Jim, perhaps you could try pushing a minor change to README.md and letting us know how it works out? - Sam Ruby >>> On Mar 21, 2016, at 4:19 PM, Sam Ruby wrote: >>> >>> On Mon, Mar 21, 2016 at 3:14 PM, Jim Jagielski wrote: >>>> Well, it looks like the format has been changing... so I >>>> can see concerns. >>>> >>>> But really, I'm not sure why it needs to be so >>>> "standardized" esp when it's mucking around with >>>> stuff it has no reason to. It's adding a line, so >>>> I don't see the reason why it has to "recreate" the >>>> file in the 1st place. Either it finds where a new >>>> proxy needs to go and adds it there, or find the >>>> line that needs to be updated, and modified *that* >>>> line, or it finds the line it needs to delete >>>> and trashes it. >>>> >>>> If a tool is updating a file which is also mostly edited >>>> by humans, it should be pretty lax about enforcing >>>> a "format" imo. If it doesn't need to mess with >>>> a line, it should leave it alone or output it >>>> exactly as it was read... >>> >>> Originally, this was a sorted index of files in the associated >>> proxies-received directory. >>> >>> I'm OK with the idea of requirements changing and/or this being a bug >>> in the first place. >>> >>> None of us like the idea of single maintainer tools. In this case, >>> what we have here is a small, standalone tool. After the dust settles >>> (i.e., after the meeting is over), anybody want to take a crack at >>> improving it? >>> >>> Note: improving it could mean rewriting in Python and moving to Steve, >>> I don't care. What I do care about is having multiple maintainers. >>> >>> - Sam Ruby >>> >>>>> On Mar 21, 2016, at 3:02 PM, Sam Ruby wrote: >>>>> >>>>> I think having a proxy web interface continues to be a good idea; but we >>>>> need to come to a common understanding of the data format. Too late for >>>>> this meeting, but I'm inclined to change to a JSON format for future >>>>> meetings. >>>>> >>>>> Here's the relevant lines: >>>>> >>>>> https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163 >>>>> >>>>> Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost. >>>>> >>>>> This is clearly problematic. >>>>> >>>>> Suggestions welcome! >>>>> >>>>> - Sam Ruby >>
Re: Whimsy proxy tool
On Mon, Mar 21, 2016 at 4:51 PM, Jim Jagielski wrote:
> Just tried:
>
> % vi README.md
> % git commit -a
> [master a4f772a] test
> 1 file changed, 1 insertion(+), 1 deletion(-)
> % git push
> Username for 'https://git-dual.apache.org': jim
> Password for 'https://j...@git-dual.apache.org':
> Counting objects: 3, done.
> Delta compression using up to 24 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 285 bytes | 0 bytes/s, done.
> Total 3 (delta 2), reused 0 (delta 0)
> remote: To git@github:apache/whimsy.git
> remote:2f85f27..a4f772a master -> master
> To https://git-dual.apache.org/repos/asf/whimsy.git
>2f85f27..a4f772a master -> master
Promptly mirrored:
https://github.com/apache/whimsy/commit/a4f772ad61236ab9258746e54b32e9579fb26d3e
Note the Git hash ("a4f772a...") is the same both places (all three,
if you count jimsys).
So any code change you push to the ASF git repository should be
deployed on whimsy-vm2 and visible on whimsy.apache.org within 30
minutes (when Puppet next runs).
I love it when a plan comes together!
- Sam Ruby
>> On Mar 21, 2016, at 4:44 PM, Sam Ruby wrote:
>>
>> On Mon, Mar 21, 2016 at 4:38 PM, sebb wrote:
>>> On 21 March 2016 at 20:32, Jim Jagielski wrote:
>>>> I do, but I'm still unclear on dealing w/ the GH workflow.
>>>>
>>>> Can I just do it via svn, or even *our* git and not deal
>>>> w/ GH at all?
>>
>> You can do it entirely using *our* git and not deal with GH at all.
>>
>>> You can certainly just work on a clone of our Git; no need to use
>>> GitHub (once you are set up correctly).
>>
>> Nothing needs to be set up to use our git:
>>
>> https://git-dual.apache.org/repos/asf/whimsy.git
>>
>> Pushes there are automatically picked up. I've done it.
>>
>> Jim, perhaps you could try pushing a minor change to README.md and
>> letting us know how it works out?
>>
>> - Sam Ruby
>>
>>>>> On Mar 21, 2016, at 4:19 PM, Sam Ruby wrote:
>>>>>
>>>>> On Mon, Mar 21, 2016 at 3:14 PM, Jim Jagielski wrote:
>>>>>> Well, it looks like the format has been changing... so I
>>>>>> can see concerns.
>>>>>>
>>>>>> But really, I'm not sure why it needs to be so
>>>>>> "standardized" esp when it's mucking around with
>>>>>> stuff it has no reason to. It's adding a line, so
>>>>>> I don't see the reason why it has to "recreate" the
>>>>>> file in the 1st place. Either it finds where a new
>>>>>> proxy needs to go and adds it there, or find the
>>>>>> line that needs to be updated, and modified *that*
>>>>>> line, or it finds the line it needs to delete
>>>>>> and trashes it.
>>>>>>
>>>>>> If a tool is updating a file which is also mostly edited
>>>>>> by humans, it should be pretty lax about enforcing
>>>>>> a "format" imo. If it doesn't need to mess with
>>>>>> a line, it should leave it alone or output it
>>>>>> exactly as it was read...
>>>>>
>>>>> Originally, this was a sorted index of files in the associated
>>>>> proxies-received directory.
>>>>>
>>>>> I'm OK with the idea of requirements changing and/or this being a bug
>>>>> in the first place.
>>>>>
>>>>> None of us like the idea of single maintainer tools. In this case,
>>>>> what we have here is a small, standalone tool. After the dust settles
>>>>> (i.e., after the meeting is over), anybody want to take a crack at
>>>>> improving it?
>>>>>
>>>>> Note: improving it could mean rewriting in Python and moving to Steve,
>>>>> I don't care. What I do care about is having multiple maintainers.
>>>>>
>>>>> - Sam Ruby
>>>>>
>>>>>>> On Mar 21, 2016, at 3:02 PM, Sam Ruby wrote:
>>>>>>>
>>>>>>> I think having a proxy web interface continues to be a good idea; but
>>>>>>> we need to come to a common understanding of the data format. Too late
>>>>>>> for this meeting, but I'm inclined to change to a JSON format for
>>>>>>> future meetings.
>>>>>>>
>>>>>>> Here's the relevant lines:
>>>>>>>
>>>>>>> https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163
>>>>>>>
>>>>>>> Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost.
>>>>>>>
>>>>>>> This is clearly problematic.
>>>>>>>
>>>>>>> Suggestions welcome!
>>>>>>>
>>>>>>> - Sam Ruby
>>>>
>
Re: foundation: r66956 - /foundation/Meetings/20160322/proxies-received/goodale.txt
On Thu, Mar 24, 2016 at 7:27 AM, sebb wrote: > On 23 March 2016 at 01:22, sebb wrote: > > Insisting on availids only would make things much simpler. +1 - Sam Ruby
Re: [whimsy.git] [1/1] Commit 6ec6dc3: new board
On Thu, Mar 24, 2016 at 4:15 PM, sebb wrote:
> This info really needs to be obtained from a canonical source if there is one.
Indeed!
> If there isn't, one should be created.
There is one, and a quick glance will tell you why it is not being used:
https://whimsy.apache.org/roster/group/board
That being said, I now have karma to update that info directly. I
also plan to check into what it would take to add a field for
initials.
- Sam Ruby
> On 24 March 2016 at 19:48, Sam Ruby wrote:
>> Commit 6ec6dc39a7d86f08bbbc7b2243769b5487deb773:
>> new board
>>
>>
>> Branch: refs/heads/master
>> Author: Sam Ruby
>> Committer: Sam Ruby
>> Pusher: rubys
>>
>>
>> lib/whimsy/asf/rack.rb |
>>
>> 8 changes: 4 additions, 4 deletions.
>>
>>
>>
>> diff --git a/lib/whimsy/asf/rack.rb b/lib/whimsy/asf/rack.rb
>> index cfa52c4..60468eb 100644
>> --- a/lib/whimsy/asf/rack.rb
>> +++ b/lib/whimsy/asf/rack.rb
>> @@ -6,15 +6,15 @@
>> module ASF
>>module Auth
>> DIRECTORS = {
>> - 'rbowen' => 'rb',
>>'curcuru' => 'sc',
>>'bdelacretaz' => 'bd',
>> + 'isabel' => 'id',
>> + 'marvin' => 'mh',
>>'jim' => 'jj',
>>'mattmann'=> 'cm',
>> - 'ke4qqq' => 'dn',
>>'brett' => 'bp',
>> - 'rubys' => 'sr',
>> - 'gstein' => 'gs'
>> + 'gstein' => 'gs',
>> + 'markt' => 'mt'
>> }
>>
>> # decode HTTP authorization, when present
Re: Bug in new member
Sorry about that. I broke that in trying to introduce a fix for the sorting logic. Fix pushed. - Sam Ruby On Sat, Mar 26, 2016 at 10:33 AM, Craig Russell wrote: > Membership Application for A. J. David Bosschaert > > svn mv > "/srv/secretary/workbench/documents/received/David-Bosschaert-david.bosschaert-gmail.com--apache.jpeg" > /srv/secretary/workbench/documents/member_apps/a-j-david-bosschaert.jpeg > A > /srv/secretary/workbench/documents/member_apps/a-j-david-bosschaert.jpeg > D > /srv/secretary/workbench/documents/received/David-Bosschaert-david.bosschaert-gmail.com--apache.jpeg > svn update /srv/secretary/workbench/foundation/Meetings/20160322 > Updating '/srv/secretary/workbench/foundation/Meetings/20160322': > At revision 67201. > svn diff > /srv/secretary/workbench/foundation/Meetings/20160322/memapp-received.txt > Index: > /srv/secretary/workbench/foundation/Meetings/20160322/memapp-received.txt > === > --- /srv/secretary/workbench/foundation/Meetings/20160322/memapp-received.txt > (revision 67201) > +++ /srv/secretary/workbench/foundation/Meetings/20160322/memapp-received.txt > (working copy) > @@ -2,7 +2,7 @@ > --- - -- - -- > no no nono marmbrus Michael Armbrust > yes no nono pbenedict Paul C. Benedict Jr. > -yes no nono davidbA. J. David Bosschaert > +yes yes yes yesdavidbA. J. David Bosschaert > yes no nono mihaicMihai Chira > yes no nono tomc Tom Chiverton > yes no nono richard Richard Downer > svn update /srv/secretary/workbench/foundation/members.txt > Updating '/srv/secretary/workbench/foundation/members.txt': > U/srv/secretary/workbench/foundation/members.txt > Updated to revision 67201. > # > /srv/whimsy/www/secretary/workbench/file.cgi:651:in `block (2 levels) in > ' > /srv/whimsy/www/secretary/workbench/file.cgi:453:in `block in ’ > > Craig L Russell > Architect > craig.russ...@oracle.com > P.S. A good JDO? O, Gasp! > > > > >
Re: Marvin Podling Reminders
On Sun, Mar 27, 2016 at 8:05 AM, John D. Ament wrote: > Whimsy PMC - (or maybe just Sam?) > > Just wondering, and hoping you can help, what are the changes that podling > email reminders are going to be sent properly? > > If its not going to run, I'll run something myself for the month. To get this to work, we are going to need to have more of a dialog. At a minimum, I tried researching where the reminders would need to go, and would like the results to be reviewed. More in this thread: https://mail-archives.apache.org/mod_mbox/whimsical-dev/201603.mbox/%3CCAFG6u8G9%3DQ%3DhfcErPNKJPtdQrnHRruX%2B4F0LWO3F9osgr7DvaQ%40mail.gmail.com%3E > John - Sam Ruby
Re: Incorrect space escape for staple
On Mon, Mar 28, 2016 at 10:51 AM, Craig Russell wrote: > secretary assistant staple function > Staple > > convert 'schultz/Apache Membership Application.jpg' > 'schultz/Apache_Membership Application.pdf' > mv schultz/Apache_Membership Application.pdf schultz.pdf > mv: target ‘schultz.pdf’ is not a directory > svn add schultz.pdf > svn: warning: W155010: > '/srv/secretary/workbench/documents/received/schultz.pdf' not found > svn: E29: Could not add all targets because some targets don't exist > svn: E29: Illegal target for the requested operation > svn propset svn:mime-type application/pdf schultz.pdf > 'schultz.pdf' is not under version control > svn: E155010: The node > '/srv/secretary/workbench/documents/received/schultz.pdf' was not found. > svn rm --force schultz/Apache Membership Application.jpg > svn: E125001: '/srv/secretary/workbench/documents/received/schultz/Apache' > does not exist This code can be found here: https://github.com/apache/whimsy/blob/master/www/secretary/workbench/file.cgi Here is the code that will be replacing it: https://github.com/apache/whimsy/blob/master/www/secmail/views/actions/drop.json.rb Note that this code uses Kernel.system with a list of distinct parameters rather than depending on shell parsing. The new code also requires all input received from outside sources to be explicitly untainted, and that should only be done if the source is trusted (e.g., __dir__ returns a tainted value, but it safe for our purposes), or has been validated (generally with a regular expression). Also note that this is a small, well contained script; taking as input @source, @target, and @message, and returning a single result. As opposed to file.cgi which does pretty much everything, and the flow of data... well lets just say that it isn't quite so clear. It is my hope to return to the task of completing the new secmail application once all of the membership applications have been received and processed. > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org http://db.apache.org/jdo - Sam Ruby
Re: [whimsy.git] [1/1] Commit ac8bc55: Add utility to sort members.txt
Excellent!
Now that you have mastered that, here's an example of code that I will
be debugging later this week that will update the membership status of
an individual:
https://github.com/apache/whimsy/blob/master/www/roster/views/actions/memstat.json.rb
Note that this uses the same sort routine. However instead of using a
svn working directory, it does everything using a temporary directory
where it obtains a clean checkout of just the file that is to be
updated and commits it immediately. This avoid the 'svn has gotten
wedged' issue that plagued older tools on whimsy-vm1.
Updating status using the roster tool is not likely to be the only (or
even primary) way in which status is updated in the future. Some form
of this logic will also be needed by the secmail tool to process
emeritus requests. And will be useful in implementing a "self
service" emeritus form as you have suggested. As that occurs, common
logic will make its way from the separate tools into the appropriate
lib/whimsy source files.
That process of finding and refactoring out common logic is iterative.
For example, updating the count of active members at the top of
members.txt is common to both processing emeritus transitions as well
as processing new member requests.
- Sam Ruby
On Sun, Mar 27, 2016 at 9:03 PM, Craig L Russell wrote:
> Commit ac8bc5506f658150a750eccdac983f6340c0038d:
> Add utility to sort members.txt
>
>
> Branch: refs/heads/master
> Author: Craig L Russell
> Committer: Craig L Russell
> Pusher: clr
>
>
> tools/membersort.rb |
>
> 23 changes: 23 additions, 0 deletions.
>
>
>
> diff --git a/tools/membersort.rb b/tools/membersort.rb
> new file mode 100644
> index 000..98b1730
> --- /dev/null
> +++ b/tools/membersort.rb
> @@ -0,0 +1,23 @@
> +# svn update and sort the members.txt file and show the differences
> +
> +$LOAD_PATH.unshift File.realpath(File.expand_path('../../lib', __FILE__))
> +require 'whimsy/asf'
> +
> +FOUNDATION = ASF::SVN['private/foundation']
> +
> +Dir.chdir FOUNDATION
> +
> +members = FOUNDATION + '/members.txt'
> +puts 'svn update ' + members
> +system 'svn update ' + members
> +
> +source = File.read('members.txt')
> +sorted = ASF::Member.sort(source)
> +
> +if source == sorted
> + puts 'no change'
> +else
> + File.write('members.txt', sorted)
> + system 'svn diff members.txt'
> +end
> +
Re: Wunderbar class: attribute causes problems for syntax checkers
On Mon, Mar 28, 2016 at 2:06 PM, sebb wrote: > The class: attribute is frequently used in Wunderbar HTML tags. Indeed. > This causes problems for Ruby syntax checkers. I'd be curious as to which ones, as that would indicate a syntax checker that hasn't been updated since Ruby 1.9 was release in 2007. > It would be useful if there was an alias that could be used instead. > Since it appears frequently, it might be nice to allow c: > Alternatively, clazz: would do. First, wunderbar does support an alternative, but only for class names known at compile time: element class and id syntax adopted by markaby, example: _p.important Second, as HTML is case insensitive, both Class and CLASS should also work. As I feel that it is important for code to be read as written, I would prefer to avoid things like 'c', or perhaps even 'clazz' as those could be valid attribute names. If an alternative is required, I would prefer to go with _class. - Sam Ruby
Re: Wunderbar class: attribute causes problems for syntax checkers
On Mon, Mar 28, 2016 at 2:54 PM, sebb wrote: > On 28 March 2016 at 19:47, Sam Ruby wrote: >> On Mon, Mar 28, 2016 at 2:06 PM, sebb wrote: >>> The class: attribute is frequently used in Wunderbar HTML tags. >> >> Indeed. >> >>> This causes problems for Ruby syntax checkers. >> >> I'd be curious as to which ones, as that would indicate a syntax >> checker that hasn't been updated since Ruby 1.9 was release in 2007. > > I use the one in Eclipse. Perhaps it might be worth opening a bug on eclipse then :-) >>> It would be useful if there was an alias that could be used instead. >>> Since it appears frequently, it might be nice to allow c: >>> Alternatively, clazz: would do. >> >> First, wunderbar does support an alternative, but only for class names >> known at compile time: element class and id syntax adopted by markaby, >> example: >> >> _p.important > > Does that work with tag! ? > > e.g. would this work? > > tag!._stdin Yes. Test case: https://github.com/rubys/wunderbar/blob/master/test/test_html_markup.rb#L281 >> Second, as HTML is case insensitive, both Class and CLASS should also >> work. > > Using Class: avoids the error, so that would work for me. > >> As I feel that it is important for code to be read as written, >> I would prefer to avoid things like 'c', or perhaps even 'clazz' as >> those could be valid attribute names. If an alternative is required, >> I would prefer to go with _class. >> >> - Sam Ruby - Sam Ruby
Re: Wunderbar class: attribute causes problems for syntax checkers
On Mon, Mar 28, 2016 at 3:10 PM, sebb wrote:
> Just noticed another syntax complaint:
>
> _label "Contributor's Name:", for: 'iclaname'
Again, that's syntax that has been supported since Ruby 1.9.
> The colon after for is flagged as unexpected.
>
> The other main complaint is about:
>
> onClick: -> {@form = ICLA}
And, again, syntax that was introduced in Ruby 1.9
It looks like Eclipse is stuck in 1.8.7, which was retired in
https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/, but
still in active use.
For those familiar with Python, the transition from Ruby 1.8.x to Ruby
1.9.x mirrors the transition from Python 2 to Python 3 (particularly
in terms of Unicode support), just that the Ruby language transition
was more backwards compatible, and therefore less traumatic.
- Sam Ruby
> On 28 March 2016 at 19:54, sebb wrote:
>> On 28 March 2016 at 19:47, Sam Ruby wrote:
>>> On Mon, Mar 28, 2016 at 2:06 PM, sebb wrote:
>>>> The class: attribute is frequently used in Wunderbar HTML tags.
>>>
>>> Indeed.
>>>
>>>> This causes problems for Ruby syntax checkers.
>>>
>>> I'd be curious as to which ones, as that would indicate a syntax
>>> checker that hasn't been updated since Ruby 1.9 was release in 2007.
>>
>> I use the one in Eclipse.
>>
>>>> It would be useful if there was an alias that could be used instead.
>>>> Since it appears frequently, it might be nice to allow c:
>>>> Alternatively, clazz: would do.
>>>
>>> First, wunderbar does support an alternative, but only for class names
>>> known at compile time: element class and id syntax adopted by markaby,
>>> example:
>>>
>>> _p.important
>>
>> Does that work with tag! ?
>>
>> e.g. would this work?
>>
>> tag!._stdin
>>
>>> Second, as HTML is case insensitive, both Class and CLASS should also
>>> work.
>>
>> Using Class: avoids the error, so that would work for me.
>>
>>> As I feel that it is important for code to be read as written,
>>> I would prefer to avoid things like 'c', or perhaps even 'clazz' as
>>> those could be valid attribute names. If an alternative is required,
>>> I would prefer to go with _class.
>>>
>>> - Sam Ruby
Re: Wunderbar class: attribute causes problems for syntax checkers
On Mon, Mar 28, 2016 at 3:16 PM, Sam Ruby wrote:
> On Mon, Mar 28, 2016 at 3:10 PM, sebb wrote:
>> Just noticed another syntax complaint:
>>
>> _label "Contributor's Name:", for: 'iclaname'
>
> Again, that's syntax that has been supported since Ruby 1.9.
>
>> The colon after for is flagged as unexpected.
By the way, another workaround might be to use 1.8.7 syntax:
_label "Contributor's Name:", :for => 'iclaname'
>> The other main complaint is about:
>>
>> onClick: -> {@form = ICLA}
An equivalent, and Ruby 1.8.7 compatible, form:
onClick: lambda {@form = ICLA}
> And, again, syntax that was introduced in Ruby 1.9
>
> It looks like Eclipse is stuck in 1.8.7, which was retired in
> https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/, but
> still in active use.
>
> For those familiar with Python, the transition from Ruby 1.8.x to Ruby
> 1.9.x mirrors the transition from Python 2 to Python 3 (particularly
> in terms of Unicode support), just that the Ruby language transition
> was more backwards compatible, and therefore less traumatic.
>
> - Sam Ruby
>
>> On 28 March 2016 at 19:54, sebb wrote:
>>> On 28 March 2016 at 19:47, Sam Ruby wrote:
>>>> On Mon, Mar 28, 2016 at 2:06 PM, sebb wrote:
>>>>> The class: attribute is frequently used in Wunderbar HTML tags.
>>>>
>>>> Indeed.
>>>>
>>>>> This causes problems for Ruby syntax checkers.
>>>>
>>>> I'd be curious as to which ones, as that would indicate a syntax
>>>> checker that hasn't been updated since Ruby 1.9 was release in 2007.
>>>
>>> I use the one in Eclipse.
>>>
>>>>> It would be useful if there was an alias that could be used instead.
>>>>> Since it appears frequently, it might be nice to allow c:
>>>>> Alternatively, clazz: would do.
>>>>
>>>> First, wunderbar does support an alternative, but only for class names
>>>> known at compile time: element class and id syntax adopted by markaby,
>>>> example:
>>>>
>>>> _p.important
>>>
>>> Does that work with tag! ?
>>>
>>> e.g. would this work?
>>>
>>> tag!._stdin
>>>
>>>> Second, as HTML is case insensitive, both Class and CLASS should also
>>>> work.
>>>
>>> Using Class: avoids the error, so that would work for me.
>>>
>>>> As I feel that it is important for code to be read as written,
>>>> I would prefer to avoid things like 'c', or perhaps even 'clazz' as
>>>> those could be valid attribute names. If an alternative is required,
>>>> I would prefer to go with _class.
>>>>
>>>> - Sam Ruby
Re: Wunderbar class: attribute causes problems for syntax checkers
On Tue, Mar 29, 2016 at 7:55 AM, sebb wrote:
>
> I think there is a valid complaint: unexpected tRPAREN
>
> text = text.replace("^#{spaces}", 'g'), '')
>
> This is at:
>
> https://github.com/apache/whimsy/blob/master/www/test/icla/views/markdown.js.rb#L26
Fixed. Thanks!
- Sam Ruby
Re: Extract SVN and poss. other System commands into a function?
On Tue, Mar 29, 2016 at 12:29 PM, sebb wrote: > For unit testing purposes it can be useful to be able to disable svn > actions and replace them with a log message. FWIW, the board agenda tool handles this by creating test repositories: https://github.com/apache/whimsy/blob/master/www/board/agenda/Rakefile#L44 https://github.com/apache/whimsy/blob/master/www/board/agenda/main.rb#L24 > And for live running it can be useful to log the system commands that are run. > > It might therefore be useful to add some utility functions to > encapsulate the system calls. Note that scripts that use wunderbar will capture the output and add it to the "transcript" that is returned to the client: https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/builder.rb#L555 An example of this was recently posted to a the (ASF confidential) board list: https://mail-search.apache.org/members/private-arch/board/201603.mbox/raw/%3CCAAS6=7gQSnsqMyCE4wmst7KH8HSgB=H=uxoqk4sxd+azwtk...@mail.gmail.com%3E/2 Note that the wunderbar support will support parameter lists that are arrays, and will NOT echo parameters that are in nested arrays. This enables noise arguments (--no-auth-cache, --non-interactive), and credentials (--username, --password) to be omitted from the log. > WDYT? Things of general use (like logging of commands) can be put into wunderbar, and doing so would minimize the need to modify existing applications to take advantage of the feature. That being said, it might be worth making opt-in, where an application makes a single call to enable or disable logging of system commands. While I like the idea of more logging, I'm less comfortable with disabling svn actions in testing. My preference is to do testing with dummy repositories over mocking out the function entirely. - Sam Ruby
Re: Simplify committing new/replacement file to SVN by using svnmucc
On Wed, Mar 30, 2016 at 6:06 PM, sebb wrote: > I just realised that we could use the svnmucc 'put' command to > simplify adding/modifying a file. > > There is no need to create a temporary checkout of the parent directory. > > One can even use '-' to put from standard input. Thanks! Much cleaner: https://github.com/apache/whimsy/commit/8e74fe0267058e919b85380c956295e76689c2d9 > Won't be suitable for everything, but might prove useful. > > Maybe worth creating a function to implement this? I remain unclear as to the value of a function, but you are welcome to explore that. Note that _.system, when called within _html, will create elements that are placed in the html output. The board agenda tool has retry logic. I don't yet see the common logic that merits refactoring, but perhaps you see something I have missed? And if truly common code, I'm open to including it in wunderbar. - Sam Ruby
Re: Simplify committing new/replacement file to SVN by using svnmucc
On Thu, Mar 31, 2016 at 6:25 AM, sebb wrote: > On 31 March 2016 at 02:19, Sam Ruby wrote: >> On Wed, Mar 30, 2016 at 6:06 PM, sebb wrote: >>> I just realised that we could use the svnmucc 'put' command to >>> simplify adding/modifying a file. >>> >>> There is no need to create a temporary checkout of the parent directory. >>> >>> One can even use '-' to put from standard input. >> >> Thanks! Much cleaner: >> >> https://github.com/apache/whimsy/commit/8e74fe0267058e919b85380c956295e76689c2d9 > > The -r 0 qualifier is neat. I'd not noticed that before. If you don't pass that, svnmucc will overwrite existing content. > Not sure why you use stdin since the file already exists? > Why not pass the path on the command line? The file doesn't exist in this case - it is an html form parameter. @file is an object that responds to .read. Here's the relevant portion of wunderbar's implementation of _.system: https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/builder.rb#L94 >>> Won't be suitable for everything, but might prove useful. >>> >>> Maybe worth creating a function to implement this? >> >> I remain unclear as to the value of a function, but you are welcome to >> explore that. >> >> Note that _.system, when called within _html, will create > class="_stdin'> and elements that are placed in >> the html output. > > Yes, I saw. > > How does one call it outside _html? Well, you wouldn't generally call that _.system method outside of _html, but I have similar methods for _json and _text and for websockets that format and include the results in the output. >> The board agenda tool has retry logic. I don't yet see the common >> logic that merits refactoring, but perhaps you see something I have >> missed? >> >> And if truly common code, I'm open to including it in wunderbar. > > I suppose the required code as above is quite short. > > However it might be useful to create a version (or verions) that handle: > - put if absent (-r 0) > - put unconditionally > - put if newer (-r n) > > Also the function could add the standard ['--no-auth-cache', > '--non-interactive'] qualifiers. What generally is even more useful in Ruby is to do this as a block. In the board agenda tool updating the agenda is a common function, so that posting a list of action items calls Agenda.update passing a block. For example: https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/post-actions.json.rb The call to Agenda.update passes a block (do...end), and that block is called (via a yield) with the current agenda contents and is expected to return the updated contents. The definition of Agenda.update is handles not only svn, but file locks, capturing output, updating the cache, and retries: https://github.com/apache/whimsy/blob/master/www/board/agenda/models/agenda.rb#L82 Updating the cache is what broadcasts updates to other users of the agenda tool that a change has happened, so everybody's client will see the new content pretty much instantly. Wunderbar's implementation of _.system spins off three threads, one each to deal with stdin, stdout, and stderr. Looking at how treasurer/bill_upload and board/agenda do svn updates, I don't see much in common that would benefit from refactoring out. But within the board agenda tool, there clearly was a common pattern that was refactored into a common method for that one tool. And I do see how board/agenda could benefit from svnmucc. But if you see something that is in common that could benefit from refactoring out, go for it... In general, the way whimsy tools have been developed to date is to focus first on writing the tool, and then to look for common code patterns that could benefit from being moved to a common library. wunderbar predated whimsy/asf, and started out as code that I commonly added when I made use of the builder gem. In fact there still is one tool (collate_minutes that produces board/minutes) that hasn't been converted from builder to wunderbar. > It looks as though svnmucc does not honour config [auto-props] so that > could be added to the put if absent code. > >> - Sam Ruby - Sam Ruby
Re: Simplify committing new/replacement file to SVN by using svnmucc
Top posting. Despite my current skepticism, apparently in the (embarrassingly recent :-)) past I found svn update enough of a common pattern to factor out updates: https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb The implementation of this method does use a block with yield: https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/svn.rb I've now added a method to go a combination of svn info and cat; the need to log or intercede in those methods isn't quite as strong, so that is more easily factored out. The implementation of ASF::SVN.update could be changed to make use of ASF::SVN.get and svnmucc, and eliminate the need for temporary directories. - Sam Ruby On Thu, Mar 31, 2016 at 9:59 AM, sebb wrote: > On 31 March 2016 at 12:20, Sam Ruby wrote: >> On Thu, Mar 31, 2016 at 6:25 AM, sebb wrote: >>> On 31 March 2016 at 02:19, Sam Ruby wrote: >>>> On Wed, Mar 30, 2016 at 6:06 PM, sebb wrote: >>>>> I just realised that we could use the svnmucc 'put' command to >>>>> simplify adding/modifying a file. >>>>> >>>>> There is no need to create a temporary checkout of the parent directory. >>>>> >>>>> One can even use '-' to put from standard input. >>>> >>>> Thanks! Much cleaner: >>>> >>>> https://github.com/apache/whimsy/commit/8e74fe0267058e919b85380c956295e76689c2d9 >>> >>> The -r 0 qualifier is neat. I'd not noticed that before. >> >> If you don't pass that, svnmucc will overwrite existing content. >> >>> Not sure why you use stdin since the file already exists? >>> Why not pass the path on the command line? >> >> The file doesn't exist in this case - it is an html form parameter. >> @file is an object that responds to .read. > > I see, I assumed it was the file path name. > >> Here's the relevant >> portion of wunderbar's implementation of _.system: >> >> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/builder.rb#L94 >> >>>>> Won't be suitable for everything, but might prove useful. >>>>> >>>>> Maybe worth creating a function to implement this? >>>> >>>> I remain unclear as to the value of a function, but you are welcome to >>>> explore that. >>>> >>>> Note that _.system, when called within _html, will create >>> class="_stdin'> and elements that are placed in >>>> the html output. >>> >>> Yes, I saw. >>> >>> How does one call it outside _html? >> >> Well, you wouldn't generally call that _.system method outside of >> _html, but I have similar methods for _json and _text and for >> websockets that format and include the results in the output. > > Would it not also be useful for inline ruby code where the output > needs to be processed further by the script? > >>>> The board agenda tool has retry logic. I don't yet see the common >>>> logic that merits refactoring, but perhaps you see something I have >>>> missed? >>>> >>>> And if truly common code, I'm open to including it in wunderbar. >>> >>> I suppose the required code as above is quite short. >>> >>> However it might be useful to create a version (or verions) that handle: >>> - put if absent (-r 0) >>> - put unconditionally >>> - put if newer (-r n) >>> >>> Also the function could add the standard ['--no-auth-cache', >>> '--non-interactive'] qualifiers. >> >> What generally is even more useful in Ruby is to do this as a block. >> In the board agenda tool updating the agenda is a common function, so >> that posting a list of action items calls Agenda.update passing a >> block. For example: >> >> https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/post-actions.json.rb >> >> The call to Agenda.update passes a block (do...end), and that block is >> called (via a yield) with the current agenda contents and is expected >> to return the updated contents. > > I see. > > That's a design method I've not had much experience with, so I don't > tend to think of it when writing code. > Must give it more attention. > >> The definition of Agenda.update is handles not only svn, but file >> locks, capturing output, updating the cache, and retries: >> >> https://github.com/apache/whimsy/blob/master/www/board/agenda/models/agenda.r
Re: gitpubsub for code on Whimsy - broken?
On Fri, Apr 1, 2016 at 8:43 AM, sebb wrote: > How often does the Whimsy code get updated from git? Every time puppet runs, i.e. every 30 minutes. > And where is the cronjob defined? I don't know how puppet works, but here is relevant portion of the puppet manifest: https://github.com/apache/infrastructure-puppet/blob/deployment/modules/whimsy_server/manifests/init.pp#L58 > Or does it use a constantly running daemon, in which case how to check > if it is running? I don't know how to check if puppet is running. > I have committed a couple of changes recently. > The last one was over two hours ago now (Fri Apr 1 10:37:44 2016 > +0100) but it still has not been applied as far as I can tell. > > The git code info says: > > Git code info: 40e810b 2016-04-01 01:01:16 +0100 > > I don't have experience with gitpubsub, but projects.a.o and > reporter.a.o SVN code updates are almost instantaneous. > > It's a bit of a problem if code updates take a long time, especially > if a mistake needs to be corrected, tho' that's not the case here. - Sam Ruby
Re: gitpubsub for code on Whimsy - broken?
On Fri, Apr 1, 2016 at 8:48 AM, Sam Ruby wrote: > On Fri, Apr 1, 2016 at 8:43 AM, sebb wrote: >> How often does the Whimsy code get updated from git? > > Every time puppet runs, i.e. every 30 minutes. > >> And where is the cronjob defined? > > I don't know how puppet works, but here is relevant portion of the > puppet manifest: > > https://github.com/apache/infrastructure-puppet/blob/deployment/modules/whimsy_server/manifests/init.pp#L58 > >> Or does it use a constantly running daemon, in which case how to check >> if it is running? > > I don't know how to check if puppet is running. Daniel Gruno looked into it... the puppet agent died due to lack of memory. I have no idea what caused that, there was plenty of available memory when we checked (long after the fact). Daniel doubled the memory (4G=>8G). And I rebooted the machine. >> I have committed a couple of changes recently. >> The last one was over two hours ago now (Fri Apr 1 10:37:44 2016 >> +0100) but it still has not been applied as far as I can tell. >> >> The git code info says: >> >> Git code info: 40e810b 2016-04-01 01:01:16 +0100 >> >> I don't have experience with gitpubsub, but projects.a.o and >> reporter.a.o SVN code updates are almost instantaneous. >> >> It's a bit of a problem if code updates take a long time, especially >> if a mistake needs to be corrected, tho' that's not the case here. > > - Sam Ruby - Sam Ruby
Re: gitpubsub for code on Whimsy - broken?
On Fri, Apr 1, 2016 at 9:02 AM, sebb wrote: > On 1 April 2016 at 13:48, Sam Ruby wrote: >> On Fri, Apr 1, 2016 at 8:43 AM, sebb wrote: >>> How often does the Whimsy code get updated from git? >> >> Every time puppet runs, i.e. every 30 minutes. > > I see. > > That's not as frequently as I had hoped. Note that the puppet manifest doesn't simply put the code there and hope that it is picked up. Whenver the code is updated, a rake task is run that may install new gems or restart passenger applications. > And it will be affected by any problems that cause puppet to fail. Independent of anything else, we should probably start monitoring for puppet status and generating an alert when it is down. Here's how to do that: $ service puppet status * agent is running Infra also has their own checks, but for some reason those also failed. > I think we need to ask Infra if the code can be updated more like svnpubsub. > Or alternatively I suppose we could add a function to update the code > on demand (with suitable auth). I would like to go very slowly with that due to security concerns. If a web process could be fooled into updating the code, that could be very bad. >>> And where is the cronjob defined? >> >> I don't know how puppet works, but here is relevant portion of the >> puppet manifest: >> >> https://github.com/apache/infrastructure-puppet/blob/deployment/modules/whimsy_server/manifests/init.pp#L58 > > Thanks. > >>> Or does it use a constantly running daemon, in which case how to check >>> if it is running? >> >> I don't know how to check if puppet is running. > > On projects.a.o it writes to the system log. > > $ grep puppet /var/log/syslog > > will likely show the most recent puppet-agent activity. > >>> I have committed a couple of changes recently. >>> The last one was over two hours ago now (Fri Apr 1 10:37:44 2016 >>> +0100) but it still has not been applied as far as I can tell. >>> >>> The git code info says: >>> >>> Git code info: 40e810b 2016-04-01 01:01:16 +0100 >>> >>> I don't have experience with gitpubsub, but projects.a.o and >>> reporter.a.o SVN code updates are almost instantaneous. >>> >>> It's a bit of a problem if code updates take a long time, especially >>> if a mistake needs to be corrected, tho' that's not the case here. >> >> - Sam Ruby - Sam Ruby
Re: gitpubsub for code on Whimsy - broken?
On Fri, Apr 1, 2016 at 9:06 AM, sebb wrote: > On 1 April 2016 at 14:03, Sam Ruby wrote: >> On Fri, Apr 1, 2016 at 8:48 AM, Sam Ruby wrote: >>> On Fri, Apr 1, 2016 at 8:43 AM, sebb wrote: >>>> How often does the Whimsy code get updated from git? >>> >>> Every time puppet runs, i.e. every 30 minutes. >>> >>>> And where is the cronjob defined? >>> >>> I don't know how puppet works, but here is relevant portion of the >>> puppet manifest: >>> >>> https://github.com/apache/infrastructure-puppet/blob/deployment/modules/whimsy_server/manifests/init.pp#L58 >>> >>>> Or does it use a constantly running daemon, in which case how to check >>>> if it is running? >>> >>> I don't know how to check if puppet is running. >> >> Daniel Gruno looked into it... the puppet agent died due to lack of >> memory. I have no idea what caused that, there was plenty of >> available memory when we checked (long after the fact). >> >> Daniel doubled the memory (4G=>8G). And I rebooted the machine. > > As of yet, the code still has not been updated: > > Git code info: 40e810b 2016-04-01 01:01:16 +0100 Barring human intervention, the code should be updated the next time puppet runs. As of yesterday, that was roughly 9 and 39 minutes after the hour, but that may vary. In case of emergency, the best thing to do is to jump on hipchat and ask the kind folks there to kick puppet: sudo service puppet restart sudo puppet agent -td - Sam Ruby >>>> I have committed a couple of changes recently. >>>> The last one was over two hours ago now (Fri Apr 1 10:37:44 2016 >>>> +0100) but it still has not been applied as far as I can tell. >>>> >>>> The git code info says: >>>> >>>> Git code info: 40e810b 2016-04-01 01:01:16 +0100 >>>> >>>> I don't have experience with gitpubsub, but projects.a.o and >>>> reporter.a.o SVN code updates are almost instantaneous. >>>> >>>> It's a bit of a problem if code updates take a long time, especially >>>> if a mistake needs to be corrected, tho' that's not the case here. >>> >>> - Sam Ruby >> >> - Sam Ruby
[discuss] move mlreq tool back to whimsy
tl;dr: it is only a matter of time before the infrastructure team notice that mlreq is hosted on a vm that is set to be decommissioned, and sebb notices that mlreq is currently using an old version of the whimsy/asf gem. Let's fix the above before it is a problem. Originally, whimsy was a playground, and when things got to the point where people depended on them I worked with the infrastructure staff and those tools would 'graduate' and become owned by the infrastructure team. Since then, whimsy has become a PMC, the infrastructure contractors that were involved in this exercise are no longer active, and the current contractors are now focused on SLAs, and do what is expected of people who are tracked by SLAs do: move the issues states like 'planned enhancements', and buck questions about ownership to management. Despite asking this question a number of times, I've never gotten a response. It is time for the PMC as a whole to ask this question. At the moment, this email is focused on a single tool. My opinion is that there is a larger problem of single developer code bases. The whimsy PMC is making slow but steady progress here; but there are plenty of other codebases that aren't -- some of which aren't even under revision control or under automated deployment. Thoughts? See also: https://issues.apache.org/jira/browse/INFRA-11502 - Sam Ruby
Re: Comments on memstat.json.rb
On Fri, Apr 1, 2016 at 10:42 AM, Craig Russell wrote:
> Just a few questions/comments on the code.
>
> 1. entry = ASF::Person.find(@userid).members_txt(true) does some heavy
> lifting and then a few lines later, message = "Move
> #{ASF::Person.find(@userid).member_name} to #{@action}” which lifts the same
> weight. Could this be replaced with message = "Move #{entry.member_name} to
> #{@action}”?
person.members_txt() returns a string, so entry.member_name won't work.
> Or is Person.find really a lightweight function?
ASF::Person.find caches its results, so subsequent calls are light weight.
If you feel so inclined, feel free to refactor this to person =
ASF::Person.find(@userid); and then change the two places were
Person.find is called to use this value.
> 2. There is a section “Deceased”. Would it make sense to add a few lines of
> code for this section?
It would not be difficult to do. Go for it!
> 3. Where did the @action parameter come from?
It comes from the form. See:
https://github.com/apache/whimsy/blob/ef8a40770cbba9da72da0bfacb45cf334ab248ec/www/roster/views/committer.js.rb#L187
If you were to add other buttons, the name/value pairs on those
buttons (or input fields, or textareas, etc), will be used to set
instance variables (i.e., variables whose names start with an '@') to
the associated value.
Feel free to experiment. If you were to create a button and push that
change, it would only show up to people listed in the asf-secretary
LDAP service:
https://whimsy.apache.org/roster/group/asf-secretary
> 4. Could this be called directly from the command line, e.g. ruby
> views/actions/memstat clr emeritus
Directly? No. But it is quite possible to write a script that sets a
few instance variables and then reads and evals the script. The tests
for the board agenda tool do this:
https://github.com/apache/whimsy/blob/master/www/board/agenda/spec/actions_spec.rb#L40
It should be possible to write proper unit tests for this function,
given dummy test data for members.txt. If this is of interest, I can
set that up over the weekend, and you could add to it.
The board agenda tests can test for server rendering, and can also
make use of phantomjs which runs a headless webkit based browser and
can be used to test javascript.
Tests for pure server functions (without rendering) run very fast.
When rendering is involved, it is noticeably slower, but not too bad.
Tests that involve the creation and teardown of a browser are even
slower, to the point where such tests are generally only worth it for
non-trivial operations. I wouldn't, for example, be inclined to write
a test for showing the emeritus/deceased buttons.
> Craig
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
- Sam Ruby
Re: Comments on memstat.json.rb
On Fri, Apr 1, 2016 at 11:09 AM, Sam Ruby wrote: > On Fri, Apr 1, 2016 at 10:42 AM, Craig Russell > wrote: > >> 4. Could this be called directly from the command line, e.g. ruby >> views/actions/memstat clr emeritus > > Directly? No. But it is quite possible to write a script that sets a > few instance variables and then reads and evals the script. The tests > for the board agenda tool do this: > > https://github.com/apache/whimsy/blob/master/www/board/agenda/spec/actions_spec.rb#L40 > > It should be possible to write proper unit tests for this function, > given dummy test data for members.txt. If this is of interest, I can > set that up over the weekend, and you could add to it. Just a heads up: I'm looking at adding support for a "dry run" of these scripts, which likely will result in some change to the script itself, and may need additional setup by wrapper scripts. - Sam Ruby
Re: Comments on memstat.json.rb
On Fri, Apr 1, 2016 at 11:45 AM, sebb wrote: > On 1 April 2016 at 16:09, Sam Ruby wrote: >> On Fri, Apr 1, 2016 at 10:42 AM, Craig Russell >> wrote: >> >>> 4. Could this be called directly from the command line, e.g. ruby >>> views/actions/memstat clr emeritus >> >> Directly? No. But it is quite possible to write a script that sets a >> few instance variables and then reads and evals the script. The tests >> for the board agenda tool do this: >> >> https://github.com/apache/whimsy/blob/master/www/board/agenda/spec/actions_spec.rb#L40 > > Is it not possible to add a section of the form: > > if __FILE__ == $0 > @uid = ARGV[0] > @state = ARGV[1] > eval(File.read(__FILE__)) # or some other invocation method > end That indeed could be added to the top of the file, without the eval. - Sam Ruby
Re: Comments on memstat.json.rb
On Fri, Apr 1, 2016 at 11:43 AM, Sam Ruby wrote: > > Just a heads up: I'm looking at adding support for a "dry run" of > these scripts, which likely will result in some change to the script > itself, and may need additional setup by wrapper scripts. The /roster/committer/* pages now support dry runs of changes. Double click on on a light green area to show a form; make the updates you wish, and then option-click on Macs (control-click everwhere else) on the relevant button. The results will come back in JSON form. For LDAP changes, they will show you the previous value, for SVN changes you will see a transcript of commands issued and their responses. You will also see other information, including a JSON representation of the committer page. - - - This tool can be run locally assuming you have your .whimsy file set up and LDAP configured. See https://github.com/apache/whimsy/blob/master/DEVELOPMENT.md#setup The commands you need to run a local server can be found in https://github.com/apache/whimsy/blob/master/www/roster/README The server will automatically restart whenever it detects a code change. You mentioned adding an action to move a member to deceased... that sounds like a relatively straightforward change that can be developed and tested locally. To make it even easier, I've split up the file that shows the page, which means that only two files would need to be updated for this change. For the client side: https://github.com/apache/whimsy/blob/master/www/roster/views/person/memstat.js.rb and for the server side: https://github.com/apache/whimsy/blob/master/www/roster/views/actions/memstat.json.rb - Sam Ruby
Re: [whimsy.git] [1/1] Commit 5a59778: Initial draft of mirror checking page
On Sat, Apr 2, 2016 at 10:10 PM, Sebastian Bazley wrote: > Commit 5a59778cec543ef7de0f9ea8bd501827836a082c: > Initial draft of mirror checking page > > > Branch: refs/heads/master > Author: Sebb > Committer: Sebb > Pusher: sebb > > > tools/mirror_check.rb| +++ > www/members/mirror_check.cgi | +++ > > 344 changes: 344 additions, 0 deletions. > > > > diff --git a/tools/mirror_check.rb b/tools/mirror_check.rb > new file mode 100755 > index 000..5fd443b [snip] > + > +# Are we really running under a shell? > +if __FILE__ == $0 and ENV['SHELL'] and ! ENV['REQUEST_METHOD'] As an alternative to checking ENV, consider moving the html view code (_html below and methods like display above) to the cgi. [snip] > +print "Status: 200 OK\r\n" Probably not a good idea; Wunderbar will output a status line if there is a failure; I'm not sure how CGI servers handle having mutliple status lines. - Sam Ruby
project wiki for board reports?
As new chair :-), I'd like to move towards making project reports more of a community effort. I know some other projects develop their reports using a wiki; any objections or better ideas? - Sam Ruby
Re: gitpubsub for code on Whimsy - broken?
On Fri, Apr 1, 2016 at 9:21 AM, sebb wrote: > On 1 April 2016 at 14:10, Sam Ruby wrote: >> On Fri, Apr 1, 2016 at 9:02 AM, sebb wrote: >>> On 1 April 2016 at 13:48, Sam Ruby wrote: > > I meant that the function would do a git pull or whatever it is that > the scheduled service does anyway. > I did not mean that the function would be able to add arbitrary code. > The code would still have to be committed to the git repo first. > > The auth would only be needed to prevent it being done unnecessarily. I'll look into this. As of a few hours ago gitpubsub was enabled for git-dual repositories, including whimsy. It does mean that we would have another process that would need to be monitored, but that's no problem. That process would need to be able to update code, install gems, and touch files in the docroot. I'd like to do what I should have done from the beginning: create a local role account do to these updates. - Sam Ruby
Re: project wiki for board reports?
On Mon, Apr 4, 2016 at 8:55 AM, Shane Curcuru wrote: > Sam Ruby wrote on 4/3/16 7:02 PM: >> As new chair :-), I'd like to move towards making project reports more >> of a community effort. I know some other projects develop their reports >> using a wiki; any objections or better ideas? >> >> - Sam Ruby > > +1, although it would be nice to not have yet another login (i.e. not on > a separate wiki realm). I don't see this PMC using a wiki for too much. > > Why not just an SVN file that is exposed via a simple whimsy page that > just presents an Edit and Commit buttons? That way command line users > can go old skool, but UI people can hit the web page super-simply. So... https://svn.apache.org/repos/private/pmc/whimsy/ ? This would enable the rare situation where we have tags. > - Shane > > P.S. I'd build it, but don't have time to do code work for another few > weeks until after budget and ApacheCon. The SVN repository could be set up now, and the front end could be added later. - Sam Ruby
Re: gitpubsub for code on Whimsy - broken?
On Mon, Apr 4, 2016 at 11:56 AM, sebb wrote: > On 4 April 2016 at 12:54, Sam Ruby wrote: >> On Fri, Apr 1, 2016 at 9:21 AM, sebb wrote: >>> On 1 April 2016 at 14:10, Sam Ruby wrote: >>>> On Fri, Apr 1, 2016 at 9:02 AM, sebb wrote: >>>>> On 1 April 2016 at 13:48, Sam Ruby wrote: >>> >>> I meant that the function would do a git pull or whatever it is that >>> the scheduled service does anyway. >>> I did not mean that the function would be able to add arbitrary code. >>> The code would still have to be committed to the git repo first. >>> >>> The auth would only be needed to prevent it being done unnecessarily. >> >> I'll look into this. >> >> As of a few hours ago gitpubsub was enabled for git-dual repositories, >> including whimsy. >> >> It does mean that we would have another process that would need to be >> monitored, but that's no problem. >> >> That process would need to be able to update code, install gems, and >> touch files in the docroot. I'd like to do what I should have done >> from the beginning: create a local role account do to these updates. > > Why not just use the _www account? EEK! -1. No. I'm trying to be careful, running with $SAFE=1, untainting content only when I can trust the source or if it passes validation; but should a script injection attack vulnerability be present, the last thing I would want to do is to allow the web server to be able to overwrite code. > That's what is done on projects.a.o. Perhaps we should compare notes. That doesn't seem wise. On the other hand: http://imgs.xkcd.com/comics/bridge.png > The account does not need auth to do a pull from the main git repo, > but it does need to create files which are readable by the _www id, > and directories which are writable. Readable should not be a problem. > So if we use something other than _www, care will need to be taken to > ensure that the writable permissions are not affected. That's where puppet comes in, changing the ownership and/or permissions to selected directories. Directories like /srv/whimsy/www/public and /srv/whimsy/www/logs and /srv/whimsy/www/board/minutes which should contain only data, not code. - Sam Ruby
Re: Feature request: access to previous comments
On Tue, Apr 5, 2016 at 12:25 PM, Mark Thomas wrote: > Hi, > > As a new board member I'd find it very useful to be able to see previous > comments along with the previous reports while I am reviewing a PMC's latest > report. If this is already available and I've missed it, feel free to point > me in the right direction. Previous reports, and a secretary's summary of the discussion for public consumption is available. Simply click on the "Prior Reports" link (which my be on the info dropdown on narrow windows). If you are looking for the original (unfiltered) comments, they are available in https://svn.apache.org/repos/private/foundation/board/archived_agendas, but not surfaced in the board agenda application anywhere. Any thoughts on how you would like these comments shown (always shown, available when requested); and how far back to go (3months? A year?). > Thanks, > > Mark - Sam Ruby
looks like updates have stopped?
I pushed the following earlier today... https://github.com/apache/infrastructure-puppet/commit/ad8176c2f13793a086e9d530623937eb19a0f359 Checking to see what is wrong. - Sam Ruby
Re: Not in members.txt - why is that classed as .not_found ?
On Wed, Apr 6, 2016 at 4:40 AM, sebb wrote: > At present, non-members are flagged with "Not in members.txt" which is > fine, but the text is in red. > That seems wrong; it's not an error to not be a member. It certainly was a surprise to me to find non-members in the ASF member group. And to the secretary too; particularly as there have been periodic suggestions to replace members.txt with LDAP. I would like those differences to continue to be highlighted. If we can find an automated way to distinguish between those that were intentionally added despite not being a member and unexplainable differences, then perhaps a different color would be warranted. There are LDAP entries in ou=services that could be used. The cn value for this service is one that the infrastructure team would prefer not be widely displayed; you can see it mentioned in groups.html.rb as a name to skip over when displaying groups. But first, it would be helpful to have the infrastructure team as well as the secretary confirm the intent here. > Maybe this crept in with the recent code re-org; I don't remember > noticing it earlier git blame is your friend: https://github.com/apache/whimsy/blame/master/www/roster/views/members.html.rb - Sam Ruby
Re: Monitor.rb and monitors/*.rb - inconsistent symbol/string hash keys
On Tue, Apr 5, 2016 at 5:43 PM, sebb wrote:
> I've started looking into how to quieten down the warnings without
> losing all the info.
>
> The monitors are called very fequently (maybe once or twice per minute)
> So it's vital that sending an e-mail is not needlessly repeated.
>
> I was hoping to use the previous_status hash which is passed in.
>
> I tried comparing hashes, but this shows differences, for example:
>
> previous
> {"ldap-services"=>{"href"=>"../logs/public-ldap-services",
> "mtime"=>"2016-04-05 00:15:43 +0100", "level"=>"warning",
> "data"=>"Last updated: 2016-04-05 00:15:43 +0100 (more than 1.5 hours
> old)"}}
>
> current
> {"ldap-services"=>{:href=>"../logs/public-ldap-services",
> :mtime=>2016-04-05 00:15:43 +0100, :level=>"warning", :data=>"Last
> updated: 2016-04-05 00:15:43 +0100 (more than 1.5 hours old)"}}
>
> The difference is that the input hash uses strings as hash keys,
> whereas the output hash uses symbols.
>
> It looks like monitor.rb is using mainly strings, whereas
> public_json.rb mainly uses symbols.
> This makes it harder to detect actual changes.
>
> Is there any reason not to use symbols for hash keys throughout?
No. :-)
Feel free to make it consistent.
- Sam Ruby
Re: Not in members.txt - why is that classed as .not_found ?
On Wed, Apr 6, 2016 at 12:41 PM, sebb wrote:
> On 6 April 2016 at 11:39, Sam Ruby wrote:
>> On Wed, Apr 6, 2016 at 4:40 AM, sebb wrote:
>>> At present, non-members are flagged with "Not in members.txt" which is
>>> fine, but the text is in red.
>>> That seems wrong; it's not an error to not be a member.
>>
>> It certainly was a surprise to me to find non-members in the ASF
>> member group. And to the secretary too; particularly as there have
>> been periodic suggestions to replace members.txt with LDAP.
>>
>> I would like those differences to continue to be highlighted. If we
>> can find an automated way to distinguish between those that were
>> intentionally added despite not being a member and unexplainable
>> differences, then perhaps a different color would be warranted.
>
> When I checked earlier today, *every* non-member seemed to be flagged
> up, not just ones in the unix group.
>
> For example, I'm pretty sure this one was:
>
> https://whimsy.apache.org/roster/committer/davekoelmeyer
>
> and all the others I checked in JspWiki.
>
> Looks like it is fixed now (71fe9e9?)
Ah, yes that was a regression that I also noticed and fixed. I
thought you were talking about the
https://whimsy.apache.org/roster/group/member page, but you were
talking about individual committer pages.
The problem is that while JavaScript will treat lots of values as
false, including null, 0, '"", and [], it will treat {} as true. So I
fixed that on the server side. Now the client will see undefined,
which JavaScript will also treat as false.
>> There are LDAP entries in ou=services that could be used. The cn
>> value for this service is one that the infrastructure team would
>> prefer not be widely displayed; you can see it mentioned in
>> groups.html.rb as a name to skip over when displaying groups. But
>> first, it would be helpful to have the infrastructure team as well as
>> the secretary confirm the intent here.
>>
>>> Maybe this crept in with the recent code re-org; I don't remember
>>> noticing it earlier
>>
>> git blame is your friend:
>>
>> https://github.com/apache/whimsy/blame/master/www/roster/views/members.html.rb
>>
>> - Sam Ruby
- Sam Ruby
Re: Feature request: access to previous comments
On Thu, Apr 7, 2016 at 4:24 AM, Mark Thomas wrote: > On 2016-04-05 17:43, Sam Ruby wrote: >> On Tue, Apr 5, 2016 at 12:25 PM, Mark Thomas wrote: >> > Hi, >> > >> > As a new board member I'd find it very useful to be able to see previous >> > comments along with the previous reports while I am reviewing a PMC's >> > latest report. If this is already available and I've missed it, feel free >> > to point me in the right direction. >> >> Previous reports, and a secretary's summary of the discussion for >> public consumption is available. Simply click on the "Prior Reports" >> link (which my be on the info dropdown on narrow windows). > > I'd found those and they are very useful. > >> If you are looking for the original (unfiltered) comments, they are >> available in >> https://svn.apache.org/repos/private/foundation/board/archived_agendas, >> but not surfaced in the board agenda application anywhere. > > That is exactly what I was looking for. > >> Any thoughts on how you would like these comments shown (always shown, >> available when requested); and how far back to go (3months? A year?). > > Personally, I'd always like to see these with the prior report when looking > at the prior reports. In terms of how far back, the previous report as a > minimum and ideally a year. My motivation is that I want to more easily spot > patterns in comments over time. I've committed an initial implementation. Warning: some browsers seem to aggressively cache stylesheets, so you might want to go to the following page, refresh it, and then verify that 'h5.history' is present: https://whimsy.apache.org/board/agenda/stylesheets/app.css This just affects the indentation of the date headers for comments, but it is confusing without that indentation. > Thanks, > > Mark > -- > Sent via Pony Mail for dev@whimsical.apache.org. > View this email online at: > https://pony-poc.apache.org/list.html?dev@whimsical.apache.org - Sam Ruby
Re: Error trying to fix Johnzon report
Thanks for the stack traceback!
Unfortunately, what I can glean from the traceback is that a commit
was NOT attempted, and the code treated that as a commit failure and
retried the operation until the retry count was exceeded; at which
point it claimed that there was a commit failure.
I've updated the logic to only retry if a commit actually was
attempted and failed; I'll continue to investigate.
- Sam Ruby
On Sat, Apr 9, 2016 at 6:06 PM, John D. Ament wrote:
> {
> "transcript": [
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-vb3tyn",
> " U /tmp/d20160409-10839-vb3tyn",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-rms8jj",
> " U /tmp/d20160409-10839-rms8jj",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-bzuvft",
> " U /tmp/d20160409-10839-bzuvft",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-bzuvft/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-bzuvft/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-bzuvft/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-1vz6kj7",
> " U /tmp/d20160409-10839-1vz6kj7",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-1vz6kj7/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-1vz6kj7/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-1vz6kj7/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-1wx5o0k",
> " U /tmp/d20160409-10839-1wx5o0k",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-1wx5o0k/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-1wx5o0k/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-1wx5o0k/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-1lleuon",
> " U /tmp/d20160409-10839-1lleuon",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-1lleuon/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-1lleuon/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-1lleuon/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-114bqz3",
> " U /tmp/d20160409-10839-114bqz3",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-114bqz3/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-114bqz3/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160409-10839-114bqz3/board_agenda_2016_04_20.txt",
> "Updated to revision 67653.",
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160409-10839-7k5pmo",
> " U /tmp/d20160409-10839-7k5pmo",
> "Checked out revision 67653.",
> "$ svn update /tmp/d20160409-10839-7k5pmo/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160409-10839-7k5pmo/board_agenda_2016_04_20.txt':",
> "A
Re: Error trying to fix Johnzon report
On Sun, Apr 10, 2016 at 4:33 PM, John D. Ament wrote:
> Well, there's definitely something up w/ the johnzon report. Now I get this
There were two bugs, only one was unique to the johnzon resolution.
Both are fixed now, and I've deployed and verified the fixes. And I
made a fix to the title of the johnzon resolution title to match other
resolutions.
Thanks!
- Sam Ruby
> {
> "transcript": [
> "$ svn checkout --depth empty
> https://svn.apache.org/repos/private/foundation/board
> /tmp/d20160410-17871-1n4xpey",
> " U /tmp/d20160410-17871-1n4xpey",
> "Checked out revision 67660.",
> "$ svn update /tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt",
> "Updating '/tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt':",
> "A/tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt",
> "Updated to revision 67660."
> ],
> "exception": "#",
> "backtrace": [
> "/srv/whimsy/www/board/agenda/views/actions/post.json.rb:68:in `block
> in _evaluate'",
> "/srv/whimsy/www/board/agenda/models/agenda.rb:118:in `block in
> update'",
> "/srv/whimsy/www/board/agenda/models/agenda.rb:100:in `open'",
> "/srv/whimsy/www/board/agenda/models/agenda.rb:100:in `update'",
> "/srv/whimsy/www/board/agenda/views/actions/post.json.rb:10:in
> `_evaluate'",
> "/srv/whimsy/www/board/agenda/routes.rb:125:in `block in (required)>'",
> "/srv/whimsy/lib/whimsy/asf/rack.rb:195:in `call'",
> "/srv/whimsy/lib/whimsy/asf/rack.rb:82:in `call'",
>
> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in
> `process_request'",
>
> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:160:in
> `accept_and_process_next_request'",
>
> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:113:in
> `main_loop'",
>
> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler.rb:416:in
> `block (3 levels) in start_threads'",
>
> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/utils.rb:113:in
> `block in create_thread_and_abort_on_exception'"
> ]
> }
>
> All I did was a reflow of the report.
>
> On Sun, Apr 10, 2016 at 1:20 PM Sam Ruby wrote:
>
>> Thanks for the stack traceback!
>>
>> Unfortunately, what I can glean from the traceback is that a commit
>> was NOT attempted, and the code treated that as a commit failure and
>> retried the operation until the retry count was exceeded; at which
>> point it claimed that there was a commit failure.
>>
>> I've updated the logic to only retry if a commit actually was
>> attempted and failed; I'll continue to investigate.
>>
>> - Sam Ruby
>>
>> On Sat, Apr 9, 2016 at 6:06 PM, John D. Ament
>> wrote:
>> > {
>> > "transcript": [
>> > "$ svn checkout --depth empty
>> > https://svn.apache.org/repos/private/foundation/board
>> > /tmp/d20160409-10839-vb3tyn",
>> > " U /tmp/d20160409-10839-vb3tyn",
>> > "Checked out revision 67653.",
>> > "$ svn update
>> /tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt",
>> > "Updating
>> '/tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt':",
>> > "A/tmp/d20160409-10839-vb3tyn/board_agenda_2016_04_20.txt",
>> > "Updated to revision 67653.",
>> > "$ svn checkout --depth empty
>> > https://svn.apache.org/repos/private/foundation/board
>> > /tmp/d20160409-10839-rms8jj",
>> > " U /tmp/d20160409-10839-rms8jj",
>> > "Checked out revision 67653.",
>> > "$ svn update
>> /tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt",
>> > "Updating
>> '/tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt':",
>> > "A/tmp/d20160409-10839-rms8jj/board_agenda_2016_04_20.txt",
>> > "Updated to revision 67653.",
>> > "$ svn checkout --depth empty
>> > https://svn.apache.org/repos/p
Re: Error trying to fix Johnzon report
On Sun, Apr 10, 2016 at 7:10 PM, John D. Ament wrote:
> I saw the change to the board report. Just curious, why is there a
> shortened form displayed on the report?
Short version of the answer: to make the text that shows up in the
browser tab meaningful.
Of course, there isn't any strong requirement that the tab matches
what is shown in the header of the page itself, nor that either match
what is shown in the agenda index page or in the navigation links at
the bottom of the page.
While everything is up for discussion, of those, I would be most
opposed to putting the full title in the navigation links in the
bottom of the page; and least opposed to putting the full title in the
header at the top. There is no obvious "right" answer for what should
be shown at the top, but my preference is to match the navigation
links at the bottom.
> John
- Sam Ruby
> On Sun, Apr 10, 2016 at 6:43 PM Sam Ruby wrote:
>
>> On Sun, Apr 10, 2016 at 4:33 PM, John D. Ament
>> wrote:
>> > Well, there's definitely something up w/ the johnzon report. Now I get
>> this
>>
>> There were two bugs, only one was unique to the johnzon resolution.
>> Both are fixed now, and I've deployed and verified the fixes. And I
>> made a fix to the title of the johnzon resolution title to match other
>> resolutions.
>>
>> Thanks!
>>
>> - Sam Ruby
>>
>> > {
>> > "transcript": [
>> > "$ svn checkout --depth empty
>> > https://svn.apache.org/repos/private/foundation/board
>> > /tmp/d20160410-17871-1n4xpey",
>> > " U /tmp/d20160410-17871-1n4xpey",
>> > "Checked out revision 67660.",
>> > "$ svn update
>> /tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt",
>> > "Updating
>> '/tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt':",
>> > "A/tmp/d20160410-17871-1n4xpey/board_agenda_2016_04_20.txt",
>> > "Updated to revision 67660."
>> > ],
>> > "exception": "#",
>> > "backtrace": [
>> > "/srv/whimsy/www/board/agenda/views/actions/post.json.rb:68:in `block
>> > in _evaluate'",
>> > "/srv/whimsy/www/board/agenda/models/agenda.rb:118:in `block in
>> > update'",
>> > "/srv/whimsy/www/board/agenda/models/agenda.rb:100:in `open'",
>> > "/srv/whimsy/www/board/agenda/models/agenda.rb:100:in `update'",
>> > "/srv/whimsy/www/board/agenda/views/actions/post.json.rb:10:in
>> > `_evaluate'",
>> > "/srv/whimsy/www/board/agenda/routes.rb:125:in `block in > > (required)>'",
>> > "/srv/whimsy/lib/whimsy/asf/rack.rb:195:in `call'",
>> > "/srv/whimsy/lib/whimsy/asf/rack.rb:82:in `call'",
>> >
>> >
>> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in
>> > `process_request'",
>> >
>> >
>> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:160:in
>> > `accept_and_process_next_request'",
>> >
>> >
>> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:113:in
>> > `main_loop'",
>> >
>> >
>> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/request_handler.rb:416:in
>> > `block (3 levels) in start_threads'",
>> >
>> >
>> "/usr/local/rvm/gems/ruby-2.3.0/gems/passenger-5.0.23/src/ruby_supportlib/phusion_passenger/utils.rb:113:in
>> > `block in create_thread_and_abort_on_exception'"
>> > ]
>> > }
>> >
>> > All I did was a reflow of the report.
>> >
>> > On Sun, Apr 10, 2016 at 1:20 PM Sam Ruby wrote:
>> >
>> >> Thanks for the stack traceback!
>> >>
>> >> Unfortunately, what I can glean from the traceback is that a commit
>> >> was NOT attempted, and the code treated that as a commit failure and
>> >> retried the operation until the retry count was exceeded; at which
>> >> point it claimed that there was a commit failure.
>> >>
>> >> I've updated the logic to only retry if a commit actually was
>> >> atte
