Re: GNOME Feature Proposal: Backup

Hi Michael,

Thanks for all of this. Let me reiterate that I *really* want to see
Deja Dup in 3.2. We just need to figure out how to make it work.

Michael Terry wrote:
> On 12 May 2011 17:05, Allan Day <allanpday gmail com> wrote:
> > I presume you'd be happy for Deja Dup to become a GNOME Control Center
> > panel?
> Depends on what you mean.  I'm happy for Deja Dup to be shown as a
> panel in the control center.  But it sounds like you're asking about
> actually putting it in the control center git tree?  I guess I don't
> see the point.
>  * I'd like to continue to support GTK-but-not-GNOME platforms (why
> not?) even if only as second-class citizens.  So I'll probably add a
> preference dialog that simply wraps the deja-dup control panel for
> such cases.  Having the panel be out-of-trunk makes that unnecessarily
> hard.

It makes it harder, I guess. Whether it is unnecessary depends on your
point of view. ;)

>  * I assume the rest of deja-dup would be a separate module, so now it
> would be split across modules, losing the ability to share
> translations or logic.  I'd have to write a library to share some of
> the logic bits.  So that would be more work.
>  * The only reason to be in tree that I can see is that g-c-c plans to
> drop the API for panels?  But that is a separate thread.

And what a thread it is...

> > If Deja Dup is accepted, we'll need to work together and GNOME
> > contributors (developers, designers, bug reporters and triagers,
> > translators, documentors, etc) will want to contribute to Deja Dup. How
> > will they do that?
> My intent is to achieve high levels of collaboration.

Great to hear! GNOME has a lot to offer; we could achieve great things

>   I have lots of
> ideas about how the GNOME community and LP projects can have tighter
> integration.  I can defend why LP works for me, but that's not
> entirely the point here I feel.
> It could be so easy to collaborate!  We could mirror bzr trunk in git,
> grant permissions to bzr trunk to an automatically sync'd group on LP,
> grant permissions to the translation web UI+trunk to the GNOME
> translation team.
> I could move my mailing list.  I like to think the
> project already works well with GNOME designers (you and I have done a
> review before).  Etc.

Moving the mailing list would be helpful for design collaboration, I
think. I'm kinda happy to follow your current LP list, but other
designers might not be.

> So the big question to GNOME is how much do ya'll want to avoid the
> extra step of such collaboration for Features you consider part of
> your core?  Is that a hard-blocker?  Who gets to decide if it is?
> I'm theoretically open to moving infrastructure, pending a weighing of
> benefits.  But I'm also curious if GNOME is even theoretically open to
> me not moving.

It's the release team who decide in the final instance. (So see Fred and
Olav's messages. :) ) My personal view is that we should be flexible,
provided that we can find a way to effectively work together.

Would you be willing to use GNOME Bugzilla?

> > See my other message on the branding question - this isn't necessarily a
> > problem. I'm just interested to hear your thoughts on how Deja Dup will
> > be branding itself as a standalone application.
> I had envisioned the same way as a non-standalone app.  It would
> appear as "Backup" to the user.  Either as a standalone preference
> dialog or control center panel.  But I've been thinking it needs to
> show its brand name at least once (I currently show it in the welcome
> screen).  That way users know what they are getting.
> Now if your question is really about what that brand is ("GNOME
> Backup" vs "Deja Dup") that's a different issue that I'm just now
> guessing you meant?
> I don't feel strongly on the name presented to users.  I'm open to
> feedback here.  It could maybe even be presented differently if
> deja-dup is a standalone app vs a panel?

Thanks, that's really useful. This is somewhat new territory for GNOME,
so it's nice to know we have the flexibility to work things out.

IRC: aday on

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