Re: [draft] Planning for GNOME 3.0



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
> Matthias):
>
> 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
> in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
> projects are indeed already well underway, with working code and strong
> development going on since nearly six months. This means the effort is

since^Wfor nearly

> not about starting those projects, but about first completing them so
> that people can work daily with them, and then polishing them.

Like it.

>> 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
people.

>> 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.
>
> Re javascript (and introspection comment from Matthias), I added:
>
> 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
> bring new popular languages like Javascript to GNOME is a huge benefit.

Reasonable.

>> 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. ;)

Luis


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]