Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth round)

[Tracy Phillips]

I agree with the respin.

Cloudstack is still a young open source project and we don't need any
negative press/tweets/blogs/gossip :)


On Fri, Sep 20, 2013 at 1:03 AM, Animesh Chaturvedi <
animesh.chaturv...@citrix.com> wrote:

>
>
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Thursday, September 19, 2013 5:15 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > round)
> >
> >
> >
> > > -Original Message-
> > > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > Sent: Thursday, September 19, 2013 4:46 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > > round)
> > >
> > > I prefer a respin, as painful as that seems. VPC is a major feature,
> > > do we really want to release something that we know will break anyone
> > > who tries to upgrade?  I could deal with #1 if we are able to include
> > > the hotfix script in the packaging, such that the release notes can
> > > provide dead simple instructions for upgrade (no 'go download this
> > > script'). I'm just not clear on what we can change and what we can't
> > post-vote.
> >
> > [Animesh>] I don't think the  release artifacts can be changed so the
> > script will have to be downloaded. David/Chip/Wido any thoughts on that?
> > We can have the script available before the release announcement if we
> > continue with current VOTE.
> >
> > >
> [Animesh>] Only Marcus, Indra and Simon have responded I am prepared to
> respin tomorrow after VPC testing is complete with fixes from Alena. I
> would like to stick to 72 hour VOTE including weekend since last time most
> of the VOTEs were received over weekend.
>
>
> > > On Thu, Sep 19, 2013 at 3:59 PM, Animesh Chaturvedi
> > >  wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > > >> Sent: Thursday, September 19, 2013 10:43 AM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0 (fifth
> > > >> round)
> > > >>
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > > >> > Sent: Thursday, September 19, 2013 9:49 AM
> > > >> > To: dev@cloudstack.apache.org
> > > >> > Subject: RE: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > >> > (fifth
> > > >> > round)
> > > >> >
> > > >> > We do need to ensure that we have the db upgrade fix that was
> > > >> > mentioned on the other thread, otherwise people going from 4.1 to
> > > >> > 4.2 will have their VPCs break. Looks like we are waiting on a
> > > >> > script. It sounds like the plan will be to provide instructions
> > > >> > in the release notes. Really wish we would have caught that, its
> > > >> > not just that we find bugs at RC, but the severity of ones we
> > > >> > miss is astounding
> > > >> sometimes.
> > > >>
> > > >> [Animesh>] I am also stumped why this was not caught earlier.
> > > >> Kishan has a fix that is being tested.
> > > > [Animesh>] So while the fix  is being tested we have two options
> > > >
> > > > 1. Release 4.2, release note this issue, provide a separate script
> > > > that would have to be run if someone was using VPC in 4.1 and
> > > > upgraded to 4.2, fix this issue in 4.2.1
> > > >
> > > > 2. Since we have not released 4.2 yet, respin another RC and another
> > > > round of VOTE. That would be a record 6th RC Vote and 2 recalls
> > > > after successful votes :(
> > > >
> > > > Thoughts?
> > > >
> > > >>
> > > >> > On Sep 19, 2013 10:18 AM, "Animesh Chaturvedi" <
> > > >> > animesh.chaturv...@citrix.com> wrote:
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > > > -Original Message-
> > > >> > > > From: Wido den Hollander [mailto:w...@widodh.nl]
> > > >> > > > Sent: Wednesday, September 18, 2013 4:55 PM
> > > >> > > > To: dev@cloudstack.apache.org
> > > >> > > > Subject: Re: [VOTE][RESULTS] Release Apache CloudStack 4.2.0
> > > >> > > > (fifth
> > > >> > > > round)
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On 09/19/2013 01:28 AM, Animesh Chaturvedi wrote:
> > > >> > > > >
> > > >> > > > > The vote has *passed* with the following results (binding
> > > >> > > > > PMC votes
> > > >> > > > indicated with a "*" next to their name:
> > > >> > > > >
> > > >> > > > > +1 : Alex*, Chip*, Sebastien*, Prasanna*, Hugo*, Marcus*,
> > > >> > > > > +Wido*, Sebastien, Rajesh Batala, Sheng, Vijay, Abhi,
> > > >> > > > > +Likitha, Ian, Gavin, Daan, Amogh, Simon Weller,
> > > >> > > > >
> > > >> > > > > I'm going to proceed with moving the release into the
> > > >> > > > > distribution
> > > >> > > > repo now and work on release notes and other documentation
> > > tasks.
> > > >> > > > >
> > > >> > > > Who is going to build the RPM and Deb packages?
> > > >> > > >
> > > >> > > > I think I should build the .deb packages since I'm th

Re: [DISCUSS] UI: New look and feel

[Tracy Phillips]

I am a fan of Foundation's look (or Bootstrap even)...

http://foundation.zurb.com/

3d elements make it look dated, kind of like it does now. The less images,
the better imo.




On Thu, Sep 26, 2013 at 7:11 PM, Kelcey Jamison Damage <
kel...@backbonetechnology.com> wrote:

> Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.
>
> - Original Message -
> From: "Ilya Musayev" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, September 26, 2013 4:08:50 PM
> Subject: RE: [DISCUSS] UI: New look and feel
>
> Brian,
>
> Are we no longer using icons on the left navigation menu or is this a
> draft?
>
> Thanks
> ilya
>
> > -Original Message-
> > From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
> > Sent: Thursday, September 26, 2013 6:28 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] UI: New look and feel
> >
> > You just made my day, these look great. Most importantly it has a look
> that
> > will sell to IT managers, etc.
> >
> > I wish you the best of luck with this and hope for rapid progress :)
> >
> > Again, it looks awesome!
> >
> > - Original Message -
> > From: "Brian Federle" 
> > To: dev@cloudstack.apache.org
> > Cc: "Sonny Chhen" , "Animesh Chaturvedi"
> > , "Jessica Wang"
> > 
> > Sent: Thursday, September 26, 2013 3:11:07 PM
> > Subject: [DISCUSS] UI: New look and feel
> >
> > Hi all,
> >
> > In addition to the CSS code cleanup I'm working on, I am planning a
> 'reskin' of
> > the current UI to give a better user experience and look and feel. This
> will
> > utilize SASS and a grid system as I have discussed in the previous
> thread.
> >
> > I created a task in JIRA and wiki functional spec, which has screenshots
> of
> > what I've done so far and what I plan to do:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
> > al+appearance
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> >
> > You can also checkout the ui-restyle branch on git, if you are able to
> manually
> > compile the cloudstack.scss file via SASS (that will be automated in the
> > future). I can send over instructions on how to compile SASS manually;
> it's
> > pretty easy to setup.
> >
> > Let me know what you think so far :)  I'll of course up and post more
> > screenshots as I get more done. This reskin is only changing the CSS
> mainly,
> > with minimal changes to actual usage or JS code, so it is basically a
> drop-in
> > replacement for the current styling. I'm hoping to get this in by 4.3,
> so please
> > give me feedback on anything from the current UI you don't like or want
> > changed, and I can see about improving it.
> >
> > Thanks!
> > Brian
> >
>
>

