Re: UserIDs and setups for developers
On 11/25/12, Gordon Haverland <ghaverla@materialisations.com> wrote:
> On November 24, 2012, Zenaan Harkness wrote:
>> Just use your own email address, ghaverla@...
>>
>> If you want to distinguish various email addresses, create
>> multiple (real) email addresses, and use those per-project.
>> That could easily get unwieldy though...
>>
>> Where do you want emails to go? Is your code to be given away/
>> made public in some way?
>> Presumably by including an email address in your source code,
>> you're providing a way for other developers to contact you. In
>> which case, to satisfy your intent you need to use a real
>> email address.
>
> I am getting close to producing a package (written in Perl) which
> is useful to people who do GPS related work, but should be useful
> to any kind of surface related work (such as Materials Science and
> Engineering, which is my "home"). But, I think this package will
> eventually be something like 50 different modules, as probably
> something like 10 different families of packages.
>
> The intention is to send this to CPAN, being a Debian person I
> suppose I could build it for Debian. But parts of this package
> are of general usefulness. Which is why it will be families of
> modules.
If you build for debian, dpkg-deb can un-zip a .deb package, just like tar etc.
If it's generally useful to a range of people, then presumably it will
get used, regardless of packaging - but easy installation does make it
more convenient.
> Most people start by doing something simple. I didn't. From what
> other people have recommended, I should start "publishing" the
> bits that work.
Definitely. Publish early, publish often.
Create a git account somewhere, eg on code.google.com
Choose a license before publishing I recommend. I like GPL family,
others prefer BSD/X/MIT family etc.
See http://www.gnu.org/licenses/license-list.html
for comparison and ideas on why _you_ might prefer one license over
another. You might choose to choose a license on pragmatic,
political-strategic, broad-acceptance-strategic, or other bases.
> I suppose most people who write Perl code, expect bugs and
> everything else to go to CPAN. Over the years, I've had questions
> about using various other Perl modules, and so having some other
> contact method seems to be needed. I thought it would be useful
> on my end, to have incoming mail related to Perl, to have a UserID
> of 'perl' in the destination address.
I think just a regular email address - either way, make sure to test
whatever email addy you choose, that it gets to you, when an email is
sent from in-the-wild.
> Maybe this package of mine becomes useful to people. And perhaps
> Debian picks it up. My hope then would be to use debian@... as
> the contact, instead of perl@....
That is natural part of debian packages - std contact locations, bug
reporting etc.
> I can see how this can snowball into all kinds of directions. I
> have never produced software which is useful across many
> different applications before, and I am just trying to minimize
> problems for me, or for users.
Focus on releasing those parts which work. Small clean modular,
working, these are good attributes :)
cheers
zenaan
Reply to: