Re: Building nightly flatpak apps in the CI
On Wed, Sep 18, 2019, at 16:05, Michael Catanzaro wrote: > On Wed, Sep 18, 2019 at 8:05 pm, Abderrahim Kitouni > wrote: > > Some apps use Devel as a suffix to the app-id, some separating it > > with a dot, and some not. > > The dot is pretty important IMO, because without it the app ID just > looks silly. Compare: > > org.gnome.EpiphanyDevel > > vs. > > org.gnome.Epiphany.Devel Aesthetics aside, I would make the case for not using a dot. Your normal build and your nightly build are two separate entities. That is, your nightly build isn’t a sub-component of your normal build (in my mind). For example (and please correct me if I’m wrong), a flatpak sandbox will let you claim any DBus name that is a dot-name underneath your APP_ID. It feels weird to me that a normal flatpak could intrude on the bus namespace of its nightly build (not that it would, but still).___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Managing Google API key secrets
There was a previous thread about how GOA's keys are only intended for GNOME-core apps and that third party apps should use their own keys. But there was also some uncertainty around how to do that for Google, since Google's TOS requires that you not commit key secrets to an open git. Here's a solution that worked for me. Hopefully it will be useful for third party app developers looking to migrate away from GOA and maybe could even let GOA stop having a public secret key. tl;dr; Register and use an iOS client key, which allows for a login flow that doesn't need a secret key. The main problem is: you need an API secret to log in, but Google won't let you commit that secret anywhere public. So what's an open source app supposed to do? Well, Google admits that installed apps can't keep a secret. So they allow mobile apps to use an alternative login flow that does not require a secret. Though for some reason, the "Other" key type for installed apps (vs "Android" or "iOS") does *not* allow that flow. But unfortunately, "Other" is exactly the key type that a GNOME developer would naturally use. But if you *do* register as a mobile app, Google will let you do a "Proof Key for Code Exchange" (PKCE pronounced pixy) which is just basically giving Google an arbitrary string that you create at runtime and then include in all your requests. And you need to run a localhost http server on an arbitraty port, to accept the access token from Google. If you do all this, Google won't require a client secret, just a client id, which _can_ be public. Now, none of this prevents someone from stealing your client id and masquerading as your app... But :shrug: at least you're following TOS. And that's the same risk any mobile app is currently taking. When you register an iOS key, they'll ask for an application ID - but you can just give it your appid like org.gnome.XXX - they don't confirm that it's registered with the iOS store or anything. Registering as a mobile app _is_ a lie, but a white one. I feel like it's following the spirit of the law, at least. Here's documentation from Google about this flow and how to use it: https://developers.google.com/identity/protocols/OAuth2InstalledApp Another interesting tidbit from that page is that Google prefers that you send the user to the system browser for the consent screen, rather than loading it in-app in a GtkWebKit frame or whatever (presumably so that the user knows they're actually on a Google page and the app isn't phishing them for their Google password).___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarifications regarding GNOME Online Accounts
Thank you for the clarification! As someone that had been confused about the intent and ended up relying on GOA in my third party app, it’s nice to see the intention spelled out so clearly. I just wanted to mention an interesting challenge in having open source apps handle this themselves. Let’s take Google as an example. According to their developer terms of service [1]: “Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.” So in order for an open source project to access Google APIs, it would want build secrets. An interesting argument for flatpaks and snaps, where you could have those (as long as you don’t use a public builder). Unfortunately, distros do not typically support build secrets. I’m not sure what to do in those cases. (And if a distro did support them, would they use their own API keys or act as a trusted handler for maintainers’ keys?) GOA currently just embeds the API secret anyway, presumably because the realistic alternative is just not supporting Google. For my part, I’m not sure what to do. Short term, I’ll probably just keep coasting on GOA’s loose approach. [1] https://developers.google.com/terms/___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019, at 16:16, Debarshi Ray wrote: > "maintain GNOME's Google support" is bit misleading here. I'll try to > explain. > > "GNOME's Google support" is libgdata and the GNOME API key. Using > libgdata is independent of using GOA, and that's where the > overwhelming bulk of effort goes - keeping up with API changes and so > on. As for the API key, we often have a hard time because we don't > fall into one of the big buckets called: web application, iOS app, > Android app, etc.. Since the Linux desktop is such a small portion of > the user base, we always run into weird rough edges that don't affect > the more popular platforms that much. > > The one genuine case where you might have to do some work is when a > bug in Deja Dup adversely affects the GNOME API key. Say, for example, > if there's a bug in the code that DoSes the Google servers or causes > data loss or something catastrophic like that. > > But other than that I don't know what "maintain GNOME's Google > support" would mean. I meant (1) keeping GNOME's API key valid, (2) maintaining libgdata, (3) maintaining the GVFS google backend (which only supports using GOA keys -- an app can't give it its own keys), and (4) maintaining the GOA google backend. If GNOME lets their API key be revoked, all of the above will be dropped on the floor. Libgdata might live on independently, but GNOME wouldn't have a reason to put it into releases any more. You say deja-dup has nothing to worry about. But I very much have to solve the problem of many of my users losing access to their backups (through my app at least) in three weeks. Will not inspire confidence. Again, my fault I guess for using GOA in the first place. (I assume you meant that deja-dup doesn't have much to worry about in the main context of this thread about Documents support etc being dropped from GNOME. And you're correct there. But Michael's comment about GNOME losing it's Google key in three weeks does have me spooked.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, Jan 23, 2019, at 21:39, Michael Gratton wrote: > If GOA Mail is going to be removed from Fedora can there at least be a > method to programatically determine what is supported and what isn't, > so Geary can avoid launching the control center when people want to add > an account on Fedora? A minor technical side note here. You actually might be able to programatically determine that: libgoa-backend will tell you what providers exist and what features they support. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Sun, Jan 27, 2019, at 11:14, mcatanz...@gnome.org wrote: > Err... well this seems like as good a time as any to mention it: Philip > and I both noticed emails from Google warning that they'll shut us down > unless we do a huge amount of work in a very short amount of time. > Neither of us plan to work on this. My only use of the Google > integration is for Safe Browsing, which doesn't use > gnome-online-accounts at all and which I'm just hoping won't be > affected. > > If anyone wants to help, see > https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three > weeks left. Ooof. A while back I excitedly integrated GOA support for Google Drive into the deja-dup backup program, using the gvfs backend to handle the actual file access. I totally understand the difficulty GNOME is in here, and I'm not expecting you folks to do work that you don't have the time for. I don't have the time to maintain GNOME's Google support either, so no shade thrown by me. But it sure is a bummer. And a lesson to me about relying on GNOME's platform. So it seems that for apps like mine which had supported Google accounts through GOA, the next steps would be to register their own OAuth developer account with Google and write their own custom access backend to replace the generic gvfs one? Ideally within the next three weeks and then backporting the change for all existing stable releases in the wild before users hit errors from the GNOME key being revoked. I understand the party line in this thread to be that I should have already been doing that and never should have used GNOME's code in the first place. Fair enough. I misunderstood GNOME's stance on that. Maybe libgoa should have you define -DGOA_API_YES_I_AM_A_CORE_GNOME_APP to help prevent this misunderstanding in the future. Well, thank you to the folks that did work on Google integration. I appreciate it, and the feature was good while it lasted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GUI automation framework
Does GNOME have a currently recommended automation framework for tests? I know dogtail, ldtp, and such were used in past. But I haven’t seen much talk in recent years about this part of the stack nor was I able to find any recent wiki pages about it. Is dogtail still the state of the art? Thanks in advance. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Saving App State
I wanted to start a discussion about how GNOME and friends use saved state. Currently, applications tend to stuff bits of saved state (like window position, which tabs are open, etc.) in gsettings, because it is convenient. But that puts the state in ~/.config instead of ~/.cache and I believe is discouraged for other reasons(?). Regardless, gsettings is a nice API for storing the same kind of data that state-saving would use. Is a similar API for state on any roadmaps? If we were able to funnel all state-saving through the same API and into the same store, we could potentially do some neat things with it like syncing the state between devices. And along with a single API, we could provide some guidelines (like maybe instead of having every app save its x,y position, just let the shell save that state). This isn't necessarily a call for full session saving again. But at least letting what applications are already doing, do it in a recommended way. (Though regarding session saving, apparently Mac OS Lion recently added Resume which is basically desktop-wide saved state.) -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 28/01/12 12:54, Colin Walters wrote: Anyways I don't think we're in violent disagreement here, and what I want to focus on is concrete actions. Vincent, Michael, Milan, as the people who actually contributed code here - are you guys OK with the DBus backend work and/or future plans to use systemd? Sure, it's fine. It means extra work for Ubuntu next cycle, but as has already been discussed, we have time to plan for it. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
I maintain the GNOMEish app deja-dup. I also would like it if GNOME supported apps that want to stay on a stable compiler during the cycle. I use the following macro in acinclude.m4 to allow specifying a specific valac-X.XX version with a friendly fallback to valac. In configure.ac: DD_PROG_VALAC([0.14.0], [valac-0.14 valac]) In acinclude.m4: AC_DEFUN([DD_PROG_VALAC], [AC_PATH_PROGS([VALAC], [$2], []) AS_IF([test -z $VALAC], [AC_MSG_ERROR([No Vala compiler found.])], [AS_IF([test -n $1], [AC_MSG_CHECKING([$VALAC is at least version $1]) am__vala_version=`$VALAC --version | sed 's/Vala *//'` AS_VERSION_COMPARE([$1], [$am__vala_version], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]) AC_MSG_ERROR([Vala $1 not found.])])])]) ]) -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 18 May 2011 13:21, Michael Terry m...@mterry.name wrote: 2) I'll move my mailing list to GNOME. That seems rather painless and seems to make it easier for GNOME people. It's super low traffic, so doesn't really matter. But I encourage people to make it high traffic. Just an overdue update that this happened! Subscribe away: https://mail.gnome.org/mailman/listinfo/deja-dup-list -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 19 May 2011 04:45, Allan Day allanp...@gmail.com wrote: These changes seem like good ones. Heh, well of course you think so. :) Though, I've gotten bad feedback about the feasibility of a round-trip bzr-git-bzr conversion. I may start small with just a git mirror. But moving bugs out of LP is a step too far for me. As would be carving up pieces of Deja Dup into other modules (like gnome-control-center). So I'll just keep chugging along as a separate app for now. But hopefully these changes will let the GNOME community become more involved if ya'll desire. As I've said previously, it would be great to have an integrated GNOME backup feature, and it would be cool to work together on this. The two issues you mention above seem to be blocking us though. Regarding bug tracking: I was waiting to hear some arguments about how Deja Dup could continue to use LP bug tracking and be a core GNOME module... if you do think that is possible, do make the case! Of course I think it's possible, but Olav made it clear that the issue was settled law. Assuming it's not, I see at least a couple options: A) GNOME devs could deal with it and realize that one more web account won't kill them. The ability to search and reassign bugs to deja-dup from within b.g.o don't seem like killer features to me. It must be an issue now with external dependencies and you live with it. B) We could have a deja-dup module in b.g.o as well as the canonical one in LP. LP has this cool feature to synchronize comments and such between a bug in LP and a bug elsewhere. It's turned off for b.g.o, but it may be possible that it could be turned on per-module. I'd have to look into it. Likewise, let's be clear about what's in the way of keeping Deja Dup as a single module: would whitelisting gcc panels solve that issue? Yes, as I've said in the g-c-c thread. Though the idea didn't get any traction. But again, not being Core isn't the end of the world. I'm content to remain a well-integrated (potentially-Featured) external app while doing what I can to reduce the barriers to collaboration with GNOME developers, designers, etc. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 19 May 2011 09:19, Lennart Poettering mzta...@0pointer.de wrote: (also, all big distributions but one have announced their plans to switch to systemd by now) Hopefully it's easy to see how such comments (and the way it's phrased -- that one distro has a name!) dovetail with the concerns elsewhere in this thread about GNOME and Ubuntu. So what are the criteria for deciding which platforms to drop from GNOME's scope? This thread is making it sound like the release team is OK with criteria like whichever platforms systemd doesn't run on, which would certainly seem to put Ubuntu next in line for the axe. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 19 May 2011 10:32, Bastien Nocera had...@hadess.net wrote: So what are the criteria for deciding which platforms to drop from GNOME's scope? This thread is making it sound like the release team is OK with criteria like whichever platforms systemd doesn't run on, which would certainly seem to put Ubuntu next in line for the axe. I think you need to look at the thread again. That was never mentioned, and we even mentioned ways for distributions that don't use systemd as the init system to ship the D-Bus mechanisms. True. I guess I'm really just interested in an official answer to What are the criteria for deciding which platforms are within GNOME's scope? That's obviously an iffy thing when talking about new modules, because sometimes innovation happens in one place and other platforms get forced to play catchup, which isn't strictly ruling out support. Though some things you know can be ported easily, others you know can't be. Without some formal guidance here, I worry about a slippery slope. And it sounds like the GNOME OS concept changed some minds about what that guidance should be. Olav mentioned the Linux-only issue being on the agenda for the next Foundation meeting. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 19 May 2011 09:22, Michael Terry m...@mterry.name wrote: LP has this cool feature to synchronize comments and such between a bug in LP and a bug elsewhere. It's turned off for b.g.o, but it may be possible that it could be turned on per-module. I'd have to look into it. Not possible right now. :( I filed a bug with the Launchpad project about it: https://launchpad.net/bugs/785173 -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 19 May 2011 11:17, Jason D. Clinton m...@jasonclinton.com wrote: On Thu, May 19, 2011 at 10:02, Michael Terry m...@mterry.name wrote: True. I guess I'm really just interested in an official answer to What are the criteria for deciding which platforms are within GNOME's scope? Those for which people whom want them to work show up and do the integration work needed, as it's always been. I don't see anything in this thread that indicates that we're changing this position, at all. Come, there's more nuance than that. Say I proposed an awesome app store Feature for GNOME, but it happened to require some new package format I'd invented, I gather GNOME wouldn't just assume that all platforms should switch to my new format. There must be some maximum threshold of work that is forced upon platforms in the form of keeping up with GNOME. I'm curious where the release team thinks that threshold lies. And presumably it considers user base and/or developer base in how much work it is asking others to do? i.e. requiring some HURD feature and asking Linux devs to adapt would probably be a harder sell than the reverse? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
It seems discussion died down around this, which means the status quo of just a GNOME external app will prevail. But I'm going to go ahead and take some steps to increase potential cooperation between Deja Dup and GNOME, for those that are interested: 1) I'll try to stay more on top of the jhbuild moduleset. It got bit-rotten as Colin pointed out, but now it's up to date. 2) I'll move my mailing list to GNOME. That seems rather painless and seems to make it easier for GNOME people. It's super low traffic, so doesn't really matter. But I encourage people to make it high traffic. 3) I'll experiment with moving my trunk to GNOME git. This will let GNOME people more easily dip their toes in the Deja Dup waters. Ideally this will be as low-cost an experiment for me as possible, so I'm curious about other people having done similar conversions. I'll keep a bzr mirror in LP for existing developers. But could I move back to bzr and not lose anything? i.e. would a round-trip (bzr-git-bzr) imply some metadata loss? And also, does being in git imply that the translation team would automatically consider the module? But moving bugs out of LP is a step too far for me. As would be carving up pieces of Deja Dup into other modules (like gnome-control-center). So I'll just keep chugging along as a separate app for now. But hopefully these changes will let the GNOME community become more involved if ya'll desire. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 14 May 2011 00:32, Michael Terry m...@mterry.name wrote: Hrm. I do have a need to clean up the jhbuild sets. I also know that older modulesets should be pointing at the branches of DD, not trunk. I will fix that soon. Just FYI, I fixed up the modulesets. Now librsync is built for duplicity, DD has the correct gtk3-oriented dependencies, and DD points at the appropriate versioned branches for each moduleset. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
In a UDS session this week about this control center issue, one discussed idea was a hard-coded (in source) whitelist or brightlist. To be clear, a brightlist would be a set of plugins that appear at the top as part of the OS and there's some other section where everything else goes. A whitelist would instead just stop anything else from appearing. This way, GNOME designers can enforce a set of plugins that only they want for their OS. Since it's in-source, it would be difficult for random third parties to work around it. But at the same time, other distros that also believe themselves to be creating an OS can distro-patch the list and have the experience they want. Everyone wins, with exceedingly little technical effort. What do the g-c-c maintainers feel about that? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 12 May 2011 17:05, Allan Day allanp...@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. * 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. 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. 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. 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. 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? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]
On 13 May 2011 10:31, Olav Vitters o...@vitters.nl wrote: So your suggestion is to still have new panels? Depending on whether you wanted to allow 3rd party panels, you could use a brightlist or a whitelist. But yes, a public API coupled with a whitelist to allow only design-approved external modules. It seems there is an assumption that no external API is meant to force; it is not. The purpose is to ensure that the control center options follows a logic (designed) structure; not have options all over the place. If you want additional option in Ubuntu, address this to either the Ubuntu design team or the GNOME design team. Then the options should be added whereever the design teams thinks it should go. Right. And this proposal was designed to allow each design team to decide their own OS's experience easily by patching the whitelist. The plan to drop the API adds a larger technical barrier that appears artificial. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 11:53, Gendre Sebastien ko...@romandie.com wrote: I'm agree with Luca: It would be better if split Déjà Dup with Gnome Backup. Also, we can have: - Gnome Backup as a G-C-C panel for Gnome Desktop. - Déjà Dup as a GTK+ Application for non-Gnome Desktop, ex for XFCE. One minor point about this: Deja Dup is GPL-3+. G-C-C is GPL-2+. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 12:28, Allan Day allanp...@gmail.com wrote: Would you be willing to use GNOME Bugzilla? That specifically would be the hardest part of an infrastructure move. Some important downstreams (Ubuntu and flavors) and my sister project Duplicity are all in LP. So it's very easy to share bugs and triaging work there. Plus since I'm an Ubuntu developer in my day job, it's my normal workflow. So there's good technical collaboration reasons why I value LP for bugs as well as the more squishy comfort reason. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 13:01, Allan Day allanp...@gmail.com wrote: There are good reasons for wanting to have Deja Dup on GNOME Bugzilla, I think. I can imagine myself wanting to CC other GNOME contributors on Deja Dup bugs. I can also imagine bugs being punted between Deja Dup and other GNOME modules. Plus there's the whole release planning and GNOME QA effort to consider. Don't forget that there's a high chance that people will fix Deja Dup bugs for you if you're on GNOME Bugzilla. :) (Note that I write here with love and without heat. I'm a GNOME developer and user and I want the world to be a better place.) I guess I was hoping more for collaboration than assimilation. :) Note that I am willing to, over time, train a new maintainer from within GNOME who could take over the project while I continue to contribute (which is more fun than maintaining). But I suspect there wouldn't be takers. If there would be, GNOME would likely already have a backup story or I would already see existing GNOME contributors to DD. You could call this the if you had invented Facebook you would be Facebook argument. I would also freely consult on how to fork part of DD or how to write a new backup program if GNOME really wanted to. Point is, I am largely just interested in the world not senselessly losing data (arguably the most preventable common point of pain with computers) regardless of who does it. So while I'm so willing to collaborate in that way, if I'm doing the work, I'd like to use the tools that make sense to me. Especially since I think it's so easy to collaborate between our tools. Granted, it's a bit harder than you'd ideally like. But I'm willing to meet you halfway (mailing list, mirrors, etc). Secondly, DD is already an app that has the stamp of approval for being featured in GNOME marketing last I checked. So GNOME can today talk about it's amazing backup story. So what does being a core module/Feature really buy here? (I mean, benefits above and beyond the goodness of being on GNOME infrastructure, which I could have without being a core module.) I see the following, but I may have missed something: * DD gets the slightly increased integration of being in the panel vs a window (really, not a large distinction in the grand scheme). * A formal agreement within GNOME that developers should be paying attention to the module. Though note that DD would love attention regardless of core status! :). * A bit of a social thing by declaring which camp DD is aligned with. Is it a policy requirement that Features be core modules? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 21:50, Colin Walters walt...@verbum.org wrote: Deja Dup could definitely qualify pretty easily as a Featured Application; see: https://live.gnome.org/TwoPointNinetyone/FeaturedApps I had thought it was a Featured App already. When modulesets got redesigned during my previous proposal, I thought that was the outcome. But it's not in that list, true. Are Featured Apps still a thing in 3.2? I don't see the corresponding ThreePointOne page. A few concerns: 1) I'd like to see at least some discussion for how (if) this intersects with the already existing Finding and Reminding feature: https://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding I'd be interested in hearing from designers if there's any intersection here too. 2) The external dependency set is pretty large =( It looks like duplicity would in turn pull in quite a few new modules. If you're serious about proposing this though, can you try fixing the jhbuild in the gnome-apps-3.2 moduleset to actually work? _librsyncmodule.c:26:22: fatal error: librsync.h: No such file or directory It looks like it's missing several things; the Fedora package at least depends on librsync, gnupg, python-boto. Hrm. I do have a need to clean up the jhbuild sets. I also know that older modulesets should be pointing at the branches of DD, not trunk. I will fix that soon. 3) If you're still planning to have this run outside of GNOME, are you going to keep around the application mode in some way? If so, maybe it makes sense to stick with that for this cycle, and we can make it a Featured App, and revisit deeper integration for 3.4? I expect to allow building both a panel and a window versions of the preferences. That way, any distros that intend to follow through with re-adding the panel API can get a better experience if they want to. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 19:18, Allan Day allanp...@gmail.com wrote: Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: * What do we do about the infrastructure question? Core modules are supposed to be developed as a part of the wider project; that means that they use GNOME's infrastructure. * Can you technically achieve the level of integration that we're after if Deja Dup continues to exist as a standalone app? (This is a serious question - I don't know the answer.) * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. I'm coming into this interested less in questions framed as how can Deja Dup make GNOME better than as how can Deja Dup being part of GNOME make users' backup experience better. For example, I think of the infrastructure question in terms of whether there's a reason to believe switching to GNOME infrastructure will result in more or less maintenance work being done. And the branding question less in terms of will it be better for GNOME marketing than will it be better for users. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi, Allan. Thanks for your past and continuing help with design! :) Answers below. On 11 May 2011 11:33, Allan Day allanp...@gmail.com wrote: This looks like an improvement on the UI that you presented the last time you proposed Deja Dup. It could still be much better though. How would you feel about paring it down to something more minimal? Ideally, the UI should be limited to switching it and on/off, selecting the backup storage location, and giving an idea of status (a little 'hey, you're backups are fine!'). So specifically, you're talking about dropping: * Encryption toggle * Include/exclude * How long to keep backups * How often to back up I'm happy to have a discussion about what to do for each. One question: I know that you had a discussion on the usability list about renaming Deja Dup. Would you be happy to remove the remaining references to Deja Dup in the UI and just call it Backup? The only remaining references are the one-time welcome screen and the help documentation. I'm not fully wedded to those, though I'm hesitant to remove all instances. I can think of a at least a couple reasons at least a one-time brand is useful: * Some branding (even only once) is useful here to reassure user it will read the backup data they made elsewhere. * The user can install it on non-GNOME and they need to know what app to search for. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 13:42, Mattias Eriksson snag...@acc.umu.se wrote: Include/exclude: I think Exclude is still relevant (include should default to all personal data), since I (and probably a lot of other users) download stuff from the Internet that are very temporary, it can be movies, software installers aso... on my Mac I have added and exclude rule for the download folder since that would just waste space on my backup-unit. Just a note: Default include is $HOME, default excludes are Trash and Downloads. There are secret excludes for common cache directories too. How long to keep backups: Forever or as long as there are storage left. I like the TimeCapsule version with a nice default algorithm that tries to keep as much as possible as long as possible. The collapsing of older backups is tough with this backup format. Duplicity does not assume it can run code on the backend, so it can't really do a logarithmic collapsing of backups as they get older (unless it downloaded, collapsed, uploaded). I agree it would be a nice feature though. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 13:57, Milan Bouchet-Valat nalimi...@club.fr wrote: Why not just ask the user when performing a new backup in case there's not enough space left? Since DéjàDup already does full backups from time to time, it could notice the user that in order to backup new data, s/he needs to get rid of older versions until the date of a full backup (chosen so that just enough data can be freed to make the new one). When disk space is low, the oldest backup is already deleted to make room. I just meant it is hard to implement 'telescoping' backups where we only keep monthly backups from 1 year ago, weekly backups from a month ago, etc. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
BTW, it seems like there's a bit of feeling-as-we-go about the optimal design and feature set here. Maybe I could sit down with some GNOME designers like Allan and talk about what their ideal backup experience is and they can talk to me about current Deja Dup behavior and features? It could be over IRC or something. I just feel like a real-time discussion with designers would clarify to them what the shape of the Deja Dup experience is, its limitations, and where it can be changed. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Feature Proposal: Backup
Hello! You may remember me as the bloke that proposed the Déjà Dup backup tool as a GNOME module a little back, right as modules were being reorganized. I've been encouraged to try again as a Feature. I don't fully understand the process, but I gather an email to this list starts it off. Here's a quick thousand foot view: * Homepage here: https://launchpad.net/deja-dup * It's a backup program aimed at non-technical users. * It's a graphical wrapper and policy manager for the backup program duplicity. * It's included by default in Fedora 13 on and will be default in Ubuntu 11.10. * It follows the GNOME schedule and best practices already. For the next major version (20.0), I've done a redesign aimed at making it more invisible and appear as part of the OS. I've made it live just as a control center panel and removed some branding to look a bit less like a separate app. See http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. I suspect GNOME might be interested in having a backup story so I'm offering this one. And I'd be happy to have increased design advice and developer eyeballs. I have a few related questions: * What does being a GNOME Feature obligate me to? Basically the normal module stuff? * Déjà Dup lives in Launchpad. I'd love to explore ways of integrating the GNOME workflow and LP, but I would prefer that it remain in LP. I'm also happy to answer any questions about Déjà Dup, obviously. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 10 May 2011 20:54, Mattias Eriksson snag...@acc.umu.se wrote: Looking at the screenshots and from testing some previous versions I have some thoughts. I think the schedule part of the settings is for advanced usage. By default I think a good backup program should monitor the file system for changes and do backup continuously, that way the user knows that everything is safe. Like if I connect my camera and import the pictures to my computer, I would like to just not have to care if the images are backed up or when they will be backed up I just want to delete the pictures on my camera knowing that a backup will exist as soon as possible. I would tend to agree that from the casual user's perspective, they just want a backup. I've so far resisted adding anything fancier than the ability to say every week or every month etc. But since I don't know how to do continuous detection well yet, I haven't done it. It would probably also want some design thinking for how to present feedback to the user in a more continuous context. Also I think that a small status applet like on the mac would be great to have, since that will show the user that things are being backed up and provide a menu for the settings and forcing a backup. There is a status icon used when backing up in classic GNOME. I was asked to remove it when the user is in the Shell. So I suspect GNOME designers would especially not like a status icon that is always there. And a thought for future features... I saw that there were support for some cloud services for offsite backup, which is great! But is would be great for personal offsite backups (like http://www.crashplan.com/), where you install the software on multiple computers (your own or your friends) allowing them to store backup on each others disks. Curious. Any GIO target is supported, so I suppose you could point at each other's machines if they are running SSH or some such, but that isn't quite as integrated as you mean. There is a long wishlist, but I've mostly been focusing on trying to tighten the experience rather than feature work. Thanks for your thoughts! -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 10 May 2011 21:51, Bastien Nocera had...@hadess.net wrote: That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. There's a separate thread for this that I replied to. I'd really like Deja Dup to be even more integrated into the system, meaning that we should make it possible to backup the whole system, using fanotify(), and possibly integrating with btrfs snapshots. My plans have always been aimed at personal data only, with any support for whole-system backup as a nice bonus. There are technical issues there like if you hit a file the user doesn't have read support for, are you going to prompt for the root password every time? This is a personal backup program, not something for system administrators. But I'm not opposed to improving support as long as it doesn't harm the existing personal backup experience. As for btrfs snapshots and such. I could envision adding support to duplicity to determine what changed via btrfs, but would not want to make btrfs part of the backup format itself. Duplicity's existing format design assumes very little about the backend (put, get, delete, list) so that it can support cloud destinations like Amazon S3. S3 won't be adding a btrfs in the cloud anytime soon. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 02:55, Andrew Cowie and...@operationaldynamics.com wrote: --encrypt-key 5CB48AEA \ --sign-key 5CB48AEA \ specify asymmetric encryption using my GPG key. Not supported currently. Needs design work to still be friendly for non-technical users. --volsize 100 \ implementation detail, but it should be tweakable? I've been taking the stance it shouldn't be tweakable. One thing Deja Dup does is adjust it whether you're hitting the network or not. --exclude '/home/andrew/**/*.o' \ I can tell it to ignore certain files or folders by name, but it doesn't seem I can exclude by pattern? As a developer there are an awful lot of intermediate files that I don't need to backup --exclude '/home/andrew/**/tmp/**/*.class' \ --exclude '/home/andrew/**/tmp/**/*.h' \ and so on. Can't do it. You can't even specify specific files, just folders. It needs design work: https://live.gnome.org/DejaDup/Design/Proposal-MoreThanFolders --exclude '/home/andrew/.gvfs' \ --exclude '/home/andrew/.local/share/gvfs-metadata' \ --exclude '/home/andrew/.cache' \ --exclude '**/*.cache' \ --exclude '**/Cache/**' \ If we're backing up a user's home directory, then ignoring all this stuff could just be automatic, right? .gvfs and .cache are already secretly excluded along with .thumbnails and the like (unless you specifically include them). See the help documentation for a list. I didn't know about gvfs-metadata, but if it lives in .local/share, sounds like user data that should be backed up. --exclude '/home/andrew/.gnome2/epiphany/favicon_cache' \ --exclude '/home/andrew/.local/share/Trash' \ --exclude '/home/andrew/.Trash' \ --exclude '**/sessions' \ --exclude '/home/andrew/.nautilus/metafiles' \ --exclude '/home/andrew/.nautilus/saved*' \ --exclude '/home/andrew/.fontconfig' \ Sounds like we need to file bugs against epiphany to put its cache in ~/.cache. Same for nautilus. I'll look into .fontconfig. The user's trash is in the default user-visible exclude list. Ditto. And of course doing a system level backup, we don't need (and need to forceably skip): --exclude '/dev' \ --exclude '/proc' \ --exclude '/sys' \ --exclude '/tmp' \ --exclude '/var/lock' \ --exclude '/var/run' \ --exclude '/var/cache/apt' \ --exclude '/var/lib/apt/lists' \ --exclude '/var/log' \ --exclude '/media' \ --exclude '/mnt' \ And so on. /dev, /proc/, /tmp, and /sys are excluded by secret default I believe. I don't think /media or /mnt are, but those are good suggestions. While this is clearly the sort of thing that could degenerate into a zillion configuration options and permutations, I'd like to hope GNOME's backup solution could help me out here and just Do The Right Thing™. Agreed. That's why I've taken the view that volsize and obvious cache exclusions should not be something the user should have to see. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On 8 October 2010 03:13, Johannes Schmid j...@jsschmid.de wrote: The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. I am afraid that the problem is not to import PO files in damned-lies but to commit them from damned-lies to the repositories. And we have to find a solution for this while keeping the current permissions that are specific to git.gnome.org. From a Launchpad perspective, a translation branch can be imported from git into a bzr branch in Launchpad. This would involve zero change from an LP maintainer perspective (currently, there is a bzr branch in LP for translations that gets written to by translators through the web interface; maintainers merge that branch before a release). So the trick then would be having Damned Lies import pot/po files from a bzr trunk. Then GNOME translators can edit them in git like they like. Then LP can import that translation branch with changes. Eh? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On 7 October 2010 07:57, Johannes Schmid j...@jsschmid.de wrote: What about Launchpad? I think if we want to integrate which other hosting possibilities we definitely need a working i18n-solution with Transiflex and Launchpad before accepting applications from there. Probably something the sysadmin-team and the i18n-team should focus on in this cycle. For Launchpad applications (such as mine, Deja Dup), I proposed three ways we could smooth the way for GNOME/LP interaction last time this came up: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the trunk. This way, documenters and GNOME-approved coders can directly commit. It would be best if being added to that team was automatic. Then have some documentation that says, for this app, here is the trunk. 2) Having the maintainer set the approved translation team to '~gnome-translation-project' and having some documentation for translators that this particular app lives in launchpad. With Launchpad Translations, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. Existing translation teams should be encouraged to join that team (or automatically added), as it seems a little sparse right now: https://translations.launchpad.net/+groups/gnome-translation-project 3) For the documentation team, a similar situation. Again, this would need some documentation that says, 'for this app, edit docs in this trunk'. Then they could directly commit. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On 1 June 2010 19:37, Lucas Rocha luc...@gnome.org wrote: 3. We strongly believe that we should encourage a strong ecosystem of apps around GNOME, and integrating all applications in the GNOME Desktop moduleset is not the best way to achieve this. As the maintainer of Déjà Dup, I approve of this move. I feel Déjà Dup is a bit of a poster child for this change. 1) Déjà Dup already follows the GNOME schedule, watches GnomeGoals, follows HIG, and uses GNOME technology. 2) Déjà Dup is already shipped in multiple distros. Inclusion in GNOME would just offer more marketing/developers (of which I'm primarily interested in the latter), not necessarily Déjà Dup's 'chance to hit it big'. 3) Déjà Dup already has an infrastructure that works for me. I'd be very sad to move away from Launchpad, but was willing to do if it meant access to the extra exposure. But am glad to hear that I won't need to. I don't think using, say, GNOME Bugzilla would improve my chances of attracting developers. 4) Not being under the watchful eye of release managers means I can be slightly more adventurous (don't need to have dependencies approved). One thing I had hoped to gain access to via GNOME is the documentation teams and translation teams. Launchpad provides very good translation support, so I'm not hurting there, but my understanding is that the GNOME translation teams are more comprehensive/committed. It would be nice if the new Applications scheme had some facility for improving cooperation between those teams and externally-hosted applications. Maybe for willing applications in Launchpad, that means: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the branch. This way, documenters and GNOME-approved coders can directly commit. 2) Having the maintainer set the approved translation team to '~gnome-translation-project' and having some documentation for translators that this particular app lives in launchpad. With Launchpad, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. 3) For documentation, a similar situation. Have some documentation for them that says, 'for this app, edit docs in this trunk'. Then they could directly commit. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
Hi, it's the maintainer of Deja Dup again. A couple things: 1) I've been talking to the usability guys a bit about the UI in general and thoughts on a possible Profiles interface. There's an ongoing discussion on the mailing list (though I think I haven't been terribly responsive in the thread) and a wiki page: http://live.gnome.org/DejaDup/UIReview 2) I'm still curious to get feedback on other maintainers' experience with pulling in other regular developers once they became a GNOME module. Frankly, I'm leery of the extra burden it would put on me in terms of bug reports and expectations-of-service. Though since the initial proposal, DD has been put in Fedora 13 by default and become a featured app in Ubuntu. I suppose I'm already on the hook pretty hard, and what's one more avenue of exposure. Here's the original question from my proposal, where I also brought up the question of the Progress on a regular basis requirement: However, I suspect that inclusion into GNOME would (by virtue of a massive amount of new users) create lots more bug activity and patch submissions. This would create much more work for me (or at least a sense of obligation to do more work). Frankly, I'm content with my current DD workload and don't want to increase it. So I would probably scale back my feature work as more maintainer work cropped up. How OK is GNOME with modules that don't add many/any features ever release? I know there is a Progress on a regular basis requirement, but I'm not sure how that's scaled for developer team size. Ideally I'd get a co-maintainer or some frequent developers? I'd even be happier if someone else wanted to maintain it and I would just be a developer on the project. I'm curious about other maintainers' experiences about how GNOME-inclusion leads to more developers or maintainers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
Comments below. On 10 March 2010 15:49, Matthias Clasen matthias.cla...@gmail.com wrote: Jon and I went over the UI and interactions a bit, and came away with the following ideas for improvement. Don't be scared by this long list, it is mostly UI details... ::snip:: Hope this helps, Yes, it does, thanks! One of the things I wanted to eventually take advantage of is the GNOME usability team, but these are all valid usability issues. I haven't replied to each one because largely I agree and the particular details of why things are the way they are now aren't important. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
In the interests of JFDI, I added deja-dup and its external dependency duplicity to jhbuild's 2.30 moduleset for ease of testing. Déjà Dup will also shortly land in Fedora rawhide, thanks to Rahul Sundaram! -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Module Proposal for 3.0: Déjà Dup Backup Tool
I'm not sure if this is too early, but it's been 6 months since modules proposals opened for 2.30, so I'm guessing it's an appropriate time for 3.0 modules? I think GNOME could use a backup program. There are some out there already, but having a GNOME-blessed one would focus development effort. = What's my proposal? = First, I'm specifically proposing my own pet project Déjà Dup (DD) for inclusion in the Desktop release set. DD is only one of many backup programs out there. I think it's pretty sweet but would also like to open the floor for comparisons to or inclusion of other programs. Maybe mine isn't the best fit and overtures to other maintainers would be appropriate. Déjà Dup's story is that it only tries to be a data backup program for disaster recovery. But aims to be the best little disaster recovery program there is. It's main website is https://launchpad.net/deja-dup, and there is a mission statement for more details of why it exists (http://live.gnome.org/DejaDup/Mission). It is designed to do the right thing without getting in the user's way. It encourages backing up to a cloud service. It encourages backing up on an automatic schedule. It is designed to target the not-very-computer-literate. It prefers to backup too much rather than too little. It integrates well into GNOME. It's also basically a glorified frontend for the command-line backup program duplicity. Next, I will talk a little bit about where I see backups fitting into GNOME and whether it needs such a program at all. == User Trust == If the user doesn't trust their backup system, what's the point? A backup system is only as strong as its restore, but by the time you find out that your system fails the restore test, it's usually too late. Backups are tricky. We're responsible for user's data and they will be very mad if we lose it. Maybe GNOME doesn't want to get into that business, though one can always point to the boilerplate disclaimer of fitness for any particular task. :) Déjà Dup is a wrapper around the already-proven command line tool duplicity. (Although, Duplicity is a program under active development. So it's not necessarily a rock-solid hasn't-needed-fixes-for-years tool.) DD has a suite of automated GUI tests. So I trust it (and use it). But these facts aren't user visible. I suspect user trust is a matter of time and usage. Unfortunately, Déjà Dup hasn't been around very long (about a year and a half now). == Why Not Just Live in the Cloud? == More and more of our lives are being stored remotely in Internet services and clouds (flickr, facebook, Ubuntu One, rhapsody). This seems to reduce the need for a backup of your data, if it all lives in the cloud. However, I don't think backup can ever be quite replaced. Unless a cloud system is specifically designed to hold your data, encrypted, with snapshots, with promises of availability, no-data-loss, and integrated into your desktop, there is still a strong use case for your own backup. * Most cloud services only keep track of your current files. If you delete a file and later realize you need it a month ago, you're out of luck. * Cloud services tend to be fragmented (different services for different data). You don't have easy access to all your data from one place. * There will likely be data that you don't trust the cloud to hold. * You often only put a 'weaker' version of the data in the cloud, but keep the pristine version locally (e.g. photo upload to flickr). * You may have large amounts of data that aren't appropriate for upload. Of course, there's no reason you can't store your backup files in the cloud. I look forward to the sci-fi future where everyone uses thin clients into server farms that offer transparent data safety and duplication. I won't stand in that future's way for love of my own code. But in the meantime, I think a backup program is a useful offering. == What Does Backing Up Give Me? == There are already different solutions for the basic thrust of what backups do (data protection). * Rollback to previous versions of files with btrfs or some version of my-filesystem-is-a-vcs * Sync local files to the cloud (like Ubuntu One) But none of those are able to meet all disaster recovery needs (of three main sorts): * Revert to old version of file. * Recover a small number of lost (accidentally deleted) files. * Total system failure. What many backup systems (and Déjà Dup specifically) provide are: * Rollback to previous versions * Automatic backups (i.e. no-intervention after initial setup -- if you have to do it manually, you're not doing it enough) * Incremental backups (space saving) * Encryption (so you can backup to non-trusted locations) * Ease of off-site backup (for really bad disasters like floods, fires, or mass theft) = Déjà Dup Details = OK, hopefully I've convinced ya'll that a backup program is a useful offering. Here's more information about my
Re: Backup
2009/11/18 Sandy Armstrong sanfordarmstr...@gmail.com: If you intend to propose your app for 2.32 (aka 3.0), note that the proposal period has not yet opened, but you can get a head start by trying to follow the GNOME release schedule, and potentially migrating your code and bug tracking from launchpad to gnome.org. Infrastructure things like this help to reduce some of the hurdles in module proposals. I've made a draft of the 'bid' I will send when the proposal period opens: http://live.gnome.org/DejaDup/GNOME I'm not prepared to abandon Launchpad just for the hope of inclusion, but releasing in sync with GNOME for the 2.30 cycle would be a good way to get familiar with GNOME cadence. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Backup
Is GNOME interested in shipping an official backup program? I (as a long-time lurker) haven't ever noticed discussion about it. I feel the backup market currently has a lot of almost-there UIs and lots of duplicated effort. That might either mean it's a good time for GNOME to step in and polish one, or that it's a good time for GNOME to wait for one to 'win'. I'm not even sure that GNOME cares particularly, but it seems like a hole in the market. For full disclosure, I am notably biased in any such discussion as the maintainer of one of those almost-there duplicated efforts (an app called deja-dup). But I'd like to think that I'm more interested in a good user experience than my own ego. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Backup
2009/11/18 Tristan Van Berkom t...@gnome.org: Usually what is best is for you to make an official proposal and explain why you think your module should be included in GNOME releases - personally I think if we dont have any backup mechanism I would probably give it a thumbs up. Fair enough, and I would be willing to go through that process for my own pet project, but I was interested in taking the temperature. My own project may not necessarily be the best fit (though of course I think it's the best thing since sliced bread). I wanted to make a 'fill-in-the-blank backup module proposal'. Unless such a discussion would best take place in the context of a concrete module proposal? -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Backup
2009/11/18 Lennart Poettering mzta...@0pointer.de: Hmm. This doesn't even do backups on optical disks, does it? Isn't that a bit weird? Yeah, it's not yet feature-complete. Patches welcome. :) The optical experience would be a bit tricky/different, and I've been trying to avoid adding half-baked features. I suppose such issues would best be raised in an eventual module proposal. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Re: gnome-media/gnome-cd commit]
Whoa, whoa, whoa. I think there's some miscommunication here. First and foremost, I will go about reverting tonight. Secondly, I did reply to Bastien when he originally emailed me explaining that I was under the impression I had gotten permission (in bug 411975). It appears I didn't include Ronald in that reply (a Reply/Reply All mistake). The text of my email is below [1]. I thought that the matter was resolved with that explanation because I heard no response. Ronald's email on the 9th never made it to me. It appears to only be addressed to Bastien(?). Again, I'm sorry for the trouble this commit has caused, but I never acted in bad faith. I honestly originally thought permission had been granted and never received notice to revert (did Ronald also email the invalid [EMAIL PROTECTED] address?). -mt [1] Hello, Bastien! Mmm, I don't think Ronald did. In bug #411975 [1], Marc-Andre Lureau reviewed the patch and said it should be committed. So I did. If I messed up procedure, it was an accident. Also sorry for the misleading email account. That was a misunderstanding on my part (thought CVS access came with an email to use for CVS commits). [1] http://bugzilla.gnome.org/show_bug.cgi?id=411975; On 9/6/07, Bastien Nocera [EMAIL PROTECTED] wrote: FYI, Mike, you still haven't reverted this commit, despite having nearly a month to do so. The code in itself doesn't look like it's going to cause problems, but consider this your first warning. You need to ask maintainers permission before doing commits like this, especially as a new contributor (which I guess from your Bugzilla statistics). GNOME SVN isn't a free-for-all... Cheers -- Bastien Nocera [EMAIL PROTECTED] -- Forwarded message -- From: Ronald S. Bultje [EMAIL PROTECTED] To: Bastien Nocera [EMAIL PROTECTED] Date: Thu, 9 Aug 2007 23:54:32 -0700 Subject: Re: gnome-media/gnome-cd commit I can't remember ok'ing this, Michael, please revert and put in bugzilla. If not, I will, and I'll be a pain to make it go in again. I promise. Ronald On 8/9/07, Bastien Nocera [EMAIL PROTECTED] wrote: Hey Michael, I just wanted to know why you committed to gnome-cd[1] without branching. Did Ronald give you the right to commit without branching? Cheers PS: The e-mail address you used for your commit log doesn't work either. [1]: The big commit: 2007-05-14 Michael Terry [EMAIL PROTECTED] * Makefile.am: Install app icon into hicolor theme, not .../pixmaps * gnome-cd.c: (make_button_from_icon_name), (make_popup_menu), (init_player), (tray_icon_create), (main): Look up icons in theme, not from stock * gnome-cd.desktop.in.in: Remove png suffix from icon * images/Makefile.am: * images/None/Makefile.am: Don't install unused icons * images/None/None.theme: Remove obsolete icons section * images/media/media-fwd.png: * images/media/media-stop.png: * images/media/a-stop-menu.png: * images/media/media- eject.png: * images/media/a-first-menu.png: * images/media/a-eject-menu.png: * images/media/media-rew.png: * images/media/media-play.png: * images/media/a-last-menu.png: * images/media/a-play-menu.png: * images/media/media-rec.png: * images/media/media-prev.png: * images/media/media-pause.png: * images/media/media-next.png: * images/media- eject.png: * images/None/media-fwd.png: * images/None/media-stop.png: * images/None/a-stop-menu.png: * images/None/a-first-menu.png: * images/None/media-eject.png: * images/None/media- rew.png: * images/None/a-eject-menu.png: * images/None/media-play.png: * images/None/a-last-menu.png: * images/None/a-play-menu.png: * images/None/media-prev.png: * images/None/media- pause.png: * images/None/media-next.png: * images/lcd/a-fwd.png: * images/lcd/a-pause-pressed.png: * images/lcd/a-fwd-pressed.png: * images/lcd/a-first.png: * images/lcd/a- first-menu.png: * images/lcd/a-eject.png: * images/lcd/a-first-pressed.png: * images/lcd/a-eject-pressed.png: * images/lcd/a-rwnd.png: * images/lcd/a-rwnd-pressed.png: * images/lcd/a-stop.png: * images/lcd/a-stop-menu.png: * images/lcd/a-stop-pressed.png: * images/lcd/a-eject-menu.png: * images/lcd/a-last.png: * images/lcd/a-last-menu.png : * images/lcd/a-play.png: * images/lcd/a-last-pressed.png: * images/lcd/a-play-menu.png: * images/lcd/a-play-pressed.png: * images/lcd/a-pause.png: * images/mixer.png: * images/a-play-menu.png: * images/cd.png: * images/red-lcd/a-fwd.png
