Bugzilla – Full Text Bug Listing
| Summary: | Consider i18n patches against maintenance branches | ||
|---|---|---|---|
| Product: | Community | Reporter: | Sean Flanigan <sflaniga> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antoine, daniel_megert, mober.at+eclipse, overholt |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Sean Flanigan
I don't really see the problem, or at least I'm not sure how the AC could help: For Ganymede, it looks like the train has left. I doubt we can pursuade projects into accepting patches now (after SR2 is pretty much completed). For Galileo, given that i18n is a requirement for the release, I cannot see why i18n patches wouldn't be accepted for maintenance as well. For non-train-projects I cannot see how we could force them into accepting i18n changes. Could you explain a bit more? - Keep in mind that the AC's responsibility is the Community as a whole, see http://wiki.eclipse.org/Architecture_Council whereas whatever you'd want to see in the Release Train (read: differentiates Release Train Projects from other projects) is under the custody of the Planning Council. (In reply to comment #1) > I don't really see the problem, or at least I'm not sure how the AC could help: > > For Ganymede, it looks like the train has left. I doubt we can pursuade > projects into accepting patches now (after SR2 is pretty much completed). Hmm. I had hoped there was some possibility of getting more complete i18n into Ganymede's maintenance cycle. I didn't realise that Ganymede is virtually finished with, since Galileo is still some months away. > For Galileo, given that i18n is a requirement for the release, I cannot see why > i18n patches wouldn't be accepted for maintenance as well. > > For non-train-projects I cannot see how we could force them into accepting i18n > changes. Well, encouragement is more what I had in mind! > Could you explain a bit more? - Keep in mind that the AC's responsibility is > the Community as a whole, see http://wiki.eclipse.org/Architecture_Council > whereas whatever you'd want to see in the Release Train (read: differentiates > Release Train Projects from other projects) is under the custody of the > Planning Council. Well, I am mainly concerned about the projects in the release train, but I had hoped the Architecture Council would raise awareness of i18n issues generally for all Eclipse projects. I'm not sure there's much more to explain. I just don't like to see i18n patches go to waste, whether it's my work or someone else's. I knew it would be difficult to get anywhere with the maintenance branch, but I hope you're right about Galileo. Thank you for the reply. (In reply to comment #2) > (In reply to comment #1) > I had > hoped the Architecture Council would raise awareness of i18n issues generally > for all Eclipse projects. I've added an item to the next AC meeting agenda. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Externalizing strings is no longer a must-do, but part of https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements/Appendix#Required_for_good_adoption And of course patches for externalizing strings should be accepted by projects. |