Build Failure - Githubissues

Date 1/8/2020. time 00:22 CET _>

Build failed, used several compilers up to a professional Watcom Compiler from Cisco still nothing just so you know.

Ana Green

Closing this issue as the user has already been repeatedly advised in issue #28 that we are aware of this issue and there have been messages in various commits saying this.

We have CI tools for a reason to do test builds for us. The only time you need to report a build failure to us is if our build tools are building successfully but your local build is not working.

Additionally using build tools that we do not provide for our projects is not supported and we will not provide support to anyone using build tools with our projects that we do not provide.

Emperor Starfinder Chair, Board of Directors Funder, President, and CEO Core Developer - Grid Architecture Development Grid Architecture Development Work Group Leader Virtual World Research Inc.

Sure it is an issue yet you closing it, We have CI tools yes so? (You) The only time you need to report a build failure to us is if our build tools are building successfully but your local build is not working. - Oh, but we did not only build it locally but also on the company I work CISCO the same issue but ok I drop it this is ridiculous.

Ana Green

Aloha,

reviewing the issue, a couple of things to note.

First I don't think that the issue is being closed for any malicious or inappropriate reasons. This issue was addressed in the referenced issue and was acknowledged by the development team. So the issue would, therefore, be seen as a duplicate of that issue. We close duplicate issues in order not to confuse people or ourselves.

Second, If you do work at Cisco then you should know that in the development world CI stands for Continuous Integration. We use other CI tools internally which are custom made by us and therefore I cannot disclose those due to our Non Disclosure Rules (NDA). The README.md file in this repository lists a few CI tools that we use. Two for security scanning and two for building. These tools are triggered when a pull request from the community is submitted or a member of the development team pushes a commit to a branch or to master. Upon completing their tasks the badge information is updated on the README.md file and an email is sent to each of the members of the development team internally to let us know the status and any problems encountered during the operation. This is how we know if there is an issue relating to the CI tools. What Emperor is saying here is that where our building CI tools have told us there is a problem with building the code, it is obvious you will have a problem locally and not necessary to open an issue ticket. There are times when our CI tools will pass but some folks might have a problem with building locally. When that happens is when you should open an issue to let us know the build failed. If you ever encounter issues with building the first thing to do is check whether the badge on the README.md file says its passing. If it is passing there then there would be likely an issue we wouldn't know about. However, if the badge says failed or is marked in orange or red then it is a good chance we already know about it.

Third, As was stated in the referenced issue, we also have internal development repositories. Our internal repositories are always going to be ahead of the public repositories. So if a fix to an issue is available it will go to the internal repository first. Then when it is deemed ready for the public repository it will make it's way there. In this case, the fix to this issue is in the internal repository and is awaiting approval to be pushed to the public repository. However because of the major commit that was mentioned that commit technically makes this issue moot as the build does work in that commit. Because the major commit does make major changes to the code, it is better to await that commit which should be pushed to the public repository in the next few days.

I know it is one of those things that people want to dive right in, but patience will pay off because the changes coming are good. The future of virtual worlds is bright.

Best Regards Briakallista Starfinder Core Developer Roleplay Lifestyles Development, Maintenance Member - Grid Architecture Development Work Group Member - Viewer Development Work Group Virtual World Research Inc.

@BriaKallistaStarfinder: Yes I work for CISCO maybe its something for you look here: https://jobs.cisco.com/jobs/SearchJobs/?3_19_3=%5B%22162%22%2C%22163%22%2C%22%22%5D&3_12_3=%5B%2241330107%22%2C%22186%22%2C%22194%22%2C%22187%22%2C%22196%22%2C%22197%22%2C%229013351%22%5D&source=Cisco+Jobs+Career+Site&tags=CDC+Prof+engineering for me CI means Continuous Integration is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. While automated testing is not strictly part of CI it is typically implied. And CO A co-operative (co-op) is a different kind of business. Our Co-op is owned by individual members and other co-ops, not big investors, and our members get a chance to have a say in how we’re run. Profits mean members receive money, rewards and offers, and a co-op can support its local community.

Here we will take a look at the most commonly adopted phases of software development to see the ways how the perfect product is launched at CISCO that same should be the case for Simulators and Grid Software but in our case, it is VoIP Software for in IP Phones.

Brainstorming and planning to create a better Simulator than the OpenSimulator in this case. Requirements and feasibility analysis. Design. Development & coding. Integration and testing. Implementation and deployment. Operations and maintenance.

