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.
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
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
th
-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 us
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
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
adop
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#dis
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 thin
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 seems like there are two sides thus far about how to proceed: one being
that we should accept and implement PUP-3, and the other being that we
should tweak our current process. I’d like to propose the following
solution.
For the 2.14 release, we try out one of the tweaks to our current git
work
I want to make a case to adopt the PUP as its written. 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.
On Tue, Jun 6, 2017 at 9:04 AM, David Davis wrote:
> It seem
On Fri, Jun 2, 2017 at 12:01 PM, Brian Bouterse wrote:
> Yes we should enable branch protection to prevent all pushes using that
> script. That is one of the main benefits that accepting this pup would
> allow (I think).
I think doing this would be at least as beneficial in a merge-forward mode
Yes we should enable branch protection to prevent all pushes using that
script. That is one of the main benefits that accepting this pup would
allow (I think).
On Fri, Jun 2, 2017 at 10:48 AM, Michael Hrivnak
wrote:
> We already have this script to automatically set branches as protected:
>
> ht
We already have this script to automatically set branches as protected:
https://github.com/pulp/devel/blob/master/scripts/protect-branches.py
And it could easily disable push also.
On Fri, Jun 2, 2017 at 10:44 AM, Patrick Creech wrote:
> On Fri, 2017-06-02 at 16:21 +0200, Ina Panova wrote:
> >
On Fri, 2017-06-02 at 16:21 +0200, Ina Panova wrote:
> That's correct, we need not to forget to set the new branch as protected.
>
This can be included in the process for creating new .y releases to ensure it's
done at creation
time.
signature.asc
Description: This is a digitally signed message
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
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 t
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 branc
Regarding improving our current git workflow, I do have a proposal on the
PUP-3 as an alternative:
https://github.com/daviddavis/pups/blob/54907337a9211671cd908327fe3ba9b7dd93e750/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 thi
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 apo
Just wanted to thank everyone that’s voted or replied already. Some great
discussions on this proposal so far.
There are four more calendar days left to vote. So if you haven’t voted
yet, please do so in the couple days.
Thank you.
David
On Tue, May 30, 2017 at 3:07 PM, Eric Helms wrote:
> A
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
rel
+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 co
+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
+0 from me
I think community contributions can be handled well in both cases,
merge-forward or cherry-pick.
As for the difficulty it is more a matter of habit, in my opinion.
I expect the cherry-pick approach to be less error-prone and mostly for
that reason I would give it a try with all the dra
Currently, "The general rule is to always choose the oldest upstream branch
that will need to contain your work." [0] In practice, this means that
bugfixes will default to an x.y-dev branch (and therefore a z release). The
PUP-3 process would include bugfixes in x.y-dev only if we actively decide
t
Usually, you tend not have your PR opened for months,especially if it is a
bugfix tracked in our sprint :)
Really, what is difficult about step 5 and 6 i don't understand? you pull
changes so branch is up to date, then you merge into this branch, then you
push to upstream. If there are conflicts y
The ability for us to change the PR branch does eliminate some of the back
and forth with the contributor so that is addressed and good. I hadn't
thought of that.
The reason I'm still +1 is because I have two main concerns with the
current processes: conflict resolution and avoiding the epic merge
The current workflow is more than a two-step process. To expand all the
steps:
1. Decide what x.y-dev branch to open a PR against
2. Open a PR against that branch
3. After the PR is accepted, decide if you can actually still merge it
against the branch. This is necessary if for example, if I opene
To address your concern about how to handle community contributions (1), in
GitHub, you can change the base branch of any PR if you have commit access
to the repo. So contributors could open PRs against master and then we
could switch it to the correct x.y-dev branch if needed, Github will
automati
-0
I don't know, i am personally not super excited about cherry-picking, too
many involved resources imho in order to compensate crazy git history.
1. submit pr against master
2. decide into which branches it should be cherry-picked
3. submit PRs against those branches
4. Find someone to approve
On 05/25/2017 10:30 AM, Patrick Creech wrote:
> -1
>
> While trying to come up with a decision on this topic, I googled "git merge
> vs cherry-pick". The
> overwhelming ammount of search results were basically 'don't cherry-pick!'.
> The page that I favored
> is [0]. It brings up some good po
+1 from me
I read the article, but does it really apply to us? The issues it describes
stemsfrom "when a change is cherry-picked into a branch and there is a
conflict a new commitid is created". In our case when a cherry pick back
creates a conflict we are recommending to abandon the cherry pick [
-1
I've come late to this topic, and wanted to wait till voting time to form an
opinion, so I apologize
if some of the reasons I'm voting -1 have already been discussed and brought up.
While trying to come up with a decision on this topic, I googled "git merge vs
cherry-pick". The
overwhelming
+1
On Wed, May 24, 2017 at 4: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-0
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].
36 matches
Mail list logo