Re: [DISCUSS] UI: New look and feel

[Tracy Phillips]

If you could use font icons, that would be really nice..

(MIT License)
http://fortawesome.github.io/Font-Awesome/icons/

(Apache License)
http://getbootstrap.com/components/#glyphicons



On Fri, Sep 27, 2013 at 1:53 PM, Brian Federle wrote:

> Right now the plan was to remove the icons, though if people think that
> they are important to usability then we can definitely put them back in.
> I'm thinking flat icons though, which would look better with the new
> design. I'll play around with it and maybe post a screenshot with icons
> included.
>
> The action icons on the detail pages will still be there, and of course if
> plugins supply their own icons they will be displayed.
>
> -Brian
>
> 
> From: SuichII, Christopher [chris.su...@netapp.com]
> Sent: Friday, September 27, 2013 5:14 AM
> To: 
> Subject: Re: [DISCUSS] UI: New look and feel
>
> Brian - The new style looks great, but I'd like to repeat someone else's
> question: Are we getting rid of the icons on the nav bar? As a plugin dev,
> it would be really nice to keep our company logo by our UI plugin.
>
> Shiva & Sebastien - What impact would this angular.js project have on UI
> plugins?
> --
> Chris Suich
> chris.su...@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
>
> On Sep 27, 2013, at 2:44 AM, sebgoa  wrote:
>
> >
> > On Sep 27, 2013, at 6:52 AM, Shiva Teja  wrote:
> >
> >> On Fri, Sep 27, 2013 at 9:28 AM, Ian Duffy  wrote:
> >>
> >>> I think so
> >>> implementation of AngularJS like the way Shiva did it for his GSoC
> >>> project would be good.
> >>>
> >>
> >> I'm trying to setup a demo for my project. This should give an idea
> about
> >> the code.
> >>
> >>
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/common/resources/virtualmachines.js
> >>
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.js
> >>
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.tpl.html
> >>
> >> Thanks,
> >> Shiva Teja
> >
> > Thanks Shiva, I was going to mention it.
> >
> > Shiva has worked on an angular.js app for a cloudstack frontend.
> > All the code has been contributed in tools/ngui
> >
> > This could easily be used with Brian new "CSS" and it would clean up all
> the javascript.
> >
> > -Sebastien
> >
>
>

Re: Can't bring up a new 4.2 environment

[Tracy Phillips]

I tend to agree. This is an Release Candidate, not an actual Release.

However, I am not so sure going forward that there should be a pure time
based release unless the their is a way to not plow through the release
dates. Perhaps having code freezes earlier in the cycle would help.


On Wed, Aug 28, 2013 at 9:14 AM, Wei ZHOU  wrote:

