Open Stack

On 04/28/2014 06:54 PM, Anne Gentle wrote:
> 
> 
> 
> On Mon, Apr 28, 2014 at 12:58 AM, Andreas Jaeger <aj at suse.com
> <mailto:aj at suse.com>> wrote:
> 
>     On 04/28/2014 07:56 AM, Tom Fifield wrote:
>     > On 28/04/14 13:52, Andreas Jaeger wrote:
>     >> On 04/28/2014 02:28 AM, Tom Fifield wrote:
>     >>> On 28/04/14 01:30, Andreas Jaeger wrote:
>     >>>> Anne,
>     >>>>
>     >>>> even if we do not tag openstack-manuals right now, we should
>     tag IMHO
>     >>>> the other projects to mark the release of Icehouse - this means
>     all the
>     >>>> API projects as well as the operations-guide.
>     >>>
>     >>> Operations guide is not tied to a particular OpenStack release, so I
>     >>> wouldn't bother for that one. The API site uses API versions (eg v2,
>     >>> v3), rather than release versions, so I question whether there's
>     a need
>     >>> for this ?
>     >>
>     >> It was done with Havana, so I thought it was custom usage.
>     >>
>     >>> Is there a particular use case for repo tags for these two?
>     >>
>     >> I stumpled upon this when looking at Stackalytics where the
>     config files
>     >> need some information when a release cycle starts. Adding just
>     git ids
>     >> to the list works as well,
>     >
>     >
>     > OK, fair enough, I guess it doesn't break anything, and stackalytics
>     > (and stats in general) is a fair use-case .. the point-in-time
>     where we
>     > stopped cycle X and started cycle Y :)
>     >
>     > As long as we can avoid confusion (eg people thinking they need to
>     > backport for these repos), all good on my end! Sorry for getting
>     in the
>     > way :)
> 
> 
> I think the original reason for branching still holds true -- to make
> releases from released documentation that we can then replicate. It does
> mean backporting so the less we do of that, the better!
> 
> The reasons for tagging sound like:
> - stats tracking 
> - change management (Knowing when a big change happened to a repo may be
> important. In the case of the ops guide, we tagged because we wanted to
> know when O'Reilly edits were happening and be able to re-create the
> original version for reference.)
> 
> My concern with the overhead of tagging at each release is related to
> the reasons. 
> -Stats aren't the best method to measure doc contributions for accuracy
> and completeness or coverage. In the past we just used a known SHA for
> stats collection, has that changed?
> - We want to get rid of the <project>-api repos anyway for all the
> overhead in maintenance they cause, so adding tags now seems against
> that goal of decreasing work done to those repos.
> 
> I'd rather not add another task to releases. The projects get to rely on
> their release manager for the tagging-related tasks -- the Docs PTL
> won't have that luxury. That said, for change management, I think it's
> fair to ask for tagging. So it might make sense to tag operations-guide
> and openstack-manuals, but I'm not sure we need it for other docs repos,
> especially API docs.
> 
> I think that's all my concerns. So my counter proposal would be to tag:
> openstack-manuals
> operations-guide (and even this is iffy since there won't be a reason to
> recreate an original version for a while?)
> 
> But not the API repos. 

With that reasoning, I'm also fine with only tagging openstack-manuals
(and we tag that one only once we branch) and not tagging
operations-guide at all.

Let me send a patch for the stats tracking,
Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126