[OPEN-ILS-DEV] Conference wish list: proper use of git

[James Fournie]

Howdy,

I gave a brief overview of our techniques at the hackfest and I was
considering recklessly volunteering as well, so I'd be happy to help
out in any way I can.

We've been using git quite a bit for the past year to manage our
changes to the Evergreen code, opac skins and circ scripts, as well as
migration scripts at Sitka.  I'm not involved in the mobile PAC
development so I can't speak to use of git there.

In general most of my experience revolves around forking a stable
branch (ie: rel_1_6_0) rather than trunk.  I have some partly
documented workflows including rolling up/merging your repo to the
upstream branch, upgrading your branch and backporting bugfixes and
generating patches.  I'm not sure these are useful to the core
developers but may be useful to implementors that just want a way to
maintain a production codebase with local customizations (and easily
share bugfixes or enhancements back to the community).

~James
BC SITKA



On Tue, Dec 28, 2010 at 6:11 AM, Galen Charlton <gmc at esilibrary.com> wrote:
> Hi,
>
> On Dec 23, 2010, at 7:31 PM, Dan Scott wrote:
>> Let's assume that we would opt to go with the herd and adopt git in the
>> hopes of attracting more contributions to our core Evergreen and OpenSRF
>> distributions. I think it would make for a killer presentation to go
>> through our project's common workflows and show how git would improve
>> our lives (as well, of course, as how to perform said workflow in git,
>> with git's apparent love of flags for common operations). If we did want
>> to adopt git, then making the changeover as easy as possible so that
>> precious developer time is not wasted would be a good thing - and this
>> sort of presentation would be a big help. And I'm definitely _not_ the
>> person to give this presentation :)
>
> I recklessly volunteer to give such a presentation.  I've been working with Git for the Koha project for years, and as evidenced by git.esilibrary.com, Equinox has been poking around with Git and git-svn recently, so with any luck by the time conference rolls around we'll have muddled our way through some of the workflows and the presentation will be informed by more practical experience applying Git to the Evergreen source tree.
>
>> To really be unconventional, I think it would be awesome to schedule a
>> session immediately following a git presentation strictly for discussion
>> and planning: when to make the change; who is going to do what; where
>> would the primary repo be hosted; how will we provide web-based access /
>> commit mailing list / etc; how will this interoperate with bug reporting
>> and tracking, who will update the "developer howto" docs that we
>> currently provide via the wiki on contributing to the project, yada yada.
>
> +1
>
>> So... any thoughts here? I think we would probably want an agreement in
>> principle that we want to move to a DVCS before asking someone to
>> propose a session and asking the Conference Committee to set aside two
>> consecutive slots, and maybe the end of December isn't the best time to
>> have that discussion, but I wanted to get these thoughts out while
>> they're relatively fresh.
>
> +1 to adopting a DVCS.
>
> As you say, we should get an agreement in principle before asking the concomm carve out two slots.  My personal preference is to adopt Git, as I'm most familiar with it and some of the tools (such as gitolite) that we'd likely want to use if we choose Git.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> VP, Data Services
> Equinox Software, Inc. / Your Library's Guide to Open Source
> email:  gmc at esilibrary.com
> direct: +1 352-215-7548
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
>
>