Open Stack

On Mon, Apr 28, 2014 at 12:58 AM, Andreas Jaeger <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.

Thoughts?
Anne




>  You're not getting in the way - I was just too brief in my email ;)
>
> I'm also fine with any other means - and if we don't want to tag, so be it,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: 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
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140428/1c56b069/attachment.html>