Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[David Davis]

Thanks to everyone who voted and responded. The final vote is:

+1 - 5 votes
+0 - 1 vote
-0 - 3 votes
-1 - 0 votes

I’m going to wait though before I call this PUP approved until we reach a
decision in our discussion on the pulp-dev mailing list about what
constitutes consensus in our PUP process. If approved, I’ll then open up a
plan.io task with a plan to move forward.


David

On Mon, Jun 12, 2017 at 1:03 PM, Brian Bouterse  wrote:

> Yes, it's more of a guide than an absolute rule. If a merging developer
> wants to cherry-pick and resolve conflicts, we should not disallow that. To
> capture that aspect, the current language could be reverted back to the "we
> should consider..." language that would allow the merger to have discretion
> and choice.
>
> I'm +1 still in both cases.
>
> As an aside, reviewing a merge conflict resolution is not easy in git. I'm
> stating this hoping I just don't understand it and that someone can show me
> how it's done some other time. After spending a good amount of time in #git
> one day on this topic w/ @asmacdo I'm convinced this isn't a use case git
> handles well. If that is true then having a review process for conflict
> resolution is something git and github won't allow us to facilitate. I hope
> I'm wrong about this.
>
> -Brian
>
>
> On Mon, Jun 12, 2017 at 10:01 AM, David Davis 
> wrote:
>
>> Regarding your concern about not cherry-picking if there are conflicts,
>> the PUP originally said “we should consider …”. I think we went with
>> stronger language though to dissuade developers from cherry-picking (by
>> default) if there are conflicts. That said, as in the use case you mention,
>> I think that’s a perfectly fine example of when it’s ok to cherry-pick even
>> though there’s a conflict. I think of this as more of a guideline than an
>> absolute rule.
>>
>>
>> David
>>
>> On Mon, Jun 12, 2017 at 9:23 AM, Michael Hrivnak 
>> wrote:
>>
>>> -0 for similar reasons to those already discussed.
>>>
>>> We've identified alternatives that would address many of the concerns
>>> listed in the Motivation section. To re-cap:
>>>
>>> Merge mistakes: we have multiple options we could implement with the
>>> merge-forward option.
>>>
>>> Community PR rebasing: we can either use the new github feature to
>>> auto-rebase, or take the same approach as the PUP (let the PR stay on
>>> master) and just accept that some of those changes won't make it into a Z
>>> release.
>>>
>>> Merge conflict resolution: the PUP says this can lead to mistakes that
>>> go unreviewed, but we've also heard feedback in this discussion that
>>> merging forward is almost never a problem. My view is that on rare
>>> occasions a merge conflict can get resolved incorrectly, but it's not a
>>> substantial problem for us, and those cases should be easily caught with
>>> automated testing. We will make mistakes that break master for lots of
>>> reasons, some that even go unnoticed in review. We should strive to make
>>> those rare, but also should have confidence that our testing will catch
>>> such problems and enable us to quickly correct them. Our current guidelines
>>> do encourage review for merge conflicts that are substantial:
>>>
>>> http://docs.pulpproject.org/dev-guide/contributing/merging.h
>>> tml#merging-your-changes
>>>
>>> We could make the language around that stronger, or even require review
>>> for such cases.
>>>
>>> All of that said, while I think we have ways to address nearly all the
>>> PUP's concerns without changing to a cherry-pick model, I'm certainly
>>> willing to try such a model. My preference would be to try some
>>> less-drastic changes to our process first, and see how that goes. But I am
>>> sure that we could be successful with a cherry-pick model, and given broad
>>> interest am willing to try it.
>>>
>>> I have only one big concern: "If the cherry-pick has conflicts, we
>>> should abandon the cherry-pick and encourage users to upgrade to the next Y
>>> release." I worry that this will have a big impact on our ability to
>>> deliver bug fixes. As long as we retain some discretion to employ a small
>>> amount of conflict resolution when reasonable, I think this could be a fine
>>> guideline. But if we were to apply it as an absolute rule, it may affect
>>> many more changes, and substantially slow down our ability to release fixes
>>> early and often. For example, often when we see a conflict, it is with
>>> import statements. It would be a shame to omit a fix from a Z release over
>>> that.
>>>
>>> On Fri, Jun 9, 2017 at 9:09 AM, David Davis 
>>> wrote:
>>>
 Just wanted to send out a reminder that voting is ending on Monday,
 June 12 at 9pm UTC. I haven’t seen much of a response around trying to
 adopt an alternative to PUP-3 that doesn’t involve cherry-picking so I am
 going to assume there isn’t much interest in doing so. Again, please
 respond with any thoughts 

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[Michael Hrivnak]

