I agree with Shane's input. Some additional thoughts: Re: svn vs git; the issue is how to supply the user and password on commits(svn) and pushes(git). Svn has convenient --username and --password arguments, and we have experience with ensuring that such information does not show up in logs. While git supports user:password inside the name of the repository URL, that probably should be avoided as it likely will show up in error messages. Other methods like personal access tokens might be worth exploring. What likely would be the solution would be to use the PseudoTerminal class for ruby (https://ruby-doc.org/stdlib-2.4.2/libdoc/pty/rdoc/PTY.html), and watch for the password prompt and respond to it. Once this is solved, it would open up git for other whimsy tools, but until this is investigated and resolved, svn is the easier choice.
I also agree that incubator/reports should be a separate tool. It can initially be created by stealing code from the board agenda tool. I wouldn't worry too much about small amounts of duplication; but large amounts of duplication can be factored out into library functions that both tools (and potentially other tools) could use. The place to start is with code that parses the incubator report and spits out JSON. To get an idea of what I'm talking about, take a look at https://whimsy.apache.org/board/agenda/2017-11-15.json. The agenda is split up into pages, each with text and many with additional information (like owner, shepherd, etc). The first version of the incubator report tool could be as simple as a read/only display of these reports. Once that is up and running, actions can be added one by one. One thing I would like to make a case for is to have a test suite. There is a test suite for the board agenda tool, and it is run as a part of CI after every commit. I suggest you try it out: $ cd whimsy/www/board/agenda $ bundle install $ npm install $ rake test - Sam Ruby On Mon, Nov 27, 2017 at 12:28 PM, Shane Curcuru <[email protected]> wrote: > John D. Ament wrote on 11/26/17 8:46 PM: >> I want to start bouncing around the idea of moving podling board reports >> into screens in whimsy. The problem: moinmoin & there's a section of 5 >> years of reports that needs to get duplicated on the landing page. User >> IDs on moinmoin are a pain, since they require unique credentials. Would >> be better if this were maintained within a single system. > > I love this idea, and have some suggestions although it's unlikely I can > give much help on the coding side. > > - Trying to build something for a wiki system is a bad idea. Changing > the PPMC process to checkin their reports to SVN/Git is far easier a > social change than getting Whimsy to reliably work with a wiki. > > - Managing files from SVN is easy including commits; git commits are not > implemented. I'd think it would be reasonably easy to build, and > certainly would be easy to test if done similarly to the SVN way: > > https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/svn.rb#L185 > > - Figure out which features need to be complete and enforce validation > up front, vs. which features could simply be advisory / post a warning. > Having strict controls from LDAP would be great - but it might be a > while before that's fully implemented/tested/the PPMC rosters are all > complete and up-to-date. Rolling the tool out allowing anyone in IPMC > group to access it means 1) rarely the wrong person will change > something, but 2) new podling members won't have to wait until their > special podling's LDAP is updated or whatever. > > - From the perspective from a watching but only occasionally active PMC > member, this would work best as an independent tool modeled on the board > agenda tool - which has a ton of other logic that we don't necessarily > need in the IPMC's process of having podlings submit reports, mentors > signoff, and basically organizing the Incubator report to then submit as > a whole to the board agenda. > > Looking at it another way, in terms of making our tools simpler for more > PMC members to help out with, having an IncubatorReport tool would be a > lot clearer than adding a lot more stuff to the existing Agenda > application. IPMC needs to coordinate various submissions and checkoffs > over the couple of weeks that the report is built; the output is then > one file (structured so Agenda can easily *read* metadata) that's just > pushed to foundation/board/current_agenda_file. The board Agenda > application has a lot more live working functionality you don't strictly > need. > > But again, just an idea for simplicity. 8-) > >> >> I plan at some point to start putting together ideas on how to move >> proposals over as well, but one step at a time. >> >> This is ideally what I want to see (and there's likely more): >> >> - PPMC members have access only to post their own reports. They can't post >> each others, and they can't post to TLPs. They probably also can't read >> the TLP reports, but its likely OK if they >> - Roster is robust enough that we have their information about who is >> responsible for submitting the report and who is responsible for signing >> off on the report. >> - I imagine, I want podling mentors to sign off on reports similar to how >> the board signs off on reports. >> - There's a podling report template. I want the template to be present >> when they first go to submit the report. I want to easily update this >> template (so it should be read from another file, or in a single spot in >> the code). >> - I want to tie the notifications into whimsy. Initial notification when >> the report becomes available (e.g. today), reminders every other day until >> submitted. >> - Remember that we ask podlings to be ready a week prior. I'd actually >> like if this tool could bridge that gap automatically, since really all the >> IPMC does is flag inappropriate reports. I'd be fine with it being a VP >> Incubator step to bring the report in, e.g. accept it. >> - There's a cap (default) on 3 podlings per shepherd. Shepherds can tweak >> this in the file, but this implies that not all podling reports have >> shepherds assigned to them. >> - I'm fine if the file that the report gets saved to is in the incubator >> SVN. I would prefer it in the incubator git. I don't think there would be >> anything blocking either use though. >> >> This is just some ideas. I'm wondering how much of the current agenda can >> be reused to build this? >> >> John >> > > > -- > > - Shane > https://www.apache.org/foundation/marks/resources