Excuses it is longer as I thought but this is also my last response, you don't go to your CO or Manager and tell him/her "It does not compile, waste of time" but in this case, it seems to be just fine and not a waste of time, I guess 0.9.x has been broken uh? It was already badly written, So Brainstorming and planning are not how to change or alter Opensim 0.9.x but to create a complete new Simulator, it is easy to use any code and change the code, till it breaks. In short Software, the design is a preeminent component of software project development. During the design phase, the actual conceptualizing of the solution is created, that is the detailed software architecture meeting specific project requirements is created. The development phase is about writing code and converting design documentation into the actual software within the software development process. This stage of SDLC is generally the longest as it’s the backbone of the whole process and there are a number of vital things to pay attention to. The software engineering team has to make sure their code meets the software requirements specifications Not to forget it is for SIP, or Satellite code most remain compilable, may not fail to compile (how do you test phase one) to start with if it doesn't compile, like I said a waste of time and at CISCO money. The software development release cycle proceeds from alpha, beta, release candidate to actual production build. Once the complete architecture (DB, API, etc) and the planned functionality of the solution are built, the testing stage starts. I never saw that happening in case of any OpenSimulator project, you? Now that the software is built and completed the next phase involving system testing and integration starts. Depending on the adopted testing processes it might vary. But typically the QA engineers use a whole range of frameworks alongside continuous integration executing unit tests, automation compilation, and testing. This is a stage when the actual installation of the crafted solution takes place. It’s done step-by-step according to the implementation plan. The newly built and tested application is moved to production including data and components transfer while during the next releases only the specific changes will be deployed. Depending on the complexity of the project it might be a straightforward release (if the project is simple) or staggered released (in stages) in case of a more complex project. At this point, the Software Development Life Cycle as a structured iterative process varies from company to company aiming at delivery of the best quality product that satisfies the needs even of the most demanding customers. The software development life cycle can be shaped or adjusted to the needs of each particular project, app development or software provider to identify precise actions so that the particular goals are achieved. Any project I have seen in the Open Simulator project is the same, they using some Master, merged or not, changing version number and build code and name, adding some other code so it looks different and on top saying "This is not Open Simulator it is X" where X can be anything, like Halcyon, for example, the code is full of dead Open Simulator code what doesn't do anything anymore, simply disabled. So why not in the first place Brainstorming and planning for a complete real new Simulator not using some bad code from some OpenSourced Open Simulator what is already a really bad code. Then planning to create a better Simulator but completely different than Open Simulator see now you can say it is not an Open Simulator clone. But then again a Company like CISCO, IBM, INTEL, etc has to keep their name up, after all, it's business while Open Simulator is clearly not such a name and therefore not relevant to his functionality or name as it is not a business model. Relevant Software offers established practices of the software development life cycle. Following them proved to be a driving factor for the successful delivery of well-tailored great software solutions that meet business needs and offer exceptional customer satisfaction. SDLC empowers the customers to stay on top of the processes and the development team together with the project management team can focus on the vital elements in a timely and efficient manner. Open Simulator will and is a hobby, it doesn't mater what for label you hang on it.

CISCO Development Team, With all respect, Ana Green

Aloha,

Ana, you missed my point. The point of what I said is if you work at CISCO then you should know that we do have policies and procedures we work by. Likewise, you should know that if our team closes an issue because it is an issue that we know about already which was stated multiple times then it is not something to take personally. Nor does our closing an issue, require a long-winded rant that goes off the topic of the issue being commented on. The more you go into long responses and go off-topic the more your proving that you might not work there. The same also goes to those who go into topics not related to the issue just to try to prove they are knowledgable. Having read a number of the issues you post on our project arm which is good especially if it is an issue we aren't aware of, but also on other architecture projects, I have noticed you do have a habit of going off-topic in long responses, whether in frustration or not. This is something you will want to work on as it only hurts the perception of others about you.

We do operate a bit differently then many of the grid architecture projects your familiar with for a reason. We have internal repositories both for our open source project arm and our proprietary grid architecture to run our main grid. So if in an issue you report we acknowledge that we are aware of the issue and have fixed it in our internal development repository then you know it is just a matter of being patient, that fix will make its way to the public repositories.

Likewise, we do not support BuildTools that are not listed in our repositories. So testing against any other tools other than the ones we support in our repositories will most likely get ignored. That is why it is always better to go by what we support and not try to test it against something else unless the member of our team handling the issue specifically requests. This way you will not only avoid confusion yourself and for us, but you will help others avoid confusion who might read the issue later on down the road.

Virtual-Universe / Virtual-Universe-Early-Dev

Build Failure #31