-0 for similar reasons to those already discussed.

We've identified alternatives that would address many of the concerns
listed in the Motivation section. To re-cap:

Merge mistakes: we have multiple options we could implement with the
merge-forward option.

Community PR rebasing: we can either use the new github feature to
auto-rebase, or take the same approach as the PUP (let the PR stay on
master) and just accept that some of those changes won't make it into a Z
release.

Merge conflict resolution: the PUP says this can lead to mistakes that go
unreviewed, but we've also heard feedback in this discussion that merging
forward is almost never a problem. My view is that on rare occasions a
merge conflict can get resolved incorrectly, but it's not a substantial
problem for us, and those cases should be easily caught with automated
testing. We will make mistakes that break master for lots of reasons, some
that even go unnoticed in review. We should strive to make those rare, but
also should have confidence that our testing will catch such problems and
enable us to quickly correct them. Our current guidelines do encourage
review for merge conflicts that are substantial:

http://docs.pulpproject.org/dev-guide/contributing/merging.html#merging-your-changes

We could make the language around that stronger, or even require review for
such cases.

All of that said, while I think we have ways to address nearly all the
PUP's concerns without changing to a cherry-pick model, I'm certainly
willing to try such a model. My preference would be to try some
less-drastic changes to our process first, and see how that goes. But I am
sure that we could be successful with a cherry-pick model, and given broad
interest am willing to try it.

I have only one big concern: "If the cherry-pick has conflicts, we should
abandon the cherry-pick and encourage users to upgrade to the next Y
release." I worry that this will have a big impact on our ability to
deliver bug fixes. As long as we retain some discretion to employ a small
amount of conflict resolution when reasonable, I think this could be a fine
guideline. But if we were to apply it as an absolute rule, it may affect
many more changes, and substantially slow down our ability to release fixes
early and often. For example, often when we see a conflict, it is with
import statements. It would be a shame to omit a fix from a Z release over
that.

On Fri, Jun 9, 2017 at 9:09 AM, David Davis  wrote:

> Just wanted to send out a reminder that voting is ending on Monday, June
> 12 at 9pm UTC. I haven’t seen much of a response around trying to adopt an
> alternative to PUP-3 that doesn’t involve cherry-picking so I am going to
> assume there isn’t much interest in doing so. Again, please respond with
> any thoughts or feel free to change your vote if that’s not the case.
> Thanks.
>
>
> David
>
> On Tue, Jun 6, 2017 at 4:59 PM, David Davis  wrote:
>
>> Talking with @bmbouter a little more about the PUP process and looking
>> back at PUP-1, I think that the only way for PUP-3 to not be accepted is if
>> a core developer were to cast/recast a -1 vote. I know there has been talk
>> about alternatives but looking at the votes, there is a consensus around
>> adopting PUP-3:
>>
>> +1 - 5 votes
>> +0 - 1 vote
>> -0 - 2 votes
>> -1 - 0 votes
>>
>> If anyone feels strongly about trying out an alternative or discussing
>> alternatives further, please recast your vote or respond with your
>> concerns. Otherwise, I think we'll proceed with approving/rejecting the PUP
>> based on the votes on the deadline of June 12th.
>>
>>
>> David
>>
>> On Tue, Jun 6, 2017 at 4:27 PM, David Davis 
>> wrote:
>>
>>> I have updated the proposal’s motivation section. Note that the actual
>>> change/workflow hasn’t changed at all.
>>>
>>>
>>> David
>>>
>>> On Tue, Jun 6, 2017 at 4:08 PM, David Davis 
>>> wrote:
>>>
 Looks like @bmbouter made a comment to include this but I forgot to
 include it:

 https://github.com/pulp/pups/pull/3#discussion_r111498031

 Will update the PUP.


 David

 On Tue, Jun 6, 2017 at 3:48 PM, Michael Hrivnak 
 wrote:

