Hello, guys. What kind of hardware do you need actually to improve? I host own DC and probably could give you our spare hardware connected to dedicated managed switch. I can not guarantee the resources will be granted and when the customer need it I'll take it, but we usually have 5-10 spare servers with Xeon E5620, E3-1230.
Best wishes, Ivan. 2017-07-04 19:57 GMT+07:00 Syed Ahmed <sah...@cloudops.com>: > As Paul said, in theory, running KVM as your base hypervisor in Trillain > shoud be possible. We have done nested KVM in the past with XenServer and > KVM as the nested hypervisors and with KVM being the base hypervisor. I am > not completely sure about how VMWare handles being in a nested environment. > Having said that, I believe if we get KVM and XenServer support with KVM as > being the base hypervisor, we will have a lot more adaptability for > Trillian. I will work with Paul and team on this. > > As a side note, I have been working on getting to run integration testing > from a docker container. We need this because we require our tests to be > done on real hardware for cloud.ca. I really like the container approach > as > it bundles all dependencies required by Marvin into a single container > which can be launched from any machine which has docker. This would hugely > benefit running it via Jenkins for example. I will open-source it as soon > as I am happy with it. > > > > On Mon, Jul 3, 2017 at 2:34 PM, Will Stevens <wstev...@cloudops.com> > wrote: > > > I have added Syed to this. He has done some initial review to get a port > > to KVM working, but I am not sure how far he got yet. > > > > *Will Stevens* > > CTO > > > > <https://goo.gl/NYZ8KK> > > > > On Mon, Jul 3, 2017 at 2:26 PM, Paul Angus <paul.an...@shapeblue.com> > > wrote: > > > >> I will take an action to look at trillian on KVM. There's nothing > >> explicit or implicit in trillian itself that it requires vmware as long > as > >> we can trunk the guest VLANs and virtualise the hypervisors. > >> > >> ________________________________ > >> From: Will Stevens <wstev...@cloudops.com> > >> Sent: 3 Jul 2017 2:06 am > >> To: dev@cloudstack.apache.org > >> Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof > >> > >> Sorry, I have been keeping up with these threads while on vacation at a > >> campsite. :) Finally back to a computer. > >> > >> Yes, ideally we would have more people actually committing code and > >> validating the PRs are ready for merge. Right now, we have VERY limited > >> CI > >> setups, so we are bottlenecked on the ability to actually test the PRs > in > >> a > >> timely fashion. This leads to PRs sitting for a week at a time in some > >> 'phase' of the process. This means that the developers get pushed off > to > >> other items to pay the bills and it then causes a lag everywhere. > Because > >> of this, the RM has basically had to fill the role of making sure > >> everything is moving and understanding and unblocking the different PRs > as > >> they move through the review/test/commit phases. > >> > >> Yes, we need more reviewers. That is very true. > >> > >> Also true, is that we need more CI environments. I would love to see > >> Trillian be able to be run on KVM on a developers laptop to at least > test > >> the core components. We could then start to standardize the dev/test > >> cycle > >> for developers so we can start focusing on a 'minimum support feature > >> set'. We could also hopefully leverage the developers setups to run CI > >> overnight if they choose to participate (or at least their own PRs). If > >> we > >> could standardize well enough to push the workload to the edge, I think > we > >> would end up with more active rigs in the game. > >> > >> I personally feel that if we can put the CI on rails and standardize our > >> dev environment, a lot of our 'we need an full time RM' problems go > away. > >> However, I do think we will need a full time RM for at least a year to > be > >> able to shepherd that into existence though. > >> > >> *Will Stevens* > >> CTO > >> > >> <https://goo.gl/NYZ8KK> > >> > >> > >> paul.an...@shapeblue.com > >> www.shapeblue.com > >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >> @shapeblue > >> > >> > >> > >> On Sun, Jul 2, 2017 at 8:06 PM, Syed Ahmed <sah...@cloudops.com> wrote: > >> > >> > Agree with Ron about this being a role of the commiter but in what I > >> have > >> > seen, it is mostly the RM who has to run around and ask for > updates/make > >> > sure fixes are done. > >> > > >> > Part of the problem also is that there is a lack of reviewers. We've > had > >> > some issues recently [1] which were code which was committed was not > >> > properly reviewed and later lead to problems. Having a RM and some > core > >> > reviewers is essential to maintain quality and sanity of the release. > >> > > >> > I also agree with testing on a known setup with known parameters. The > >> > community can pool resources for hardware and Trillian can be used as > >> the > >> > CI framework. There was supposedly hadware donated by Citrix to the > ASF. > >> > Anyone know what happened to that? > >> > > >> > [1] https://github.com/apache/cloudstack/pull/1834 > >> > > >> > > >> > On Sun, Jul 2, 2017 at 9:55 AM, Ron Wheeler > <rwheeler@artifact-software. > >> > com> > >> > wrote: > >> > > >> > > I think you are describing the roles of all of the committers > >> > > > >> > > Is it normal at Apache for the RM to be doing all of this stuff? > >> > > > >> > > I would expect that the RM has a QC role in these activities but > >> others > >> > > are doing the work. > >> > > > >> > > Ron > >> > > > >> > > > >> > > On 01/07/2017 7:18 PM, Will Stevens wrote: > >> > > > >> > >> Oh, and if a system VM is touched, then you have to add in a new > >> system > >> > VM > >> > >> build and install into the CI setup prior to testing... > >> > >> > >> > >> On Jul 1, 2017 6:41 PM, wrote: > >> > >> > >> > >> Which is part of the reason the RM job is hard and time consuming. > >> > >> - checking the PRs have the appropriate tests. > >> > >> - updating the CI to include the new tests. > >> > >> - run and report CI for the PR (with very limited CI infra > community > >> > >> wide). > >> > >> - chase PR authors to get their PRs to a point where you are happy > >> they > >> > >> are > >> > >> not breaking master > >> > >> - rinse repeat for 200+ PRs... > >> > >> > >> > >> On Jul 1, 2017 6:34 PM, "Will Stevens" <williamstev...@gmail.com> > >> > wrote: > >> > >> > >> > >> Yes, we can totally reject PRs until we are happy with the > associated > >> > >> tests. > >> > >> > >> > >> On Jul 1, 2017 5:48 PM, "Alex Hitchins" <a...@alexhitchins.com> > >> wrote: > >> > >> > >> > >> Out of interest, are there any guidelines/rules in place to reject > >> PR's > >> > >>> without unit tests? > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> Alexander Hitchins > >> > >>> ------------------------ > >> > >>> E: a...@alexhitchins.com > >> > >>> W: alexhitchins.com > >> > >>> M: 07788 423 969 > >> > >>> T: 01892 523 587 > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: Paul Angus [mailto:paul.an...@shapeblue.com] > >> > >>> Sent: 30 June 2017 21:58 > >> > >>> To: dev@cloudstack.apache.org > >> > >>> Subject: RE: [DISCUSS] - Releases, Project Management & Funding > >> Thereof > >> > >>> > >> > >>> Taken from a talk on CloudStack testing [1]... > >> > >>> > >> > >>> There are Many, many, MANY permutations of a CloudStack > deployment…. > >> > >>> • Basic / Advanced > >> > >>> • Local / shared / mixed storage > >> > >>> • More than 8 common hypervisor types/versions • 4 or 5 Management > >> > server > >> > >>> OS possibilities • That’s 144 combinations only looking the > basics. > >> > >>> > >> > >>> [1] https://www.slideshare.net/ShapeBlue/cloudstack-eu-user-grou > >> > >>> p-trillian?qid=74ff2be0-664c-4bca-a3dc-f30d880ca088&v=&b=& > >> > from_search=1 > >> > >>> > >> > >>> Trillian [2], can create any of those, and multiple at the same > >> time, > >> > but > >> > >>> the amount of hardware required to do that means that we have to > >> pick > >> > our > >> > >>> battles. Running the blueorangutan bot command '@blueorangutan > >> matrix' > >> > >>> in a > >> > >>> PR will run the smoke test suite against a PR using 3 > environments, > >> one > >> > >>> each of KVM, XenServer and vSphere and takes around 8 hours. > >> > >>> > >> > >>> But that is only looking for major regressions. A full component > >> test > >> > >>> run > >> > >>> takes around 5 days to run and is riddled with bugs in the tests. > >> > >>> > >> > >>> Ultimately these are still of limited scope, few people are as > >> diligent > >> > >>> as > >> > >>> say Mike T in creating practical marvin tests for their code / > >> > features. > >> > >>> > >> > >>> [2] https://github.com/shapeblue/Trillian > >> > >>> > >> > >>> Therefore we need hardware to run tests on, but more importantly > we > >> > need > >> > >>> the tests to exist and work in the first place. Then we can > really > >> do > >> > >>> something. > >> > >>> > >> > >>> > >> > >>> > >> > >>> paul.an...@shapeblue.com > >> > >>> www.shapeblue.com<http://www.shapeblue.com> > >> > >>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: Alex Hitchins [mailto:a...@alexhitchins.com] > >> > >>> Sent: 30 June 2017 21:34 > >> > >>> To: dev@cloudstack.apache.org; dev@cloudstack.apache.org > >> > >>> Subject: RE: [DISCUSS] - Releases, Project Management & Funding > >> Thereof > >> > >>> > >> > >>> Consultation with users is something that should definite be done. > >> > Canvas > >> > >>> as many as possible. > >> > >>> > >> > >>> I agree that most people will be running test environments before > >> full > >> > >>> rollout of any technology, I guess see it a little from a CTO > eyes - > >> > why > >> > >>> shortlist a technology that doesn't even endorse its own releases? > >> > >>> > >> > >>> Hopefully we will get some more replies to this thread from other > >> > >>> CloudStack enthusiasts to help shape this conversation. > >> > >>> > >> > >>> I'm setting up a new development environment now to get my hands > >> mildly > >> > >>> soiled. Going the Windows route again. Fancy a challenge for the > >> > weekend. > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> Alexander Hitchins > >> > >>> ------------------------ > >> > >>> E: a...@alexhitchins.com > >> > >>> W: alexhitchins.com > >> > >>> M: 07788 423 969 > >> > >>> T: 01892 523 587 > >> > >>> > >> > >>> -----Original Message----- > >> > >>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > >> > >>> Sent: 30 June 2017 21:08 > >> > >>> To: dev@cloudstack.apache.org > >> > >>> Subject: Re: [DISCUSS] - Releases, Project Management & Funding > >> Thereof > >> > >>> > >> > >>> > >> > >>> On 30/06/2017 3:28 PM, Alex Hitchins wrote: > >> > >>> > >> > >>>> We can't validate all scenarios no, hence suggesting several > common > >> > >>>> > >> > >>> setups as a reasonable baseline. I like the idea of users posting > >> their > >> > >>> hardware and versions as a community endeavour. > >> > >>> > >> > >>>> I strongly feel there should be an established, physical setup > that > >> > the > >> > >>>> > >> > >>> release team have access to in order to validate a release. > >> > >>> > >> > >>> This is perhaps something that should be requested from the user > >> > >>> community. > >> > >>> I would expect that anyone running Cloudstack in production on a > >> major > >> > >>> site would have a test setup and might be very happy to have the > dev > >> > team > >> > >>> test on their setup. > >> > >>> This would save them a lot of resources at the expense of a bit of > >> time > >> > >>> on > >> > >>> their test environment. > >> > >>> > >> > >>> If this was some random cat meme generator on GitHub, I'd accept > the > >> > >>>> > >> > >>> risk in running an untested version. For something I'd be running > my > >> > >>> business on however I'd expect there being some weight behind the > >> > >>> release. > >> > >>> > >> > >>>> Perhaps I have unrealistic expectations! > >> > >>>> > >> > >>> Not at all. > >> > >>> Your expectations might be the key to making a pitch to the user > >> > >>> community > >> > >>> for some help from people and organizations that are not > interested > >> in > >> > >>> writing code but have a major interest in testing. > >> > >>> In addition to access to test equipment, this might actually get > new > >> > >>> people on the team with the right skills required to extend the > test > >> > >>> scripts and test procedure documentation. > >> > >>> > >> > >>> Does anyone have a list of the configuration specifications that > are > >> > >>> required to test a new release? > >> > >>> > >> > >>> Would it help to approach major users of Cloudstack with a direct > >> > request > >> > >>> for use of their test equipment and QA staff in return for early > >> access > >> > >>> to > >> > >>> new releases and testing on their hardware? > >> > >>> > >> > >>> Ron > >> > >>> > >> > >>> Alexander Hitchins > >> > >>>> ------------------------ > >> > >>>> E: a...@alexhitchins.com > >> > >>>> W: alexhitchins.com > >> > >>>> M: 07788 423 969 > >> > >>>> T: 01892 523 587 > >> > >>>> > >> > >>>> -----Original Message----- > >> > >>>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > >> > >>>> Sent: 30 June 2017 20:13 > >> > >>>> To: dev@cloudstack.apache.org > >> > >>>> Subject: Re: [DISCUSS] - Releases, Project Management & Funding > >> > >>>> Thereof > >> > >>>> > >> > >>>> On 30/06/2017 2:19 PM, Alex Hitchins wrote: > >> > >>>> > >> > >>>>> Releasing against a defined reference rig would be a very good > >> idea, > >> > >>>>> > >> > >>>> especially if we could replicate several. > >> > >>> > >> > >>>> It concerns me slightly that we are building a platform we want > to > >> > >>>>> > >> > >>>> promote people to deploy in enterprise environments with the > caveat > >> > >>> 'run at > >> > >>> your own risk'. > >> > >>> > >> > >>>> There is no choice as near as I can tell. > >> > >>>> It seems that there are too many combinations of hardware, > network > >> > >>>> > >> > >>> configurations and OSs to guarantee that a release will work on > all > >> of > >> > >>> them > >> > >>> and still get a release delivered. > >> > >>> > >> > >>>> As Will pointed out, the Release Team does not have access to > every > >> > >>>> > >> > >>> combination where previous releases are in production use, to test > >> the > >> > >>> new > >> > >>> release candidate. > >> > >>> > >> > >>>> Currently it may be not very explicit about what are the fully > >> tested > >> > >>>> > >> > >>> configurations and from what Will said, I gather that there is no > >> > policy > >> > >>> saying what the minimum test set is to declare a release ready to > >> go. > >> > >>> > >> > >>>> There is no reason preventing a release being tested after > release > >> by > >> > an > >> > >>>> > >> > >>> end-user or a developer and adding to the release documentation > >> > something > >> > >>> to the effect that "Users have reported that this release has been > >> put > >> > >>> into > >> > >>> production on XYZ configuration with no modifications." > >> > >>> > >> > >>>> This at least gets the release out the door for the 95% of the > >> users > >> > >>>> > >> > >>> that do not have an XYZ rather than waiting for someone with an > XYZ > >> to > >> > >>> find > >> > >>> time to test it. > >> > >>> > >> > >>>> It may also encourage companies using or selling XYZs to put up > >> some > >> > >>>> > >> > >>> resources (hardware and people) dedicated to testing so that they > >> get > >> > >>> into > >> > >>> the initial release. > >> > >>> > >> > >>>> Ron > >> > >>>> > >> > >>>> We need to up our game. > >> > >>>>> > >> > >>>>> 'We' he says, after two years MIA! > >> > >>>>> > >> > >>>>> On 30 Jun 2017, at 18:41, Ron Wheeler > <rwheeler@artifact-software. > >> > com> > >> > >>>>>> > >> > >>>>> wrote: > >> > >>> > >> > >>>> How much time is there between a feature freeze and the RC being > >> cut.? > >> > >>>>>> Do people know far enough in advance that their feature is in > or > >> out > >> > >>>>>> > >> > >>>>> and if in must be ready to go to a RC release by such and such a > >> > date? > >> > >>> > >> > >>>> Is the use case testing well defined - hardware, configurations, > >> etc. > >> > >>>>>> Can you put out a release that says: "This release has been > >> tested > >> > on > >> > >>>>>> > >> > >>>>> these configurations (A, B ,C) but the following > >> configurations/use > >> > >>> cases > >> > >>> are not yet fully tested and other configuration may be used at > your > >> > own > >> > >>> risk after your own internal tests have been run successfully." > >> > >>> > >> > >>>> Is there any concept that "Cloudstack is verified to run on the > >> > >>>>>> > >> > >>>>> following configurations and should also run on these > >> configurations > >> > >>> but > >> > >>> has not been tested fully. It may run on these configurations but > is > >> > not > >> > >>> tested during the release cycle." > >> > >>> > >> > >>>> Ron > >> > >>>>>> > >> > >>>>>> On 30/06/2017 1:14 PM, Will Stevens wrote: > >> > >>>>>>> Have not looked at Release Tsar, but worth checking out. > >> > >>>>>>> > >> > >>>>>>> In general, the biggest problem we have with releasing on a > >> > >>>>>>> schedule is the lack of a CI setup which covers the entire > >> > >>>>>>> software. Or at least a 'supported' set of features. This > means > >> > >>>>>>> that the release is always bound to a bunch of volunteers > >> getting > >> > >>>>>>> around to testing their use case. Solidfire and Nuage are > pretty > >> > good > >> > >>>>>>> > >> > >>>>>> about getting some CI run on some pieces. > >> > >>> > >> > >>>> Trillian is great for covering a portion of the tests, but it > >> > >>>>>>> currently does not cover the whole software use case. We also > >> need > >> > >>>>>>> more trillian deployments in the wild to support the CI > >> initiative. > >> > >>>>>>> > >> > >>>>>>> We do need to be stricter about nothing going in after an RC > is > >> cut > >> > >>>>>>> but blockers. The limited CI coverage and the dependence on a > >> few > >> > >>>>>>> people for testing exasperates this problem. > >> > >>>>>>> > >> > >>>>>>> So there is multiple layers to this. I think someone dedicates > >> to > >> > >>>>>>> the RM role would help this a lot because they would have a > >> single > >> > >>>>>>> community focus mandate, so it is in their best interest to > >> > >>>>>>> implement a flow which does not inhibit their ability to > >> deliver on > >> > >>>>>>> > >> > >>>>>> their mandate. > >> > >>> > >> > >>>> On Jun 30, 2017 12:53 PM, "Ron Wheeler" > >> > >>>>>>> <rwhee...@artifact-software.com> > >> > >>>>>>> wrote: > >> > >>>>>>> > >> > >>>>>>> Perhaps a Release Tsar would be a better solution. > >> > >>>>>>>> The RM needs to have absolute control over what is in or out. > >> > >>>>>>>> Reasonable discussion allowed and then a decision once the RM > >> > >>>>>>>> feels that the case has been fully explored and that a > positive > >> > vote > >> > >>>>>>>> > >> > >>>>>>> is expected. > >> > >>> > >> > >>>> The importance on meeting deadlines needs to have a higher > >> > >>>>>>>> priority. If a feature/fix can not meet the quality/testing > >> > >>>>>>>> threshold on time then it gets dropped from the RC and > >> scheduled > >> > for > >> > >>>>>>>> > >> > >>>>>>> the next release. > >> > >>> > >> > >>>> A few cycles of a bit of ruthlessness should get everyone`s > >> > >>>>>>>> intention and shorten the release cycle. > >> > >>>>>>>> > >> > >>>>>>>> Meeting release schedules would also reduce the pain of a > >> feature > >> > >>>>>>>> being deferred. > >> > >>>>>>>> According to the schedule proposed last > >> > >>>>>>>> year,(https://cwiki.apache.org > >> > >>>>>>>> /confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+ > >> > >>>>>>>> Release+Cycle+and+Calendar) > >> > >>>>>>>> Cloudstack 4.9.10 (LTS) , 5.04.0 (LTS) as well as 5.1.3.0 > >> > >>>>>>>> (maintenance) > >> > >>>>>>>> 5.2.1.0 (Maintenance) were released June 2017. > >> > >>>>>>>> > >> > >>>>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/ > >> > Release+Pro > >> > >>>>>>>> c edure seems to be pretty reasonable. The RM probably needs > to > >> > >>>>>>>> moderate the vote and explain what -1 votes mean to product > >> > >>>>>>>> credibility if they delay the release. Negative votes because > >> > >>>>>>>> someone`s new feature did not make it should be ignored. > >> > >>>>>>>> > >> > >>>>>>>> Ron > >> > >>>>>>>> > >> > >>>>>>>> On 30/06/2017 12:09 PM, Paul Angus wrote: > >> > >>>>>>>>> > >> > >>>>>>>>> We could probably split this topic down also.... > >> > >>>>>>>>> > >> > >>>>>>>>> I think I may have mentioned previously ?? my view on how we > >> have > >> > >>>>>>>>> somewhat shot ourselves in the foot with the release process > >> this > >> > >>>>>>>>> time around. I think that for the most part, people have > been > >> > >>>>>>>>> well intentioned, and have been trying to 'make this release > >> as > >> > >>>>>>>>> good as possible' which is counter-productive, as it's been > >> > >>>>>>>>> > >> > >>>>>>>> introducing new blockers. > >> > >>> > >> > >>>> I'm not sure we have a problem in our 'loosely-agreed' process, > >> > >>>>>>>>> it's just that repeatedly people have ignored it. > >> > >>>>>>>>> > >> > >>>>>>>>> WRT a full-time release manager, I suspect that they would > >> find > >> > >>>>>>>>> that "you can lead a horse to water, but you can't make it > >> > drink". > >> > >>>>>>>>> They would not be able to compel anyone to 'hurry up and fix > >> that > >> > >>>>>>>>> bug you created', although I guess maybe they could pull a > >> > feature > >> > >>>>>>>>> > >> > >>>>>>>> if the author(s) didn't sort it out. > >> > >>> > >> > >>>> Because ultimately a release manager, paid or otherwise should > >> > >>>>>>>>> only be doing what the 'community' decides the release > >> manager's > >> > >>>>>>>>> role is. So we need to be clear about how we want releases > to > >> > >>>>>>>>> work before worrying about who manages that. > >> > >>>>>>>>> > >> > >>>>>>>>> Kind regards, > >> > >>>>>>>>> > >> > >>>>>>>>> Paul Angus > >> > >>>>>>>>> > >> > >>>>>>>>> paul.an...@shapeblue.com > >> > >>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> > >> > >>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> -----Original Message----- > >> > >>>>>>>>> From: Alex Hitchins [mailto:a...@alexhitchins.com] > >> > >>>>>>>>> Sent: 30 June 2017 15:05 > >> > >>>>>>>>> To: dev@cloudstack.apache.org > >> > >>>>>>>>> Subject: RE: [DISCUSS] - Releases, Project Management & > >> Funding > >> > >>>>>>>>> Thereof > >> > >>>>>>>>> > >> > >>>>>>>>> I am in complete agreement with you. Also on your other > reply > >> > >>>>>>>>> regards to a FT release manager. > >> > >>>>>>>>> > >> > >>>>>>>>> If 'we' don't go down this line, more and more people will > >> follow > >> > >>>>>>>>> the Cosmic/Schuberg Philis path or even use Cosmic instead. > >> > >>>>>>>>> > >> > >>>>>>>>> I'm encouraged by your response. Sounds like a few others > hold > >> > >>>>>>>>> the same concerns. > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> Alexander Hitchins > >> > >>>>>>>>> ------------------------ > >> > >>>>>>>>> E: a...@alexhitchins.com > >> > >>>>>>>>> W: alexhitchins.com > >> > >>>>>>>>> M: 07788 423 969 > >> > >>>>>>>>> T: 01892 523 587 > >> > >>>>>>>>> > >> > >>>>>>>>> -----Original Message----- > >> > >>>>>>>>> From: Will Stevens [mailto:williamstev...@gmail.com] > >> > >>>>>>>>> Sent: 30 June 2017 14:54 > >> > >>>>>>>>> To: dev@cloudstack.apache.org > >> > >>>>>>>>> Subject: RE: [DISCUSS] - Releases, Project Management & > >> Funding > >> > >>>>>>>>> Thereof > >> > >>>>>>>>> > >> > >>>>>>>>> Yes, Schuberg Philis, a very active community member forked > >> > >>>>>>>>> Cosmic off of CloudStack and has been developing their fork > >> for > >> > >>>>>>>>> > >> > >>>>>>>> their needs. > >> > >>> > >> > >>>> I do think we need to have a more consistent front on this > >> > >>>>>>>>> matter. I think it would make a big difference on the > quality, > >> > >>>>>>>>> release cadence and perception of the project. > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> On Jun 30, 2017 9:48 AM, "Alex Hitchins" < > >> a...@alexhitchins.com> > >> > >>>>>>>>> > >> > >>>>>>>> wrote: > >> > >>> > >> > >>>> Thanks Will, > >> > >>>>>>>>> > >> > >>>>>>>>> I understand it's something that comes with a big bag of > >> > >>>>>>>>> troublesome worries. > >> > >>>>>>>>> > >> > >>>>>>>>> If this topic comes up again in any discussions, I'd be > >> > >>>>>>>>> interested to hear their thoughts on what I see as the > >> > >>>>>>>>> alternative; without a dedicated RM/PM/Captain, people will > >> fork > >> > >>>>>>>>> off CS so they can achieve the same thing, and CS ultimately > >> > >>>>>>>>> looses out long term. I can't remember the name of the fork, > >> but > >> > >>>>>>>>> I think I'm right that a previous large CS contributor/user > >> > >>>>>>>>> forked off as they wanted greater management in the areas we > >> are > >> > >>>>>>>>> > >> > >>>>>>>> discussing here. > >> > >>> > >> > >>>> > >> > >>>>>>>>> Alexander Hitchins > >> > >>>>>>>>> ------------------------ > >> > >>>>>>>>> E: a...@alexhitchins.com > >> > >>>>>>>>> W: alexhitchins.com > >> > >>>>>>>>> M: 07788 423 969 > >> > >>>>>>>>> T: 01892 523 587 > >> > >>>>>>>>> > >> > >>>>>>>>> -----Original Message----- > >> > >>>>>>>>> From: Will Stevens [mailto:williamstev...@gmail.com] > >> > >>>>>>>>> Sent: 30 June 2017 14:31 > >> > >>>>>>>>> To: dev@cloudstack.apache.org > >> > >>>>>>>>> Subject: Re: [DISCUSS] - Releases, Project Management & > >> Funding > >> > >>>>>>>>> Thereof > >> > >>>>>>>>> > >> > >>>>>>>>> Apache has been historically against the idea of a > cloudstack > >> > >>>>>>>>> foundation and there is a bit of a pandoras box there which > we > >> > >>>>>>>>> will want to be careful about opening. > >> > >>>>>>>>> > >> > >>>>>>>>> Apache added direct contribution, but it was unusable for us > >> > >>>>>>>>> historically because it required a minimum contribution of > >> 50k, > >> > >>>>>>>>> which none of us can afford. However, there have been some > >> > >>>>>>>>> changes to the board recently which are in our favour if we > >> want > >> > to > >> > >>>>>>>>> > >> > >>>>>>>> put pressure to lower that to say 5-10k. > >> > >>> > >> > >>>> Even if we do solve for smaller direct contributions, we will > >> > >>>>>>>>> have to jump through hoops to be able to use those funds > for a > >> > >>>>>>>>> dedicated release manager. I do think this is a possibility > >> if we > >> > >>>>>>>>> manage our needs and communications very well. I had some > >> > >>>>>>>>> preliminary discussions with some apache foundation folks to > >> > >>>>>>>>> express these specific concerns. I played off the fact that > i > >> > >>>>>>>>> know they dont want to entertain a cloudstack foundation and > >> > >>>>>>>>> tried to see if i could get them to move on the direct > >> > >>>>>>>>> contribution mechanism to make it usable for us, > specifically > >> > >>>>>>>>> with the goal of hiring a full time release manager. I > >> definitely > >> > >>>>>>>>> had their ear and they acknowledged the problems we are > facing > >> > >>>>>>>>> (and currently discussing). They expressed concerns about > >> being > >> > >>>>>>>>> able to hire someone with the direct contributions, but > >> > >>>>>>>>> brainstormed a bit to potentially hire an agency who > actually > >> > does > >> > >>>>>>>>> > >> > >>>>>>>> the hire and they pay the persons salary through the agency > >> with > >> > >>> the direct > >> > >>> contribution funds. > >> > >>> > >> > >>>> All to say, there are potential options here, but there be > >> > >>>>>>>>> dragons, so we have to handle this topic with care. > >> > >>>>>>>>> > >> > >>>>>>>>> On Jun 30, 2017 9:12 AM, "Ron Wheeler" > >> > >>>>>>>>> <rwhee...@artifact-software.com> > >> > >>>>>>>>> wrote: > >> > >>>>>>>>> > >> > >>>>>>>>> https://www.apache.org/foundation/contributing.html says: > >> > >>>>>>>>> > >> > >>>>>>>>>> "If you have a specific target or project that you wish to > >> > >>>>>>>>>> directly support, pleasecontact us > >> > >>>>>>>>>> <https://www.apache.org/founda > >> > >>>>>>>>>> tion/contributing.html#Fundraising>and we will do our best > >> to > >> > >>>>>>>>>> > >> > >>>>>>>>> satisfy your wishes." > >> > >>> > >> > >>>> 1) Is Apache willing to allow projects to set up their own > >> > >>>>>>>>>> foundations? I doubt but someone would need to check this > >> out. > >> > >>>>>>>>>> Does the PMC have the project charter or the agreement that > >> was > >> > >>>>>>>>>> signed when Cloudstack moved. > >> > >>>>>>>>>> > >> > >>>>>>>>>> 2) Has anyone tried to contact Apache about directing > >> support to > >> > >>>>>>>>>> Cloudstack. > >> > >>>>>>>>>> > >> > >>>>>>>>>> I am not convinced that lack of paid staff is the issue. > >> > >>>>>>>>>> This discussion reminded me of this. > >> > >>>>>>>>>> Q: How many psychiatrists does it take to change a > lightbulb > >> ? > >> > >>>>>>>>>> A: Only one, but the lightbulb must want to change > >> > >>>>>>>>>> > >> > >>>>>>>>>> http://www.lightbulbjokes.com/directory/p.html > >> > >>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>>> Ron > >> > >>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>>> On 30/06/2017 6:48 AM, Alex Hitchins wrote: > >> > >>>>>>>>>> > >> > >>>>>>>>>> As per Giles's comment to the previous thread, I thought I > >> would > >> > >>>>>>>>>> > >> > >>>>>>>>>>> start a discussion on the subject to canvas peoples > >> thoughts, > >> > >>>>>>>>>>> opinions > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> and fears. > >> > >>>>>>>>>> My question for discussion, is there is any mileage in > >> someone > >> > >>>>>>>>>> > >> > >>>>>>>>>>> creating a "CloudStack Foundation" as a non-profit entity, > >> > >>>>>>>>>>> funded largely by key CloudStack players with the sole > >> function > >> > >>>>>>>>>>> of employing dedicated resource (part or full time) to > >> handle > >> > >>>>>>>>>>> all releases and other essential 'back office' functions. > >> The > >> > >>>>>>>>>>> idea being it's in everyone's interest to chip in a little > >> each > >> > >>>>>>>>>>> to fund core project and > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> release management. > >> > >>>>>>>>>> The idea might be utterly irrelevant, pointless and/or > >> straight > >> > up > >> > >>>>>>>>>> > >> > >>>>>>>>> daft. > >> > >>> > >> > >>>> I urge you all to let me know. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Something for you all to think over this weekend. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Alexander Hitchins > >> > >>>>>>>>>>> ------------------------ > >> > >>>>>>>>>>> E: a...@alexhitchins.com > >> > >>>>>>>>>>> W: alexhitchins.com > >> > >>>>>>>>>>> M: 07788 423 969 > >> > >>>>>>>>>>> T: 01892 523 587 > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> -----Original Message----- > >> > >>>>>>>>>>> From: Giles Sirett [mailto:giles.sir...@shapeblue.com] > >> > >>>>>>>>>>> Sent: 30 June 2017 09:51 > >> > >>>>>>>>>>> To: dev@cloudstack.apache.org > >> > >>>>>>>>>>> Subject: RE: JIRA - PLEASE READ > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> All > >> > >>>>>>>>>>> This thread seems to have turned into 2 quite different > >> > >>>>>>>>>>> > >> > >>>>>>>>>> discussions: > >> > >>> > >> > >>>> 1. The use (or not) of Jira - which was the original discussion > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> 2. Ways/means of encouraging (and paying for more > structured > >> > >>>>>>>>>>> contributors) > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> I know that it could be argued that these are related. > >> Could I > >> > >>>>>>>>>>> suggest opening up a thread on "release and project > >> management > >> > >>>>>>>>>>> and funding it" and keeping this thread to the original > >> > >>>>>>>>>>> discussion > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> (I will weigh in on both of these at some stage) > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Kind regards > >> > >>>>>>>>>>> Giles > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> giles.sir...@shapeblue.com > >> > >>>>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> > >> > >>>>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >> @shapeblue > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> -----Original Message----- > >> > >>>>>>>>>>> From: Alex Hitchins [mailto:a...@alexhitchins.com] > >> > >>>>>>>>>>> Sent: 29 June 2017 18:49 > >> > >>>>>>>>>>> To: dev@cloudstack.apache.org > >> > >>>>>>>>>>> Subject: Re: JIRA - PLEASE READ > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> If it isn't being treated as a product it will be very > >> > >>>>>>>>>>> impossible to market it as enterprise ready. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> I know we all know this. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Similar sized projects under the Apache banner must have > the > >> > >>>>>>>>>>> same issue, what is the best way to gather experience of > >> these > >> > >>>>>>>>>>> > >> > >>>>>>>>>> projects? > >> > >>> > >> > >>>> See how they handle these growing pains. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> A cloudstack foundation entity funded by companies earning > >> from > >> > >>>>>>>>>>> cloudstack seems a good way forward. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Another tuppence, this is getting expensive. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> On 29 Jun 2017, at 18:18, Ron Wheeler > >> > >>>>>>>>>>> <rwhee...@artifact-software.com> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> wrote: > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> I understand that it is a volunteer organization. > >> > >>>>>>>>>>>> I do not know how many (if any) of the committers and PMC > >> > >>>>>>>>>>>> members are funded by their organizations (allowed or > >> ordered > >> > >>>>>>>>>>>> to work on Cloudstack during company time) which is often > >> the > >> > >>>>>>>>>>>> way that Apache projects get staffed. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Clearly it is hard to tell someone who is being funded > by a > >> > >>>>>>>>>>>> company to fix a problem or who is working on their own > >> time, > >> > >>>>>>>>>>>> to do or not do something. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> On the other hand, the PMC has to build a community > >> culture > >> > >>>>>>>>>>>> that is good for the project. > >> > >>>>>>>>>>>> That means describing a vision, planning and enforcing a > >> > >>>>>>>>>>>> roadmap, and maintaining a focused project "marketing" > >> effort. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> There is a lot of extremely talented individuals working > on > >> > >>>>>>>>>>>> Cloudstack and it appears to have a very strong and > >> valuable > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> code-base. > >> > >>> > >> > >>>> To me the key question is about the PMC and the core committers' > >> > >>>>>>>>>>>> ability to make Cloudstack a "product" that can compete > for > >> > >>>>>>>>>>>> market share and acceptance. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Is Cloudstack at a point in its development where it > >> should be > >> > >>>>>>>>>>>> treated like a product? > >> > >>>>>>>>>>>> - sufficient functionality to compete > >> > >>>>>>>>>>>> - sufficient user base to be a competitor in the market > >> > >>>>>>>>>>>> - production reliability and stability > >> > >>>>>>>>>>>> - business model for supporting companies to justify > their > >> > >>>>>>>>>>>> continued support > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> This may not require more effort but requires different > >> > >>>>>>>>>>>> policies and different activities. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> There has to be someone or a PMC that can say "No". > >> > >>>>>>>>>>>> - This change can not be included in this release because > >> it > >> > >>>>>>>>>>>> will delay the release. > >> > >>>>>>>>>>>> - This change adds an unacceptable level of complexity > >> > >>>>>>>>>>>> - This bug fix will have to wait for the next release > >> because > >> > >>>>>>>>>>>> it is too late to test it and fix the docs. > >> > >>>>>>>>>>>> - This fix breaks the docs > >> > >>>>>>>>>>>> - The release can not be made until this doc is updated. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Does the core group want to make it a competitive product > >> or > >> > >>>>>>>>>>>> is it sufficient for the interested players to continue > in > >> its > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> current form? > >> > >>> > >> > >>>> Ron > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> On 29/06/2017 9:42 AM, Will Stevens wrote: > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> I personally don't know how Jira solves any of this, but > >> > >>>>>>>>>>>>> assuming it does, fine... > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> The bigger problem which you have raised is that > >> CloudStack > >> > >>>>>>>>>>>>> has zero funding. So we can't hire a project manager, > or a > >> > >>>>>>>>>>>>> release manager or someone whose job it is to maintain > >> > >>>>>>>>>>>>> documentation. I have been trying to find a way to, at > the > >> > >>>>>>>>>>>>> very least, fund a full time release manager who can > focus > >> > >>>>>>>>>>>>> 100% on the project. As the release manager for 4.9, I > >> know > >> > >>>>>>>>>>>>> it is a full time job. I did my best, but it is a ton of > >> work > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>> and is hard to stay on top of. > >> > >>> > >> > >>>> Everyone contributing to CloudStack is donating their time. > >> > >>>>>>>>>>>>> They can't make a living off supporting ACS, so every > one > >> is > >> > >>>>>>>>>>>>> doing their best with the little time they can take away > >> from > >> > >>>>>>>>>>>>> their day job or their family life. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Yes, having clear guidelines and sticking to them helps, > >> but > >> > >>>>>>>>>>>>> without a solid CI infrastructure backing the project > and > >> > >>>>>>>>>>>>> improved testing and automation, we will always > struggles > >> > >>>>>>>>>>>>> with release schedules and such. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> I have been involved in this project long enough to know > >> that > >> > >>>>>>>>>>>>> all the problems you point out exist, but they are also > >> not > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>> easily solved. > >> > >>> > >> > >>>> Obviously we have to work with the initiatives we have and > >> > >>>>>>>>>>>>> take small steps towards improvement, but we also have > to > >> be > >> > >>>>>>>>>>>>> realistic with our expectations because we are counting > on > >> > >>>>>>>>>>>>> people's generosity to move them forward. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Simplifying moving parts and streamlining the process > will > >> > >>>>>>>>>>>>> lead to more contribution because there is less barriers > >> to > >> > >>>>>>>>>>>>> entry. This one reason why I struggle to see the value > in > >> > Jira > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>> as it is used today. > >> > >>> > >> > >>>> I personally don't understand what value it is giving us that > >> > >>>>>>>>>>>>> the github PRs and Issues don't solve. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> I will remain open minded and will follow along with > what > >> > >>>>>>>>>>>>> people think is best, but I think it is worth > >> understanding > >> > >>>>>>>>>>>>> what we are trying to solve for and simplify our > approach > >> in > >> > >>>>>>>>>>>>> solving it so we can get better systems in place. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> On Jun 29, 2017 9:17 AM, "Ron Wheeler" > >> > >>>>>>>>>>>>> <rwhee...@artifact-software.com> > >> > >>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> As a real outsider, IMHO Paul is right. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> At times it seems that Cloudstack is a coding hobby > rather > >> > >>>>>>>>>>>>>> than a project or a production quality product. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Who decides what goes into a release? How does this > >> affect > >> > >>>>>>>>>>>>>> the release schedule? > >> > >>>>>>>>>>>>>> Who is responsible for meeting the "published" roadmap > >> (of > >> > >>>>>>>>>>>>>> which there seem to be many) of releases? > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> How is a system admin that is not part of the project > >> > >>>>>>>>>>>>>> supposed to plan for upgrade windows? > >> > >>>>>>>>>>>>>> How does one know when a feature, bug fix or release > >> will be > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> available? > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>> How does the PMC manage function creep in a release, > >> > maintain > >> > >>>>>>>>>> > >> > >>>>>>>>>>> quality and consistency, reject changes that hurt the > >> > >>>>>>>>>>>>>> overall vision or add too much complexity? > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> No one seems to care about documentation but if someone > >> did, > >> > >>>>>>>>>>>>>> how would they stop undocumented features or features > >> that > >> > >>>>>>>>>>>>>> contradict the documentation from being incorporated? > >> > >>>>>>>>>>>>>> Who makes sure that the documentation is correct at the > >> time > >> > >>>>>>>>>>>>>> of the release? > >> > >>>>>>>>>>>>>> Release notes are not much help for someone doing a new > >> > >>>>>>>>>>>>>> install or evaluating Cloudstack. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Without a JIRA entry, how does an end-user who > >> encounters a > >> > >>>>>>>>>>>>>> problem know that it has been fixed already in the next > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>> release? > >> > >>> > >> > >>>> Without a JIRA entry, how does the community comment on a > >> > >>>>>>>>>>>>>> proposed change before it gets coded? > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> If changes are going to be accepted without a JIRA, is > >> there > >> > >>>>>>>>>>>>>> a definition of a minor fix that does not require a > JIRA? > >> > >>>>>>>>>>>>>> - does not change functionality? > >> > >>>>>>>>>>>>>> - only affects an "edge case" or cleans up an exception > >> that > >> > >>>>>>>>>>>>>> is not properly handled? > >> > >>>>>>>>>>>>>> - only improves code readability or future > extensibility? > >> > >>>>>>>>>>>>>> - does not affect documentation? > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Apache projects that are popular and enjoy wide support > >> do > >> > >>>>>>>>>>>>>> have strong management. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> There are other examples where great Apache software is > >> > >>>>>>>>>>>>>> failing to get recognized because the PMC is not paying > >> > >>>>>>>>>>>>>> attention to the product management side of things. > >> > >>>>>>>>>>>>>> I use Apache Jackrabbit which is a quality product > with a > >> > >>>>>>>>>>>>>> strong technical team supporting it. > >> > >>>>>>>>>>>>>> It has very little following because the documentation > >> and > >> > >>>>>>>>>>>>>> marketing collateral is very poor. > >> > >>>>>>>>>>>>>> It gets by because the audience for it is largely > >> software > >> > >>>>>>>>>>>>>> developers who can read code and can test features to > >> work > >> > >>>>>>>>>>>>>> out the functionality. > >> > >>>>>>>>>>>>>> It would get a lot more attention if they paid > attention > >> to > >> > >>>>>>>>>>>>>> the product management side of the project. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Cloudstack needs to avoid this situation and > >> unfortunately > >> > >>>>>>>>>>>>>> this takes effort and some discipline. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Ron > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> On 29/06/2017 8:03 AM, Will Stevens wrote: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Why are we still using jira instead of the PRs for > that > >> > >>>>>>>>>>>>>>> communication? Can we not use issues in github now > >> instead > >> > >>>>>>>>>>>>>>> of jira if someone needs to open an issue but does not > >> yet > >> > >>>>>>>>>>>>>>> have code to contribute. If not, jira could still be > >> used > >> > for > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> that. > >> > >>> > >> > >>>> I think duplicating data between jira and the PR is kind of > >> > >>>>>>>>>>>>>>> pointless. I feel like the github PRs and the cide > >> going in > >> > >>>>>>>>>>>>>>> should be the source of truth, not a random third > party > >> > tool. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> For the 4.9 release notes, i built a tool to generate > >> the > >> > >>>>>>>>>>>>>>> release notes from the PRs merged in that release. I > >> think > >> > >>>>>>>>>>>>>>> that is easier and more accurate than depending on > jira > >> > >>>>>>>>>>>>>>> since it does not track the actual code tree. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Thats my 0.02$. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> On Jun 29, 2017 5:25 AM, "Paul Angus" > >> > >>>>>>>>>>>>>>> <paul.an...@shapeblue.com> > >> > >>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Such a view of CloudStack is what holds CloudStack > back. > >> > >>>>>>>>>>>>>>> It stops users/operators from having any chance of > >> > >>>>>>>>>>>>>>> understanding what CloudStack does and how it does it. > >> > >>>>>>>>>>>>>>> Code for code's sake is no use to anyone. > >> > >>>>>>>>>>>>>>> Jira is about communication between developers and to > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> everyone else. > >> > >>> > >> > >>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Kind regards, > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Paul Angus > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> paul.an...@shapeblue.com > >> > >>>>>>>>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> > >> > >>>>>>>>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >> > >>>>>>>>>>>>>>> @shapeblue > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> -----Original Message----- > >> > >>>>>>>>>>>>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > >> > >>>>>>>>>>>>>>> Sent: 29 June 2017 10:14 > >> > >>>>>>>>>>>>>>> To: dev <dev@cloudstack.apache.org> > >> > >>>>>>>>>>>>>>> Subject: Re: JIRA - PLEASE READ > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus > >> > >>>>>>>>>>>>>>> <paul.an...@shapeblue.com> > >> > >>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> + Release notes will be impossible to create without a > >> > >>>>>>>>>>>>>>> + proper Jira > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> history. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> And no one will know what has gone into CloudStack. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> No they are not mr Grumpy. they should be base on the > >> code > >> > >>>>>>>>>>>>>>>> anyway, > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> hence on git, not jira. I do not appose to the use of > >> Jira > >> > >>>>>>>>>>>>>>> but it is not required for good coding practices and > as > >> we > >> > >>>>>>>>>>>>>>> are not and will not function as a corporation, jira > is > >> an > >> > >>>>>>>>>>>>>>> extra for those that grave for it. not a requirement. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> -- > >> > >>>>>>>>>>>>>>> Daan > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > > > >> > > > >> > > >> > > > > > -- With best regards, Ivan Kudryavtsev Bitworks Software, Ltd. Cell: +7-923-414-1515 WWW: http://bitworks.software/ <http://bw-sw.com/>
