cloudstack-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [WEBSITE] Release support lifetime and related content
Date Tue, 12 Mar 2013 19:11:18 GMT
On Tue, Mar 12, 2013 at 02:13:54PM -0400, Mathias Mullins wrote:
> Chip, 
> Are you thinking of leaving this in the wiki or formalizing this out to a
> static page and then updating it as reviews come through? I would think
> for the website and this being very definitive data that this might
> constitute a static page rather than living in the wiki.

I put it on the wiki, specifically so that I could get the content
written down *somewhere*.  I'm more than happy if we decide to move it

The question is "where".  Some of the content is useful for developers
(and therefore should probably stay on the wiki).  Some of the content
is useful for both developers and users (which should probably be on the

I'd ask that the relevant material for devs is considered in any site
redesign.  I'd further suggest that, more generally, developer-centric
documentation should live on the wiki.  For instance, the "contributing"
page has instructions for working with review-board, but it's getting
out of date.  I'd rather allow the dev community to work with the wiki
to evolve processes over time...  

> I think the content is good, There were a couple points I had questions
> on. 
> 1. In the break out of the schedule under "Feature Release Cycle", do you
> want to put a timing for how long a initial vote will last, how secondary
> votes would happen (if needed) 

Those are good points.  Just added it to the page.

> and how long after release the merge back
> to the master will happen? 

This relates to your second question...  see below.

> Those could be talked about without talking to
> when a release would happen. I know being new to the project that has
> always been kinda confusing to me.
> 2. Another thing that is a little confusing (and this could be because I'm
> not a coder) is that the graphics seem to contradict each other about when
> the code merges back to the master. The second graphic under "Release
> Branch Lifecycle" shows coming off the master, but doesn't show a merge
> back to the master when that release is concluded. Is that intentional?
> This may be a learning question on my side.

Commits are expected to happen in both master and release branches.  We
don't "merge back to master" really...  the *normal* flow is to fix in
master, and cherry-pick into the release branch.  The optional approach
is to fix in the release branch, and port over to master.  We don't do a
full merge from branch to master though.

> Thanks,
> Matt 
> On 3/12/13 1:30 PM, "Chip Childers" <> wrote:
> >On Tue, Mar 12, 2013 at 05:15:12PM +0000, Musayev, Ilya wrote:
> >> > -----Original Message-----
> >> > From: Chip Childers []
> >> > Sent: Monday, March 11, 2013 9:07 PM
> >> > To:
> >> > Subject: [WEBSITE] Release support lifetime and related content
> >> > 
> >> > Hi all,
> >> > 
> >> > In working on some changes to the "Releases" section of the wiki, I
> >>put
> >> > together some information that we may want to publish to the website.
> >> > 
> >> > At a minimum, I think that it would be useful to have a statement of
> >>our
> >> > support model somewhere (perhaps the downloads page).
> >> > 
> >> > Take a look here:
> >> > 
> >> >
> >> > 
> >> > -chip
> >> 
> >> I read it over several times. Just need you to confirm that this is
> >>final and approved.
> >> I'd like to update Wikipedia and reference this doc as source.
> >
> >So in projects like this, there's no such thing as *final*.  We only have
> >the
> >current consensus.  However, I think that it's reasonable to consider
> >this to be the current consensus (otherwise I wouldn't have documented
> >it... ;-) ).

View raw message