Re: [gnome-flashback] What to do about gnome-panel in 3.8 ?

["Jonathan Carter (highvoltage)" <jonathan ubuntu com>]

Hi!

On 23/03/2013 11:58, Dmitry Shachnev wrote:
> On Sat, Mar 23, 2013 at 12:48 PM, Philipp Kaluza<floss ghostroute eu>  wrote:
> > Gnome 3.8 is just around the corner, and we kinda dropped the ball on
> > getting up and running in time. I am partially to blame for this, as I
> > initially didn't push hard enough on the naming discussion, and then had
> > more trouble to get jhbuild into a good place than in earlier cycles -
> > related to trying to get the new code running with my old (wheezy)
> > system-wide ConsoleKit.

Don't be too hard on yourself, I also found that discussion a bit 
motivating at first but I think I'm now over it.

It seems that the session should just be called "Flashback", I suppose 
the mailing list and wiki page names should be changed as well.

> > As it currently stands, I assume the release notes will talk about the
> > deprecation and removal of Fallback mode. If we want to change that
> > message, we should act now. Review https://live.gnome.org/GnomeFlashback
> > , contact the release team about a little shout-out in the release
> > notes, and roll 3.8 tarballs.

*nod*, for the 3.8 timeframe, this was the only thing I was hoping for, 
just to get a release out. Even though it's no longer an official Gnome 
project, I think it's a good idea to line up with the Gnome release 
numbers and release dates and even as manpower can afford, follow the 
same QA processes.

> As gnome-panel is no longer part of official GNOME releases, we can
> build and upload new tarballs whenever we want without breaking any
> freezes (AFAIK).

That is indeed the case. I suggest though that new features be targetted 
for 3.10 since time is running out for the 3.8 timeframe.

> It will be very good to have Gnome Flashback mentioned in the release
> notes, of course.

+

> > Related to the last part: I've been playing a bit further with
> > https://bugzilla.gnome.org/show_bug.cgi?id=694625 . By explicitly
> > mix&matching Gnome components to match with the system components in
> > Debian Wheezy, I've been able to get a session started with the provided
> > patch (only having gnome-session load component "nautilus" instead of
> > "nautilus-classic"). I'd much rather like to test / have somebody test a
> > full jhbuild against a current set of system components. If anybody
> > could test this or point me in the right direction (e.g. "Arch linux
> > release X has current stuff OOTB, just install dev packages a, b and z
> > and jhbuild."), I'd appreciate it. As is, I _could_ see us releasing the
> > patch and declaring the Flashback session definition a "technology
> > preview" or similar, if we have consensus that this communication
> > strategy should lead to more good than bad, and less general
> > misunderstandings, rather than more. Either way, I see us dealing with
> > bugfixes well after 3.8.1, but I think that's worth it.

*nod*, and thanks for all your work on that and the great status update. 
Jeremy poked me earlier in the week to review the patch for the 
namechange as well, but there were too much going on for me at the same 
time at that point.

> While we are at it, I think it'll be a good idea to start the “new
> life” of gnome-panel by incorporating Debian patches [1]. Most of them
> seem applicable upstream, including the recently added
> 18_fix_force_quit_applet.patch. What do you think?
>
> [1]: http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-panel/debian/patches/

None of those seem very distro specific, so it seems that it makes sense 
to do so.

> > (Oh and yes, this would break a ton of gnome freezes, but I guess that's
> > better than not being part of the upstream release at all.)
> >
> > What does everybody think ? Please reply also if you only have a quick
> > answer for one of my questions, as I really think we should get the
> > communication going again ASAP.

I'd like to better keep track of things that break in the Fallback 
session because of larger gnome changes. Both for documentation (like 
release notes, errate, etc) and to help shape a roadmap for the project. 
I suppose using a tag on bug reports would be more convenient than a 
wiki page?


-Jonathan