Hi,
M wrote (30 Mar 2011 15:59:18 GMT) :
> Here I am :)
Great. First, thanks for your quick and detailed answers that now
allow me to help you go a bit more deeply into things, on your way to
a proper GSoC application.
>> Have you read our TODO item [0] related to this project? An
>> alternative idea we recently had is documented there under the
>> "Getting rid of GDM3" title. We're not sure if this approach is
>> better or worse for Tails than the GDM3 greeter one you submitted a
>> proposal for. What do you think?
> Of course I read it and I think that although idea of getting rid of
> gdm is might be worth considering, but maintaining custom
> application in its place is definitely harder.
I'm not that sure.
At the end of the day you're probably right, but I'd like to see this
decision based on things a bit more convincing than "is definitely
harder", see what I mean?
Of course, a custom application would need to rewrite some wheels GDM3
already has, that is the bits that are common to every display
manager. On the other hand, I'm for example wondering, among those
interfaces:
1. GDM greeter <-> the rest of GDM
2. {GDM, other display manager} <-> the rest of the desktop stack
... which one has the best documented API with planned backward
compatibility?
Arguments based on other criteria are obviously welcome as well.
> We might use slim display manager as a lighter replacement but I'm
> not convinced that this is the best way to deal with cd space
> constraints:
I don't think using slim would help that much for size issues: we
ship a GNOME desktop, so most libraries GDM3 depends on are likely to
be installed anyway.
Using slim may make sense if, and only if, it makes things easier to
implement and/or to maintain. Also, I'm not sure Debian Live support
slim properly enough.
> approach taken by Fedora looks more appealing in a long
> term - http://fedoraproject.org/wiki/Features/LZMA_for_Live_Images
About LZMA compression, we're waiting for new stuff to reach Debian
squeeze-backports:
https://tails.boum.org/todo/use_lzma_compression/
>> Note that we don't mind using Glade twice a year in case we want to
>> add a new option or redesign any given settings section, I believe.
> This definitely makes life much easier - in this case there is no
> need to store in dconf anything besides maybe default values for
> offered configuration options.
Ok.
>> Also, can you please check if the dconf shipped in Debian Squeeze
>> is mature enough to be seriously used?
> I presume it's still very experimental cause it's marked as such :-)
Just curious: reference please? (Neither the Debian package
description nor the dconf homepage support this assertion.)
> Anyway, it looks like proper way would be to just use gsettings
> which will abstract backend usage
It seems to me gsettings is not part of Debian Squeeze. Am I wrong?
> , although "dconf profiles"
> (http://live.gnome.org/dconf/SystemAdminstrators) looks like
> interesting concept.
I am sorry if our reality-lead requirements tend to prevent you from
using shinny new tools that are likely to be the way to go in the
future, but... Tails is currently developped on the basis of Debian
Squeeze, and will likely be for the next ~18 months. If tails-greeter
is based on gsettings/dconf, it's unlikely to be of any practical use
for Tails soon enough.
What do you think of this? Does it seem possible to you to implement
tails-greeter using tools that are usable as of today (Debian Squeeze
+ squeeze-backports) only, in a way that makes it easy later to port
it to new settings interfaces?
Anyway, again, tails-greeter will not make that much use of a settings
backend (only default configuration default values, as you stated
above), so that part shall not draw that much discussion, time and
energy.
>> I'm not sure this fits as a split out part. Every single step will
>> need testing and debugging, isn't it?
> My bad - I meant split as in "part of work TBD", not as in "part of
> schedule" - see corrections below.
Ok.
>> Some other things are also needed to get the result of your work up
>> and running in Tails. I'll cite a few of them, and would like to know
>> which ones you intend to make them part of your GSoC project's
>> schedule, which ones you don't feel like committing yourself to:
>>
>> - UI design with usability in mind for the
> Definitely not. I mean there will be of course some UI designed as
> part of the project but since I'm no specialist in this it will
> probably suck in so many ways... the only sane solution I see is to
> try to make ui design change as easy as possible by separating
> related parts from the rest of the code.
Ok, seems reasonable to me. I think this decision and its rationale
shall be part of the document that will become your final application
for GSoC.
>> - Debian packaging (how familiar are you with Debian, by the way?)
> I'm working on Debian derivative daily so I'm eager to learn making
> .deb packages.
Ok. I'll keep my remarks about when you will learn it for the schedule
part bellow.
>> - i18n/l10n
> Definitely yes. English is not my native language (which probably
> obvious by now from all the mistakes I made :) so I'm convinced of
> importance of it "by default" :)
Ok.
>> - design documentation
> I presume that it will be 1st or 2nd step of project anyway.
Well, reading this I fear you start designing the whole thing before
doing anything practical. Of course you need to think and show us a
big picture at some point (e.g. as part of your GSoC proposal to start
with, and probably in a more detailed way in the beginning of the
3-months coding time), but on the scheduling topic, I think you'd
better split your project into smaller parts, and design documentation
would be written before/while implementing every such small part.
>> - end-user documentation (is be needed for this tool? offline
>> documentation probably not, but under-the-mouse help seems useful
>> for the usecase. Probably important enough to be integrated as
>> part of the UI, who knows.)
> I think it depends on how we organize ui update process. As far as I
> understood I should gather information from devs of various
> subsystems of TAILS to assemble list of user-requested options.
Right, you may have to pressure us a bit so that we make design and UI
decisions on a few planned features. The more you start doing so in
advance, the less you'll be stalled because of us during the 3 months
coding time. In the current state of existing (sometimes slow) Tails
developers community process, I don't see how this could be
effectively done during the first week of the coding time.
Bootstrapping this process seems like a very good candidate for the
"community diving" month, so that:
* we have enough time to answer your questions
* you'll be forced to participate into our development community,
we'll be forced to speak to each other, to get to know each other a
bit, which is the whole point of the "community diving" month.
> The format for this information should include at least
> "name-value", "save-defaults", "effects" (send this dbus, write to
> this file etc). It could also include "dev readable" and "human
> understandable" description - the latter could be reflected in UI.
Ok. I feel like a bit more formal and detailed version of the above
lines could be worth adding to your GSoC application.
>> - All those things that tend to be forgot in draft schedules, you
>> know :p - I'm sure you can find a few more.
> Noting on my mind right now except some sort of test automation.
Some of us have started investigating how Sikuli could be used for
such matters. See
https://tails.boum.org/todo/automated_builds_and_tests/ for details.
> I'm pretty sure the more will emerge as the project develops.
Sure
>> We use Git. Participating in Tails, you'll quickly get *practically*
>> familiar with it. It's probably worth planning a bit of time in your
>> schedule to get up to speed with the tools used in Tails development,
>> such as Git. The "community diving" month is probably a great time to
>> do so. How much will you be available to spend time on Tails during
>> this month?
> Several hours a week.
Ok. I think you need to think a bit what you intend to do as part of
the community diving month, and what you want to do as part of the
3-months coding time.
> I've used git to get sources of some projects I worked with and to
> see diff between my modifications and original code. I also used
> commit\push but for my own repo so I guess getting used to it will
> not take long.
Hrm, well, in my experience using Git as a basic SVN replacement
(which you are describing) is relatively easy, while getting up to
speed using its more advanced features (branches, rebasing, history
rewriting and so on) takes quite more time. My advice to you would be
not to underestimate this time.
>> Great. I'd rather see design documentation as something that needs
>> to be written on your way designing and implementing the code, than
>> something pertaining to the maintenance process. How do you see it?
> I'm trying to be realist in here: design documentation is "how it
> supposed to be" and "maintenance documentation" I was talking about
> is "how it was actually done" :-)
I think you'll need to update the design documentation incrementally
when you change your mind while coding. Else we would have to guess
from your code what you are trying to do, which makes any review at
the very least painful. By proceeding like this, the design
documentation state at the end of the GSoC would give us maintenance
documentation for free. What do you think?
> Absolutely - that's why I've mentioned email in a first place.
Ok.
>> Could you please elaborate?
> So my current idea of project schedule goes like this:
> week #1: gather some info on user-requestable settings
As I explained above, I don't think starting this question / answer
play that late is reasonable.
> and try to replace gdm-simple-greeter with my code,
Sounds great.
> draft design description (including settings description format)
I've already commented above on this matter so I won't repeat myself
here.
> week #2-3: add abovementioned test setting into tails-greeter
> week #4-6: extend with more settings,
I did not found what the "abovementioned test setting" refers to,
which makes it hard for me to understand this part of the schedule.
> iron out process for "settings owners" to put info regarding
> settings they'd like to be requested from user into tails-greeter
Could you please clarify / elaborate what you mean with "iron out
process"?
> week #7: write some tests (compile time & runtime), .deb packaging,
> documentation write\rewrite etc
A few remarks on week #7:
1. One week seems *very* short to me to do all this stuff, unless you
already are really at ease with code testing and Debian packaging.
2. I'd be much more comfortable with this schedule if you included (at
least unit-) testing as part of your code writing process.
3. The best way to have Tails developers (and users!) review and test
your work would be to have a branch in Tails Git repository where
you push your work; depending on how it presents itself, it may
deserve a Debian package (in this case, a dedicated repository
would be setup for tails-greeter, and a Debian package would be
pushed at least at milestone time to the Tails repository) or not
(in this case, you'd only work in the Tails Git repository).
In either case, you'll need to do some packaging/glue-ing work from
the very beginning and all along I think, rather than late in the
coding process as you are suggesting.
> week #8: fix last-minute bugs, do some human-testing if possible.
What do you mean by "human-testing"?
> week #9: was already eaten out by some unforseen surcumstances in
> this schedule :)
Ok, great.
Some other things that are missing from your current proposal:
- What programming language do you intend to use?
- The code sample you sent us is in Python. Is this the language you
are the best at? Could you provide some other code samples?
- When will you learn how-to, and setup the needed environment to
build a Tails system in order to test your work in a realistic
environment?
Cheers,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Who wants a world in which the guarantee that we shall not
| die of starvation would entail the risk of dying of boredom ?
