Community
Participate
Working Groups
The font foreground and incoming/outgoing decorations on the scheduled presentation containers are often incorrect, and provide little value. I propose that we suppress them, and instead provide representative icons.
+1 for removing the bogus decorations. In my opinion, this can only be a temporary work-around though. The solution is to fix the underlying problems and provide correct decorations.
Moving to 3.4.1. The final build for 3.4 has already been contributed to the Helios repository.
Created attachment 171649 [details] patch
Created attachment 171650 [details] mylyn/context/zip
Steffen: I think that we need to consider this, because the presentation looks buggy as-is. Try bootsrapping on the patch to see the difference. This is a small UI polish item with pretty much zero risk.
The patch looks fine. But considering that this is not a regression and has been broken for several releases I am not sure that there is a big benefit. I don't remember seeing bug reports or votes from the community that expressed interest in fixing this problem. Process wise we are past the final build and rebuilds now require PMC and PC approval. The consensus on the Mylyn call was that the severity of this bug does warrant a rebuild and hence it is too late to make this change for 3.4. If you strongly disagree you can initiate the exception process and I can provide a new build within a couple of a hours. I have pasted the summary of the process from David William's email below. Please keep in mind that in addition to that the overall cost is 2-3 hours that we need to spent on tagging, building and testing: A. Automatic (aggregation) builds will be turned off after RC4 is done (June 10). B. If a project (and their PMC) really think they have one of those "emergency fixes for very serious regressions" type bugs, they can post a note here to this cross project mailing list. The note should explicitly request a rebuild, explain why its such a bad bug and why its so important to fix before maintenance (and give the bug number, of course). This is mostly to keep everyone informed, and slow everyone down so each change in carefully considered, but also ... C. If the PC Lead (currently me :) thinks it is reasonable, the button will be pushed and a rebuild of the repo will take place. If there's some doubt about if it is reasonable, I will ask for further review from PC and/or the project's PMC.
Given those conditions, I agree that this does not make the cut, and that the process outlined is a good one. I assume that other projects will stick to it, and that this year will be unlike previous years, and that there will not be a post RC4 set of rebuilds for a number of projects requesting changes. Should I commit to HEAD and then close?
Yes, please feel free to commit to head. That will ensure it gets into 3.4.1.
Done.