> Agree with Edison
>
> Can we revert this commit?
>
> 2013/8/28 Edison Su 
>
> > Sounds related to bug 21cb33a02ce2ff1e1b22af275068451a3ab6add5
> >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Tuesday, August 27, 2013 4:01 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Can't bring up a new 4.2 environment
> > >
> > > Hi,
> > >
> > > I've tried twice to create a new 4.2 environment (clean DB, starting
> > over from
> > > scratch), but both times I received the following exception (below).
> > >
> > > System VMs won't start.
> > >
> > > Any thoughts on this?
> > >
> > > Thanks!
> > > Mike
> > >
> > > INFO  [cloud.secstorage.PremiumSecondaryStorageManagerImpl]
> > > (secstorage-1:) No running secondary storage vms found in datacenter
> > id=1,
> > > starting one INFO  [storage.secondary.SecondaryStorageManagerImpl]
> > > (secstorage-1:) No stopped secondary storage vm is available, need to
> > > allocate a new secondary storage vm INFO
> > > [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:) No
> > > stopped console proxy is available, need to allocate a new console
> proxy
> > > INFO  [storage.volume.VolumeServiceImpl] (consoleproxy-1:) lock is
> > > acquired for VMTemplateStoragePool 1 WARN
> > > [storage.endpoint.DefaultEndPointSelector] (consoleproxy-1:) can't find
> > > endpoint
> > >
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationExcepti
> > > on:
> > > Column 'id' in where clause is ambiguous at
> > > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > > at
> > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructor
> > > AccessorImpl.java:39)
> > > at
> > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCon
> > > structorAccessorImpl.java:27)
> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> > > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> > > at com.mysql.jdbc.Util.getInstance(Util.java:386)
> > > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040)
> > > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4074)
> > > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4006)
> > > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2468)
> > > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2629)
> > > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2719)
> > > at
> > > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.ja
> > > va:2155)
> > > at
> > > com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java
> > > :2318)
> > > at
> > > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(D
> > > elegatingPreparedStatement.java:96)
> > > at
> > > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(D
> > > elegatingPreparedStatement.java:96)
> > > at
> > >
> org.apache.cloudstack.storage.endpoint.DefaultEndPointSelector.findEndPoi
> > > ntInScope(DefaultEndPointSelector.java:119)
> > > at
> > >
> org.apache.cloudstack.storage.endpoint.DefaultEndPointSelector.findEndPoi
> > > ntForImageMove(DefaultEndPointSelector.java:170)
> > > at
> > >
> org.apache.cloudstack.storage.endpoint.DefaultEndPointSelector.select(Def
> > > aultEndPointSelector.java:178)
> > > at
> > > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObj
> > > ect(AncientDataMotionStrategy.java:209)
> > > at
> > > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsy
> > > nc(AncientDataMotionStrategy.java:411)
> > > at
> > > org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(D
> > > ataMotionServiceImpl.java:55)
> > > at
> > > org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImage
> > > Async(VolumeServiceImpl.java:439)
> > > at
> > > org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFro
> > > mTemplateAsync(VolumeServiceImpl.java:543)
> > > at
> > > com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerI
> > > mpl.java:2526)
> > > at
> > > com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:
> > > 2582)
> > > at
> > > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineMa
> > > nagerImpl.java:888)
> > > at
> > > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerIm
> > > pl.java:578)
> > > at
> > > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerIm
> > > pl.java:571)
> > > at
> > > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProx
> > > yManagerImpl.java:556)
> > > at
> > > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsolePr

Re: [DOCS] feedback

[Tracy Phillips]

Kudos to you Sebastian!

I am glad to see it in Markdown.


On Tue, Sep 3, 2013 at 3:09 AM, Prasanna Santhanam  wrote:

> On Mon, Sep 02, 2013 at 08:53:37PM +0100, Ian Duffy wrote:
> > > By syntax highlighting do you mean marking 'code sections'? If so then
> > yes you can...
> >
> > http://daringfireball.net/**projects/markdown/syntax#**precode<
> http://daringfireball.net/projects/markdown/syntax#precode>
> >
> > No, syntax highlighting isn't part of the markdown spec, which is why I
> > asked. Its something github added to their own flavor of it.
> >
>
> There's a fork of github-flavoured-markdown done by
> https://github.com/chjj/marked
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: [DOCS] feedback

[Tracy Phillips]

On Tue, Sep 3, 2013 at 8:26 PM, Animesh Chaturvedi <
animesh.chaturv...@citrix.com> wrote:

>
> [Animesh>] Any change should be done post 4.2
>

I agree, this should be post 4.2.

Re: [DOCS] feedback

[Tracy Phillips]

I really like markdown, very readable in the state that it is in before it
is converted to whatever else. I also like reStructuredText.

Outputting to different formats is important I guess, however, I would say
that most real reading that is done is done in html.

With that said, I love beautiful documentation, one because I enjoy what I
am reading to look nice, if given the choice and two, from a marketing
perspective, our docs look like they came from Redhat in the early 2000's
(read old and outdated)

Take Ceph's install docs where they are using http://sphinx-doc.org to
create them.

http://ceph.com/docs/master/install/

Very nice looking, well laid out and useful. I don't think the concern
about about formats was as important as usability.

Tracy

Re: Password prompt like nine times

[Tracy Phillips]

On Wed, Sep 4, 2013 at 6:47 PM, Mike Tutkowski  wrote:

> Hi,
>
> I think this has been discussed a few times on the list before.
>
> When I start up the CSMS, I get prompted for my password about nine times.
>
> I thought updating the sudoers file would fix this, but it still happens.
>
> Any thoughts on this?
>
> Thanks!


Mike,

Do you mean the Cloudstack Management Server when you say CSMS?

What do you have in your  sudoers file?

Tracy

Re: Password prompt like nine times

[Tracy Phillips]

>From my /etc/sudoers (btw, use visudo to edit with)

cloud ALL =NOPASSWD : ALL

In my /etc/sudoers.d/cloudstack

cloud ALL =NOPASSWD : ALL

Seems redundant but that was what the install script put in.

T




On Thu, Sep 5, 2013 at 3:05 AM, sebgoa  wrote:

>
> On Sep 5, 2013, at 1:30 AM, Kelven Yang  wrote:
>
> > You need to make sudo-ers no-password required
> >
>
> bad idea, someone compromises your account and he is root.
>
> > Kelven
> >
> > On 9/4/13 4:10 PM, "Tracy Phillips"  wrote:
> >
> >> On Wed, Sep 4, 2013 at 6:47 PM, Mike Tutkowski
> >>  >>> wrote:
> >>
> >>> Hi,
> >>>
> >>> I think this has been discussed a few times on the list before.
> >>>
> >>> When I start up the CSMS, I get prompted for my password about nine
> >>> times.
> >>>
> >>> I thought updating the sudoers file would fix this, but it still
> >>> happens.
> >>>
> >>> Any thoughts on this?
> >>>
> >>> Thanks!
> >>
> >>
> >> Mike,
> >>
> >> Do you mean the Cloudstack Management Server when you say CSMS?
> >>
> >> What do you have in your  sudoers file?
> >>
> >> Tracy
> >
>
>