>
> On Tue, Jun 6, 2017 at 9:58 AM, Brian Bouterse 
> wrote:
>
>> I think we need to redo the git workflow because we can't continue to
>> resolve conflicts during merge forward as we did before. I see that as 
>> the
>> central issue the PUP is resolving.
>
>
> The PUP likely needs additional revision in that case; it does not
> mention conflict resolution at all as a motivation. It would be valuable 
> to
> spell that out and discuss it.
>
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>


>>>
>>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red 

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[David Davis]

Just wanted to send out a reminder that voting is ending on Monday, June 12
at 9pm UTC. I haven’t seen much of a response around trying to adopt an
alternative to PUP-3 that doesn’t involve cherry-picking so I am going to
assume there isn’t much interest in doing so. Again, please respond with
any thoughts or feel free to change your vote if that’s not the case.
Thanks.


David

On Tue, Jun 6, 2017 at 4:59 PM, David Davis  wrote:

> Talking with @bmbouter a little more about the PUP process and looking
> back at PUP-1, I think that the only way for PUP-3 to not be accepted is if
> a core developer were to cast/recast a -1 vote. I know there has been talk
> about alternatives but looking at the votes, there is a consensus around
> adopting PUP-3:
>
> +1 - 5 votes
> +0 - 1 vote
> -0 - 2 votes
> -1 - 0 votes
>
> If anyone feels strongly about trying out an alternative or discussing
> alternatives further, please recast your vote or respond with your
> concerns. Otherwise, I think we'll proceed with approving/rejecting the PUP
> based on the votes on the deadline of June 12th.
>
>
> David
>
> On Tue, Jun 6, 2017 at 4:27 PM, David Davis  wrote:
>
>> I have updated the proposal’s motivation section. Note that the actual
>> change/workflow hasn’t changed at all.
>>
>>
>> David
>>
>> On Tue, Jun 6, 2017 at 4:08 PM, David Davis 
>> wrote:
>>
>>> Looks like @bmbouter made a comment to include this but I forgot to
>>> include it:
>>>
>>> https://github.com/pulp/pups/pull/3#discussion_r111498031
>>>
>>> Will update the PUP.
>>>
>>>
>>> David
>>>
>>> On Tue, Jun 6, 2017 at 3:48 PM, Michael Hrivnak 
>>> wrote:
>>>

 On Tue, Jun 6, 2017 at 9:58 AM, Brian Bouterse 
 wrote:

> I think we need to redo the git workflow because we can't continue to
> resolve conflicts during merge forward as we did before. I see that as the
> central issue the PUP is resolving.


 The PUP likely needs additional revision in that case; it does not
 mention conflict resolution at all as a motivation. It would be valuable to
 spell that out and discuss it.


 --

 Michael Hrivnak

 Principal Software Engineer, RHCE

 Red Hat

>>>
>>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[David Davis]

Looks like @bmbouter made a comment to include this but I forgot to include
it:

https://github.com/pulp/pups/pull/3#discussion_r111498031

Will update the PUP.


David

On Tue, Jun 6, 2017 at 3:48 PM, Michael Hrivnak  wrote:

>
> On Tue, Jun 6, 2017 at 9:58 AM, Brian Bouterse 
> wrote:
>
>> I think we need to redo the git workflow because we can't continue to
>> resolve conflicts during merge forward as we did before. I see that as the
>> central issue the PUP is resolving.
>
>
> The PUP likely needs additional revision in that case; it does not mention
> conflict resolution at all as a motivation. It would be valuable to spell
> that out and discuss it.
>
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[Ina Panova]

