=head1 PRIORITIES

=over 4

=item Command options to specify provided/required packages

=item Command to list dependors and dependants

=item Command to list outdated packages

=item Command to verify prereqs on a stack

=item Command to unregister a pkg/dist ??

=item Write test cases for Stack operations

#--------------------------

=item Stack property: strict (no overlapping dists)

=item Stack property: target perl

=item Stack property: source repositories

=item Stack property: allow devel releases

=item Repo property: log level

=item Repo property: default sources

=item Repo property: default target perl

=item Repo property: defautl devel option

=item Prettier stack listing and stack prop listing

=item Re-examine log levels for messages

=item Verify checksums during 'verify'

=item Add hooks before/after adding and pulling

=item Ensure there is an open revision before each Repos operation

=item Give revisions properties

=item Compute checksum for stack after each revision

=item Allow revisions to be tagged

=item Mark stacks as merged after merge

=item Mark stacks as deleted after delete

=item Warn if an unmerged stack is being deleted

=item Way to pin/unpin all packages in a stack

=item Make the Store transactional

=item Rollback a stack to prior revision

=item View history for entire repository or stack

=item Examine the delta between two stacks

=item Rewrite tests with Test::Class

=back

=head1 LESS IMPORTANT

=over

=item Documentation review

Need to add the 'documentation' key to all my attributes.  Also, need
to figure out how to get Pod::Weaver to consolidate

=item API documentation

=item Support target_perl option

So you can specify which perl to compute dependencies with.  Because
the perl you want to deploy with may not be the one that you use to
run Pinto.

=item More robust list action

Actually, I think it is good enough for now

=item Query language?

Not yet -- no clear use case.

=back

=head1 IDEAS FOR COOL NEW ACTIONS

=over

=item look: Unpack archive in temp dir and launch shell there

=item ack: Do an ack command across all distributions

=item news: list recent additions. maybe something from Changes file

=back

=head1 OTHER STUFF TODO

In no particular order...

=over 4

=item Create a hook mechanism to do stuff before or after an Action

Like to notify people when the repository contents have changed.  Or
to kick off a build when the repository changes.

=item Enable plugins for visiting and filtering. See CPAN::Mini and
CPAN::Mini::Visit.

=item Standardize API, using named parameters except where it makes
sense not to.

=item Write a tutorial to explain different ways for using Pinto in
the development/deployment cycle. ++

=item Generate a RECENT file.  This could just contain the files
added in the last action (if any).

=item Improve Perl::Critic compliance.

=item Document, document, document.

=item Tests, tests, tests.

=item Look for better ways to use Moose roles.

=item Profile and look for performance optimizations.

=item Add --package option to the Add action

To excplicitly declare what packages the archive provides, in cases
where the META is whack or the packages can't be discovered.

=back

=head1 STUFF DISCUSSED WITH RJBS

=head2 Features inspired by XPAN

=over 4

=item Implement a "dry-run" feature.  

Whenever Pinto fetches a .tar.gz, it first puts in a temporary
directory (I think).  After the packages and prereqs have been
extracted, only then does it actually place it in the repository.  So
if --dryrun is enabled, don't put it in the repository.  Also, if
--dryrun is enabled, roll back the database transaction.  There might
be multiple layers of transactions going on, so we'll have to roll
back at the right level.  Finally, each Action must return 0 if
--dryrun is enabled, to indicate that the repository state has not
changed and does not need to be committed to VCS.

=item Warn when an imported/added package conflicts with a pinned
package.

Each time a package is added, Pinto looks at all the other packages
with the same name and sorts them according to version number, whether
it is pinned, and whether it is "local" or "foreign".  From that, it
determines what the "latest" version is and marks that to be included
in the index.  So that would probably be the time to warn if an
incoming prereq is blocked by an older pinned package.

=back

=head2 Other housekeeping chores that need to be done...

=over 4

=item Optimize generation of CHECKSUMS files.

At the moment, I'm using Adreas' module, which generates a CHECKSUMS
file by recomputing md5s for everything in the directory.  I think
this is because PAUSE is paranoid about keeping accurate CHECKSUMS.
But this makes importing/adding/mirroring slow if the author's
directory already contains a lot of dists.  Better to just compute the
md5 for the new dist and append it to the ones that are already in the
CHECKSUMS file.

=item Come up with a strategy for schema migration.

I'm using SQLite and DBIx::Class.  Every time the database schema
changes, I break compatibility with all the existing repos (if there
are any).  So I need some way for Pinto to upgrade its own schema.  I
know there are frameworks for doing this but I just haven't learned
them.  Or maybe just use something like KiokuDB.

=item Document the architecture.

Pinto has a pretty well-defined architecture -- there are distinct
layers and separations of concern.  It may not be the *right*
architecture, but it is definitely there.  I need to capture it on
paper so I (and others) can reason about it.

=item Document the API.

Only the command-line interface has any real documentation.  The
internal API has started to become stable and needs to get some
documentation love.

=back

=head2 Grand wishes...

=over 4

=item Make Pinto extensible in the way that Dist::Zilla is.

For example, I can imagine roles like BeforeAddition/AfterAddition and
BeforeRemoval/AfterRemoval that provide hooks where plugins can make
stuff happen when a dist is added or removed from the repository.
Stuff like publish the POD to a website, or tweet a notification, or
fire off a build, or run a local metacpan.  But that all may be
premature.

=back

=cut
