Need to track docs for future releases

[Lefty Leverenz <le...@hortonworks.com>]

Now that all the Hive docs are in the wiki, we can't commit new
documentation to trunk or branch.  But we don't want to add docs to the
wiki prematurely, so there's an increased likelihood that we'll lose track
of some doc requirements for future releases.  Does anyone know of a good
way to ensure that no doc gets left behind?

One possibility is to use labels on JIRAs that need future documentation.
 When HIVE-# gets committed with "Fix in 0.12" and still needs docs, it
would get a label such as "doc-needed-v0.12" which can be used to find all
the doc requirements at release time.

That might be the simplest solution, although I see two problems:  if the
fix number gets changed, the label has to change too; and sometimes people
enter a label that seems right to them but doesn't match exactly.

Another possibility is to use JIRAs, either adding a child JIRA for each
closed JIRA that still needs doc or using an umbrella JIRA for each
upcoming release.

An ideal solution would automatically spew out a list of JIRAS that need
docs for a given release number, either on request or when the release
happens.  Is that technically possible?

– Lefty

Re: Need to track docs for future releases

[Lefty Leverenz <le...@hortonworks.com>]

Please don't all speak at once.

Related issue:  Do we need a "Resolved" or "Fix Version/s" status for
"fixed in the wiki"?

– Lefty



On Thu, May 2, 2013 at 3:38 PM, Lefty Leverenz <le...@hortonworks.com>wrote:

> Now that all the Hive docs are in the wiki, we can't commit new
> documentation to trunk or branch.  But we don't want to add docs to the
> wiki prematurely, so there's an increased likelihood that we'll lose track
> of some doc requirements for future releases.  Does anyone know of a good
> way to ensure that no doc gets left behind?
>
> One possibility is to use labels on JIRAs that need future documentation.
>  When HIVE-# gets committed with "Fix in 0.12" and still needs docs, it
> would get a label such as "doc-needed-v0.12" which can be used to find all
> the doc requirements at release time.
>
> That might be the simplest solution, although I see two problems:  if the
> fix number gets changed, the label has to change too; and sometimes people
> enter a label that seems right to them but doesn't match exactly.
>
> Another possibility is to use JIRAs, either adding a child JIRA for each
> closed JIRA that still needs doc or using an umbrella JIRA for each
> upcoming release.
>
> An ideal solution would automatically spew out a list of JIRAS that need
> docs for a given release number, either on request or when the release
> happens.  Is that technically possible?
>
> – Lefty
>
>