30.03.2011 15:32, amnesia@??? пишет:
> 3. The mailing list / remailer I am using to send this email is
> the private, OpenPGP-encrypted core Tails developers one. I'd
> rather discuss this stuff with you and the rest of the on the
> Tails community on our public development mailing list
> (tails-dev@???); would you mind?
Here I am :)
Comments are inline.
> 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. 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: approach taken
by Fedora looks more appealing in a long term -
http://fedoraproject.org/wiki/Features/LZMA_for_Live_Images
Also I like arguments about gdm mentioned in pretty funny video here:
http://fadenb.soup.io/post/98490494/Linux-Bully-Beatdown-at-27C3-feat-Datenwolf :)
> Although interesting as a discussion starter, this part of your
> application will need to be a bit more complete, e.g. include a draft
> schedule from now to the end of the 3 months of coding; you'll
> probably want to have a look to the various GSoC howtos that are
> available on the GSoC website and wiki for inspiration and examples.
I'll do my best :)
> 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.
> 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 :-)
Anyway, it looks like proper way would be to just use gsettings which will abstract
backend usage, although "dconf profiles"
(
http://live.gnome.org/dconf/SystemAdminstrators) looks like interesting concept.
> 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.
> 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.
> - 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.
> - 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" :)
> - design documentation
I presume that it will be 1st or 2nd step of project anyway.
> - 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. 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.
> - 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. I'm pretty sure the
more will emerge as the project develops.
> 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. 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.
> 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 mostly live offline, and check my mail once ~every one day or two.
> During the GSoC coding time, I intend to spend the time needed to
> properly mentor your work and enjoy it, and we'll probably need to
> schedule chat times together, but I want to make clear right now that
> I won't be idling on IRC the whole day long. Also, not that many of us
> Tails developers spend time on our IRC channel. To get feedback from
> them, to keep them tuned on your work, you'll need to use async'
> communication means (email, wiki) instead. Does it seem doable to you?
Absolutely - that's why I've mentioned email in a first place.
> Could you please elaborate?
So my current idea of project schedule goes like this:
week #1: gather some info on user-requestable settings and try to replace
gdm-simple-greeter with my code, draft design description (including settings
description format)
week #2-3: add abovementioned test setting into tails-greeter
week #4-6: extend with more settings, iron out process for "settings owners" to put
info regarding settings they'd like to be requested from user into tails-greeter
week #7: write some tests (compile time & runtime), .deb packaging, documentation
write\rewrite etc
week #8: fix last-minute bugs, do some human-testing if possible.
week #9: was already eaten out by some unforseen surcumstances in this schedule :)
cheers,
Max.
