Well all things we do in 3.x get merged up from time to time to 3.10-dev and 4.0-dev. So it might just had not happen in the mean time. I can take a look into a up merge in the next days.

I just did the staging -> 3.10 update. Seems that 3.10 to 4.x thing is much bigger and requires more time than i have now. But please be assured that once that happend this feature is also there in 4.x

#31300

I don't understand why this issue is closed. I am beta testing J! 4; I'm not testing J! 3.10 alpha. I'm asking that this matter be allowed to remain an open issue for J! 4, please, regardless of whether any J! 3.x enhancements may possibly be later merged into J! 4. If it's not possible to implement this feature in J! 4 then we can leave it but, until then I think this issue should remain open as a reminder of something that should be put into J! 4.

There is no need to keep it open as a reminder. The reminder is already present in #31300 placed there by @Quy

Thanks, Brian. Basically you're saying that my feedback from beta testing was noted (which is good) and has been added to something that looks quite unrelated (which is puzzling to me) and that these two issues will be looked at in the future (possibly) but you'd rather that we don't keep my feedback on the notice paper and it may be a waste of beta tester's time to provide our feedback from our testing of J! 4.

I understand from @Quy that you'd rather have one GitHub issue to address all of these J! 4 matters than have individual "issues" for each, as we discover them.

I understand that now. Roger, wilco, over and out.

no thats not what was said

No? I'm sorry, I don't understand.

I thought @Quy wanted a GitHub issue item that basically says "All J! 3.x issues, not yet addressed in J! 4, that will be looked into as we go ahead in J! 4" (see #31298)

Not eventually but definitely this is true for all bugs fixed in the 3.x series. I would propose to have one ticket thats than marked as release block and not have one per bug fixdd in 3.x

So, would you kindly explain the reason for closing individual issues as we discover them? It seems counter-intuitive to me that we close individual issues (by tacking them on to some broader milestone "issue"). I'm simply asking what is the best way for beta testers to post their feedback into GitHub.

So, would you kindly explain the reason for closing individual issues as we discover them? It seems counter-intuitive to me that we close individual issues (by tacking them on to some broader milestone "issue").

Yes. The reason it is a one time task to apply all changes made from 3.x to 4.x else we would have to open for every PR merged into 3.x also an issue for 4.x. I'm not sure whether that is something that would help.

I'm simply asking what is the best way for beta testers to post their feedback into GitHub.

I would say exactly like you did here. And than we can take a look into them and fix them.

Thanks, @zero24. It still puzzles me that we should have one "issue" (#31300 addressing several unrelated matters) as a milestone/cognate matter simply because it may be convenient and save the trouble in revisiting each of those unrelated matters down the track. Further, having one cognate matter (wherein individual items may or may not be addressed, or not necessarily addressed at the same time) kind of defeats the purpose of having an issue tracker—that allows individual tracking on the progress of each of those items.

However, if the purpose of GitHub has changed, so that we're simply trying to reduce the number of open issues by collecting those issues into one place, then I have to say that I disagree with this approach. Is that the real purpose: to just reduce the number? In any case, it's not a matter of what I believe; it's not my GitHub and you can manage it how you see fit.

Thanks, @zero24. It still puzzles me that we should have one "issue" (#31300 addressing several unrelated matters) as a milestone/cognate matter simply because it may be convenient and save the trouble in revisiting each of those unrelated matters down the track. Further, having one cognate matter (wherein individual items may or may not be addressed, or not necessarily addressed at the same time) kind of defeats the purpose of having an issue tracker—that allows individual tracking on the progress of each of those items.

They are not unrelated as they have the same reason as 3.x has not been merged yet into 4.x its not an individual issue that needs a patch. ;)

However, if the purpose of GitHub has changed, so that we're simply trying to reduce the number of open issues by collecting those issues into one place, then I have to say that I disagree with this approach. Is that the real purpose: to just reduce the number? In any case, it's not a matter of what I believe; it's not my GitHub and you can manage it how you see fit.

I agree with you here this here is a specific thing as it is realted to the upmerge. ;)

I would say exactly like you did here. And than we can take a look into them and fix them.

It appears to me that, when we beta testers provide our feedback on GitHub, that the developers simply take a look at them and close the issue (or kick the can down the road to some unspecified future time when they may or may not be addressed). Whether these issues are related to one another (as in, everything relates to the internet and we could simply have one item to talk about the internet, I suppose) is a matter of opinion.

I'm saying that, for all the years I've used GitHub, before I create a new issue, I look at all the open issues and search for anything that's still outstanding or not yet addressed. By collecting "related issues" into one big carry-all, it makes things more difficult to search the open issues to find something that may have been discussed before. So, while we may have different opinions about how we use GitHub—and I'm only providing my feedback as a way of helping all people who use GitHub—I think that time-saving measures like "put everything into one basket and let's keep an eye on the basket" defeat the purpose of tracking issues. ?

It is a matter of fact not opinion.

Sorry for not explaining earlier.

Releases from v3.9 and v3.10 will be ported to v4.0 before its release.
See merged PRs #29010 (3.9.17 & 3.9.18), #28335 (3.9.16), #28291 (3.9.15), #28227 (3.9.14)

#31300 is an issue/reminder with a release blocker tag to port the other releases 3.9.19+.

Thus, there is no need to open new issues for issues fixed in 3.9.19+ as they will be ported to v4.0.

I don't want to prolong the agony (or take issue with a useless debate about opinions versus "fact"—wherever that fact is established) but as a matter of housekeeping. If the objective is to reduce the size of the number of outstanding—possible release blockers—then reducing the size (by simply closing each new issue and lumping them together into one issue as a future reminder) is a cleaner's trick that's known by its technical name: sweeping the dirt under the carpet. Eventually the carpet has to be lifted and the accumulated dirt has to be cleared away.

I really don't care how these housekeeping tasks are addressed, whether the house looks clean (because the dirt is allowed to accumulate under the carpet) or whether the house is clean. Cleanliness is a matter of perception. It may help to remind development people that we're not all wired to GitHub and we're not all married to the J! 4 project; we're muddling our way through things. Most gumby "GitHub unaware" folk don't look beyond the confines of the J! forum and would be unaware of what transpires here [on GitHub] ... and that's a fact. If it were not for friendly folk like @brianteeman (whom I hold in high regard even though we have different views on many things) who visit the J! forum, then the common folk who use the forum would be less well informed.

If the objective is to reduce the size of the number of outstanding—possible release blockers—then reducing the size

Well would that solve anything at all? To me not right? So for what reason other than technical as mention above should we do that. Its not that we close all issues and link them to a single one.

Lets try an car example:
You have a car you want to replace it with a new car but want already a new radio. You got the new radio from the shop and installed it into your current car, because it is already there and you want to use it. By the time you replace your car with the new one you want to take that radio out (the same radio) and place it in the new car.
That is also true for the for 10 other different things.
Now you want to keep track of the things to be move to the new car, you have all that stuff already it only need to be moved to the new car.

What we did than was to have one ticket reminding us on all the things we want to move to the new car, we have them already so no need to buy a new one or reinvent something new just take the existing one over.

In our case we can copy our radio and have it in the old and in the new car at the same time but that just works because we have software and not hardware. ;)

