Hi all,
I'll try to keep this as brief as possible:
1) Vitality:
- how many releases did you publish within the last 12 months?
10
- How many of these releases have 'only' been bug fix releases?
3
- how many weeks from now did you publish the most recent
release?
The last release was published Oct 28th, about two weeks ago
- Do you plan to publish a new release within the next month?
Yes.
- How many hours do you spend on your project per week?
That depends on quite a few factors, not least of which is the mood I'm in as well as
my daytime job.
- How many hours of your free (unpaid) time do you spend on your
project(s) per week?
see above.
- Do you believe that your program is granted to be supported
and to make progress in a long term scope?
- will it survive the next year?
- will it survive the next 2 years?
- will it survive the next 5 years?
- will it survive the next 10 years?
- what will happen if you finish your study or if you
change your job?
- what will happen if you find a new friend, marry or
get children?
I've been very dedicated to GnomeToaster development in the past and I may well remain
so for the forseeable future.
GnomeToaster is not a project of study, it all happens out of personal interest.
- Do you believe that you get enough help from other people and
users of your program for development and support?
Yes.
2) Portability:
Does your project run on:
- Solaris
Never tried.
- Linux
Yes.
- Win32 (if yes, does it need an X server?)
Nope.
- HP-UX
- MacOS X (if yes, does it need an X server?)
Never tried.
- Is your program portable at all?
It's all a matter of how long it will take to make it run on a different platform.
I wouldn't consider it portable software in the way many other projects (including
cdrtools) are.
- Do you plan to increase the portability of your program?
In an more or less event-driven way, yes. If someone wants to make it work on a
particular platform he's more
than welcome to do so and I'll support him wherever I can.
- Which platform that is not yet supported will get support in
the near future?
None. I do use Linux and plan to make the best of GnomeToaster on that platform. There
are some continuing efforts going
on to have it work on *BSD, though.
3) Open Source:
- Is your project an OpenSource project?
Yes.
- Does your project rely on non-OpenSource parts?
(this may be one or more libraries needed to
allow compilation ad linking)
mpg123 is used to decode mp3 files plus I may use closed-source components in the
future.
GnomeToaster does not depend on any closed-source components, they're optional for a
specific purpose.
4) Code quality:
- Do you perform code reviews?
- on a regular base
Yes.
- Do you use any source code control system?
If yes, do you:
- use CVS
Sure.
- Do you allow other people to make changes on your source?
If yes, how do you control the quality of these changes?
Do you
- check and discuss patches before applying a reviewed
version of the patch
I can be rather picky about applying patches.
5) Documentation:
- Is there any written documentation?
Yes. See http://gnometoaster.rulez.org/documentation/gnometoaster_users_guide.html
- Do you have a troff -man version of the documentation?
Nope. Too much for a manpage. But if someone wants to do a summary, he'll be welcome.
- Do you have a sgml version that auto-translates into troff?
I used to. I'm currently using lyx to do the documentation, though. Don't know if it
can convert to sgml
- If there is a troff or sgml manual, do you:
- have documented all features of your program in it?
No, as there's no sgml manual but a html one but I guess that doesn't count ?
If it does, the answer also has to be no. I really enjoy to do the coding bit so it
usually takes a few month for me
to finally make up my mind to update the documentation. But at those very weekends the
docs are uptodate afterwards ;-)
- update the man page every time you change the behavior
of the program?
If there's a major change regarding the user interface I usually update the docs. I do
not, however, explicitly mention every
new feature added to the software. One has to look those up in the (rather talkative)
ChangeLog.
6) What do you believe is the status of the programs from cdrtools or
other 'Schily SING' software with respect to the above questionnaire?
Pretty much fulfills it. Obviously who wrote this questionaire has made sure to
mention exactly what is important
to him.
I wouldn't be myself, though, if I'd not mention the fact that I'd rather see cdrecord
and mkisofs go into a libcdrecord
or libmkisofs with some sort of a commandline frontends handling both. This would make
life considerably easier for
GUI authors as they'd just have to link against a (hopefully) stable binary interface.
As some of you may know, GnomeToaster provides for the ability to actively edit
filesystems (removing particular files out of a directory, renaming files etc.) at the
cost of having the filesystem be a symbolic link tree (makes it impossible to burn
actual links to the disc). graft-points may be a nice feature for commandline/small
scripting activities but they're rather
inapt for extensive filesystem editing.
Finally I'd ask you, Joerg, to not misunderstand what I wrote above. I know what the
hell of a lot of work it is to
keep cdrtools uptodate. But I believe you've been asking above question partly because
you want to get feedback about
cdrtools and their aptness for the ever-so-important business of developing a GUI
frontend for them so I just told
you what seems to be important for myself to get a bit closer to having the "perfect"
GUI for cdrtools and other commandline
programs (I also support cdrdao in GnomeToaster for it has features cdrecord doesn't
have and has been supporting recorders
that haven't been available with cdrecord in the past).
7) Which features from cdrtools do you support?
- which features from cdrecord
- which features from mkisofs
- which features from cdda2wav
The ones mentioned above.
8) Which features from cdrtools do you _not_ support?
- which features from readcd
That one I don't.
9) Which features do you get requests for and you believe that you will
be able to implement them in a reasonable time but the needed low
level support is not yet present in the appropriate cdrtools program?
All I can think of for now is having filesystems with symbolic links.
9a) Do you plan to enhance the portability of your program to a set of
platforms similar to cdrtools?
This is not the primary goal of GnomeToaster development. I'm willing to support other
platforms, but not at any expense.
9b) Which platforms that are supported by cdrtools will (or may) never be
supported by your program?
- in the near future?
- really never?
It pretty much comes down to the same thing. I'm probably not going to support WIN32.
Regards,
A.Eckleder
--
### Who is General Failure - and why is he reading my harddrive ? ###
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
