Re: Moving GLib and GTK+ to git
- From: David Zeuthen <david fubar dk>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: Kristian Høgsberg <krh redhat com>, GNOME i18n list <gnome-i18n gnome org>, gtk-devel-list gnome org
- Subject: Re: Moving GLib and GTK+ to git
- Date: Tue, 31 Mar 2009 15:59:13 -0400
On Tue, 2009-03-31 at 15:05 -0400, Matthias Clasen wrote:
> Commit messages: Here are some recommendations that I think meet our needs:
It would be nice to have hooks to enforce this in the master repo at
git.gnome.org. Thoughts?
> Working with branches:
> As Kristian explained to me, there are two basic approaches to
> handling bug fixes in git branches. Either commit the fix on the devel
> branch and cherry-pick it to the stable branch, or commit the fix to
> the stable branch and merge the whole stable branch to the devel
> branch periodically. While both approaches should work, the second one
> has the advantage of keeping more information about the availability
> of the fix in the git topology.
>
> Anyway, we don't have to create a 2.16 branch today, we can take a few
> days to feel our way into working with git before getting serious
> about major feature merges.
Do we want to recommend that contributors
1. submit patches to bugzilla (like we've done up until now)
2. publish a git repo with their changes
Surely we would need to handle both, but it's my experience that it is
much easier for maintainers to work with 2. Especially for more
complicated features that include a series of patches.
So maybe we want to actually recommend workflow 2 to contributors. Maybe
even add some bugzilla-bling-integration, I don't know.
David
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]