commits following field experience during the last few months #166

Open
wants to merge 26 commits into
from

Conversation

Projects
None yet
4 participants
@y-trudeau
Contributor

y-trudeau commented Nov 4, 2012

All my commits since 3.9.3.

y-trudeau and others added some commits Jun 1, 2012

@fghaas

This comment has been minimized.

Show comment Hide comment
@fghaas

fghaas Nov 6, 2012

Member

@dmuhamedagic: as far as I'm concerned, with a patchset this large this is a NAK for the upcoming release. Let's revisit this after the release is cut.

@y-trudeau: can you please make a point, henceforth, to submit patches as you fix issues? This throw-over-the-wall style of large patchsets is making proper review exceptionally difficult.

Member

fghaas commented Nov 6, 2012

@dmuhamedagic: as far as I'm concerned, with a patchset this large this is a NAK for the upcoming release. Let's revisit this after the release is cut.

@y-trudeau: can you please make a point, henceforth, to submit patches as you fix issues? This throw-over-the-wall style of large patchsets is making proper review exceptionally difficult.

@dmuhamedagic

This comment has been minimized.

Show comment Hide comment
@dmuhamedagic

dmuhamedagic Nov 6, 2012

Contributor

If I'm able to see correctly, there are just a few fixes and features here. But we also get a full development history which makes it indeed quite a bit of unnecessary work for reviewers. @y-trudeau: could you rebase/fold your commits and issue another pull request which would not result in this large number of commits. If there's a new feature, it should come as a single commit.

The commit messages are not of the best quality. It is important to know what is the impact of each of the changes.

The problem here is that Yves is only occasionally involved in the upstream development. It makes it rather difficult also when we have mysql pull requests coming from other people which result in conflict with changes from the Yves' private project.

Contributor

dmuhamedagic commented Nov 6, 2012

If I'm able to see correctly, there are just a few fixes and features here. But we also get a full development history which makes it indeed quite a bit of unnecessary work for reviewers. @y-trudeau: could you rebase/fold your commits and issue another pull request which would not result in this large number of commits. If there's a new feature, it should come as a single commit.

The commit messages are not of the best quality. It is important to know what is the impact of each of the changes.

The problem here is that Yves is only occasionally involved in the upstream development. It makes it rather difficult also when we have mysql pull requests coming from other people which result in conflict with changes from the Yves' private project.

@y-trudeau

This comment has been minimized.

Show comment Hide comment
@y-trudeau

y-trudeau Nov 6, 2012

Contributor

Le 2012-11-06 02:16, Florian Haas a écrit :

@dmuhamedagic https://github.com/dmuhamedagic: as far as I'm
concerned, with a patchset this large this is a NAK for the upcoming
release. Let's revisit this after the release is cut.

I am perfectly fine with this but be aware many bugs in the 3.9.3
release are fixed in these commits.

@y-trudeau https://github.com/y-trudeau: can you please make a point,
henceforth, to submit patches as you fix issues? This
throw-over-the-wall style of large patchsets is making proper review
exceptionally difficult.

This time I succeeded to use git for my commits instead of sending patch
files to Dejan so yes, I can try to improve and send patches along the way.


Reply to this email directly or view it on GitHub
#166 (comment).

Contributor

y-trudeau commented Nov 6, 2012

Le 2012-11-06 02:16, Florian Haas a écrit :

@dmuhamedagic https://github.com/dmuhamedagic: as far as I'm
concerned, with a patchset this large this is a NAK for the upcoming
release. Let's revisit this after the release is cut.

I am perfectly fine with this but be aware many bugs in the 3.9.3
release are fixed in these commits.

@y-trudeau https://github.com/y-trudeau: can you please make a point,
henceforth, to submit patches as you fix issues? This
throw-over-the-wall style of large patchsets is making proper review
exceptionally difficult.

This time I succeeded to use git for my commits instead of sending patch
files to Dejan so yes, I can try to improve and send patches along the way.


Reply to this email directly or view it on GitHub
#166 (comment).

@y-trudeau

This comment has been minimized.

Show comment Hide comment
@y-trudeau

y-trudeau Nov 6, 2012

Contributor

Le 2012-11-06 05:08, Dejan Muhamedagic a écrit :