Re: Password prompt like nine times

[Tracy Phillips]

On Thu, Sep 5, 2013 at 3:05 AM, sebgoa  wrote:

>
> On Sep 5, 2013, at 1:30 AM, Kelven Yang  wrote:
>
> > You need to make sudo-ers no-password required
> >
>
> bad idea, someone compromises your account and he is root.
>
>
>
True. But they are on your box unauthorized, its just a matter of time
before it is cracked.

Re: documentation/wiki is a mess

[Tracy Phillips]

+1 to Marty.


On Fri, Sep 6, 2013 at 2:32 AM, Marty Sweet  wrote:

> My view is that when a feature is added the developer should give a short
> overview of how to use all of the items which have been added, a doc
> contributor can then write this up in a user friendly manner which is
> similar to the whole style of the rest of the documentation.
>
> Example description of documentation subtask on feature bug:
> -> Click Storage Tab
> -> Click on the volume you require
> -> Click the 'Resize Volume' icon, this may only appear if xyz
> -> Put in a value
>  -> If it's less then it will shrink, causing xyz
>  -> If it's more then it will expand, although the user must expand the
> filesystem in the OS (This then would create another document, as the
> process differs on win/linux)
>
> The doc contributor then has a useful set of notes for reference, so they
> don't have to spend lots of time trying to workout the in's and out's of a
> implemented feature.
>
> Marty
>
>
> On Thu, Sep 5, 2013 at 5:16 PM, Darren Shepherd <
> darren.s.sheph...@gmail.com
> > wrote:
>
> > On 09/05/2013 07:56 AM, David Nalley wrote:
> >
> >> On Thu, Sep 5, 2013 at 7:00 AM, Daan Hoogland 
> >> wrote:
> >>
> >>> -1 on no docs no submits.
> >>>
> >>> Docs are important to people that need a contribution they didn't
> >>> write themselves. The first ones are the ones to write docs where
> >>> missing. You contribute because you need code, not because you need
> >>> docs on it.
> >>>
> >>>
> >> If the developer who wrote the code for a feature can't tell me (or
> >> the rest of the userbase) how it works and how to use it, then I
> >> question exactly how useful the feature is.
> >>
> >>
> > Everyone should be on the hook to document in some fashion.  The doc
> > writer are usually just better at it.
> >
> > So as somebody who is more dev focused, I just don't know where to put
> > things.  I'm not about to touch the XML docs.  That seems like a doc
> team's
> > domain.
> >
> > So personally I'd like to see a bit more organization in the wiki and
> then
> > a clear cut definition of when stuff goes to the XML.  Additional
> proposals
> > and design specs don't count as documenting functionality. Those things
> are
> > just SDLC artifacts.  Frankly I think the current design template should
> > have the scope, impact, and QA notes and then link to another place in
> the
> > wiki with the design.  As the development is in progress the wiki page
> can
> > be marked with WIP.
> >
> > We should be careful about "no X, no commit" policies.  We don't want to
> > discourage contributions.  Documentation is useful and if somebody wants
> to
> > contribute then I think they would be inclined to put some documentation
> > such that it can be used by other people.  If we make the process easy
> and
> > obvious to do such, I think more documentation will exist.
> >
> > Darren
> >
> >
>

Re: www.cloudstack.org not resolving

[Tracy Phillips]

Matt,

Probably the contact listed in the whois

Domain ID:D150572512-LROR
Domain Name:CLOUDSTACK.ORG
Created On:07-Jan-2008 15:12:00 UTC
Last Updated On:12-Sep-2013 11:24:54 UTC
Expiration Date:07-Jan-2018 15:12:00 UTC
Sponsoring Registrar:Domain.com, LLC (R1915-LROR)
Status:TRANSFER PROHIBITED
Status:TRANSFERPERIOD
Registrant ID:tu7wMGD9wRRhInik
Registrant Name:Sheng Liang
Registrant Street1:PO Box 1644
Registrant Street2:
Registrant Street3:
Registrant City:Mountain View
Registrant State/Province:California
Registrant Postal Code:94042
Registrant Country:US
Registrant Phone:+1.6503945612
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:shengli...@gmail.com
Admin ID:tuwTxVMRjkR6lNM7
Admin Name:Sheng Liang
Admin Street1:PO Box 1644
Admin Street2:
Admin Street3:
Admin City:Mountain View
Admin State/Province:California
Admin Postal Code:94042
Admin Country:US
Admin Phone:+1.6503945612
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:shengli...@gmail.com
Tech ID:tuvYURg6jpeMiajb
Tech Name:Sheng Liang
Tech Street1:PO Box 1644
Tech Street2:
Tech Street3:
Tech City:Mountain View
Tech State/Province:California
Tech Postal Code:94042
Tech Country:US
Tech Phone:+1.6503945612
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:shengli...@gmail.com
Name Server:NS71.DOMAINCONTROL.COM
Name Server:NS72.DOMAINCONTROL.COM




On Fri, Sep 13, 2013 at 10:04 AM, Mathias Mullins <
mathias.mull...@citrix.com> wrote:

