[Debburn-devel] want to help

Albert Cahalan acahalan at gmail.com
Wed Sep 6 13:17:53 UTC 2006


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.



More information about the Debburn-devel mailing list