dbs has put together a proof-of-concept branch merging the documentation repository with the code repository at user/dbs/doc_consolidation_master in working
The goal is to enable DIG members to commit directly to anything under the docs/ subdirectory of Evergreen. Release notes and install instructions will be located there, with INSTALL && README now being simple symlinks to the actual install docs.
Any objections / questions? Shall we make it so?
Release notes entries
We're putting these in a "RELEASE_NOTES_NEXT" directory or something like that now (clarification appreciated)
Is the process that, when the branch gets merged, the release notes entry will get pulled into the release notes file at that time and the RELEASE_NOTES_NEXT directory gets deleted?
Github pull requests
I imagine we're going to get more pull requests from github users. More contribution == goodness, but we also need to maintain sign-offs and quality commit logs (see fun Linus rant about github pull requests), and there seems to be a common pattern in github pull requests that suggests people aren't reading our "contributing" wiki doc, or our dev:git wiki page.
Maybe we could edit the HACKING doc to the root of the git directory / tarball to make it contain the simplest possible info about requirements (good commit logs, sign-offs, pointer to http://bugs.launchpad.net)?
Any thoughts on https://bugs.launchpad.net/evergreen/+bug/925776 (OU-targeted URI's and scoping with staff searches) I told Beth (from the ticket) that I'd bring it up and see what folks thought.
dbs added a comment, following a similar complaint from rjackson-isl in IRC this morning, trying to describe the use case for the behaviour. It's working as designed, but it sounds like there's a non-trivial number of staff who would prefer it to be designed differently.
GSoC project updates: Ideally from the students themselves, if they're in attendance.
Please note any bottlenecks / barriers that you might be running into; the community wants to help.
There's some good info in the write-up in the pull request itself, but the commits need to be cleaned up with improved comments and DCO sign-offs. Would anyone be willing to work with Bennett to help guide him through our process?
Update: Bennett took another stab at a cleaned-up commit, per the bug; still need eyeballs & braiiinz
Evergreen
Evergreen release 2.0.11
Evergreen release 2.1.2
Once OpenSRF 2.1.0 is cut, dbs will focus on a 2.1.2 release