> David,
>
> Who do we need to reach out too? We are in day 3 of outage now?
>
> Matt
>
>
> On 9/11/13 9:58 PM, "David Nalley"  wrote:
>
> >The ASF has taken charge of the domains, but I suspect DNS is lagging a
> >bit.
> >
> >--David
> >
> >On Wed, Sep 11, 2013 at 9:03 PM, Mathias Mullins
> > wrote:
> >> Cloudstack.org isn't resolving.
> >>
> >> Cloudstack.apache.org is up and running.
> >>
> >> Do we need to get a hold of infrastructure?
> >>
> >> Matt Mullins
> >> Cloud Platforms Implementation Engineer
> >> Worldwide Cloud Services ­ Citrix System, Inc.
> >> +1 (407) 920-1107 ­ Office/Cell Phone
> >> matt.mull...@citrix.com
> >>
>
>

Re: 4.4 Feature Freeze

[Tracy Phillips]

+1 to Daan.

Tracy Phillips
Weberize, Inc.


On Wed, Feb 26, 2014 at 7:48 AM, Daan Hoogland wrote:

> -1 for postponing the feature freeze. It will amount to more features
> in the release. I'd rather shorten the cycle and do more releases then
> to pack more bugs in a single go.
>
> On Wed, Feb 26, 2014 at 1:13 PM, Guo Star  wrote:
> > +1
> >
> >
> > 2014-02-26 20:01 GMT+08:00 Abhinandan Prateek <
> abhinandan.prat...@citrix.com
> >>:
> >
> >> +1 for 4.4 feature freeze on 3/28.
> >>
> >> On 26/02/14 10:01 am, "Sateesh Chodapuneedi"
> >>  wrote:
> >>
> >> >> -Original Message-
> >> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> >> Sent: 26 February 2014 04:46
> >> >> To: dev@cloudstack.apache.org
> >> >> Subject: Re: 4.4 Feature Freeze
> >> >>
> >> >> I think this is a good idea, Animesh (to push out feature freeze to
> >> >>3/28).
> >> >
> >> >+1 to move 4.4 feature freeze date to 3/28.
> >> >
> >> >Regards,
> >> >Sateesh
> >> >
> >> >> I also agree we should discuss 4+ month development cycles again.
> >> >>
> >> >>
> >> >> On Tue, Feb 25, 2014 at 3:43 PM, Animesh Chaturvedi <
> >> >>animesh.chaturv...@citrix.com> wrote:
> >> >>
> >> >> > I will start a separate discussion on 4 month cycle or longer, but
> >> >> > wanted to call out one more important date.
> >> >> >
> >> >> > We have a last day for feature proposal date which is typically a
> >> >> > month before feature freeze date. If following 4.3 schedule + 4
> month
> >> >> > it would have been 2/14 and we are already past that. Since it was
> not
> >> >> > announced for
> >> >> > 4.4 release yet my suggestion would be to keep feature proposal
> open
> >> >> > for another week and push all  the dates out by 2 weeks to give
> folks
> >> >> > opportunity to finish up their features for new proposals that are
> yet
> >> >> > to come out.
> >> >> >
> >> >> > To be clear that would mean pushing out feature freeze to 3/28 from
> >> >> > 3/14 and all the other dates likewise.
> >> >> >
> >> >> >
> >> >> > Thanks
> >> >> > Animesh
> >> >> >
> >> >> > > -Original Message-
> >> >> > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> >> >> > > Sent: Tuesday, February 25, 2014 1:05 PM
> >> >> > > To: dev@cloudstack.apache.org
> >> >> > > Subject: RE: 4.4 Feature Freeze
> >> >> > >
> >> >> > > With the experience of 4.2 and 4.3 I think we should discuss if
> we
> >> >> > > can realistically achieve 4 month cycle our RCs take 2 months. I
> was
> >> >> > > going to open up the discussion after 4.3 is shipped though.
> >> >> > >
> >> >> > > > -Original Message-
> >> >> > > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> >> >> > > > Trippaers
> >> >> > > > Sent: Tuesday, February 25, 2014 8:50 AM
> >> >> > > > To: 
> >> >> > > > Subject: Re: 4.4 Feature Freeze
> >> >> > > >
> >> >> > > > Hey,
> >> >> > > >
> >> >> > > > If we stick to our 4 month release schedule the feature freeze
> is
> >> >> > > > four months after the feature freeze of 4.3. The feature
> freeze of
> >> >> > > > 4.3 was
> >> >> > 8 Nov
> >> >> > > 2013.
> >> >> > > >
> >> >> > > > So the proposed release schedule for 4.4 would look like this
> >> >> > > > (dates slightly modified to take efficiency and RM's personal
> life
> >> >> > > > into
> >> >> > account ;-) ):
> >> >> > > >
> >> >> > > > Feature Freeze: March 14, 2014
> >> >> > > > Testing/Bug Fixes:  March 15, 2014 till April
>

Re: Cloudstack support for Xen (on Ubuntu)

[Tracy Phillips]

Rafael,

Once you put XCP on, do you gain features that belong to Xenserver or is it
limited in someway?

The only reason I am not using Xenserver is that I have to manage it
differently than my other hosts.

Tracy

Tracy Phillips
Weberize, Inc.


On Fri, Apr 11, 2014 at 8:26 AM, Rafael Weingartner <
rafaelweingart...@gmail.com> wrote:

> True that, just xen hypervisor is not yet supported. However, if you also
> install the XCP over xen hypervisor it will work.
>
>
> On Fri, Apr 11, 2014 at 7:05 AM, Nux!  wrote:
>
> > On 11.04.2014 10:10, Pradeep Cloudstack wrote:
> >
> >> I have a server running Ubuntu 13.04. I am planning to install Xen
> >> Hypervisor on that
> >> (https://help.ubuntu.com/community/XenProposed#Xen_and_XAPI)
> >>
> >> Can I then have it managed (as a host) by Cloudstack 4.2 ?
> >>
> >
> > Not yet, there are plans to make it happen, but Xen is not yet supported.
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: automated apache cloudstack installation with cldstk-deploy

[Tracy Phillips]

Very, very nice. I watched your videos a month or so ago.

Good work!

Tracy Phillips
Weberize, Inc.


On Mon, Apr 21, 2014 at 2:23 PM, Antone Heyward
wrote:

> I wanted to get some feedback on this as I have added it github. Hopefully
> it helps some get into using apache cloudstack and make the deployment
> process easier than it already it.
>
> https://github.com/thehyperadvisor/cldstk-deploy
>
> To keep it small in size i have not included the RPMS but there is a way
> to download them. It’s not that pretty but works. I can add the RPMS if
> people don’t care about the size.
>
> Antone Heyward
> @thehyperadvisor
> http://thehyperadvisor.com
>
>

Re: Support pure Xen as a hypervisor follow-up

[Tracy Phillips]

Thanks for the update. This is good news.


On Wed, May 14, 2014 at 4:53 AM, sebgoa  wrote:

>
> On Apr 9, 2014, at 2:37 PM, Dave Scott  wrote:
>
> > Hi,
> >
> > Following up from Tim's "Support pure Xen as a hypervisor" proposal last
> month[1] I'd like to start working on this and maybe even make a little bit
> of progress while I'm at CCC in Denver.
> >
> > Helpfully James Bulpin managed to get CS + libvirt + xen to start an
> instance in a simple configuration. Although the patches[2] are not
> intended to be production-ready :) they help highlight some of the areas we
> need to change.
>
> Dave, just to let you know that Tim has done some important "refactoring"
> to split up XenServer hypervisor in CS between Xen and XenServer. That way
> we could keep using xapi for XS but start moving to libvirt for Xen.
>
> Tim worked in the xen2server branch (don't ask about the name, I messed it
> up…:) ).
>
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/xen2server
>
> Would be nice to see some of the libvirt stuff in that branch to handle a
> new driver for Xen.
>
> Since the two hypervisors will be split up, we could still drop in some
> early libvirt patches to handle Xen and put this in 4.5 as a wip.
>
> -Sebastien
>
> >
> > Some of the areas are:
> >
> > 1. hypervisor detection
> >
> > Where we currently look for KVM specifically ("lsmod | grep kvm") we
> could switch to either detecting any Linux hypervisor (by reading
> /sys/hypervisor/type) and assuming if a hypervisor is present then we can
> use libvirt on it (is this a fair assumption?) Or we could white-list “kvm”
> or “xen”. Or we could query libvirt directly (perhaps via 'virsh
> capabilities'?)
> >
> > 2. fiddling with the domain.xml
> >
> > When starting a domain via libvirt the XML configuration has
> hypervisor-specific stuff in it. Some of this is easy to change like:
> >
> >  
> >
> > obviously becomes
> >
> >  
> >
> > and
> >
> >  /usr/libexec/qemu-kvm
> >
> > should probably be
> >
> >  /some/other/path/qemu-dm
> >
> > Some is a bit more invasive (to the VM) such as the virtual hardware
> type should be switched from "virtio" to "xen" (and the block device in
> Linux will change from /dev/vd* to /dev/xvd*) and we'll have to either
> implement or work around the lack of
> >
> >   ...
> >
> > -- I presume this is a control channel into the system VM. Perhaps we
> could implement this in libvirt/libxl using vchan?
> >
> > 3. system VMs?
> >
> > It would be very convenient if the system VM images could work on both
> xen and KVM. This is probably doable as long as we don't bake in virtual
> hardware specific information (such as /dev/vda) in the image. We could use
> the qcow2 format in both cases. What do you think?
> >
> > … and I’m sure there’s more.
> >
> > Anyway, feedback would be welcome. If anyone else in Denver wants to
> chat, then come grab me later!
> >
> > Cheers,
> > Dave Scott
> >
> > [1]
> http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e
> >
> > [2]
> https://github.com/jamesbulpin/cloudstack/commits/jamesb_xen_exploratory
>
>

Re: [PROPOSAL]remove 4.4-forward

[Tracy Phillips]

git-flow with master always golden would be a good method.

Right now the development model just isn't working.

fwiw, I am not a developer, just a tinkerer with git and some bash and a
lurker :)


On Thu, Jul 24, 2014 at 10:47 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Yep...what Wei said. :)
>
>
> On Thu, Jul 24, 2014 at 8:20 AM, Wei ZHOU  wrote:
>
> > yes. I think 4.4-forward can be merged into 4.4 branch after 4.4.0
> release,
> > then delete it.
> >
> >
> > 2014-07-24 15:08 GMT+02:00 Daan Hoogland :
> >
> > > As we will probably need a 4.4.1 I will spend some tine cherry picking
> > > through 4.4-forward to get any changes we will need from there (plus
> > > test cases)
> > >
> > > I will remove 4.4-forward after I am done.
> > >
> > > As per the git flow way of working any fixes on 4.4 will be done on a
> > > per fix branch of off 4.4.
> > >
> > > please speak up if you have objections!
> > >
> > > --
> > > Daan
> > >
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [DISCUSS][PROPOSAL] git workflow

[Tracy Phillips]

The best thread I have read in awhile...

Good read http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html



On Thu, Jul 24, 2014 at 8:06 AM, Daan Hoogland 
wrote:

