Re: Proposal to delay release of Precise Pangolin
On Wed, Oct 19, 2011 at 3:15 AM, nick rundy nru...@hotmail.com wrote: Canonical/Ubuntu, please don't feel obligated to release Precise Pangolin in April 2012. A delayed release would strengthen stability and allow more bugs to be fixed in both Unity and GNOME 3.2. Considering the long-lived nature of an LTS release, it would be preferable if Precise Pangolin was delayed a month or two (or more) than for it to be released on time with visible bugs. There are so many bugs that plague Oneiric. Many exist in GNOME 3.2. Perhaps Precise could be delayed a month or two and Ubuntu developers could fix some of the minor bugs plaguing GNOME 3.2? After reading the following posts i wanted to raise the release issue. It seems that staff are under a lot of pressure to deliver the 6 month releases as well as LTS. I've been using Ubuntu for about 5 yrs and it seems that quality varies between releases likely due to the pressure staff are under. Would it not be better for all to produce an annual version that's allowed time for testing and bug fixing. LTS is ok but second year and one is starting to find quite a few apps that have been updated and a six month release simply doesn't give adequate time for staff. If you're wondering what i do... i'm an april updater james -- 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
Re: Proposal to delay release of Precise Pangolin
On 12/13/2011 12:11 AM, James Freer wrote: After reading the following posts i wanted to raise the release issue. It seems that staff are under a lot of pressure to deliver the 6 month releases as well as LTS. I've been using Ubuntu for about 5 yrs and it seems that quality varies between releases likely due to the pressure staff are under. Would it not be better for all to produce an annual version that's allowed time for testing and bug fixing. LTS is ok but second year and one is starting to find quite a few apps that have been updated and a six month release simply doesn't give adequate time for staff. If you're wondering what i do... i'm an april updater A release cycle that's twice as long doesn't really give you more time to test changes, it just gives you twice as many changes to test. And it makes some kinds of changes much more difficult, because they need to be staged over multiple releases for a smooth transition. Here's a good post (short): http://jroller.com/thuss/entry/there_are_pros_and_cons But if you have time, I recommend reading Martin Michlmayr's full Doctoral dissertation. http://www.cyrius.com/publications/michlmayr-phd.html From the conclusion: == In contrast to traditional software development which is feature-driven, the goal of time based release management is to produce high quality releases according to a specific release interval. This dissertation has shown that feature based release management in FOSS projects is often associated with lack of planning, which leads to problems, such as delays and low levels of quality. [...] Time based releases are associated with two factors that act as important coordination mechanisms: 1. Regularity: the production of releases according to a specific interval allows projects to create regular reference points which show contributors what kind of changes other members of the project have made. Regularity also contributes to familiarity with the release process, and it leads to more disciplined processes. 2. Schedules: by using time rather than features as the orientation for a release, planning becomes possible in voluntary projects. Time based projects can create schedules which describes important deadlines and which contains dependency information between different work items and actors. Together, these mechanism reduce the degree of active coordination required in a project. Developers can work on self-assigned work items independently and with the help of the schedule integrate them into the project in time for the release. As such, the time based release strategy is a means of dealing with the complexity found in geographically distributed volunteer projects with hundreds of contributors. == Allison -- 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
Python2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hey guys, how do i know if a python-file is executed by Python2 not Python3? There is a command python3 but none called python2 or am I missing something? greetings, Kai -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO59E9AAoJEKU5B2k1XeME2tkQAJ6R5coQ5TsGjbgXZ8IJto9F 3p6iEHQ+liQ5HF8uww3P9hm6T5dvmfOGlElIurVs7iqYDXoGhjJLl8AWJxvacvUb nsqzSyzJvu7JeGMfxZkyMVv0/dG8MpK2lT+AVb3kDCqUhgpchqq1ndeDjcXBChMX WqJi5+hTyFHmCevVffc6lejzQVi1vFJGSr0IkjPELSqyFHoVVCM/5uwZkbX4lOmT cN4hJPLgmGgtCZYHcN3Zcn43cHvF7fhk9zB2Cmd0ZCYeEep06T8rLrBcpG9SUByd YyRZnrN6ykK5kxG0hUKuN3+fb3LvYPDiYaPIydB78of5Yl3jlxytU/RqgehE4pnk gyziPbaYy8NTB/Ac72ZeGjzi3cSblwVzqJdczoOKk1cQNKwSt4/gKZxfyzTvhbCr H0rJIf9G+DuxEjNk6J+EJyg9ML0LF65B62lUjz3qMK5PuBJ7XvpFCRqJFHHk5iok QJrneBc9u88rBWgXqUEOj2/iPixU+00U9kJHNV+fVuODCmwhJ6X9oJYqz6oAHYkF z13WHYDAlQmfbnVxEr2q+RdZUhtRygIjBPwrpAlcwwL78iQBshQJE+2gciQwO/mG EPwZ7sENlewCwo+y3Z2H+5g6TjVLZqZNpTSxDLlAi1Qou90GXuelLjgS/uN26gr2 sAtxvEsWVVcV2EZH3/H+ =HYbO -END PGP SIGNATURE- -- 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
Re: Python2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Dec 13, 2011, at 11:27 PM, Kai Mast wrote: how do i know if a python-file is executed by Python2 not Python3? There is a command python3 but none called python2 or am I missing something? /usr/bin/python (a.k.a. 'python' at your shell prompt) will always be Python 2. You need to say /usr/bin/python3 or 'python3' to invoke Python 3. This will never change for Ubuntu (or Debian for that matter), unless PEP 394 ends up recommending something different, which I don't expect: http://www.python.org/dev/peps/pep-0394/ You've noticed that there is no 'python2' command, which is expected. How many of y'all remember Python 1.x or even Python 0.x? :) It's possible that PEP 394 will recommend a 'python2' command, but I rather doubt it's worth it since Python 2.x is at the end of its development life (i.e. there will never be a Python 2.8, but Python 2.7 will be maintained for longer than the usual amount of time). One other thing to note. Although you should generally never need it or use it, if your code is tied to a very specific Python version, you always have 'python2.7' and 'python3.2' available. In most cases 'python' and 'python3' is all you need. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO59YcAAoJEBJutWOnSwa/AFQP/RmW6Nl4sioaxltNqEg8bO9i 09v7de7HKkYeHcmqLiEAbetJe4kW3LGbaAYZTlrWCdpDCoZ1UAZDI5CX/WSIIKvS W1LBmmnowOM0t6ifaMnkZCShuREuCDAsuhOIOxvFfq108oVMsoNgrZCgI0UYNfS6 xaCKJ671iDotQp+6XQZ5wgoYedjnvNU3NTUg46fW97E38/1b1Us3lvW1xkKYNjXo Dc1dEN8N4Mc0vRvhT7DYDJhSjWGi9KDZG9o8WSOWYiR66HjlSrvUJB3mEgUtox0X XlsFEEc1vhwsz0oa3F/vZIDrbj01YOkeV0FQg/OaVRmxWl7GF3GzeIsjWaa7HoX1 mBYuh6se7GKW8qZc23dLppNvtPt9AWhOVYDjpXnKDplju8CBza0iXatUVpSpkngG oifhNQvr6HD+HXa1wePYrGxnqRRiYq2V3OqfCu3OlJ6RkuMLOEo9Hz14g/asDKGg jT8O/ZmvDhpxUJlUJIe7zgOK8tGBImZE2hIbFyiHo2tKxEKlUaO/cUf/+FheSQrA NH5MA6YMmOcygm73u57xBfeKJud3FD5hyc6HWFc4vRDWWMARB2sV/KSo114K2P4v wDP3Kl4JuHU32RJWoXS2eBJGXwcgSflrnX0ASvq+VocoktwbyoHBwEOLPpaQFf0c MJQTLA0s7neZOg7EZ8kP =dS1S -END PGP SIGNATURE- -- 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
Re: Proposal to delay release of Precise Pangolin
On Tue, Dec 13, 2011 at 9:20 AM, Allison Randal alli...@canonical.com wrote: On 12/13/2011 12:11 AM, James Freer wrote: After reading the following posts i wanted to raise the release issue. It seems that staff are under a lot of pressure to deliver the 6 month releases as well as LTS. I've been using Ubuntu for about 5 yrs and it seems that quality varies between releases likely due to the pressure staff are under. Would it not be better for all to produce an annual version that's allowed time for testing and bug fixing. LTS is ok but second year and one is starting to find quite a few apps that have been updated and a six month release simply doesn't give adequate time for staff. If you're wondering what i do... i'm an april updater A release cycle that's twice as long doesn't really give you more time to test changes, it just gives you twice as many changes to test. And it makes some kinds of changes much more difficult, because they need to be staged over multiple releases for a smooth transition. Here's a good post (short): http://jroller.com/thuss/entry/there_are_pros_and_cons But if you have time, I recommend reading Martin Michlmayr's full Doctoral dissertation. http://www.cyrius.com/publications/michlmayr-phd.html From the conclusion: == In contrast to traditional software development which is feature-driven, the goal of time based release management is to produce high quality releases according to a specific release interval. This dissertation has shown that feature based release management in FOSS projects is often associated with lack of planning, which leads to problems, such as delays and low levels of quality. [...] Time based releases are associated with two factors that act as important coordination mechanisms: 1. Regularity: the production of releases according to a specific interval allows projects to create regular reference points which show contributors what kind of changes other members of the project have made. Regularity also contributes to familiarity with the release process, and it leads to more disciplined processes. 2. Schedules: by using time rather than features as the orientation for a release, planning becomes possible in voluntary projects. Time based projects can create schedules which describes important deadlines and which contains dependency information between different work items and actors. Together, these mechanism reduce the degree of active coordination required in a project. Developers can work on self-assigned work items independently and with the help of the schedule integrate them into the project in time for the release. As such, the time based release strategy is a means of dealing with the complexity found in geographically distributed volunteer projects with hundreds of contributors. == Allison Allison... WOW I really do appreciate your reply. I didn't fully understand time based releases and should really have done some research... all seemed 'above my head'. I have downloaded Martins' dissertation but it's going to take me a few days to 'read and digest'. thanks james -- 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
