Greetings,
We currently only use one branch in our git repo: master. Now that Matahari is making its way into some Linux distributions, such as Fedora 16 [1], I think it's time to create and maintain a release branch.
--- Create a release branch.
The first thing that needs to be done is to create a new branch, which I propose be called "release-0.4".
--- Maintain the release branch
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
--- Release tarballs
Once we have the release branch up and going, we should regularly make release tarballs (matahari-0.4.X). We can plan for doing so roughly monthly, but the frequency could differ based on the quantity and severity of bugs that have been fixed.
--- Release maintenance commitment
Given that Matahari is still in heavy development, I would rather not make any promises about how long a given release series will be maintained. In the case of the 0.4 release series, which is is in Fedora 16, it will at least be maintained as long as Fedora 16 is supported.
Let me know what you think. We need to get this settled before we make any more feature additions to master.
Thanks,
[1] http://fedoraproject.org/wiki/Features/Matahari
On Thu, Aug 25, 2011 at 02:08:16PM -0400, Russell Bryant wrote:
Greetings,
We currently only use one branch in our git repo: master. Now that Matahari is making its way into some Linux distributions, such as Fedora 16 [1], I think it's time to create and maintain a release branch.
--- Create a release branch.
The first thing that needs to be done is to create a new branch, which I propose be called "release-0.4".
v0.4?
Heaps of other projects use this. Nice and short :)
--- Maintain the release branch
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
--- Release tarballs
Once we have the release branch up and going, we should regularly make release tarballs (matahari-0.4.X). We can plan for doing so roughly monthly, but the frequency could differ based on the quantity and severity of bugs that have been fixed.
--- Release maintenance commitment
Given that Matahari is still in heavy development, I would rather not make any promises about how long a given release series will be maintained. In the case of the 0.4 release series, which is is in Fedora 16, it will at least be maintained as long as Fedora 16 is supported.
Let me know what you think. We need to get this settled before we make any more feature additions to master.
Thanks,
[1] http://fedoraproject.org/wiki/Features/Matahari
-- Russell Bryant _______________________________________________ Matahari mailing list Matahari@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/matahari
On 08/25/2011 06:20 PM, Angus Salkeld wrote:
On Thu, Aug 25, 2011 at 02:08:16PM -0400, Russell Bryant wrote:
Greetings,
We currently only use one branch in our git repo: master. Now that Matahari is making its way into some Linux distributions, such as Fedora 16 [1], I think it's time to create and maintain a release branch.
--- Create a release branch.
The first thing that needs to be done is to create a new branch, which I propose be called "release-0.4".
v0.4?
Heaps of other projects use this. Nice and short :)
Sure, that's fine. I don't care much about the name, as long as it makes sense.
On 08/25/2011 02:08 PM, Russell Bryant wrote:
Greetings,
We currently only use one branch in our git repo: master. Now that Matahari is making its way into some Linux distributions, such as Fedora 16 [1], I think it's time to create and maintain a release branch.
--- Create a release branch.
The first thing that needs to be done is to create a new branch, which I propose be called "release-0.4".
--- Maintain the release branch
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
--- Release tarballs
Once we have the release branch up and going, we should regularly make release tarballs (matahari-0.4.X). We can plan for doing so roughly monthly, but the frequency could differ based on the quantity and severity of bugs that have been fixed.
--- Release maintenance commitment
Given that Matahari is still in heavy development, I would rather not make any promises about how long a given release series will be maintained. In the case of the 0.4 release series, which is is in Fedora 16, it will at least be maintained as long as Fedora 16 is supported.
Let me know what you think. We need to get this settled before we make any more feature additions to master.
This sounds reasonable to me.
If we're doing roughly monthly tarballs/releases, can we pick a rough time/date to do it each month? Like: last wednesday of each month or smth, so that we can have some regularity.
On 08/25/2011 11:08 AM, Russell Bryant wrote:
Greetings,
We currently only use one branch in our git repo: master. Now that Matahari is making its way into some Linux distributions, such as Fedora 16 [1], I think it's time to create and maintain a release branch.
--- Create a release branch.
The first thing that needs to be done is to create a new branch, which I propose be called "release-0.4".
--- Maintain the release branch
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
This proposal makes good sense, but it has been my experience in other projects that if 1 person is not responsible for ensuring patches get backported, patches don't get backported.
Worth a shot tho :)
Regards -steve
--- Release tarballs
Once we have the release branch up and going, we should regularly make release tarballs (matahari-0.4.X). We can plan for doing so roughly monthly, but the frequency could differ based on the quantity and severity of bugs that have been fixed.
--- Release maintenance commitment
Given that Matahari is still in heavy development, I would rather not make any promises about how long a given release series will be maintained. In the case of the 0.4 release series, which is is in Fedora 16, it will at least be maintained as long as Fedora 16 is supported.
Let me know what you think. We need to get this settled before we make any more feature additions to master.
Thanks,
On 08/26/2011 11:38 AM, Steven Dake wrote:
On 08/25/2011 11:08 AM, Russell Bryant wrote:
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
This proposal makes good sense, but it has been my experience in other projects that if 1 person is not responsible for ensuring patches get backported, patches don't get backported.
Worth a shot tho :)
Well I will review things. I'm actually not proposing backports, though. I'm proposing that it be policy that if you're merging a bug fix that is applicable to the release, that it gets committed there first and then pulled over to master. I'm expecting committers to understand and adhere to that policy so that we share the burden. It has worked fine for me in my last major project.
On 08/26/2011 08:51 AM, Russell Bryant wrote:
On 08/26/2011 11:38 AM, Steven Dake wrote:
On 08/25/2011 11:08 AM, Russell Bryant wrote:
There are a few different models that we could follow for maintaining the release branch. I propose that committers share the responsibility of maintaining the branch. If the commit you are making is a bug fix, push it into release-0.4 and then "git cherry-pick -x" it to master. Otherwise, just push your changes to the branch they are applicable for as usual.
This proposal makes good sense, but it has been my experience in other projects that if 1 person is not responsible for ensuring patches get backported, patches don't get backported.
Worth a shot tho :)
Well I will review things. I'm actually not proposing backports, though. I'm proposing that it be policy that if you're merging a bug fix that is applicable to the release, that it gets committed there first and then pulled over to master. I'm expecting committers to understand and adhere to that policy so that we share the burden. It has worked fine for me in my last major project.
Forward porting can tend to lead to regressions since master may end up without patches that are in a released branch. This happens when a committer fixes the immediate problem in a released branch and adds the forward port to their future tasks. Could be future tasks are forgotten... But YMMV :)
Regards -steve
On 08/27/2011 01:10 PM, Steven Dake wrote:
Forward porting can tend to lead to regressions since master may end up without patches that are in a released branch. This happens when a committer fixes the immediate problem in a released branch and adds the forward port to their future tasks. Could be future tasks are forgotten... But YMMV :)
and backporting can lead to bugs never getting fixed in a release branch. There's room for error either way.
matahari@lists.fedorahosted.org
-
Angus Salkeld -
Perry Myers -
Russell Bryant -
Steven Dake