Re: [gnome-flashback] GNOME Flashback maintenance

[Dmitry Shachnev <mitya57 ubuntu com>]

Hi, and thanks for your reply.

On Fri, Feb 21, 2014 at 2:49 PM, Philipp Kaluza <floss ghostroute eu> wrote:
> Hi Alberts, hi Dmitry,
>
> Am 18.02.2014 19:09, schrieb Dmitry Shachnev:
> > On Tue, Feb 18, 2014 at 12:52 AM, Alberts Muktupāvels
> > <alberts muktupavels gmail com> wrote:
> > > Our maintainer/maintainers have not responded here for a long time.
> I asked that some unfinished / unreviewed commits that got pushed to
> master were reverted.
> That never happened, except for the few I reverted myself.
>
> > > I wanted
> > > / I was ready to spend my time to improve gnome-panel, but they are not even
> > > responding to questions.
> The last question from you that I'm aware of showed a complete lack of
> understanding what each branch is targeted at - although I had
> documented that _repeatedly_. Which shows me that you don't even read
> the mails that I write.
>
> It's really hard for me to find the motivation to work on gnome-panel et
> al., when I feel my efforts are sabotaged.

I understand your point. I think "feature branches" are a very good idea.

> > > So now I am not trying to do anything upstream, but when I have time I am
> > > working with forked versions in github.
> > I think it may be a better idea to work in "experimental" branch in
> > official tree (or something like that), so that it the work is more
> > visible to interested developers and downstreams, and so it doesn't
> > look like "yet another GNOME fork".
>
> I think that touches the base of our problem.
> I had asked for help in rescuing lost features from
> gnome-settings-daemon et al, and figuring out how to ship them as part
> of Gnome Flashback. Alberts is the one actually actively coding, but
> only interested in modernizing the code base, getting rid of deprecated
> function usage, and killing GConf.

I think we should develop in both directions (dropping deprecating
libraries and writing missing parts).

> To be blunt: At the moment, I don't see us (the subproject) surviving
> the move to a (still hypothetical) Gtk+ 4, where things like a
> deprecated GtkHBox would actually disappear on us. So this kind of work
> is just not my priority, and we don't have the strength to pull of a
> libpanel-applet ABI bump, much less just for the sake of "just" removing
> a GConf dependency.

Agreed about ABI bump. For example, c96e85f3dfe8eb4f has caused some
problems for me in Ubuntu. Actually, I gave up and did not do
SONAME/packagename bump :P

> Alberts: of course I cannot tell you what to work on. I agree with
> Dmitry, that it would be best if you continue your work upstream, but in
> a feature branch. Create a "feature/remove-foo" or
> "feature/modernize-bar" branch, work there, and ask us to review it,
> when it's ready. And please try for good commit messages, including
> references to bugzilla or relevant mailing list threads.

+1

> > Some of your commits (like "fix gweather crash"), should definitely go
> > into master as well.
>
> So, what will we do with master ? ATM I lean towards skipping 3.10
> entirely, switching everybody to building in a 3.11 environment ASAP,
> and trying to hit the 3.12 release.

Works for me.

> Regarding that particular commit: if it's a crash fix and well-tested,
> we should consider backporting it to the 3.8 branch.

+1

> (The stand-alone) Gnome Panel 3.8 does pretty much what I need it to do,
> but Gnome Flashback as a whole needs much more integration work and
> people interested in stepping up.

In Ubuntu (sorry if you don't like me speaking about Ubuntu, let me
know and I will stop that) we have forked old versions of g-s-d and
g-c-c as a temporary solution for 14.04 LTS, and I am working on
making gnome-panel work with them currently.

After the LTS, if nobody else does the work, I am planning to work on
a keygrabber that will restore layout switching and media keys
functionality.

--
Dmitry Shachnev