Hello, I am sorry for the LONG mail, but I had no volunteer time this week and this thread is related to my main commitment to the Ubuntu community so I would like to provide my input. <div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Ubuntu developers perform three major activities (and lots of others), specifically packaging available software, patching that software to address reported bugs, and working to integrate that software with the rest of the distribution. If an issue is encountered with a package, it is much preferable to report it to Ubuntu, as it may or may not affect the upstream package (and the Ubuntu developers will forward the report if it does).</blockquote><div> Because Ubuntu developers individually try to resolve the reported bugs of the entire universe(I am referring to problems which are not packaging related) they do contribute to a lot of open source developers, however they also fail to provide to the users a lot of software, fixes and improvements provided by other open source developers. It should be clear that is the result of resources management option, and based on it, the software currently provided on Universe quality is strongly based on the interest of the Ubuntu developers which may not match the user's requirements/impact . If you work on a pure, developers to developers project, this continuously collaboration effort is sufficient, if you care about users also, there is a lot more you need to address, the existing Ubuntu developers man power and processes are not sufficient. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yes, every update to a release goes through a QA process to ensure that it does not cause regressions in behaviour. Packages in each development cycle are tested thorugh a series of Alpha and Beta releases, where the developers attempt to address any discovered outstanding bugs. Further, near the end of a development cycle, and for the life of a supported release, effort is made to not update the software in such a way that might introduce new bugs, specifically meaning that while additional patches are applied to address old bugs, new version are only very rarely imported, to reduce the chance of a new change causing additional bugs. </blockquote><div> The QA effort for development has a major cost from the toolchain changes and other major packaging policy or distro related changes, again upstream related changes will be based on the work previously performed by DDs (merging) or on the current Ubuntu developers interest. Open source has evolved from the initial developers to developers relation to current developers to home users/business, I hope such changes will also be brought to more open source related processes. Some people refer to the inability to fulfill some of the user's requests as a scalability problem. I personally believe that we are still too much developers-centrict without sufficient ability/concern to turn end user's interest into collaboration. About this particular request for GIMP final, let's play the user and not the developer. Let's imagine I am a regular "GIMP User" (which I am not) and I am not a GIMP nor Ubuntu Developer, when I start GIMP on Ubuntu I see a "Release Candidate" message on the splash screen. I do not need to know about development cycles to figure that this is not a final product. Later, I read on some regular software news source that GIMP Final was released, because I am not familiar with the Ubuntu software packaging and policy I have no idea whether there is some nasty bug that is about to blow up on me or not. I found that totally reasonable from an user's perspective. It is not about the numbers, it is not about developers, it is about common sense. Scott Kitterman, You were of the persons that recently described some of the merging/update requests as "denial of service attack", you have a proper reason to request an SRU, according to your known public position on this matter there are are unskilled users that will waste developers and supporters efforts that should be applied into serious problems on several packages that will not be fixed. Daniel, based on your assessment of the changes there are no upstream changes that would technically meet SRU requirements but would worth the backports effort, have you checked the changes ? So far no one was able to provide any details about the changes to identify the specif processes to be used. If the upstream changes provide both SRU and non SRU changes, both SRU and backports should be used. Sebastien, is not the universe security/important bug fixes one of the main reasons to keep with "supported" repositories ? Isn't someone actually tracking the upstream changes to identify such security/QA ? Are this security/important bug fixes provided based on user requests ? Emmet, if you do believe that potentially this change from RC->Final is only with the splash screen logo, which if it's the case would resolve the problem from the user's expectation perspective, why bringing generic theoretical regression concerns without actually checking the changes ? About the lack of control on getdeb, I do not understand your comment, getdeb uses LP for bug tracking and it is open for anyone willing to participate. Christopher, Ubuntu also as an RC stage, you trust on Ubuntu devs ability to provide changes after the RC without introducing regressions, but you do not grant such trust to GIMP Devs? </div></div> This thread is not about GIMP, is about an issue that has been acknowledge already by some people and which keeps popping up. I am sure after Scott there will more requests from random users. I just hope we all together can skip the theoretical/ideological time consuming parts of these threads and get into practical solutions that should present also non developers requirements. Thanks -- João Pinto IRC: Lamego @ <a href="http://irc.freenode.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">irc.freenode.net</a> Jabber ID: <a href="mailto:lamego.pinto@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> lamego.pinto@gmail.com</a>