On Mon, Jul 23, 2012 at 8:18 AM, <[email protected]> wrote: > > On Sun, 22 Jul 2012, Nick M. Daly wrote: > >> Bryan, is this ready for me to add to the weekly images? This might >> solve FreedomBuddy's OpenVPN service control issues. > > It's waiting for review/consensus/merge, but at this point there have been > no complaints so it's probably good to go?
I'll wait for review and for James to merge it upstream. I'll also look it over closely before adding it to the weekly images. > Does Plinth or the freedombox > foundation have licensing policy or guidelines? Should I delegate copyright > to the foundation? Sort of a mountain over a molehill for this patch. Plinth is AGPL3, so I just AGPL3ed FreedomBuddy. I've heard nothing about copyright reassignment or contributor agreements, so I'm reserving my own copyrights for now, until asked otherwise. > I should probably give the code a one-over and include a HOWTO; I'll do this > tomorrow (tuesday). > > Does anybody have thoughts on logical error handling behavior? Some of the > existing Plinth code (eg, hostname changer) would try to revert changes when > they failed; i'm not sure if that behavior should be implemented at the > exmachina (library/wrapper) level or left to application logic. Thinking about this, I'd like to know how Ex does two things: 1. Whether changes are atomic (how do we prevent the system from seeing a semi-changed state?). 2. Whether failed changes aren't implemented. It seems like the least surprising behavior would be: if Ex can't save the changes, it rolls them back and raises an error. That way, the system's never left in an undefined state, and the controlling application can decide whether to give it another go or just bail. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
