cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS][DOCS] Docs as their own repo? Was: [DISCUSS][TRANSLATION] commit to master or not ?
Date Thu, 28 Mar 2013 14:58:42 GMT
On Thu, Mar 28, 2013 at 10:45:41AM -0400, David Nalley wrote:
> On Thu, Mar 28, 2013 at 10:34 AM, Chip Childers
> <chip.childers@sungard.com> wrote:
> > On Thu, Mar 28, 2013 at 09:27:00AM -0500, Joe Brockmeier wrote:
> >> On Thu, Mar 28, 2013, at 08:28 AM, Chip Childers wrote:
> >> > Before we get to this, I have a broader question:  Do we want to move
> >> > the docs to their own git repo?  We manage them with different rules,
> >> > especially WRT code freeze and whatnot.  This translation question just
> >> > adds to the logic to pull the repo apart.
> >>
> >> This came up once before, and initially I was against having a different
> >> repo - but we've tried it for a while, and maybe it makes sense to break
> >> it out.
> >>
> >> Two questions:
> >>
> >> - one, are we still going to bundle docs into the tarball for release?
> >
> > I'd propose that they are actually a distinct download / artifact for
> > the release.  I'd procedurally release them at the same time as the
> > source artifacts, but I don't think that there's a ton of value in
> > bundling them with the source.  The build processes are different, and
> > packaging doesn't pull in the docs anyway.  Really, our docs are being
> > published to our website as the primary target for distribution right
> > now anyway...
> >
> >>
> >> - two, there was a proposal about using docs as tooltips, how would this
> >> affect that if the two are separate trees?
> >
> > Unsure where that proposal went...  and frankly I'm not sure I agree
> > with that approach anyway.
> >
> 
> That proposal moved forward and the first generation is in 4.1 iirc.
> That said it's not in the state originally proposed, and I've been
> struggling to get answers on how it is going to be handled in the
> future.
> If this is a veto from you, lets stop folks from working on it.
> 
> --David
>

Not a veto ATM. Let's take this to a separate thread to discuss.

Mime
View raw message