If I'm able to see correctly, there are just a few fixes and features
here. But we also get a full development history which makes it indeed
quite a bit of unnecessary work for reviewers. @y-trudeau
https://github.com/y-trudeau: could you rebase/fold your commits and
issue another pull request which would not result in this large number
of commits. If there's a new feature, it should come as a single commit.

Not sure I'll have time in the upcoming weeks to do that. Remember, I
am not a developer far from and Percona keeps me very busy.

The commit messages are not of the best quality. It is important to know
what is the impact of each of the changes.

That I can improve in the future and maybe revisit some of the old commits.

The problem here is that Yves is only occasionally involved in the
upstream development. It makes it rather difficult also when we have
mysql pull requests coming from other people which result in conflict
with changes from the Yves' private project.

That's why I took care of pulling the latest master branch and apply my
changes on it. Should I have pulled another branch?


Reply to this email directly or view it on GitHub
#166 (comment).

Contributor

y-trudeau commented Nov 6, 2012

Le 2012-11-06 05:08, Dejan Muhamedagic a écrit :

If I'm able to see correctly, there are just a few fixes and features
here. But we also get a full development history which makes it indeed
quite a bit of unnecessary work for reviewers. @y-trudeau
https://github.com/y-trudeau: could you rebase/fold your commits and
issue another pull request which would not result in this large number
of commits. If there's a new feature, it should come as a single commit.

Not sure I'll have time in the upcoming weeks to do that. Remember, I
am not a developer far from and Percona keeps me very busy.

The commit messages are not of the best quality. It is important to know
what is the impact of each of the changes.

That I can improve in the future and maybe revisit some of the old commits.

The problem here is that Yves is only occasionally involved in the
upstream development. It makes it rather difficult also when we have
mysql pull requests coming from other people which result in conflict
with changes from the Yves' private project.

That's why I took care of pulling the latest master branch and apply my
changes on it. Should I have pulled another branch?


Reply to this email directly or view it on GitHub
#166 (comment).

@dmuhamedagic

This comment has been minimized.

Show comment Hide comment
@dmuhamedagic

dmuhamedagic Nov 7, 2012

Contributor

On Tue, Nov 06, 2012 at 08:52:24AM -0800, Yves Trudeau wrote:

Le 2012-11-06 05:08, Dejan Muhamedagic a écrit :

If I'm able to see correctly, there are just a few fixes and features
here. But we also get a full development history which makes it indeed
quite a bit of unnecessary work for reviewers. @y-trudeau
https://github.com/y-trudeau: could you rebase/fold your commits and
issue another pull request which would not result in this large number
of commits. If there's a new feature, it should come as a single commit.

Not sure I'll have time in the upcoming weeks to do that. Remember, I
am not a developer far from and Percona keeps me very busy.

Well, your contributions are significant, don't know how that
doesn't make you a developer :)

The commit messages are not of the best quality. It is important to know
what is the impact of each of the changes.

That I can improve in the future and maybe revisit some of the old commits.

Thanks!

The problem here is that Yves is only occasionally involved in the
upstream development. It makes it rather difficult also when we have
mysql pull requests coming from other people which result in conflict
with changes from the Yves' private project.

That's why I took care of pulling the latest master branch and apply my
changes on it. Should I have pulled another branch?

No. There are also outstanding pull requests of which nobody took
care so far. Further, people don't see your work until you issue
a pull request.

Contributor

dmuhamedagic commented Nov 7, 2012

On Tue, Nov 06, 2012 at 08:52:24AM -0800, Yves Trudeau wrote:

Le 2012-11-06 05:08, Dejan Muhamedagic a écrit :

If I'm able to see correctly, there are just a few fixes and features
here. But we also get a full development history which makes it indeed
quite a bit of unnecessary work for reviewers. @y-trudeau
https://github.com/y-trudeau: could you rebase/fold your commits and
issue another pull request which would not result in this large number
of commits. If there's a new feature, it should come as a single commit.

Not sure I'll have time in the upcoming weeks to do that. Remember, I
am not a developer far from and Percona keeps me very busy.

Well, your contributions are significant, don't know how that
doesn't make you a developer :)

The commit messages are not of the best quality. It is important to know
what is the impact of each of the changes.

