Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of yashinm92@gmail.com
 designates 209.85.217.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx75Ty_p8YRbJr9cnwHfQxfmB7RTVNTAKNSLCD_gyyLdKw@mail.gmail.com>
References: 
 <CAEkz3Nw4=sMw=5meXKv545iJ67ACnVcHiKxDSkEbaGBx1ggWCw@mail.gmail.com>
	<CAL+Y1nuZXeO2sYRRQNKXnvmPzHWFXavpXxL_tbWDw-K0uQwEhw@mail.gmail.com>
	<CAKmKYaC5YFo8Q6t2yK5M-GX_K0Uh-CkA-_+=e1QG0jM5-h9nMw@mail.gmail.com>
	<CAEkz3Nx-VkZUgro=91-6u8ZUd3qN2C18-jxw7d1N=Z_9GoEr2A@mail.gmail.com>
	<CAKmKYaA7X7w-n4jyy+TStzND6z+tMjAJGrxg6+DL2tK8nQaCQA@mail.gmail.com>
	<CAL+Y1nsHkGePbr23b0UBXz=r_UTdm0qRVUao_r1btaW6LBN6Yw@mail.gmail.com>
	<CAPaJBx57V9K3hXyNmAuhoFmruV204pdmvaF=t-a6QH4gXe-ASQ@mail.gmail.com>
	<CAEkz3NxWYgqJn-D_fzur6QGNw3ZxMYbYRRoZ8MN4My+EkS1N+Q@mail.gmail.com>
	<CAPaJBx7T6H0PwrvLE-3qXV_b=SMRcHuiD8EZ_by2hHUf8cZa2w@mail.gmail.com>
	<CAEkz3NyUdZYTHGmWSu7mRQ5UhcgHSzR4cMjq=LvPE++f21KvKg@mail.gmail.com>
	<CAPaJBx6u6AgNyXRxQN3E_N_XdiqonO3ow7BfnuyZRYhfF8eeRQ@mail.gmail.com>
	<CAHdjipL5pbQ1nMDu+3myzwpVTmGNzD7vpWdHyoiQkUkN1kftuw@mail.gmail.com>
	<CAPaJBx75Ty_p8YRbJr9cnwHfQxfmB7RTVNTAKNSLCD_gyyLdKw@mail.gmail.com>
Date: Sat, 10 Aug 2013 15:04:43 +0530
Message-ID: 
 <CAEkz3Nyg+gfz8=VGbccAfc5GwqOZ+FU+AFdbFYDaKqVzz6Apdg@mail.gmail.com>
Subject: Re: Project proposal for ICFOSS
From: Yashin Mehaboobe <yashinm92@gmail.com>
To: dev@couchdb.apache.org
Cc: Alexander Shorin <kxepal@gmail.com>, Noah Slater <nslater@apache.org>,
	Dirkjan Ochtman <djc.ochtman@gmail.com>, Dave Cottlehuber <dch@jsonified.com>
Content-Type: multipart/alternative; boundary=089e01228e5ae1eba404e3949943

--089e01228e5ae1eba404e3949943
Content-Type: text/plain; charset=ISO-8859-1

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 <nslater@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 <kxepal@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 <nslater@apache.org> wrote:
> > > On 30 July 2013 20:13, Yashin Mehaboobe <yashinm92@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

--089e01228e5ae1eba404e3949943--