Re: Issue Tracker Used? Git migration checklist.

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 26 Oct 2012, Fred Cooke wrote:

> >  If you want to be constructive, concentrate on actual development
> > of patches (scripts, hooks, documentation etc.) for the steps I listed to
> > allow everyone to work pretty much exactly as they currently do, but in a
> > git environment.
> 
> I'll focus on writing patches for sure, once I can commit them to
> git/hg/perforce/bazaar/darcs/etc

You are welcome to set up whatever repository seems convenient to you for 
storing the hooks and scripts you propose as part of the conversion (first 
the setup of a toplevel repository, then a conversion of binutils+gdb).

> > The responsibility of people proposing a VCS transition is to show how to make existing process
> > work with the proposed new VCS.
> 
> That would be you, in many list messages, no? I'm just stoking the
> fire and proposing that the "movement" takes on some structure and
> organisation.

"stoking the fire" is counterproductive unless you plan to do the actual 
conversion work (meaning converting scripts, hooks and documentation, in 
such a way that it is transparent to everyone that existing processes will 
all continue working as they do now, whether or not additional 
possibilities are *also* opened up).

The reason a conversion hasn't happened is very simple: a conversion 
involves a large amount (likely person-weeks to person-months) of boring 
work that requires a lot of familiarity with the infrastructure 
surrounding the various tools using the shared toplevel (such as release 
processes and scripts for various automatic updates from cron) and a 
willingness to work to keep many different peoples' processes and 
requirements working throughout any transition.  There are only a limited 
number of people with the relevant expertise, or interested in getting it, 
all of whom are busy with other things.  Starting discussions consumes 
those people's time and so makes it even less likely that a transition 
occurs.  No-one is interested in forming a "movement".

If you want a small task in preparation for such a conversion, I suggest 
working out how to hook up a git repository on sourceware to Bugzilla 
mails - these have been broken for glibc since that was converted to git 
(see glibc bug 13746).

You *don't* need to be an existing developer to improve infrastructure 
(see how Frederic Buclin did the GCC and sourceware Bugzilla upgrades), as 
long as you keep existing processes (people committing directly to shared 
repositories, release-building scripts, ...) working as they do now, 
whether those processes would make sense for a new project or not (they 
certainly make sense for, and work for, the existing developers).

-- 
Joseph S. Myers
joseph@codesourcery.com