That I can improve in the future and maybe revisit some of the old commits.

Thanks!

The problem here is that Yves is only occasionally involved in the
upstream development. It makes it rather difficult also when we have
mysql pull requests coming from other people which result in conflict
with changes from the Yves' private project.

That's why I took care of pulling the latest master branch and apply my
changes on it. Should I have pulled another branch?

No. There are also outstanding pull requests of which nobody took
care so far. Further, people don't see your work until you issue
a pull request.

@dmuhamedagic

This comment has been minimized.

Show comment Hide comment
@dmuhamedagic

dmuhamedagic Nov 7, 2012

Contributor

On Tue, Nov 06, 2012 at 08:47:10AM -0800, Yves Trudeau wrote:

Le 2012-11-06 02:16, Florian Haas a écrit :

@dmuhamedagic https://github.com/dmuhamedagic: as far as I'm
concerned, with a patchset this large this is a NAK for the upcoming
release. Let's revisit this after the release is cut.

I am perfectly fine with this but be aware many bugs in the 3.9.3
release are fixed in these commits.

Can we then get the critical fixes?

@y-trudeau https://github.com/y-trudeau: can you please make a point,
henceforth, to submit patches as you fix issues? This
throw-over-the-wall style of large patchsets is making proper review
exceptionally difficult.

This time I succeeded to use git for my commits instead of sending patch
files to Dejan so yes, I can try to improve and send patches along the way.

Sending patches to the linux-ha-dev ML is also fine.

Contributor

dmuhamedagic commented Nov 7, 2012

On Tue, Nov 06, 2012 at 08:47:10AM -0800, Yves Trudeau wrote:

Le 2012-11-06 02:16, Florian Haas a écrit :

@dmuhamedagic https://github.com/dmuhamedagic: as far as I'm
concerned, with a patchset this large this is a NAK for the upcoming
release. Let's revisit this after the release is cut.

I am perfectly fine with this but be aware many bugs in the 3.9.3
release are fixed in these commits.

Can we then get the critical fixes?

@y-trudeau https://github.com/y-trudeau: can you please make a point,
henceforth, to submit patches as you fix issues? This
throw-over-the-wall style of large patchsets is making proper review
exceptionally difficult.

This time I succeeded to use git for my commits instead of sending patch
files to Dejan so yes, I can try to improve and send patches along the way.

Sending patches to the linux-ha-dev ML is also fine.

@dmuhamedagic

This comment has been minimized.

Show comment Hide comment
@dmuhamedagic

dmuhamedagic Jan 25, 2013

Contributor

@y-trudeau: can we improve the situation here somehow? Yves, can you recommend how to go forward.

Contributor

dmuhamedagic commented Jan 25, 2013

@y-trudeau: can we improve the situation here somehow? Yves, can you recommend how to go forward.

@y-trudeau

This comment has been minimized.

Show comment Hide comment
@y-trudeau

y-trudeau Jan 25, 2013

Contributor

@dmuhamedagic: I have no idea on how to do otherwise than what I did. I am developing in my branch, fixing bugs and adding features. I can't or don't know how to commit to my branch and the main branch at the same time. We need to do something because since crm is no longer installed by default the agent in the main branch will be having issues soon. I plan to remove all reference to "crm" and use only "crm_attribute" and "crm_resources". BTW, coming soon is support for geo redundancy with booth.

Contributor

y-trudeau commented Jan 25, 2013

@dmuhamedagic: I have no idea on how to do otherwise than what I did. I am developing in my branch, fixing bugs and adding features. I can't or don't know how to commit to my branch and the main branch at the same time. We need to do something because since crm is no longer installed by default the agent in the main branch will be having issues soon. I plan to remove all reference to "crm" and use only "crm_attribute" and "crm_resources". BTW, coming soon is support for geo redundancy with booth.

@dmuhamedagic

This comment has been minimized.

Show comment Hide comment
@dmuhamedagic

dmuhamedagic Jan 2, 2015

Contributor

@y-trudeau there will be a new release soon, the rc is planned for mid January. Do you see some fixes urgently needed for mysql?

Contributor

dmuhamedagic commented Jan 2, 2015

@y-trudeau there will be a new release soon, the rc is planned for mid January. Do you see some fixes urgently needed for mysql?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment