Re: [draft] Planning for GNOME 3.0
- From: Luis Villa <luis tieguy org>
- To: release-team gnome org
- Subject: Re: [draft] Planning for GNOME 3.0
- Date: Mon, 30 Mar 2009 16:24:40 -0400
On Mon, Mar 30, 2009 at 4:01 PM, Vincent Untz <vuntz gnome org> wrote:
> Nod. I added this (which also takes into account a comment from
> These two ideas can form the basis of an overhauled GNOME user
> experience; they are not the only changes that we can and will do, but
> they definitely are the most advanced projects to help us move forward
> projects are indeed already well underway, with working code and strong
> development going on since nearly six months. This means the effort is
> not about starting those projects, but about first completing them so
> that people can work daily with them, and then polishing them.
>> The answer to 'what if people still want panel' is 'there *will* be an
>> 'enterprise gnome' (aka 2.x) indefinitely' because the almost-certain
>> reality is that the enterprise providers will be be forced to continue
>> to provide panel, etc. May be better to acknowledge this up front.
> Good point. I added:
> However, it's worth noting that distributors using GNOME to build
'distributors and other community members'?
> enterprise products will most certainly help maintain the GNOME 2.x
> shell for quite some time.
Perhaps 'and the project will support that to the greatest reasonable
extent'. Which may well mean 'not at all' but still will calm some
>> It is slightly disappointing to see no talk of 'bringing platform into
>> 21st century'; i.e., easy web access by devs, deep IM/people
>> integration, or jscript. (yay for jscript mostly killing the java/c#
>> discussion! ;)
> Re deep IM/people integration: this is something I wanted quite hard,
> but I've not seen any huge progress in this area for quite some time
> (even if telepathy is nicely evolving). But I'm adding it to the
> list of potential areas:
> - People: the telepathy framework has nicely progressed over the last
> few years and it's offering great perspectives to integrate instant
> messaging, and more generally, interaction with people in other
> applications. With some focus, it could contribute to make GNOME a
> social desktop where you do not only work on documents, but where you
> also really interact with your friends.
> The work that has been done on GObject introspection will also deeply
> change the way GNOME development can be done; we've already started to
> see how it can be leveraged in GNOME Shell, and the fact that it can
>> Almost certainly necessary to say something better than "the mobile
>> team could do something if they want"; maybe the board's mobile group
>> could be contacted about this? I presume gtk 3.0 would have lots of
>> appealing features for them.
> Yeah, I missed the fact that I kept this part as notes. I felt it has to
> be mentioned, but didn't know what exactly to put.
Good to leave it in; will force us to find something more constructive :)
>> Our six-month cycle works because we are making small, incremental
>> changes; while I admire the boldness of thinking such massive changes
>> are possible in a six month cycle, I also think you're crazy. Accept
>> right now that (unless there is massive investment in testing, and
>> probably even not then) this will absolutely not happen on calendar.
> Nod, I understand this and we're probably optimistic because we didn't
> experience too many bad things in the past (you know how young people
> are ;-)).
I vaguely remember what it was like to be young ;)
> That being said, I think having an aggressive schedule is the
> right thing to do. It's also why it's clearly mentioned that things
> might not be ready in time and that we should be ready to accept it.
Yes, I think you're right that it is the right thing to do. But just
don't be surprised when it isn't ready. :)
[relatedly: how does this fall on the enterprise schedules of the
distros? right before? right after? in other words, are they going to
have free cycles to help us with?]
> (now, if most people think this proposed schedule is too crazy, we can
> certainly change this)
I might add some language (perhaps to the section on testing?)
stressing that our time-based releases are also always quality-based
releases- the QA team has always reserved the right to delay releases
that aren't ready. Maybe this will be the first time the QA team has
ever had to use that. ;)
] [Thread Prev