On 11/25/12, Gordon Haverland <ghave...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNST=2vypjwr_ee4grmbpu5btzlnz0ay_kth0vo0si58...@mail.gmail.com
