Closed Tommigun1980 closed 2 years ago
Thanks for the input @tranb3r. Have you also actually checked the issues that are attached to this label?
By opening your link I already see a couple that will definitely not be making it into any upcoming Service Release and depending on some factors these might not be high impact (anymore). So that would mean still go trough all the issues and reevaluate their status.
Conversely, there are also issues that are definitely not marked high impact, like a couple of issues that make Forms apps not-usable with iOS 15, that would be on this list, but they still are on our current radar and fixed with high priority.
Additionally, there is also the labels marked with i/high
(or low, etc.) so the labels might not even mean what you think. Is it high impact because a lot of people are impacted, or is it high impact because there is a big risk at regressions? Also I think there is more to just consider than the impact, like the offset with how much effort is it to fix this issue?
Is this all a great situation to be in or any excuse? Absolutely not, we are to blame ourselves for this administration. But I think it's also not as simple as you're trying to state it here. Let me reiterate that I would love to fix anything and everything and make everyone happy, but that is just not realistic at this point. I'm doing my best here to find a balance between tidying up the issues and see what indeed is actually important and actually getting some work done for a next release.
Reading between the lines I see that you disagree with our approach? What are issues that are important to you that are not on our list right now?
@jfversluis I understand your point of view.
First, you're right, I'm probably wrong assuming that 'high impact' means 'high priority'. Maybe this could be clarified here by making sure all the most used labels have a description.
However, I'm sure you agree that it's unrealistic to think that one can review 3249 open issues. So can you share with us what is the proper query to identify 'high priority' issues ? ('high priority' meaning the ones that need to be reviewed asap, and then either fixed or closed) Also, why is SR4 project still open ? What about SR4 issues that have not been fixed ? Maybe you should clarify how theses projects are managed, because I do not understand what is exactly 'your list'.
We should have clarified under those labels what is meant. I think it's rather useless to do that retroactively. Since there was obviously no clear definition, different people might have used the label differently and thus the results will be no reflection of the truth.
The SR4 board is open because that one dates from before I (re)joined the team and I still wanted to evaluate what is on there and move things over to the current board. In fact, let me make that a priority today and close it, so that won't cause any more confusion.
As stated in this issue: I will create a project board per Service Release, and that is what is "on the list". Besides what was already deemed important in earlier releases, I have added all the issues that are listed in this issue and we have a special focus on Shell and CollectionView as we feel that is what a lot of people are using and running into blockers. In addition, we have a lot of "low hanging fruit" in the form of PRs that are already open, so we're evaluating what we can salvage from that and merge it.
How the projects are managed; I move everything that is not in the Done column to the next project, until, ideally, all columns are empty. The ones that stay in Done, we can see what was done for that SR, the other issues can be understood as: on our list/todo.
Feel free to highlight any issues that might be missing according to you and we'll see what we can do about them. Or, even better, in the spirit of Hacktoberfest, feel free to help out so there is a better chance of getting things fixed that are important to you!
Note: I'm not claiming to have exclusive right to the truth here. I wish it was as simple as filtering the list and just starting from the top, but unfortunately it's not, as hopefully I can make clear with what I'm writing here. I am trying to be as transparent and open as I can because I love to work with (all of) you to make your experience the best we can. I hope you won't conceive it as rejecting any idea that is not mine, that is absolutely not what I'm trying to do ☺️
With just the people assigned to this we're doing the best we can and everything we can (just have a look at all the PRs that Javier has put out in a short time!). Help is more than welcome in any shape or form. Either point out issues that are important to you, issues that are not relevant anymore so I can close them or anything else. I'm hoping to do this together and make our final ride into the Xamarin.Forms sunset the most pleasant one for everyone.
Here is a list of the issues I'd like to be fixed, that are not already in the board: #9839 #14154 #3054 #3855 #11593 Thank you @jfversluis and keep up the good work !!
Awesome, thank you @tranb3r! I'll go through them and see what we can do :)
an issue with interns reviewing issues is that they don't know the product at all, and so will create more churn
There are a bunch of logistics with 3K issues. At the very least, it's grunt work to determine if they include a reproducible case.
Another thing that can help - have someone follow up with the original poster of issues to verify if they have quietly solved the issue and not bothered updating it. The model assumes people are actively monitoring issues but a gentle nudge for folk who haven't been on there might get useful responses - it is the kind of thing you hand over to a Virtual Assistant.
It's all about factoring out the tasks required to do triage and getting as many of them done by others outside the team. Github.
Thanks for listening to us @jfversluis . For me, it just seems that label auto height has been fundamentally broken in Xamarin, even in v5. There are several variations of this problem reported. Not being able to fully see text in one of the most basic controls (a label), has been a bit discouraging to have to explain over the past couple of years.
https://github.com/xamarin/Xamarin.Forms/issues/3754 https://github.com/xamarin/Xamarin.Forms/issues/4950 https://github.com/xamarin/Xamarin.Forms/issues/13683 https://github.com/xamarin/Xamarin.Forms/issues/11270 https://github.com/xamarin/Xamarin.Forms/issues/13448 https://github.com/xamarin/Xamarin.Forms/issues/10077 https://github.com/xamarin/Xamarin.Forms/issues/11713
Hey @somoreingold I can totally understand! I will have a look at those and see what we can do.
Hey everyone! Just to update this thread, another SR has been released with a good number of fixes. We've been making good progress with a good number of fixes that are going in and the monthly releases.
I realize there are still some issues I need to gather from the last few comments here and put them on a board, no worries, I got that on my radar. I'm not sure how much sense it makes to keep this thread going much longer, I hope we've established some form of trusts and you appreciate what we're trying to do here :)
If there is any concern feel free to reach out either publicly for transparency or privately if you prefer that. For now I will leave this open, but I might close it in the near future. If there are any other questions or comments, let me know!
@jfversluis there's been clear progress recently - we're roughly back where we should have been a few months ago (when things were quite stale). I know we're not getting any new exciting things but that's not what we need. We need it to work, and issues addressed :)
I do have a question regarding release plans. How bad would a reported issue have to be to make you consider doing a point release with a single fix for said issue, outside of the current monthly release? for example, this latest service release essentially broke our UWP app - there was a handy workaround provided by the person reporting the issue, but sometimes such workarounds are not possible.
@MitchBomcanhao it has to be pretty bad. I don't see the issue to be honest. If it breaks so bad, why not stay on the last version that worked while we work out the rest of the issues with what you're facing and upgrade whenever everything you're using works fine?
It's not like there is only 1 version available. We're releasing monthly now, the wait shouldn't be too long. The issue you are talking about it fixed, with your help so big thanks for that! And will be available around Nov 10th. I understand that's maybe not what you want to hear, but I also see our point of view where we can't release something new because this 1 bug is fixed. At that rate we would release daily or multiple times a day and I don't think that's what people would prefer as well.
Am I wrong to say that you should then just rollback to the previous version that worked for you, or am I missing something?
@jfversluis we've been waiting for a service release that worked for us, and it has been a while since we've had some new release that didn't introduce some new issue for us. I've had to try various updates and figugre out possible workarounds, and after a while you start wondering "what will it be on the next release".
I'm sure you know that sometimes nasty bugs can be introduced and not found before stuff gets to production, and we might not be able to go back to a previous service release without running into the same issues we've been trying to avoid up until now...
Don't take me wrong, I don't want to sound ungrateful. Things are progressing and we will get there in the end. We're still working towards incorporating xf5 (stuck on 4.8 for a long time) and I can't wait to get my hands on the next SR and have it be "the one".
Gotcha! Just trying to understand your situation here. Sorry to hear you're in this state and like you already mentioned, I'm trying the best I can here to get things moving and get it in a state that works for everyone. I totally understand that you want that rather yesterday than tomorrow. The only thing I can ask, which is a big ask, is to hang on a little longer and work with us like you've already wonderfully done trying out or fixes. If you have the bandwidth to do so, turn those workarounds and bug fixes into something we can incorporate in the code in order to fix things (faster).
The way you put it it's also not going to help if I put releases out faster, or well, you can have faster test cycles, but if the version is still not "the one", what I'm doing then is burdening a lot of people with new updates all the time while I'm not even maybe helping you :)
While typing this, you can have faster cycles, nightly builds are produces each night with the latest changes. If you try those you should be able to adequately determine if the upcoming version is the right one for you?
Maybe if you want to discuss further for possible solutions it's better to take it offline :) not to make this less transparent, I think it's important that people read about our considerations with this, but I feel at this point we might get into your specific situation and how we can make that better which might not be relevant to everyone here.
Is it possible to increase the priority of CarouselView related issues? There are a number of them, but #8640 in particular seems to make it unusable.
Would like to see #9520 get some love, unable to use CollectionViews with DataTemplates that use GridColumns due to this, currently using BindableLayout as a workaround
Thanks for the new suggestions everyone!
Would appreciate if the following could be fixed :)
Also CollectionView related issue that I am having #14522
Regarding CollectionView implementation, there is one more very important feature that is missing: view (or scroll indicator) inset when the keyboard appears. Here is the related issue on the matter: https://github.com/xamarin/Xamarin.Forms/issues/9691 . Should be also implemented for the TableView.
Hey everyone! In case you missed it, we just released Service Release 7 a few days ago. I see the communication is slowing down here and as much as I enjoy being in direct contact with you, I will close this for now so we keep a good overview of things. I hope with all that we've been doing that we have restored a bit of faith on your part that at least things are moving. Probably, in some cases, not as fast as you had hoped, but we'll get there.
I will keep creating project boards for each release so you can see what we're looking at. Feel free to ping me in any issue that you want to bring to my attention and I'll try to get back to you asap. My email is also open and maybe you want to join the Discord server if you want to discuss something.
Again, thank you all so much for your patience and also the collaboration! You have all been very helpful pointing out important issues, verifying fixes and more. Let's keep in touch! <3
Hi.
I can't help but notice that there hasn't really been any commits to Xamarin.Forms for the last few months. I understand that .NET MAUI is being worked on but let's be honest, it won't release for a good while and once it releases it will take at least a year before existing applications can even think about migrating to it. So MAUI is at least two years away for us developers.
Will Xamarin.Forms be updated during these years, or should Xamarin.Forms be deemed end-of-life as of now?
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap says Xamarin.Forms 5 will be supported until November 2022. Is this still the case, or has Xamarin.Forms been abandoned prematurely in favour of .NET MAUI? If so then a realistic scenario is that any live applications, or applications currently in development for Xamarin.Forms, will need to be rewritten with a completely different SDK as developers can't just close shop for a few years. These applications will almost certainly not return to MAUI.
If nothing else, could the existing pull requests be merged? There's a ton of fixes there that people have been waiting for for a long time. Just take a week off from developing MAUI to merge them, or please update the roadmap to reflect that development has fully shifted to MAUI, and that the 2 year support commitment no longer holds.
Thank you so much for informing us on the roadmap and Xamarin.Forms support commitment!