One month ago I submitted a pull request for what I believe is a backwards-compatibility break in Symfony 2.7:
https://github.com/symfony/symfony/pull/15328
No one in the core team has reviewed it yet, which is surprising to me since I would have thought BC-breaks would be a high priority. I've read the contributing guidelines and followed them as best I can; the only problem I see is that it's not passing on HHVM for reasons that I don't think have to do with my change.
So my question is: have I missed some prerequisite for getting one's PR reviewed, or do I just need to quit whining and be patient?
I cannot talk on behalf of the core team or direct experience. In fact I should not talk at all :-)
But as an occasional open source maintainer myself, I see that there are 222 PRs open; as long as yours is failing the CI tests, I fear it will definitely get less attention than the others. Also it may have been triaged as a less important fix. Again, this is just IMHO.
I think you should really focus on fixing the broken CI test; you can ask another question here to get help.
Related
I want to connect and test Kafka.
Is it possible to test using RobotFramework.
Any exist library for this.
Thanks
Sarada
I realize this post is 5 years old, but the answer (at least now) is yes!
Repository
Keyword documentation
Sorry I don't have enough experience to provide any tutoring on it (I'm a newb with Kafka), but at least it exists.
Yes, it is possible to interact with and thus test kafka with RobotFramework. Highly unlikely there exists a library for it however, based on a brief web search.
See my earlier response to this old thread that gives a detailed discussion of what you're asking about and how to go about solving it, minus the actual implementation (which is a significant amount of work, hence no one has written and shared such a library yet).
https://groups.google.com/forum/#!topic/robotframework-users/gnfR12xAU4U
I'm implementing a blob store over Riak KV to make an experiment storing mail attachment. Riak CS seems over reaching for this goal.
I already have a prototype implemented in Python and many ideas to keep working on it. Today I stumbled upon luwak, which has a similar design, however much more complete and consistent with the Merkle tree metadata.
Is luwak abandoned in favor of Riak CS? Is it production ready?
Looks like it has been abandoned:
Hi all,
I wanted to take a moment and let the community-at-large know
that we are going to end-of-life the Luwak functionality in Riak, as
part of our 1.1 release in February. This simply means that the Luwak
repo on Github will not be actively developed/supported by Basho, or
included as a default Riak dependency. In keeping with our commitment
to Open Source, the code will still be available if someone else wants
to develop on it. You can also continue to use it with Riak if you are
willing to edit the deps and compile from source -- the Luwak README
will contain information on how to do this.
While the idea of Luwak
was interesting, we ultimately decided that it wasn’t the
architectural path we wanted to pursue for storing larger values in
Riak. If Luwak is a piece of your Riak deployment, we’d love to hear
from you and incorporate your feedback into future directions.
Please don’t hesitate to reach out to myself or Mark Phillips.
Thanks, D.
The last commit on the open-source project was a little over 3 years ago, and it's had an outstanding pull request open for 10 months (the comments on there are not encouraging either). So yeah, I'd say it's pretty dead.
I've been recently tasked with leading an effort to improve our input (and output) validation with OWASP recommendations and PCI compliance in mind. In the process, I'm trying to assess the value of the ESAPI.NET project which does not appear to have seen any activity since the spring of '09 and as it stands is incomplete.
Does anyone have experience using or extending ESAPI.NET v0.2? Is it a good starting place today for building out an infrastructure to address the targeted vulnerabilities?
FYI: I am looking at MS AntiXSS which, of course, only addresses a portion of ESAPI's scope. We already do a good job with SQL injection though there are improvements we need to make.
(If someone wants to create an ESAPI tag, feel free. I don't have the mojo.)
Looks like there were a couple updates last week: http://code.google.com/p/owasp-esapi-dotnet/source/list
You might contact one of the project leads on that list to ask what's going on.
NOTE: 05/26/2012: the last update on that project was dec 4, 2010. Yes, it is dead.
It looks like ESAPI is dead period. There's nobody using it, there are no questions, no forums, no information, nothing. The listservs (what is this, 1996?) are barren too. The documentation is terrible and the samples in the swingset don't work (server that installs is HTTP not HTTPS, and no transactions can be made in HTTP mode).
Seems to be a dead end project.
The project itself seems dead there are however some people who maintain a github copy with several (minor?) additions...
https://github.com/haldiggs/owasp-esapi-dotnet
https://github.com/jstemerdink/owasp-esapi-dotnet
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In our organisation we deliver products to different product lines depending on the requirements. in short the same application is customised according to customer requirements and delivered. After deploying the application sometimes we got some issues logged by client.
My question comes here. who is responsible to look into the issues and solve it
Programmers
Testers
Management is asking Testers to have a look into the issues and solve them. But the testers don't have the chance to look into the code. is it feasible to ask the testers to go for the issue resolution and end up wasting time doing nothing thus delaying the solution to the customers.
I would normally expect management to look through the issues every so often (say, every week), and allocate depending on schedules, severity, forthcoming releases etc. Some questions are:
is it an issue a bug, a feature request etc.?
does it prevent your client from working with your tool ?
is it impacted by forthcoming work (e.g. will a new feature remove the feature causing the issue) ?
I don't believe you can resolve these issues in isolation. It requires project managers etc. with awareness of project direction and programmers with awareness of the codebase to work together to determine how/when issues should be addressed, and their impact on other work streams.
Initially you should have a support department that does triage on all newly added issues. They should be empowered and informed enough to decide whether this is a non-issue, whether there's a work-around or whether they don't know. If it's the latter then it should be elevated to programmers.
You might also want to include the testers in the chain if the support guys are unable to produce an adequate 'how to reproduce the problem' document for the programmers.
The way it works at our company is that the testers are asked to verify the client's issue, i.e. trying to reproduce it and document the steps taken to reproduce it. Then it gets logged as an official bug and assigned to a developer who can retake the tester's steps and hopefully fix the bug.
Testers can identify an issue. How can they resolve the same? Only the developer will be able to do it. Looks really strange where a tester is asked to resolve the issue.
Who deals with the clients? Liasing with clients is not a task normally associated with the technical staff.
You should have someone whose role it is to speak to the customers, find out exactly what the issue is and how the client would like it resolved so that it may be passed onto the most relevant person to address the issue.
I would say the logical way to do it is:
Testers should try to reproduce the problem and identify its source
Report the problem with steps to reproduce it to the programmers
It's not common usage to let testers solve the issues as the programmers won't get the feedback they need to avoid the issues in the future.
Testers - verify that the problem exists.
Programmers - solve the problem.
In between there is another part to this, which is "gather information about the problem". Usually this is a split between testers and programmers; exactly how balanced that load is depends on the team.
If you don't have the code, you can't fix bugs. It's as simple as that. At the very most you could fix configuration errors, but if the misconfiguration was caused by the program that's a short-term fix.
We have 4 different environments:
Staging
Dev
User Acceptance
Live
We use TFS, pull down the latest code and code away.
When they finish a feature, the developers individually upload their changes to Staging. If the site is stable (determined by really loose testing), we upload changes to Dev, then UserAcceptance and then live.
We are not using builds/tags in our source control at all.
What should I tell management? They don't seem to think there is an issue as far as I can tell.
If it would be good for you, you could become the Continuous Integration champion of your company. You could do some research on a good process for CI with TFS, write up a proposed solution, evangelize it to your fellow developers and direct managers, revise it with their input and pitch it to management. Or you could just sit there and do nothing.
I've been in management for a long time. I always appreciate someone who identifies an issue and proposes a well thought-out solution.
Whose management? And how far removed are they from you?
I.e. If you are just a pleb developer and your managers are the senior developers then find another job. If you are a Senior developer and your managers are the CIO types, i.e. actually running the business... then it is your job to change it.
Tell them that if you were using a key feature of very expensive software they spent a lot of money on, it would be trivial to tell what code got pushed out when. That would mean in the event of a subtle bug getting introduced that gets passed user acceptance testing, it would be a matter of diffing the two versions to figure out what changed.
One of the most important parts of using TAGS is so you can rollback to a specific point in time. Think of it as an image backup. If something bad gets deployed you can safely assume you can "roll" back to a previous working version.
Also, developers can quickly grab a TAG (dev, prod or whatever) and deploy to their development PC...a feature I use all the time to debug production problems.
So you need someone to tell the other developers that they must label their code every time a build is done and increment a version counter. Why can't you do that?
You also need to tell management that you believe the level of testing done is not sufficient. This is not a unique problem for an organisation and they'll probably say they already know. No harm in mentioning it though rather than waiting for a major problem to arrive.
As far as individuals doing builds or automated build processes this depends on whether you really need this based on how many developers there are and how often you do builds.
What is the problem? As you said, you can't tell if management see the problem. Perhaps they don't! Tell them what you see as the current problem and what you would recommend to fix the problem. The problem has to of the nature of "our current process has failed 3 out of 10 times and implementing this new process would reduce those failures to 1 out of 10 times".
Management needs to see improvements in terms of: reduced costs, icreased profits, reduced time, reduced use of resources. "Because it's widely used best practice" isn't going to be enough. Neither is, "because it makes my job easier".
Management often isn't aware of a problem because everyone is too afraid to say anything or assumes they can't possibly fail to see the problem. But your world is a different world than theirs.
I see at least two big problems:
1) Developers loading changes up themselves. All changes should come from source control. Do you encounter times where someone made a change that went to production but never got into source control and then was accidentally removed on the next deploy? How much time (money) was spent trying to figure out what went wrong there?
2) Lack of a clear promotion model. It seems like you guys are moving changes between environments rather than "builds". The key distinction is that if two changes work great in UAT because of how they interact, if only one change is promoted to production it could break there. Promoting consistent code - whether by labeling it or by just zipping up the whole web application and promoting the zip file - should cause fewer problems.
I work on the continuous integration and deployment solution, AnthillPro. How we address this with TFS is to retrieve the new code from TFS based on a date-time stamp (of when someone pressed the "Deliver to Stage" button).
This gives you most (all?) the traceability you would have of using tags, without actually having to go around tagging things. The system just records the time stamp, and every push of the code through the testing environments is tied to a known snapshot of code. We also have customers who lay down tags as part of the build process. As the first poster mentioned - CI is a good thing - less work, more traceability.
If you already have TFS, then you are almost there.
The place I'm at was using TFS for source control only. We have a similar setup with Dev/Stage/Prod. I took it upon myself to get a build server installed. Once that was done I added in the ability to auto deploy to dev for one of my projects and told a couple of the other guys about it. Initially the reception was luke warm.
Later I added TFS Deployer to the mix and have it set to auto deploy the good dev build to stage.
During this time the main group of developers were constantly fighting the "Did you get latest before deploying to Stage or Production?" questions; my stuff was working without a hitch. Believe me, management and the other devs noticed.
Now (6 months into it), we have a written rule that you aren't even allowed to use the Publish command in visual studio. EVERYTHING goes through the CI build and deployments. When moving to prod, our production group pulls the appropriate copy off of the build server. I even trained our QA group on how to do web testing and we're slowly integrating automated tests into the whole shebang.
The point of this ramble is that it took awhile. But more importantly it only happened because I was willing to just run with it and show results.
I suggest you do the same. Start using it, then show the benefits to get everyone else on board.