So when I send a pull request to you from my repository, would
you rebase or merge?
We now have a nice linear history, which gives me a warm fuzzy
feeling for a simple project like OpenOCD
What would a typical pull request look like?
Subject: Pull request - my master branch has some fixes
On 08:34 Wed 29 Jun , Øyvind Harboe wrote:
So when I send a pull request to you from my repository, would
you rebase or merge?
merge never rebase the master repo
We now have a nice linear history, which gives me a warm fuzzy
feeling for a simple project like OpenOCD
What would a
On 07:21 Wed 29 Jun , Øyvind Harboe wrote:
I'd have some reservations about only one person having write
access, but not particularly the way of working. Call me old fashioned.
Does not mean you do not have the write access does just mean you dont use
it
As example if the release
On Wed, Jun 29, 2011 at 4:25 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 08:34 Wed 29 Jun , Øyvind Harboe wrote:
So when I send a pull request to you from my repository, would
you rebase or merge?
merge never rebase the master repo
I was thinking about branches
On 07:30 Tue 21 Jun , Øyvind Harboe wrote:
2011/6/21 Jon Povey jon.po...@racelogic.co.uk:
Øyvind Harboe wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and
The best way to do is to choose one git tree as the master git
then each maintainer will have their one git tree too
where they manage it how they want.
All the maintainers have their own repositories and forks at the git
mirror, but we also have write access to the master repository.
--
On Tue, Jun 28, 2011 at 6:58 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:04 Tue 28 Jun , Øyvind Harboe wrote:
The best way to do is to choose one git tree as the master git
then each maintainer will have their one git tree too
where they manage it how they
On 19:04 Tue 28 Jun , Øyvind Harboe wrote:
The best way to do is to choose one git tree as the master git
then each maintainer will have their one git tree too
where they manage it how they want.
All the maintainers have their own repositories and forks at the git
mirror, but we also
but now all the maintainer will have their own fork/repository
as done in the kernel
Right. And you will pull merge from us and push the result to the
master branch?
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
On 19:39 Tue 28 Jun , Øyvind Harboe wrote:
but now all the maintainer will have their own fork/repository
as done in the kernel
Right. And you will pull merge from us and push the result to the
master branch?
exactly
Best Regards,
J.
___
On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:39 Tue 28 Jun , Øyvind Harboe wrote:
but now all the maintainer will have their own fork/repository
as done in the kernel
Right. And you will pull merge from us and push the result to
On 19:15 Tue 28 Jun , Øyvind Harboe wrote:
On Tue, Jun 28, 2011 at 6:58 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:04 Tue 28 Jun , Øyvind Harboe wrote:
The best way to do is to choose one git tree as the master git
then each maintainer will have their
On Tue, Jun 28, 2011 at 1:56 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:39 Tue 28 Jun , Øyvind Harboe wrote:
but now all the maintainer will have their own fork/repository
as done
On 19:56 Tue 28 Jun , Øyvind Harboe wrote:
On Tue, Jun 28, 2011 at 7:30 PM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 19:39 Tue 28 Jun , Øyvind Harboe wrote:
but now all the maintainer will have their own fork/repository
as done in the kernel
Right. And
I'd have some reservations about only one person having write
access, but not particularly the way of working. Call me old fashioned.
Does not mean you do not have the write access does just mean you dont use it
As example if the release manager is in vacantion or too much busy you use it
but
On Tue, Jun 21, 2011 at 1:30 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
After some consideration, I've changed my view to that the
release manager should have git access and that the master
branch developers *should* follow the release managers
marching orders and that we follow the
Øyvind Harboe wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a
release branch there.
You pick whatever you want from the master branch or whatever patches
2011/6/21 Jon Povey jon.po...@racelogic.co.uk:
Øyvind Harboe wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a
release branch there.
You pick whatever you
On Fri, Jun 17, 2011 at 7:57 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a release branch there.
You pick whatever
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit stuff to the master branch without regards to a release.
I would like this to continue in the same manner, which I don't
think is in conflict with what you write.
- You create a fork of OpenOCD at the
On 08:17 Fri 17 Jun , Øyvind Harboe wrote:
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit stuff to the master branch without regards to a release.
I would like this to continue in the same manner, which I don't
think is in conflict with
On 08:17 Fri 17 Jun , Øyvind Harboe wrote:
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit stuff to the master branch without regards to a release.
I would like this to continue in the same manner, which I don't
think is in conflict with
On 08:35 Fri 17 Jun , Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:17 Fri 17 Jun , Øyvind Harboe wrote:
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit stuff to the master branch without regards to a release.
I would like this to
Am 06/17/2011 03:15 AM, schrieb Jean-Christophe PLAGNIOL-VILLARD:
Hi all,
I'd like to propose the following release cycle
For the people familiar with Linux kernel its basically the same
2 development window:
merge window
fix window
We will get 2
On Fri, Jun 17, 2011 at 8:25 AM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 08:17 Fri 17 Jun , Ųyvind Harboe wrote:
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit stuff to the master branch without regards to a release.
On 09:03 Fri 17 Jun , Øyvind Harboe wrote:
On Fri, Jun 17, 2011 at 8:25 AM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 08:17 Fri 17 Jun , Ųyvind Harboe wrote:
Some questions/comments:
- if we look at the current way we work with OpenOCD, we just
commit
so we do two tree the next tree (yours) and the release tree
if multiple maintainer eed to merge code together they will send it the the RM
in his next branch
the description will be what must follow the release tree for the other tree
the maintainer manage his own way
I am struggling a
On 09:57 Fri 17 Jun , Øyvind Harboe wrote:
so we do two tree the next tree (yours) and the release tree
if multiple maintainer eed to merge code together they will send it the the
RM
in his next branch
the description will be what must follow the release tree for the other tree
On 12:32 Fri 17 Jun , Øyvind Harboe wrote:
if possible a MAINTAINER file as done in the linux kernel
Do you want to write up the definitions and procedures in a patch for
MAINTAINER file and then I can commit it to OpenOCD master branch
before we start this cycle?
I think it will be
Hi all,
I'd like to propose the following release cycle
For the people familiar with Linux kernel its basically the same
2 development window:
merge window
fix window
We will get 2 weeks of merge window where any code can be merge in the
30 matches
Mail list logo
