On Mon, Mar 04, 2013 at 03:34:33PM +, Evan Dandrea wrote:
> > "From exceptions to segfaults" is quite a harsh exaggeration.
>
> >> from gi.repository import GdkX11
> >> GdkX11.get_default_xdisplay()
> [1]10593 segmentation fault (core dumped) ipython
That should just be fixed. It should
Dmitrijs Ledkovs [2013-03-04 23:08 +]:
> For me the other caveats are lack of documentation look-ups, one has
> to guess how it would be called in C api and look that up and then
> translate to semi-pythonic dot notation, test the gi call in ipython
> and only then use.
> This is hardly rapid d
Hello Evan,
Evan Dandrea [2013-03-04 15:34 +]:
> > "From exceptions to segfaults" is quite a harsh exaggeration.
>
> >> from gi.repository import GdkX11
> >> GdkX11.get_default_xdisplay()
> [1]10593 segmentation fault (core dumped) ipython
>
> >> import gtk
> >> gtk.gdk.display_get_defa
On 4 March 2013 15:34, Evan Dandrea wrote:
> On Mon, Mar 4, 2013 at 1:16 PM, Martin Pitt wrote:
>> Evan Dandrea [2013-03-04 11:24 +]:
>> "From exceptions to segfaults" is quite a harsh exaggeration.
>
>>> from gi.repository import GdkX11
>>> GdkX11.get_default_xdisplay()
> [1]10593 segmen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13-03-04 07:34 AM, Evan Dandrea wrote:
>> "From exceptions to segfaults" is quite a harsh exaggeration.
>
>>> from gi.repository import GdkX11 GdkX11.get_default_xdisplay()
> [1]10593 segmentation fault (core dumped) ipython
>
>>> import gtk
On Mon, Mar 4, 2013 at 1:16 PM, Martin Pitt wrote:
> Evan Dandrea [2013-03-04 11:24 +]:
>> If we're committed to leaving ourselves the option to change the
>> entire development stack ever year, we won't have very many high
>> quality developers or applications on our platform. Could we not
>>
On Mon, Mar 04, 2013 at 11:26:49AM +, Victor Palau wrote:
> On 28/02/13 23:07, Loïc Minier wrote:
> > I think this would be a valid solution; one thing to keep in mind with
> > this approach that security updates would be built based on some version
> > of the rolling release and so users of ol
Evan Dandrea [2013-03-04 11:24 +]:
> If we're committed to leaving ourselves the option to change the
> entire development stack ever year, we won't have very many high
> quality developers or applications on our platform. Could we not
> instead say, "enough is enough" and commit ourselves to p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/03/13 03:04, Michael Hall wrote:
>
> On 02/28/2013 04:55 PM, Matthew Paul Thomas wrote:
> > That's a worst-case scenario for Ubuntu as a platform. The type of
> > users most likely to install applications, not doing so, because
> > they're usin
On 28/02/13 23:07, Loïc Minier wrote:
> On Thu, Feb 28, 2013, Alex Chiang wrote:
>> If you want to avoid the daily grind, press the close button when
>> update-manager fires. Or set the 'check for updates' frequency to
>> monthly. I think the intended audience for monthly images could
>> handle th
On Sat, Mar 2, 2013 at 9:11 AM, Martin Pitt wrote:
> Loïc Minier [2013-03-01 12:10 +0100]:
>> I don't think we can make any commitment against all of Ubuntu or all of
>> main, but we could pick a subset by product and commit to some level of
>> API and ABI support for this subset.
>
> I still disa
Michael,
am Sun, Mar 03, 2013 at 10:48:21AM -0500 hast du folgendes geschrieben:
> Does Zynga have to provide a different version of their games for each
> different version of Android they support, or does Android give them
> backwards-compatibility so that they can target 2.2 but still run on
>
On Sat, Mar 02, 2013, Martin Pitt wrote:
> Loïc Minier [2013-03-01 12:10 +0100]:
> > I don't think we can make any commitment against all of Ubuntu or all of
> > main, but we could pick a subset by product and commit to some level of
> > API and ABI support for this subset.
>
> I still disagree. A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Hall wrote on 03/03/13 15:48:
> ...
>
> Does Zynga have to provide a different version of their games for
> each different version of Android they support, or does Android
> give them backwards-compatibility so that they can target 2.2 but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Watson wrote on 03/03/13 18:28:
>
> On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
>>
>> I agree, it was one thing when we would keep the same version of
>> a library for 6 months at a time, but with a rolling release you
>> co
On 03/03/2013 01:28 PM, Colin Watson wrote:
> On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
>> I agree, it was one thing when we would keep the same version of a
>> library for 6 months at a time, but with a rolling release you could
>> have one library or another being upgraded to
On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
> I agree, it was one thing when we would keep the same version of a
> library for 6 months at a time, but with a rolling release you could
> have one library or another being upgraded to a new major version
> every week. So unless those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/03/2013 09:18 AM, Matthew Paul Thomas wrote:
> Michael Hall wrote on 01/03/13 16:21:
>
>> On 03/01/2013 12:34 AM, Martin Pitt wrote:
>>>
>>> Michael Hall [2013-02-28 22:04 -0500]:
>> ...
>>>
Personally I don't think "target only LTS rel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Hall wrote on 01/03/13 16:21:
>
> On 03/01/2013 12:34 AM, Martin Pitt wrote:
>>
>> Michael Hall [2013-02-28 22:04 -0500]:
> ...
>>
>>> Personally I don't think "target only LTS releases" is going to
>>> be acceptable to most ISVs, especially
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Langasek wrote on 01/03/13 21:21:
>
> On Fri, Mar 01, 2013 at 10:55:14AM +, Matthew Paul Thomas
> wrote: ...
>
>> As I understand the purpose of monthly snapshots so far, we
>> could achieve the same effect simply by adding a "Display
>> mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Langasek wrote on 01/03/13 21:17:
>
> On Fri, Mar 01, 2013 at 05:40:26PM +, Colin Watson wrote:
>>
The monthly snapshots would be for users who want the fresh
software, but don't want to manage the daily grind of
updating to
Loïc Minier [2013-03-01 12:10 +0100]:
> I don't think we can make any commitment against all of Ubuntu or all of
> main, but we could pick a subset by product and commit to some level of
> API and ABI support for this subset.
I still disagree. A few years ago we heavily promoted quickly+pygtk2
as
On Fri, Mar 01, 2013 at 10:55:14AM +, Matthew Paul Thomas wrote:
> Certainly we don't want people to instinctively dismiss the dialog.
> The recent redesign has aimed at getting consent more often.
> But changing the updates frequency instead is a valid option, because
> Software Sources has
On Fri, Mar 01, 2013 at 05:40:26PM +, Colin Watson wrote:
> > > The monthly snapshots would be for users who want the fresh
> > > software, but don't want to manage the daily grind of updating to
> > > ensure that their system is secure. The way I think of it is that
> > > we "support" 2 ca
On Thu, Feb 28, 2013 at 05:15:38PM -0600, Mario Limonciello wrote:
> What about a rolling static base instead? Do a unionfs (or similar) on top
> of it. Deliver an encompassing image from month to month. Turn off apt as
> a mechanism to deliver updates. But allow it to be turned back on. Even
On Fri, Mar 01, 2013 at 11:13:27AM -0500, Michael Hall wrote:
> On 02/28/2013 11:19 PM, Scott Kitterman wrote:
> > "Rolling" can't both have stable APIs and be the development platform. You
> > need to pick one.
>
> They APIs don't have to be static, they just have to be backwards
> compatible.
On Thu, Feb 28, 2013 at 09:55:31PM +, Matthew Paul Thomas wrote:
> Rick Spencer wrote on 28/02/13 20:41:
> > On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas
> >> I don't understand why you are proposing monthly snapshots at
> >> all. Can you elaborate?
> >
> > The monthly snapshots woul
On 03/01/2013 12:34 AM, Martin Pitt wrote:
> Michael Hall [2013-02-28 22:04 -0500]:
>> This is also something that concerns me in our efforts to make Ubuntu
>> a target platform for app developers. We need to make some commitment
>> to supporting platform APIs during these rolling releases between
On 02/28/2013 11:19 PM, Scott Kitterman wrote:
> On Thursday, February 28, 2013 10:04:19 PM Michael Hall wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 02/28/2013 04:55 PM, Matthew Paul Thomas wrote:
>>> That's a worst-case scenario for Ubuntu as a platform. The type of
>>>
On Fri, 2013-03-01 at 12:10 +0100, Loïc Minier wrote:
> On Fri, Mar 01, 2013, Martin Pitt wrote:
> > I don't think that's feasible with a RR model. We don't even control
> > most of the APIs that are in Ubuntu even.
> >
> > As Matthew Paul Thomas and others pointed out, we primarily want to
> > r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Langasek wrote on 01/03/13 01:44:
>
> On Thu, Feb 28, 2013 at 02:05:35PM -0800, Alex Chiang wrote: ...
>
>> If you want to avoid the daily grind, press the close button
>> when update-manager fires. Or set the 'check for updates'
>> frequency t
On Fri, Mar 01, 2013, Martin Pitt wrote:
> I don't think that's feasible with a RR model. We don't even control
> most of the APIs that are in Ubuntu even.
>
> As Matthew Paul Thomas and others pointed out, we primarily want to
> recommend the LTS releases on the download page and for most users,
On Thu, Feb 28, 2013, Mario Limonciello wrote:
> > I'm not sure how you'd deliver security updates between monthlies
> > though?
> The way I was seeing it, you turn off APT updates from the regular archive,
> but leave them in place for the security archive. In between monthlies you
> fetch securi
hi,
On Do, 2013-02-28 at 17:51 -0800, Steve Langasek wrote:
> On Fri, Mar 01, 2013 at 12:39:58AM +0100, Oliver Grawert wrote:
> > hi,
> > On Do, 2013-02-28 at 20:14 +, Matthew Paul Thomas wrote:
>
> > > So, I'm all in favor of having two-yearly releases. But for the same
> > > reasons as six-m
Michael Hall [2013-02-28 22:04 -0500]:
> This is also something that concerns me in our efforts to make Ubuntu
> a target platform for app developers. We need to make some commitment
> to supporting platform APIs during these rolling releases between LTS
> so developers know what they can expect.
On Thursday, February 28, 2013 10:04:19 PM Michael Hall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 02/28/2013 04:55 PM, Matthew Paul Thomas wrote:
> > That's a worst-case scenario for Ubuntu as a platform. The type of
> > users most likely to install applications, not doing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2013 04:55 PM, Matthew Paul Thomas wrote:
> That's a worst-case scenario for Ubuntu as a platform. The type of
> users most likely to install applications, not doing so, because
> they're using an Ubuntu version that changes too often for
On Fri, Mar 01, 2013 at 12:39:58AM +0100, Oliver Grawert wrote:
> hi,
> On Do, 2013-02-28 at 20:14 +, Matthew Paul Thomas wrote:
> > So, I'm all in favor of having two-yearly releases. But for the same
> > reasons as six-monthly releases are bad, monthly snapshots and/or a
> > rolling release
On Thu, Feb 28, 2013 at 02:05:35PM -0800, Alex Chiang wrote:
> > The monthly snapshots would be for users who want the fresh
> > software, but don't want to manage the daily grind of updating
> > to ensure that their system is secure. The way I think of it is
> > that we "support" 2 cadences for up
On Thu, Feb 28, 2013 at 6:07 PM, Loïc Minier wrote:
> On Thu, Feb 28, 2013, Mario Limonciello wrote:
> > What about a rolling static base instead? Do a unionfs (or similar) on
> top
> > of it. Deliver an encompassing image from month to month. Turn off apt
> as
> > a mechanism to deliver updat
On Thu, Feb 28, 2013, Mario Limonciello wrote:
> What about a rolling static base instead? Do a unionfs (or similar) on top
> of it. Deliver an encompassing image from month to month. Turn off apt as
> a mechanism to deliver updates. But allow it to be turned back on. Even
> if you don't insta
hi,
On Do, 2013-02-28 at 20:14 +, Matthew Paul Thomas wrote:
> So, I'm all in favor of having two-yearly releases. But for the same
> reasons as six-monthly releases are bad, monthly snapshots and/or a
> rolling release would be much worse -- unless we are careful to
> communicate that they ar
On 28 February 2013 23:15, Mario Limonciello wrote:
>
> On Thu, Feb 28, 2013 at 5:07 PM, Loïc Minier wrote:
>>
>> On Thu, Feb 28, 2013, Alex Chiang wrote:
>> > If you want to avoid the daily grind, press the close button when
>> > update-manager fires. Or set the 'check for updates' frequency to
On Thu, Feb 28, 2013 at 5:07 PM, Loïc Minier wrote:
> On Thu, Feb 28, 2013, Alex Chiang wrote:
> > If you want to avoid the daily grind, press the close button when
> > update-manager fires. Or set the 'check for updates' frequency to
> > monthly. I think the intended audience for monthly images
On Thu, Feb 28, 2013, Alex Chiang wrote:
> If you want to avoid the daily grind, press the close button when
> update-manager fires. Or set the 'check for updates' frequency to
> monthly. I think the intended audience for monthly images could
> handle that workflow.
>
> If you want to avoid the ex
Hi,
I am overall +1 for a rolling release for multiple reasons,
mostly for the clarity it gives...
- to downstreams and ISVs (target the LTS for your
products, use 'daily' for your next-gen stuff)
- to folks on the other side of the chasm we're trying to
targe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rick Spencer wrote on 28/02/13 20:41:
> ...
>
> On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas
>
> ...
>> So, I'm all in favor of having two-yearly releases. But for the
>> same reasons as six-monthly releases are bad, monthly snapshots
>> a
Hi mpt,
A lot of points in here. Some follow up thoughts ...
On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE
> fans, and (lesserly) Gnome fans ... and awful f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE
fans, and (lesserly) Gnome fans ... and awful for pretty much everyone
else.
It's awful for first-time users trying to choose a version, for ISVs,
for OEMs and ODMs, for people who
49 matches
Mail list logo