There is no intend to hide numbers or do housekeeping it is just to not wast time on us and the developers checking issues and trying to solve issues that are already solve just need to be moved to the new car.

Could that make it a bit more clear for you?

Again, let's look at the overall perception of how the issue tracker is working. In the minutes of the bugsquad teem meeting, it was mentioned that there are 24 release blockers. In the minutes of the previous meeting, it was mentioned that "the most worrying data is relative to the number of the Release Blocker, we have 27 issues and 6 pull requests. We all agree that the maximum priority is to lower the number of Release Blockers, without this it will be difficult to reach the Release Candidate status soon."

So, the number of release blockers [in the context of producing a RC version of J! 4] is important. If one can demonstrate that the number is going down then it creates the impression that the project is moving forward but, if the total number conceals a larger number of unresolved issues then it does not demonstrate that individual matters are being worked through.

To use the car analogy, if a vehicle is still in the design/prototyping phase, then if the car radio is non-compliant or ten other matters are preventing the car moving from design into production phase, then those are matters for the designers. In our case, the "car" (J! 4.0) is not something we can drive out of the showroom because it's not yet finished. We're not talking about replacing something because the customer doesn't like it; we're talking about making the car.

As a beta tester, I'm not expecting a perfect, finished "vehicle"; I'm simply pointing out those things I've discovered in my testing. How we keep track of those things, discretely/individually, is housekeeping. If developers consider that housekeeping is a waste of their time, that says something about the way they keep their house in order, doesn't it?

Again, let's look at the overall perception of how the issue tracker is working. In the minutes of the bugsquad teem meeting, it was mentioned that there are 24 release blockers. In the minutes of the previous meeting, it was mentioned that "the most worrying data is relative to the number of the Release Blocker, we have 27 issues and 6 pull requests. We all agree that the maximum priority is to lower the number of Release Blockers, without this it will be difficult to reach the Release Candidate status soon."

So, the number of release blockers [in the context of producing a RC version of J! 4] is important. If one can demonstrate that the number is going down then it creates the impression that the project is moving forward but, if the total number conceals a larger number of unresolved issues then it does not demonstrate that individual matters are being worked through.

I personlally mention many times with the team that i disagree on the view of just lowering the numbers but we should focus on solving the issues. But it is not on me to discuss what other teams put in the reports. ;-)

To use the car analogy, if a vehicle is still in the design/prototyping phase, then if the car radio is non-compliant or ten other matters are preventing the car moving from design into production phase, then those are matters for the designers. In our case, the "car" (J! 4.0) is not something we can drive out of the showroom because it's not yet finished. We're not talking about replacing something because the customer doesn't like it; we're talking about making the car.

Yes it is not ready for production yet. But you can test drive a car without the radio right? It was not the intention to shutdown your report at any time but in this very specific case group the 'things we need to move between cars' stuff in one issue, nothing else.

As a beta tester, I'm not expecting a perfect, finished "vehicle"; I'm simply pointing out those things I've discovered in my testing.

Yes and we are very greatfull for that. Thanks!

How we keep track of those things, discretely/individually, is housekeeping.

Agree.

If developers consider that housekeeping is a waste of their time, that says something about the way they keep their house in order, doesn't it?

Sorry seems that I got that wrong. I wanted to say that i dont want to waste the time of the developers checking issues. Again the report you made here is totally valid and we still have that on our radar.

Technical this is 'just' one command in the CLI and all of that 3.9->3.10->4.0 issues can be cleared up. The problem is that right now that command, atleast for me, result into a very large number of merge conflicts and we need to find the time to solve them.

For that and only for that reason i suggested to have on ticket that collects all 3.9->3.10->4.0 as they are all solved by the same command.

There are good reasons for classify the issues, especially the "Release Blocker", at the time of writing they are 21.
And more important is to remark that this number is going lower.
That are not impressions, are numbers ie facts, and yes even if slowly we are going forward.
As for the bug squad team, we don't have the power to deal all the 800 and more open issues in one shot, so we need to concentrate our power to try to solve those that are the most important..and NO this is not "sweeping the dirt under the carpet", but to rationalise the low power that we have.