> On Thu, Jul 24, 2014 at 1:43 PM, Leo Simons 
> wrote:
> > lsimons
>
>
> has access
>
> --
> Daan
>

Re: [DISCUSS][PROPOSAL] git workflow

[Tracy Phillips]

Yes, that is what he is saying. Its really the git way.

Starting a branch with the ticket-id and short description works best.

I think this is what you are looking for
https://wiki.diasporafoundation.org/Git_workflow


On Thu, Jul 24, 2014 at 12:29 PM, Daan Hoogland 
wrote:

> On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips 
> wrote:
> > Good read
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
>
> he agrees with our thread that every work sould start with creating a
> branch, doesn't he. I think we need to say that a lot of times more.
> Start a new branch when picking up a ticket. Start a new branch when
> experimenting on a new feature. Start a new branch when bored.
>
> --
> Daan
>

Re: [DISCUSS][PROPOSAL] git workflow

[Tracy Phillips]

If you are on Ubuntu (and who isn't these days... right?), you can install
git-flow easily (git-completion is nice as well)

aptitude install git-flow git-completion

and git-flow command completion is nice

https://github.com/bobthecow/git-flow-completion


On Thu, Jul 24, 2014 at 12:36 PM, Stephen Turner 
wrote:

> I agree, every new ticket should be on a new branch. If you have two
> changesets you might ever want to merge separately, put them on separate
> branches.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 24 July 2014 17:30
> To: dev
> Subject: Re: [DISCUSS][PROPOSAL] git workflow
>
> On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips 
> wrote:
> > Good read
> > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>
>
> he agrees with our thread that every work sould start with creating a
> branch, doesn't he. I think we need to say that a lot of times more.
> Start a new branch when picking up a ticket. Start a new branch when
> experimenting on a new feature. Start a new branch when bored.
>
> --
> Daan
>

Re: [VOTE] git workflow

[Tracy Phillips]

"Once you merge release branch it on master/stable branch, you don’t lose
commit if you delete it. It’s like removing a feature branch once it’s
merged on master/target branch."

Correct. At t his point your "release" is in master. If you need to bug
fix, you checkout that tag from master.

Also, as far as CI is concerned it should be ran on the feature branch and
once the feature doesn't break anything, it should only then be merged into
develop.

http://twasink.net/2011/09/20/git-feature-branches-and-jenkins-or-how-i-learned-to-stop-worrying-about-broken-builds/

http://juristr.com/blog/2014/01/git-flow-jenkins-gitlab/

The idea is that you are not pushing a broken feature into a branch.




On Wed, Aug 6, 2014 at 10:55 AM, Rohit Yadav 
wrote:

> Hi David,
>
> On 06-Aug-2014, at 4:10 pm, David Nalley  wrote:
>
> > On Wed, Aug 6, 2014 at 9:41 AM, Rohit Yadav 
> wrote:
> >>
> >> Hi,
> >>
> >> Comments in-line;
> >>
> >> On 05-Aug-2014, at 10:45 pm, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
> >>
> >>> Rayees,
> >>>
> >>> I think you have the same misunderstanding as a lot of other folks
> >>> (including myself) had in the beginning - seeing develop branch as a
> trunk
> >>> branch that gets merged into master on a regular basis after the BVT/CI
> >>> tests pass. So the master branch reflects the develop branch minus
> changes
> >>> that didn¹t pass the tests and weren¹t merged into master -  lets
> refer to
> >>> it as implementation #1
> >>>
> >>> That¹s not what git workflow/this thread proposes. In git workflow
> master
> >>> branch reflects the latest stable release instead. So for example, we
> >>> released 4.4, and that what you would see the master to be as we merge
> the
> >>> *release branch to master, not the *develop to master. And develop
> branch
> >>> becomes the trunk branch where all the new fixes go to. I would look at
> >>> the master as at the stable branch, where you can track the history for
> >>> all the major releases as for each of them the master branch has
> >>> corresponding tags - lets call it implementation #2
> >>>
> >>> I still don¹t see many advantages in implementation #2 - making the
> master
> >>> build stable by simply making it reflect the latest release branch.
> >>> Because you:
> >>>
> >>> * never cut the release from master branch
> >>
> >> We’ve a stable branch that gets rolling/continuous releases which is
> good.
> >>
> >>> * if you are the customer, and need the latest stable code, you
> download
> >>> the official RPM
> >>> * if you are a developer, you always want to download the latest code,
> and
> >>> that comes from *develop branch
> >>> * if you want to look at the latest stable release, you look at the
> >>> release branch as per CS git workflow implementation we never remove
> the
> >>> release branches (they are needed for maintenance releases)
> >>
> >> IMO We “should" remove the release branches when done. Instead there is
> a support workflow with git-flow (see support
> http://yakiloo.com/getting-started-git-flow/) and also in the tooling
> (git flow support etc. though experimental).
> >>
> >
> > You aren't aiding your case by suggesting that we use experimental
> tooling.
>
> No, if you know you git-chops you can do it by hand, I mean to say -- the
> tool is under development for support stuff.
>
> > So removing a release branch worries me. Will there be loss of commit
> > information?
>
> Once you merge release branch it on master/stable branch, you don’t lose
> commit if you delete it. It’s like removing a feature branch once it’s
> merged on master/target branch.
>
> > I know that heretofore, each release has contained
> > commits that aren't in master. Whether that's good, bad or
> > indifferent, that is the fact, and I personally think that is unlikely
> > to change in the short term.
>
> Once merged on master/stable branch, one can checkout the release version
> tag to get the same branch.
>
> > Or put more succinctly, what does removing a release branch buy us?
>
> Less cluttered branches. You’ve the release branch merged on master and
> tags why do you want to keep branches? You can always checkout the tags to
> get the release branch.
>
> > So I like most of the things about this proposal - I like doing all
> > the work in the feature/bug branches. But the rest of this workflow
> > befuddles me a bit. I don't think that the workflow will result in a
> > stable 'master' or that we are really doing anything significant by
> > pushing what is master now to become the develop branch.
>
> You’re right. It’s just a convention of doing things, like we’ve traffic
> rules.
> They won’t stop you to break anything if you don’t follow.
>
> > In the page
> > describing this, pushes to the develop branch seem welcome 'when a
> > feature is completed' - so develop will be as messy as master is
> > today, frequently broken, and no improvement in quality. This attempts
> > to solve a quality problem with workflow, and I don't think it can

Re: [VOTE] git workflow

[Tracy Phillips]

Alena,

Check this out and see if it would resolve your concern regarding
maintaining multiple releases

http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches

git-flow uses support branches to support releases that are not on master.





On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>
>
> On 8/6/14, 3:18 PM, "Sebastien Goasguen"  wrote:
>
> >[top posting, apologies in advance]
> >
> >I am on vacation, so I will go straight to it :)
> >
> >This all discussion is not about gitflow specifically, it is about
> >modifying our git workflow and our commit practices to something more
> >standard that can:
> >
> >- ultimately help improve quality (in itself it won't but it can help lay
> >a foundation)
> >- provide a stable master (it keeps breaking, it has regressions, it
> >moves really fast etc..)
> >- help cut releases
> >
> >Any committer has write privileges and can do whatever it wants to the
> >repos, so we need to get a nice big consensus on what problems we are
> >trying to solve, and how best to get there. So let's not make this a
> >debate of yeah or neah gitflow.
> >
> >A better CI is coming but it's not yet there and we have no ETA. Even
> >with a CI infra in place, we will need commit discipline to improve
> >quality (covertity, unitests, simulator tests). Changing our git commit
> >practices has no cost (just emails and self discipline), so can we agree
> >to do that first ?
> >
> >Here are couple high level things that I have in mind ( and I confess I
> >have not read the entire threads on this yet and ti ma conflict with
> >gitflow).
> >
> >-Master: what goes in master is only something that has been put into a
> >release (aside from the maintenance releases fixes maybe...). Master is
> >the base for any release branch (until we get to 4.5, master will still
> >see some high churn to stabilize it, after 4.5 release branch is cut we
> >should enter into a stable master mode).
>
>
> Sebastian, we can’t adopt this particular high level thing - when master
> reflects the latest stable release with the tags for all previous releases
> - because support maintenance releases for multiple CS versions in
> parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be
> released. And there is no way to merge them back to master w/o breaking
> the branch history.
>
> The model when master reflects the latest released branch, can be used for
> the systems with rolling upgrades only, no maintenance releases for
> previous versions of the software.
>
> To get more details, please read the latest email exchange (today’s) on
> git workflow between me/Rohit and Dave Nalley.
>
>
>
> >
> >-Release: from the time a release branch is cut, features are only merged
> >by RM. hot fixes are only merged by RM. the RM is responsible for the
> >entire release process. Since he defines the scope and is the primary
> >person responsible to check BVT for the release branch he should be able
> >to release on-time. Major release gets merged back into master.
> >
> >-Devs: folks working on features and fixes are responsible to merge into
> >the develop branch and call the RM for a merge into a release branch
> >(this may vary with gitflow, where release branch is cut from develop)
> >
> >Once we have CI, it should run on every branch.
> >
> >-sebastien
> >
> >
> >On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk
> > wrote:
> >
> >> Edison, thank you for raising the concern about the BVT/CI. Somebody
> >> mentioned earlier that we should separate git workflow implementation
> >>from
> >> the CI effort, but I do think we have to do in in conjunction. Otherwise
> >> what is the point in introducing staging/develop branch? If there is no
> >> daily automation run verifying all the code merged from hotFixes/feature
> >> branches (and possibly reverting wrong checkins), we can as well merge
> >>the
> >> code directly to master.
> >>
> >> -Alena.
> >>
> >> On 8/6/14, 2:30 PM, "Edison Su"  wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>  Sent: Wednesday, August 06, 2014 12:59 PM
>  To: dev@cloudstack.apache.org
>  Subject: Re: [VOTE] git workflow
> 
> 
> 
>  On 8/6/14, 12:52 PM, "Erik Weber"  wrote:
> 
> > On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> >> Agree with you, Rohit. The changes to the git model we use, are
> >> needed  indeed. But we should address only the problems that CS
> >>faces,
> >> and the  main problem - quality control. The proposal should be
> >> limited just to the  changes that are really needed for the CS, and
> >> that will work with the  current CS model (minor maintenance
> >>releases
> >> support is a part of it)
> >>
> >>
> >
> > Theoretically you don't really have to change anything 

Re: [VOTE] git workflow

[Tracy Phillips]

Any process is better than what is being used right now.

git-flow is just a proven process that is working for folks who use it.
That is a fact.

git-flow somewhat enforces a process, especially if you use the git-flow
plugin:

git flow feature start 2345-eye-candy

git flow feature publish etc, etc, etc.

It took me a bit to wrap my head around the concepts but when I did, it
*really* started to make sense. It does seem like a like for forking and
rebasing but that is what git is good at.

git-flow keeps things nice and tidy.