Re: Anybody out there?

This is a multi-part message in MIME format.
--------------090202040804050705000104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 17/02/10 08:45, Alexei Znamensky wrote:
> I have been using stow for over a decade now, and it has saved my skin way
> too many times.

Same here.  Unfortunately I haven't used it for more than 2 years.
Troy's taken over maintenance (great stuff Troy!) but occasionally I
poke my head in and give some advice.

> Now I was looking for a perl patch of code where I could put my "Modern
> Perl" skills to use, and it occurred to me I could give back to stow.

Excellent!  I'm sure Troy will welcome any help he can get :-)

> I have
> just pulled the latest version and I have seen it has improved a lot since
> version 1.3.3, widely available.

Most of the changes were inspired by the challenges of using Stow at
RMIT University's Comp, Sci. department.  There we (3 or more Sys
Admins) used it to manage several hundred packages on an NFS share that
was mounted (in different ways) by a dozen servers which were (in turn)
used (24/7) by several thousand users.  If you understand that sort of
environment, then a lot of the madness will become clear :-)

> Thus, I do have some questions, before I start doing things on my own:
> 
>    - Why not use the perldoc style documentation?

I gather you mean interspersing the code with snippets that get pulled
together by perldoc.  The supposed advantage being that any changes to
the code are more likely to inspire updated documentation.  I personally
don't see this happening much in practice and so avoid it.

There's a discussion of this in Damian Conways "Perl Best Practices"
(which is meant to be thought provoking rather than gospel).  The upshot
of the argument is that code (as written) has a natural flow which is
different from documentation (as an ideal).  In order to make the
documentation read well, you have to reorganise the code in a fashion
that makes it harder to maintain.  Keeping the pod at the bottom helps
to keep the bugs out of the top :-)  Having end user documentation (as
opposed to hacker documentation) closer to the relevant code can make
the code a lot harder to read.

This argument does not really hold for Modules whose sole purpose is to
export functionality (u.e., most of its subs) to be used by other
Modules and scripts.  Interspersed perldoc works well in that case and
comments are typically maintained _because_ they get used by others often.

>    - Have you guys ever considered creating a module that encompasses the
>    Stow functionality and uploading it to CPAN? If yes, what kept you from
>    doing so? Do you guys have in concerns if I make such a module?

Never really thought of doing it as a module, though I suppose with the
current layout you could export 'stow', 'unstow' and add a configuration
layer (like say in Storable) which could handle options that would
normally be passed on the command line.  Note also the little 'chkstow'
script that comes with the distribution.

I have no objections to you building a Module which the 'stow' command
simply becomes a command line wrapper (Troy?).  Just have to take care
that the GNU liscences are upheld and the GNU people are happy having
this on CPAN (Troy - I don't see any problems but it would be good to
check with Karl beforehand).

> I am not very used to git - seen some videos, played a bit, but never really
> *worked* with it. But, as far as I recall, it allows distributed version
> control, so I might start working on it independently. I am going to start
> some work around here and see how it goes.

Happy Hacking!

Kal

-- 
Kahlil (Kal) Hodgson                       GPG: C37B01F4
Head of Technology                         (m) +61 (0) 4 2573 0382
DealMax Pty Ltd                            (w) +61 (0) 3 9008 5281

Suite 1005
401 Docklands Drive
Docklands VIC 3008 Australia

"All parts should go together without forcing.  You must remember that
the parts you are reassembling were disassembled by you.  Therefore,
if you can't get them together again, there must be a reason.  By all
means, do not use a hammer."  -- IBM maintenance manual, 1925


--------------090202040804050705000104
Content-Type: text/x-vcard; charset=utf-8;
 name="kahlil_hodgson.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="kahlil_hodgson.vcf"

begin:vcard
fn:Kahlil (Kal) Hodgson
n:Hodgson;Kahlil (Kal)
email;internet:[email protected]
tel;work:03 9008 5281
x-mozilla-html:FALSE
version:2.1
end:vcard


--------------090202040804050705000104
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Stow-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/stow-devel

--------------090202040804050705000104--