First of all, so sorry for the late reply. Secondly, I've been selected to work on this project so thank you so much for letting me work on this :) . I'll have a rudimentary code up and running as soon as possible.
Noah: So instead of integrating the Git and JIRA requests into bootstrap I will create a separate python script that will pull them into an RST file that can be improved upon if needed. That's what you meant right? Alexander: I was thinking of starting to create the RST file from current release only. From now on, a unique file will be created for each branch release (with the commit hash/version as the name?). About the integration of upgrade notes and CVE warnings into the file, could you please suggest from where I can pull the data? Is it usually present in the Git repository or the JIRA? On Sun, Aug 4, 2013 at 2:09 AM, Noah Slater <nsla...@apache.org> wrote: > Hmm. > > If we're planning to commit the file, then the generation should not be in > ./boostrap at all. > > Instead, we should ship a utility script that spits out an RST file that > serves as a *starting point* for editing, and then committing. > > > On 3 August 2013 20:33, Alexander Shorin <kxe...@gmail.com> wrote: > > > Hi Yashin, > > > > Do you plan to generate since RST file with all changes or only just > > for current release? > > > > Why I'm asking...There is already change history for old releases that > > is not possible to generate automatically: it was quite untrivial to > > automate for 1.3.0 release for me since there was a lot of false > > positive matches or no matches at all. Completely regenerate past > > history also isn't good idea since it will be very heavy operation > > with a lot of JIRA requests. > > > > So the idea: to generate changes only for current branch release. Get > > the commit hash when previous release was tagged and scan commits till > > HEAD for features, JIRA issues etc. The output will be the file for > > specific branch. > > > > For example how it may looks: > > http://kxepal.iriscouch.org/docs/1.3/whatsnew/index.html > > > > By the way. This generated change log have to be stored on disk and be > > committed: how we're planning to write Upgrade notes, CVE warnings, > > Breaking changes and Migration guides for new release? Or, if not, how > > and from where the script will embed them into generated .rst file(s)? > > > > -- > > ,,,^..^,,, > > > > > > On Sat, Aug 3, 2013 at 12:18 AM, Noah Slater <nsla...@apache.org> wrote: > > > On 30 July 2013 20:13, Yashin Mehaboobe <yashin...@gmail.com> wrote: > > > > > >> > > >> 1.User runs bootstrap > > >> > > > > > > Yep. But remember: only people building CouchDB from a Git checkout > will > > > ever need to run ./boostrap. When we distribute CouchDB from our > website, > > > all of the files that ./boostrap generates are included for them. > > > > > > > > >> 2.Bootstrap fetches the git commit messages too and stores in an rst > > file > > >> > > > > > > Sounds good. > > > > > > > > >> 3.The python script uses this rst file to generate documentation. > > >> > > > > > > Yep! But note: the Python script that generates the RST files is called > > by > > > make. So we have two steps here: > > > > > > ./bootstrap run on a pristine source checkout, and only run by devs. It > > > talks to Git, and generates an RST file. > > > > > > Make is configured to expect the RST file, as if it were a regular part > > of > > > the source. When you run "make", the regular rules for building the > docs > > > should pick up the RST file and include it into the docs. > > > > > > -- > > > NS > > > > > > -- > Noah Slater > https://twitter.com/nslater > -- - Yashin Mehaboobe
