sajolida: > segfault: >> I sent my first GSoC report only to tor-dev and forgot to send it to >> tails-dev too. I quote it in full at the end of this mail. > > I'll answer on tails-dev only and add George in explicit copy to avoid > crossposting across mailing list. > >> sajolida: >>> segfault: >>>> * I began implementing the CLI, the current code (not ready for review >>>> yet) is also available on gitlab [2] >>>> >>>> Next I plan to continue the design of the GUI, after others commented on >>>> the new prototype. There are still some features missing which I will >>>> implement in time. In parallel I will continue implementing the CLI and >>>> discussing the design decisions. >>> >>> Maybe the call for review for the CLI should be sent to >>> [email protected] instead of [email protected] :P >> >> I didn't send a call for review for the CLI yet. Actually I wrote that >> it's not ready for review yet (see the quote above). > > I understood this and was mainly pointing out, partly as a joke, that > once it was ready it should be sent to tails-dev and not tails-ux. Sorry > I was unclear.
Oh, I didn't get that joke :) > >>> Also, just out of curiosity, when are you planning to work on "Design an >>> extensible and robust format describing the services and how they >>> integrate into Tails"? >> >> I think this discussion has already started with anonym's mail [1]. I >> discussed this further with him in XMPP because I had a different design >> in mind but I think his is better, so I didn't write a mail about this >> after the chat. I already started implementing and extending the design >> (I think most shortcomings only become obvious during implementation). >> Maybe I should send another mail about this. >> >> [1] https://mailman.boum.org/pipermail/tails-dev/2016-March/010506.html > > You're right and I actually didn't read this thread very carefully > myself because it was going out of my department. I was thinking that > for example it would be good to have a blueprint that specifies how to > describe a new service (the options specific to this service, what needs > to be made persistent, how to start and stop it, etc.). And anonym's > email looks like a good start indeed. > > This will be useful during the design phase to allow people other than > anonym and George to review it. For example, I really want intrigeri to > review your specification because his vision is usually nicely > complementary to anonym's but I don't expect him to follow our threads. Ack. > > This blueprint will also be easy to transform into a design document at > the end of your project for more people to develop services. Because > you're developing something like an API or a plugin mechanism here and > this needs to be documented for others to use. Ack. > > That's something we do quite often while working on complex features: we > elaborate blueprints as working documents and reference for reviews > during the process, and then we turn them into design document once the > project is over. And it will also be nicer to you not to have to write > all this documentation once you delivered and want to go do something > else more exciting than writing doc. Ack. I'm convinced and will start working on a blueprint for the TailsService and TailsServiceOption designs. :) _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
