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
>> tails-dev@??? instead of tails-ux@??? :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.
>> 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.
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.
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.
