[Debburn-devel] want to help

[Joerg Jaspert]

On 10768 March 1977, Albert Cahalan wrote:

> This alioth site is trouble.

It can be a bit confusing if you are new to it, yes.

> Unlike sourceforge.net, it seems that I can't create a normal regular
> account. How can I get a non-guest account? If the answer is just
> "NO", would you mind moving the project elsewhere? I'd like to be a
> regular developer. I have a sourceforge.net account.

Ah, thats a misunderstanding of the -guest addittion. All -guest ones
are regular accounts, with all the usual rights attached. It is simply
that Debian Developers get an account immediately, without a -guest
attached, so any account created via the webinterface gets the -guest to
be sure it doesnt clash. It could also have been named "-noDD" or
something like that. But it doesnt mean you have a limited account, or
limited rights or something.

So, if you tell me your alioth login you can get a regular developer of
cdrkit. :)

> Settled on the name yet?

Yes. cdrkit for the suite, wodim for cdrecord.
The debburn only remains in the url for our alioth repository, as thats
way harder to move to something else, doesnt really hurt and isnt seen
by any user, only us developers.

> Thoughts on untangling the mess? I tend to think that
> ultimately the privileged code should speak a simple
> protocol on stdin/stdout, live in the /usr/lib directory,
> and never be invoked directly by the user. A library can
> speak with that, and an unprivileged /usr/bin/cdrecord
> can just use the library.

> Does anybody have any strong opinions about the level of
> portability that is appropriate? On the one hand, portability
> means more help. On the other hand, it means more work
> and some awkward limitations. I'm inclined to favor the
> current stuff: Linux 2.6, FreeBSD, MacOS X, OpenBSD,
> Solaris, HP-UX, AIX, IRIX, and maybe Windows. (with some
> minor difficulty for FreeBSD, these are the systems which
> are certain to handle respectible device addressing)

It seems we should have an IRC meeting and talk about this, later
sending some kind of minutes here. That topic also came up on IRC and
was delayed until this night (European times night :) ).

The question is basically if we want to be able to share patches with JS
or not. In theory I would like that for the parts that are not (yet?)
licensed under CDDL, which means libparanoia, libunls, mkisofs,
libhfs_iso (as of 2.01.01a11, would need to bec checked with every
release). For the CDDL licensed ones we arent able to share patches.

How about today, 19:00 UTC on irc.oftc.net, #debburn - use
`date -d "19:00 UTC"` to translate that to local time.

> What about splitting things up, just as X was split up
> after the fork from XFree86? Joerg merged a lot of stuff
> into cdrtools over the years. (mkisofs, cdda2wav, etc.)

It is an option, if it gains us enough. There are some libs also
included in the upstream tarball, which the rest links again, so one
needs to work that all out. It should be done in a branch, so it can be
tested thoroughly before we make it mainline.


From a Debian maintainers viewpoint I would like to have that ready
right after etch, and keep etch with the one-tarball package, as we
already introduced a heavy change relatively near to the release. Doing
that some time later, even more near to release, again - our release
managers would kill us. :)

-- 
bye Joerg
Some NM:
main contains software that compiles with DFSG.
[hehehe, nice typo]
Of course, eye mean "complies", knot "compiles".  Sum typos cant bee
caught bye spelling checkers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 250 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debburn-devel/attachments/20060905/5bc8bffb/attachment.pgp