[Debburn-devel] want to help

[Albert Cahalan]

On 9/5/06, Joerg Jaspert <joerg at ganneff.de> wrote:
> On 10768 March 1977, Albert Cahalan wrote:

> > 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.

It's still icky and irritating. I get to be the only person with a
totally sucky username, and it doesn't match what I use
elsewhere.

Do I get any access to machines for porting? I could really
use accounts on unusual Linux architectures and non-Linux
systems. (for procps too actually)

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

albert-guest

> > Settled on the name yet?
>
> Yes. cdrkit for the suite, wodim for cdrecord.

Sure you want to change the executable name?
It'd be no worse than the "kill" programs in procps,
util-linux, bsdutils, and elsewhere.

You'll never get the xcdroast upstream to accept a patch.
Having seen some of the cdrecord output parsers out
there, I suspect that an 8-character name would be
less trouble.

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

In addition to the obvious time problem (work schedules),
some of us just don't use chat/IM stuff ever.

> 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. :)

How about splitting off an etch branch right now, then
opening up the main branch for general hacking?

It's not as if the etch branch should really change.