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.
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).
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.
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.
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?
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 @ irc.freenode.net
Jabber ID: [EMAIL PROTECTED]
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