That's correct, we need not to forget to set the new branch as protected.




Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Fri, Jun 2, 2017 at 3:52 PM, David Davis  wrote:

> I like the first proposal of disabling pushes to all branches except
> master. It’s simple and effective. My only question is when we create a new
> branch, I’m guessing we’ll have to remember to set it to protected?
>
> Also, I am going to extend voting for another week until June 12 9pm UTC
> to give us time to discuss alternatives.
>
>
> David
>
> On Thu, Jun 1, 2017 at 4:36 PM, Michael Hrivnak 
> wrote:
>
>> There are definitely additional options to improve the current process.
>>
>> One way to prevent accidental merges is to just disable push to all
>> branches except master. Merging to all other branches would happen via the
>> "merge" button on a pull request. The normal workflow of merging to a
>> x.y-dev branch and then to master would stay the same. For the less-common
>> occasion when you need to merge stuff to more places, a quick PR is a small
>> price to pay for seeing exactly what changes you're about to merge. I think
>> we would not require review of such PRs.
>>
>> We could also run a check before doing a push. For example, client-side
>> push hooks could easily ensure that the changes being pushed are
>> acceptable. When I experimented with this in the past, I focused on the
>> idea of a "forbidden commit". When creating 2.14-dev, we would identify the
>> next commit on master that is not part of 2.14, and that becomes the
>> "forbidden commit" for the 2.14-dev branch. Any simple automation, hook or
>> not, can check if an incoming push contains the forbidden commit, and
>> reject it if so.
>>
>> Another option is to use some other automation to do the merging and/or
>> pushing for us, which is a common approach. That may be valuable with
>> cherry-picking also. For example, maybe you can push a branch to your fork,
>> but some other tool or service has to merge that into the main Pulp repo
>> after validating it.
>>
>> In any case, there are options. It's definitely in the spirit of the PUP
>> process to explore all the options, so I'm glad we're having this
>> discussion.
>>
>> On Thu, Jun 1, 2017 at 3:36 PM, David Davis 
>> wrote:
>>
>>> Regarding improving our current git workflow, I do have a proposal on
>>> the PUP-3 as an alternative:
>>>
>>> https://github.com/daviddavis/pups/blob/54907337a9211671cd90
>>> 8327fe3ba9b7dd93e750/pup-0003.md#merge-forward-less-often
>>>
>>> In it, we’d merge forward less often (e.g. once a week?) and do so via
>>> PR. I think this solves one of the biggest problems we’ve seen with merging
>>> forward: mistakes. However, it has some issues:
>>>
>>> 1. Who will perform the merge forward and how often will they perform it?
>>> 2. The person performing the merge forward won’t have the specialized
>>> knowledge to merge forward all the commits and fix any merge conflicts.
>>> That said, they can work with the commit authors to do so and conflict
>>> resolutions can be checked in the merge forward PR.
>>> 3. Contributions (as raised by @ehelms and @bmbouter) still must go
>>> against x.y-dev branches
>>>
>>> Maybe there are other alternatives as well?
>>>
>>>
>>> David
>>>
>>> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech 
>>> wrote:
>>>
 On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote:
 > -1

 I'm changing my vote to -0 to better reflect my initial intention of
 expressing my dissent, but not
 blocking the passage of this outright; as I do not believe I have
 enough knowledge and experience in
 this argument to do such.  (I apologize for any frustration, I wasn't
 aware at the time my -1 would
 solely block this.  I should have RTFM'ed).

 To follow up, I want to re-summarize my dissent here.

 I don't know all the ins and outs of this argument, and decided to keep
 it this way to better
 analyze the argument with minimal prior knowledge.  This was to be able
 to come to this at voting
 time with fresh eyes, and have a layman's take.  This allowed me to
 take the public artifacts here
 at face value to understand why we are doing this, and what direction
 we're heading.

 Upon a naive initial searching of google, it appears that the general
 public sentiment is to not
 cherry-pick by default.  I don't doubt that some of these results
 aren't the most reliable, but the
 general sentiment is overwhelming.  To me, this meant that we need to
 have the reasons and benefits
 of moving to cherry-picking clearly spelled out as the obvious choice.
 I didn't pick up on that
 sentiment from reading the e-mail chain and PUP.

 On the suggestion of 

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[David Davis]

I like the first proposal of disabling pushes to all branches except
master. It’s simple and effective. My only question is when we create a new
branch, I’m guessing we’ll have to remember to set it to protected?

Also, I am going to extend voting for another week until June 12 9pm UTC to
give us time to discuss alternatives.


David

On Thu, Jun 1, 2017 at 4:36 PM, Michael Hrivnak  wrote:

> There are definitely additional options to improve the current process.
>
> One way to prevent accidental merges is to just disable push to all
> branches except master. Merging to all other branches would happen via the
> "merge" button on a pull request. The normal workflow of merging to a
> x.y-dev branch and then to master would stay the same. For the less-common
> occasion when you need to merge stuff to more places, a quick PR is a small
> price to pay for seeing exactly what changes you're about to merge. I think
> we would not require review of such PRs.
>
> We could also run a check before doing a push. For example, client-side
> push hooks could easily ensure that the changes being pushed are
> acceptable. When I experimented with this in the past, I focused on the
> idea of a "forbidden commit". When creating 2.14-dev, we would identify the
> next commit on master that is not part of 2.14, and that becomes the
> "forbidden commit" for the 2.14-dev branch. Any simple automation, hook or
> not, can check if an incoming push contains the forbidden commit, and
> reject it if so.
>
> Another option is to use some other automation to do the merging and/or
> pushing for us, which is a common approach. That may be valuable with
> cherry-picking also. For example, maybe you can push a branch to your fork,
> but some other tool or service has to merge that into the main Pulp repo
> after validating it.
>
> In any case, there are options. It's definitely in the spirit of the PUP
> process to explore all the options, so I'm glad we're having this
> discussion.
>
> On Thu, Jun 1, 2017 at 3:36 PM, David Davis  wrote:
>
>> Regarding improving our current git workflow, I do have a proposal on the
>> PUP-3 as an alternative:
>>
>> https://github.com/daviddavis/pups/blob/54907337a9211671cd90
>> 8327fe3ba9b7dd93e750/pup-0003.md#merge-forward-less-often
>>
>> In it, we’d merge forward less often (e.g. once a week?) and do so via
>> PR. I think this solves one of the biggest problems we’ve seen with merging
>> forward: mistakes. However, it has some issues:
>>
>> 1. Who will perform the merge forward and how often will they perform it?
>> 2. The person performing the merge forward won’t have the specialized
>> knowledge to merge forward all the commits and fix any merge conflicts.
>> That said, they can work with the commit authors to do so and conflict
>> resolutions can be checked in the merge forward PR.
>> 3. Contributions (as raised by @ehelms and @bmbouter) still must go
>> against x.y-dev branches
>>
>> Maybe there are other alternatives as well?
>>
>>
>> David
>>
>> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech 
>> wrote:
>>
>>> On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote:
>>> > -1
>>>
>>> I'm changing my vote to -0 to better reflect my initial intention of
>>> expressing my dissent, but not
>>> blocking the passage of this outright; as I do not believe I have enough
>>> knowledge and experience in
>>> this argument to do such.  (I apologize for any frustration, I wasn't
>>> aware at the time my -1 would
>>> solely block this.  I should have RTFM'ed).
>>>
>>> To follow up, I want to re-summarize my dissent here.
>>>
>>> I don't know all the ins and outs of this argument, and decided to keep
>>> it this way to better
>>> analyze the argument with minimal prior knowledge.  This was to be able
>>> to come to this at voting
>>> time with fresh eyes, and have a layman's take.  This allowed me to take
>>> the public artifacts here
>>> at face value to understand why we are doing this, and what direction
>>> we're heading.
>>>
>>> Upon a naive initial searching of google, it appears that the general
>>> public sentiment is to not
>>> cherry-pick by default.  I don't doubt that some of these results aren't
>>> the most reliable, but the
>>> general sentiment is overwhelming.  To me, this meant that we need to
>>> have the reasons and benefits
>>> of moving to cherry-picking clearly spelled out as the obvious choice.
>>> I didn't pick up on that
>>> sentiment from reading the e-mail chain and PUP.
>>>
>>> On the suggestion of improving our current merge forward process, that
>>> window is left open by others
>>> in the public record appearing to suggest this as a viable option.  If
>>> that is in fact an accurate
>>> representation, then to me that is the more preferable route as it
>>> sounds like improvements to our
>>> current course instead of charting a complete new one.  If this is not
>>> the case, then it probably
>>> should be stated clearly 

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[Michael Hrivnak]

There are definitely additional options to improve the current process.

One way to prevent accidental merges is to just disable push to all
branches except master. Merging to all other branches would happen via the
"merge" button on a pull request. The normal workflow of merging to a
x.y-dev branch and then to master would stay the same. For the less-common
occasion when you need to merge stuff to more places, a quick PR is a small
price to pay for seeing exactly what changes you're about to merge. I think
we would not require review of such PRs.

We could also run a check before doing a push. For example, client-side
push hooks could easily ensure that the changes being pushed are
acceptable. When I experimented with this in the past, I focused on the
idea of a "forbidden commit". When creating 2.14-dev, we would identify the
next commit on master that is not part of 2.14, and that becomes the
"forbidden commit" for the 2.14-dev branch. Any simple automation, hook or
not, can check if an incoming push contains the forbidden commit, and
reject it if so.

Another option is to use some other automation to do the merging and/or
pushing for us, which is a common approach. That may be valuable with
cherry-picking also. For example, maybe you can push a branch to your fork,
but some other tool or service has to merge that into the main Pulp repo
after validating it.

In any case, there are options. It's definitely in the spirit of the PUP
process to explore all the options, so I'm glad we're having this
discussion.

On Thu, Jun 1, 2017 at 3:36 PM, David Davis  wrote:

> Regarding improving our current git workflow, I do have a proposal on the
> PUP-3 as an alternative:
>
> https://github.com/daviddavis/pups/blob/54907337a9211671cd908327fe3ba9
> b7dd93e750/pup-0003.md#merge-forward-less-often
>
> In it, we’d merge forward less often (e.g. once a week?) and do so via PR.
> I think this solves one of the biggest problems we’ve seen with merging
> forward: mistakes. However, it has some issues:
>
> 1. Who will perform the merge forward and how often will they perform it?
> 2. The person performing the merge forward won’t have the specialized
> knowledge to merge forward all the commits and fix any merge conflicts.
> That said, they can work with the commit authors to do so and conflict
> resolutions can be checked in the merge forward PR.
> 3. Contributions (as raised by @ehelms and @bmbouter) still must go
> against x.y-dev branches
>
> Maybe there are other alternatives as well?
>
>
> David
>
> On Thu, Jun 1, 2017 at 2:34 PM, Patrick Creech  wrote:
>
>> On Thu, 2017-05-25 at 10:30 -0400, Patrick Creech wrote:
>> > -1
>>
>> I'm changing my vote to -0 to better reflect my initial intention of
>> expressing my dissent, but not
>> blocking the passage of this outright; as I do not believe I have enough
>> knowledge and experience in
>> this argument to do such.  (I apologize for any frustration, I wasn't
>> aware at the time my -1 would
>> solely block this.  I should have RTFM'ed).
>>
>> To follow up, I want to re-summarize my dissent here.
>>
>> I don't know all the ins and outs of this argument, and decided to keep
>> it this way to better
>> analyze the argument with minimal prior knowledge.  This was to be able
>> to come to this at voting
>> time with fresh eyes, and have a layman's take.  This allowed me to take
>> the public artifacts here
>> at face value to understand why we are doing this, and what direction
>> we're heading.
>>
>> Upon a naive initial searching of google, it appears that the general
>> public sentiment is to not
>> cherry-pick by default.  I don't doubt that some of these results aren't
>> the most reliable, but the
>> general sentiment is overwhelming.  To me, this meant that we need to
>> have the reasons and benefits
>> of moving to cherry-picking clearly spelled out as the obvious choice.  I
>> didn't pick up on that
>> sentiment from reading the e-mail chain and PUP.
>>
>> On the suggestion of improving our current merge forward process, that
>> window is left open by others
>> in the public record appearing to suggest this as a viable option.  If
>> that is in fact an accurate
>> representation, then to me that is the more preferable route as it sounds
>> like improvements to our
>> current course instead of charting a complete new one.  If this is not
>> the case, then it probably
>> should be stated clearly somewhere as to why it isn't a good option.
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
___
Pulp-dev mailing list
Pulp-dev@redhat.com

Re: [Pulp-dev] PUP-3: Proposal to change our git workflow

[Eric Helms]

As an outside contributor, I'd +1 switching to cherry picking to avoid
having this conversation everytime a contributor wants to clone the repo,
make a change, push the change [1]. I think you increase the likelihood of
first time and repeat contributions if users do not have to be aware of the
release process and can simply clone the repository, get the default branch
which most developers these days perceive as the head of development and
where changes should be made.

As someone who has managed project release that heavily use cherry picking,
I've found this process to be painless especially after a bit of tooling
that uses Redmine to tell me what set of issues are required, what are
their changesets and what git hashes are associated with them. Two commands
and cherry picking done.


[1] https://github.com/pulp/pulp/pull/3037

On Tue, May 30, 2017 at 1:30 PM, Bihan Zhang  wrote:

> +1 I think it's worth giving this new process a try.
> An additional benefit that I have not seen listed is that github push
> protection can be turned on to all the branches. Which would have someone
> else sanity check changes before merging.
>
> It also means each release only generates one additional commit instead of
> the 6+ commits per release generated now.
>
>
> On Tue, May 30, 2017 at 10:11 AM, Jeff Ortel  wrote:
>
>> +1
>>
>> On 05/24/2017 03:00 PM, David Davis wrote:
>> > I’d like to kick off the voting on PUP-3 which is the proposal to
>> change our git workflow by using
>> > cherry-picks instead of merging changes forward. The proposal can be
>> viewed here:
>> >
>> > https://github.com/daviddavis/pups/blob/pup3/pup-0003.md
>> >
>> > Feel free to submit any comments/nitpicks/etc on the PR[0].
>> >
>> > PUP-1 outlines our voting system:
>> >
>> > https://github.com/pulp/pups/blob/master/pup-0001.md
>> >
>> > But to sum it up:
>> >
>> > +1: "Will benefit the project and should definitely be adopted."
>> > +0: "Might benefit the project and is acceptable."
>> > -0: "Might not be the right choice but is acceptable."
>> > -1: "Not the right choice and should definitely not be adopted."
>> >
>> > I’ll set the initial deadline for the voting to be June 5th 9pm UTC.
>> >
>> > [0] https://github.com/pulp/pups/pull/3
>> >
>> > David
>> >
>> >
>> > ___
>> > Pulp-dev mailing list
>> > Pulp-dev@redhat.com
>> > https://www.redhat.com/mailman/listinfo/pulp-dev
>> >
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] PUP-3: Proposal to change our git workflow

[David Davis]

I’d like to kick off the voting on PUP-3 which is the proposal to change
our git workflow by using cherry-picks instead of merging changes forward.
The proposal can be viewed here:

https://github.com/daviddavis/pups/blob/pup3/pup-0003.md

Feel free to submit any comments/nitpicks/etc on the PR[0].

PUP-1 outlines our voting system:

https://github.com/pulp/pups/blob/master/pup-0001.md

But to sum it up:

+1: "Will benefit the project and should definitely be adopted."
+0: "Might benefit the project and is acceptable."
-0: "Might not be the right choice but is acceptable."
-1: "Not the right choice and should definitely not be adopted."

I’ll set the initial deadline for the voting to be June 5th 9pm UTC.

[0] https://github.com/pulp/pups/pull/3

David
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev