grantstreetgroup/gitc

Git workflow management

NAME

App::Gitc - Git Changesets - tools for managing your git changes

VERSION

version 0.60

INSTALLATION

Read the HOWTO for information on setting up Gitc. Example configuration files are available.

SEE ALSO

Gitc Wiki

App::Gitc::Util

AUTHOR

Grant Street Group <[email protected]>

COPYRIGHT AND LICENSE

This software is Copyright (c) 2013 by Grant Street Group.

This is free software, licensed under:

The GNU Affero General Public License, Version 3, November 2007

gitc's Issues

Make gitosis integration optional

gitosis isn't actually necessary to use gitc

App::Gitc::Config uses no strict to munge the symbol table in a way Exporter.pm already does

By using Exporter, we can avoid the symbolic reference table work in the import subroutine.

"gitc open quickfix" could alias to "gitc quickfix"?

I have an annoying tendency to type "gitc open quickfix" when I meant "gitc quickfix" -- if not an alias, I think gitc should at least prompt to make sure that's what you really want to do.

Bugzilla issue tracker integration

...

Allow configuration to be passed on the command-line

It might be handy to have configuration that can be sent on the command-line.

App::Gitc::Its::Eventum does not use strict

That's a problem. Easy fix.

Add support for github issues

This way gitc can be used to work on gitc. ("Dogfooding" as someone recently put it.)

App::Gitc::Util uses a 2-arg open around line 1553

App::Gitc::Util uses a 2-arg open around line 1553, which is a security issue.

open my $log, "$command @$commits |" or die;

should be:

open my $log, "-|", $command, @$commits or die;

Default to no ITS

A fresh gitc install will try to integrate with Eventum (I guess via the default 'eventum.example.com' example). It should integrate with no ITS if none is configured.

Independent user management

By default, gitc relies on the developers group locally, and sends mail to the local box.

This is of course easy to work around with /etc/email.addresses, but we probably want a more advanced way to enumerate users and their external email addresses in the database.

Fix some doc issues

Looking at the distro through MetaCPAN: https://metacpan.org/release/App-Gitc

Found a few misc doc issues:

1. Duplicate Copyright and Author sections for the modules. Pod::Weaver is likely already adding in these sections automatically. Remove them from the modules and the problem should fix itself.

2. You'll want to add a # ABSTRACT: comment to all of the commands and modules. This gives each one a summary line on the release page, page title, and searches.

3. gitc-add-user's PODNAME is incorrect.

4. App::Gitc's redirection to App::Gitc::Util is a little weird. Probably better off to just transplant the docs to App::Gitc. Better yet, drop the modularization of App::Gitc, turn it into a POD, and put in the PODNAME stuff for package identification. I have an example here.

5. The README is a bit boring. After fixing point 4, add this to dist.ini:

   [ReadmeAnyFromPod / ReadmePodInRoot]    ; Pod README for Root (for GitHub, etc.)
   [ReadmeAnyFromPod / ReadmeTextInBuild]  ; Text README for Build
   [ReadmeAnyFromPod / ReadmeHTMLInBuild]  ; HTML README for Build (never POD, so it doesn't get installed)
   
   ; Or, if you want to stick with MD
   [ReadmeAnyFromPod / ReadmeMarkdownInRoot]
   filename = README.md
   
   [ReadmeAnyFromPod / ReadmeMarkdownInBuild]
   filename = README.md
   

Remove deps for App::Gitc stuff

There seems to be some requirements for App::Gitc modules that don't exist. Might want to add this to your dist.ini:

[RemovePrereqs]
remove = App::Gitc::Config
remove = App::Gitc::ListFormat::Base

Either that or the modules need to be put into the distro?

Split GSG-Reversible

GSG-Reversible should be split from this project and released to CPAN on its own. It's just sugar, but is useful outside the context of gitc.

Undeclared dependencies

Email::Simple
Text::Levenshtein
git-send-email (under newer git versions this is a separate package)

Provide a default DB configuration using SQLite

Use a SQLite database as the default so that very little additional configuration is needed to get started. If a user later wishes to use a different database, they can migrate the SQLite database pretty easily.

Fail gracefully when .gitc is not present

When .gitc is not present, certain gitc actions like "submit" cause a ridiculously long set of failure messages ending in a SQL error (of all things). We should catch this early on and throw a helpful error (or default the project name to the name of the repo or something).

Load configuration from the project's central repository

As a followup to issue #1, we should be able to load the configuration from project itself while it is still on the server. This can hep alleviate the challenge of not having the configuration during gitc-setup, but presents a some new problems on it's own:

1. What security implications could this have? Probably this is relatively safe since we'd only do it in cases where you have requested to setup a project or where it is enabled, but any time you grab something from a network and make decisions based upon what you find, security must be examined.
2. Do we want to try this normally? Do we enable it or prefer it in some repositories? For example, should there be a use_server_config setting in the $PROJECT/.gitc/gitc.config to enable this? Should it be enabled by default? Should there be a command-line option for enabling/disabling it during gitc-setup or other operations?
3. The time at which this config is probably most useful is during gitc-setup, so we'll need to make it so that it is possible to send gitc-setup a full git repository path and load the configuration at whatever location we find.

Configuration loading

Get rid of hardcoded configuration, replace with tasty config files

Allow for multiple ITS configurations to be used

Right now the ITS subsystem assumes that there is only a single configuration per ITS package. This is definitely a false assumption. Either the ITS configuration files in jira.config and eventum.config (and any others that may be added) must support multiple profiles or we need to allow for different configuration files to be used with different ITS profiles or personas or whatever makes sense.

Remove from GSG namespace, reserve real namespace on CPAN

Clearly we shouldn't be distributing this in the GSG namespace.

Have we discussed how we're going to distribute on CPAN? Generally we have one employee who maintains a particular distribution (i.e, I maintain Date::RangeParser::EN), in this case it's more substantial and it may make sense to have a shared GSG PAUSE identity.

Once we know this, we should reserve the namespace we're going to use.

Better support for decentralized workflows

Right now gitc has dependencies on developers working on a shared dev box.

We should consider decentralizing the gitc workflow to make it work, for instance, with shared development teams on an open-source project on github. (Like gitc!)

A few things we'd need:

• Issue 8 to remove dependency on local groups/users
• Issue 6 to remove dependency on gitosis
• Remove dependency on local MySQL database -- perhaps using git metadata instead

Do not require JIRA::Client or JIRA::Client::REST

These should not be required. A developer should only need install them if they want to use JIRA as their ITS.

Use Dist::Zilla to build the distribution

Dist::Zilla provides an extensive and extensible build system that should make distribution of this much easier. Some advantages include:

• Generating version numbers.
• Generating README files from a template.
• Providing special author-only tests useful for determining if the module is ready for release, but not necessarily tests you want to even run after testing (e.g., checking for POD errors and POD coverage).
• Inserting boilerplate documentation such as license at the end, version numbers, etc.
• Easy to manage meta configuration.
• Easy to use push to PAUSE to streamline the release process.
• Git integration is available to make sure the release manager avoids certain dumb mistakes.