What does it mean the phrase "You can have up to 10000 work items on a backlog" taken from this link
https://learn.microsoft.com/en-us/azure/devops/user-guide/service-limits?view=azure-devops#work-items ?
I'm using TFS 2017 update 1 on premises (I'll upgrade to Dev Ops Server 2019 update 1 asap) in a very large project with hundreds of users and after two years we collected more than 10000 work items in a single Team Project (10661 to be precise). I hope that I will able to add new work item in the future without limits in the same Team Project (I think it's reasonable to have a limit like 500000 or 1 million of work items but no with only 10000 work items). I'm afraid that I'll see an error message like "TFSXXXX: max number of work items reached".
I repeat: What does it mean the phrase "You can have up to 10000 work items on a backlog" taken from the above link?
First of all, the link you mentioned is about Azure devops Service, not TFS. To see the restrictions on TFS, you need to switch to TFS2017 version in the upper left.
Secondly, the limitation mentioned in the document is about the maximum number of work items that can be displayed in the backlog, instead of a limit on the number of work items.
Each backlog can display up to 999 work items. If your backlog exceeds
this limit, then you may want to consider adding a team and moving
some of the work items to the other team's backlog.
Regarding the limit of the number of work items, because the id of work items are increasing on a collection level, there is no limit to the increase of unique id, so the number of work items is also unlimited. You can refer to this case with similar issue.
Related
i have a project on Google Cloud Platform, using the Youtube Data V3 API. Everything was going well, earlier this month after receiving several emails alerting that I had to do an Audit, the queries for the day stopped completely. they were completely zeroed.
I followed the link to perform the Audit, and i successfully completed all the changes that were told to me in my application, strictly following the regulations. The audit went well. No further changes were required from me.
But the issue is that the queries per day remain at zero. I can't edit. It occurred to me that maybe using the Google Cloud Trial there could be some change. Negative. I'm still unable to increase the limits, not even using the balance they give you as a gift.
The project used approximately a margin of about 25,000 to 300,000 queries / day. I have requested 500.000 queries / day filling in the quota expansion form to have a little more margin.
Meanwhile the project has been stopped for almost a month. If anyone knows something or how I should proceed about it,
Thank you very much.
Have a nice day,
I am currently in the process of developing an application that essentially offers multiple conferences/rooms to each user at once.
In other words, an individual user can be in as many rooms as they would like at any one time...
However, whilst this currently works for 10/11 (it varies) rooms, as soon as the user attempts to join more rooms, it fails.
Originally I thought this was as a result of the front-end iOS, but having now tested 10+ rooms with InstantBird (MacOS XMPP Client), I can confirm that the issue seems to be at the ejabberd end...
Thus far, I have been unable to extract any sort of error message returned. I have checked the logs and everything seems fine (I may be missing something as I am not really sure what to look for).
I have a couple of ideas as to what it might be but I don't really know where to start:
Does Ejabberd limit the number of rooms a user can join at any one time?
Does Ejabberd have a timeout that may be exceeded when trying to join multiple rooms (this would explain why it varies between 10 and 12 rooms max)?
Your answer is here:
https://docs.ejabberd.im/admin/guide/configuration/#modmuc
There is a config property
max_user_conferences
and as documentation tells us:
This option defines the maximum number of rooms that any given user can join. The default value is 10. This option is used to prevent possible abuses. Note that this is a soft limit: some users can sometimes join more conferences in cluster configurations.
I'm pretty new to managing sprint cycles in TFS, although I've used it before for development. I have used JIRA for sprint planning/development in the past.
I have built out a product backlog and have about a dozen stories / items showing up under by 'backlog items.' I've taken a few and moved them into our first sprint.. so now the iteration path shows as "product name"\release1\sprint1. When I look at Sprint 1 I see only the stories and tasks that I've pulled into this sprint... just like I would expect. BUT - I still see these same stories showing up in my backlog, even through the iteration path (hope I'm using that term correctly) shows as belonging in Sprint1. I would expect that as you pull stories into a sprint, they leave the backlog. I don't want to see stories that are being worked on in the current sprint in my backlog, as that will be confusing when we go to prioritize backlog items for the next sprint.
Did I mess something up? Am I missing something obvious?
Thanks!
You didn't mess it up. The functionality to optionaly filter those items from the backlog is part of Update 3 of TFS 2013 (http://blogs.msdn.com/b/bharry/archive/2014/07/02/vs-tfs-2013-3-update-3-rc.aspx). Till that time they are/stay visible.
I have started using TFS Integration Tools to migrate work items from one TFS2010 project to another team project within the same collection. After some small trial runs and modifications to the field and value mappings I started a migration on our entire product backlog. Approximately 170000 change groups were discovered and analyse started. However, during the analysis the connection to the TFS server was lost so the migration had to be restarted. After the restart approx 340000 change groups were identified (roughly double) without any significant changes being made to work items in the backlog.
Has anyone experienced a similar problem or are aware of settings or changes that can be made in the tool to limit this increase in change groups? The amount of time taken to analyse so many groups is causing the migration to take much longer that was initially expected.
After several runs, I found out that the count appears to be a running total so logically enough when I experienced a break in connection all change groups had to be re-analysed causing the "doubling" in change groups.
Is there a way in JIRA to run a report to see how many issues were "resolved" by what users and how quickly since the issue was reported? It needs to be per user
Thanks
You can build arbitrary reports yourself with a Report Plugin Module, but my experience is that it's quite a hassle. Note that plugins will only work in self-hosted Jira installations, not in Atlassians hosted service.
Another way would be to leverage the REST API in order to fetch worklogs and process them externally.
Your requirement needs some clarifications I think. It seems you want to see the number of issues that were moved from some status to another status, or perhaps the last time the resolution field was set to a value (any value?). Then group those results by JIRA user.
A second requirement is to track the time from issue creation to the last time the resolution field was set. Again grouping by user.
I'd try using the Vertygo SLA plugin from Valiantsys to do this. It lets you define custom fields to track the time between two JIRA events such as a field updated or a status changed. I believe it can sum those fields and display grouped results in the JIRA statistics and two-dimensional gadgets.
Reports that group by user often become quite large as the number of users increases.