REMINDER - Merge Pull Requests

[Rick Salevsky]

Hi all,

this mail is a reminder to review and merge as many PRs as possible
before the repository merge on Friday. Unmerged PRs for all the master
branches will be closed automatically and you need to recreate them.

Ciao,
Rick

[Dirk Müller]

Hi Rick,

> this mail is a reminder to review and merge as many PRs as possible
> before the repository merge on Friday. Unmerged PRs for all the master
> branches will be closed automatically and you need to recreate them.

I'm not sure I understand what would cause unmerged PRs for master
branch to be closed automatically? What is the reason for that? are
you going to delete the master branches from those modules?

With almost 100 open PRs, I don't think its realistic to get most of
them merged in the remaining time, and even if, the result would most
likely be a slight desaster ;-)


Thanks,
Dirk

[Thomas Boerger]

Quite simple, as already discussed, the open pull requests will be closed with a comment that refers to the new home to get reopened by the author against the new repository.

> --
> You received this message because you are subscribed to the Google Groups "crowbar" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to crowbar+u...@googlegroups.com.
> To post to this group, send email to cro...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/crowbar/CAJaQmt9mQoki-F6KOMnOc4BA9GbsH7V3eUz5d5WJYUvvYmBiYQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Dirk Müller]

Hi Thomas,

> Quite simple, as already discussed, the open pull requests will be closed with a comment that refers to the new home to get reopened by the author against the new repository.

Ah, so there is no automatism involved. so how about adding a comment
and give the submitter a reasonable timeframe (a week?) to rebase the
patch before closing it? This way we at least know what is being lost
in the process :)

TIA,
Dirk

[Thomas Boerger]

We already anounced it last week, and will close on thursday. So it will already be a week. At some point we simply have to do the switch.

> --
> You received this message because you are subscribed to the Google Groups "crowbar" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to crowbar+u...@googlegroups.com.
> To post to this group, send email to cro...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/crowbar/CAJaQmt_xv-%3DGYTcN7XTdDDpXwzOEo-xf2f761t77L7_QDdq8pw%40mail.gmail.com.

[Rick Salevsky]

The merge was originally planed for last Friday and we extend the time
frame until this Friday. So we gave already some extra time and two
weeks should be enough for preparation. Additionally I doesn't see a big
problem for closing all PRs. The author only needs to reopen them
against the new repo, for the most cases should no rebase needed.

Ciao,
Rick

[Dirk Müller]

Hi Rick,

> The merge was originally planed for last Friday and we extend the time
> frame until this Friday. So we gave already some extra time and two
> weeks should be enough for preparation. Additionally I doesn't see a big
> problem for closing all PRs. The author only needs to reopen them
> against the new repo, for the most cases should no rebase needed.

If there is no problem for reopening against the new repo, why closing
them in the first place? Perhaps you can just do that then ?

Thanks,
Dirk

[Thomas Boerger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/21/2015 11:12 AM, Dirk Müller wrote:
> If there is no problem for reopening against the new repo, why
> closing them in the first place? Perhaps you can just do that then
> ?

Because they are open for the wron repository after the merge. And we
are not opening it again as we are not responsible for these pull
requests. The author have to reopen it again with his own name.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVrg2WAAoJEFo4j1UoOWC2ybsQAMtZZUYZ6CcfwvXykRshXOZO
b4rD5PGG7J/3bd6qR3okvD0LFBAwfNxXrqFO/uh+S79weGgB6PGlr3egHSz1YF5U
FhUw6wDZtKfNbDMam7zLpme6DQZ+SlDeGFzFGXMc2rvP1a48zU6Y0xA2FzDhJQzT
84goneCqJPR1R1cfWcot82ZnVYhmWlYa2ExsDe6z1O+zPdp/cM4kMPDdWC93/EaE
V8eBBZUbBSI85ylyRMUvfc33LLWuvhfG354dVNoTbhKLJwYweukxE9EOMQACizvJ
3vgZHj21+cSzeIEYO9vtbRe0sZvVO3wBhXbWUK1h5p+69o1HHAbCKrvFgZuU3Hbg
6SZCOn2QXkjNvFWc7Y6zYVJ8wL9yPqLH+xAaFCbaopyXM1IZ7rK55EWBmz9pMLVW
j7foi8brFbOUtFfDTwL5e4MAJmRGKlcfj3K4BwLB7w0LxYTXY0bc9gpltR2Mjnsa
MF3NAYPCrHjLUipv7qKPP/HwIgjQWarbptwVIKd7lPUtnc84aq8R8FWTCGEUf2RE
K6cnrcO5xPG9GaALlioCK7yhcDt9hGACkwOp1KqjWzDwSAi6XBZGHrxN0f0N1nTZ
2nB42M8fVUi/iEgJqCiit75R0kPpPjPa2LY7lXV/Nub1zEraktiWFpElELP37g9B
a3P+IpvjCPvse4Y0sFHO
=h+im
-----END PGP SIGNATURE-----

[Vincent Untz]

Hi,

Le mardi 21 juillet 2015, à 09:34 +0200, Rick Salevsky a écrit :
> The merge was originally planed for last Friday and we extend the time
> frame until this Friday. So we gave already some extra time and two
> weeks should be enough for preparation. Additionally I doesn't see a big
> problem for closing all PRs. The author only needs to reopen them
> against the new repo, for the most cases should no rebase needed.

After discussing with Dirk, the main point is that it's nicer to people
to let them one or two weeks while the new repos are active to look at
their old open pull requests and reopen them against the new repos.

The problem with the current grace period is that the new repos will be
force-pushed at the end, and people tend to not open PR against repos
that are considered temporary. So we effectively end up with a grace
period to let people merge current PR and then no grace period to look
at old PR and reopen them against the new repos.

Does it hurt to add this second type of grace period?

Cheers,

Vincent

> Ciao,
> Rick
>
> On Tue, 2015-07-21 at 08:52 +0200, Thomas Boerger wrote:
> > We already anounced it last week, and will close on thursday. So it will already be a week. At some point we simply have to do the switch.
> >
> > > Am 21.07.2015 um 08:48 schrieb Dirk Müller <dmu...@gmail.com>:
> > >
> > > Hi Thomas,
> > >
> > >
> > >> Quite simple, as already discussed, the open pull requests will be closed with a comment that refers to the new home to get reopened by the author against the new repository.
> > >
> > > Ah, so there is no automatism involved. so how about adding a comment
> > > and give the submitter a reasonable timeframe (a week?) to rebase the
> > > patch before closing it? This way we at least know what is being lost
> > > in the process :)
> > >
> > > TIA,
> > > Dirk
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "crowbar" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to crowbar+u...@googlegroups.com.
> > > To post to this group, send email to cro...@googlegroups.com.
> > > To view this discussion on the web visit https://groups.google.com/d/msgid/crowbar/CAJaQmt_xv-%3DGYTcN7XTdDDpXwzOEo-xf2f761t77L7_QDdq8pw%40mail.gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "crowbar" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to crowbar+u...@googlegroups.com.
> To post to this group, send email to cro...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/crowbar/1437464068.5262.14.camel%40suse.de.

> For more options, visit https://groups.google.com/d/optout.
>

--
Les gens heureux ne sont pas pressés.

[Thomas Boerger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/21/2015 11:16 AM, Vincent Untz wrote:
> After discussing with Dirk, the main point is that it's nicer to
> people to let them one or two weeks while the new repos are active
> to look at their old open pull requests and reopen them against the
> new repos.
>
> The problem with the current grace period is that the new repos
> will be force-pushed at the end, and people tend to not open PR
> against repos that are considered temporary. So we effectively end
> up with a grace period to let people merge current PR and then no
> grace period to look at old PR and reopen them against the new
> repos.

So you want to manage the move of the pull requests to the new repo? :)

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVrg4hAAoJEFo4j1UoOWC23/wP+gLf1TTtbxW5ijAqyu+0o8Cu
zL4/zZH+prneHHeBDfME9PCczLyF602UFOVhz1R17pCcZmFM3MQ7hwAMQXv/h3Iq
y5N18r0N3ddQ2OKccHL0Bk5+9iIi9IqyCuKGH61lKCZtoBTKx5HozUXCbrUNEdUB
ovOo1N5twDfTs2yfgqZ6aN/KVT6PHhs8SeO3TPE13z6PLwCdqFYPwzSQNGb35GdZ
PnvzBIWhPagO4kQWxrzUCIgJtJKwcCShzsNh/IwxkXyg4kHc0qVolQZaiHBEUMdR
GLlQ0yyvh6mFnsVlR7W3BbnYu8GROV19p8saItIDwcyKWd5Xjl14e0L7/hhdPXGL
EqL/Z/f2YsrIzZeoSGbOuk1dIAYA0Xd/Ve2FV1N9DJtWxSM5fzqXGmSlJ3FNNAii
dOF1zKvZEMLE12yihw4vwIl2nKTvSbfQkrfKBTvHutEGJKfkV6awbr5OFJg58R2O
BD8zaBvORp+JO0mkAFp4ODT+VjN+gAIkgQ9h1d4YE01rE8xjbiIdF3htUeMXHZGj
VahZhhbUYc0TQh+T2kFPpIEaSG8/RMok6F96km32ZVfDOlSZsEFWHlCRO9tcpFip
3PbKDVWr/Gvj4Eky4EzqL4Vf+YtGM4FGumskTBmDgJDaZBIiTaaOoQ5zpqsIwIyU
+EJRmgybhvQwpGfgeULS
=/Sec
-----END PGP SIGNATURE-----

[Rick Salevsky]

On Tue, 2015-07-21 at 11:16 +0200, Vincent Untz wrote:
> Hi,
>
> Le mardi 21 juillet 2015, à 09:34 +0200, Rick Salevsky a écrit :
> > The merge was originally planed for last Friday and we extend the time
> > frame until this Friday. So we gave already some extra time and two
> > weeks should be enough for preparation. Additionally I doesn't see a big
> > problem for closing all PRs. The author only needs to reopen them
> > against the new repo, for the most cases should no rebase needed.
>
> After discussing with Dirk, the main point is that it's nicer to people
> to let them one or two weeks while the new repos are active to look at
> their old open pull requests and reopen them against the new repos.
>
> The problem with the current grace period is that the new repos will be
> force-pushed at the end, and people tend to not open PR against repos
> that are considered temporary. So we effectively end up with a grace
> period to let people merge current PR and then no grace period to look
> at old PR and reopen them against the new repos.
>
> Does it hurt to add this second type of grace period?

From my point of view yes. When we merge a PR into the old repo then we
need to port them into the new one. This coasts additional time and I
think we loose the overview very fast. The risk that we forgot to port a
PR to the new repo while this period is very height.

I do not understand the problem with reopen the PRs against the new
repo. It's just:

1. fork and clone the new repo
2. recreate the branch
3. download an apply the patch
4. push and open the PR

Ciao,
Rick

[Vincent Untz]

Le mardi 21 juillet 2015, à 12:17 +0200, Rick Salevsky a écrit :
> On Tue, 2015-07-21 at 11:16 +0200, Vincent Untz wrote:
> > Hi,
> >
> > Le mardi 21 juillet 2015, à 09:34 +0200, Rick Salevsky a écrit :
> > > The merge was originally planed for last Friday and we extend the time
> > > frame until this Friday. So we gave already some extra time and two
> > > weeks should be enough for preparation. Additionally I doesn't see a big
> > > problem for closing all PRs. The author only needs to reopen them
> > > against the new repo, for the most cases should no rebase needed.
> >
> > After discussing with Dirk, the main point is that it's nicer to people
> > to let them one or two weeks while the new repos are active to look at
> > their old open pull requests and reopen them against the new repos.
> >
> > The problem with the current grace period is that the new repos will be
> > force-pushed at the end, and people tend to not open PR against repos
> > that are considered temporary. So we effectively end up with a grace
> > period to let people merge current PR and then no grace period to look
> > at old PR and reopen them against the new repos.
> >
> > Does it hurt to add this second type of grace period?
>
> From my point of view yes. When we merge a PR into the old repo then we
> need to port them into the new one. This coasts additional time and I

Oh, but PR wouldn't be merged in the old repos. Keeping them open is
just a way for contributors to see what they had submitted so they know
what they have to re-submit easily.

Vincent

> think we loose the overview very fast. The risk that we forgot to port a
> PR to the new repo while this period is very height.
>
> I do not understand the problem with reopen the PRs against the new
> repo. It's just:
>
> 1. fork and clone the new repo
> 2. recreate the branch
> 3. download an apply the patch
> 4. push and open the PR
>
> Ciao,
> Rick
>

> --
> You received this message because you are subscribed to the Google Groups "crowbar" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to crowbar+u...@googlegroups.com.
> To post to this group, send email to cro...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/crowbar/1437473875.5262.25.camel%40suse.de.

[Adam Spiers]

Rick Salevsky <rsal...@suse.de> wrote:
> The merge was originally planed for last Friday and we extend the time
> frame until this Friday. So we gave already some extra time and two
> weeks should be enough for preparation. Additionally I doesn't see a big
> problem for closing all PRs.

There *is* potentially a big problem unless it is done in the right
way. (This is why it is very good that we are discussing it - it is
impossible for one person to think of all potential problems ;-)

The problem is that closing a PR which contains valuable changes
puts it in the same bucket as all PRs which have been rejected ...

> The author only needs to reopen them
> against the new repo, for the most cases should no rebase needed.

You say "only" but it is not that easy. Firstly, when they are in the
same bucket as rejected PRs, it is *way* too easy for an important PR
to be forgotten about.

So I suggest we create new labels 'pre-bc-repo-merge' or similar
(ideas for better names welcome) and then attach it to all currently
open PRs before closing them. That way we can easily obtain a list of
all these PRs.

Then we could create another label called something like
'transferred-post-bc-repo-merge', and every time we port a PR to a
merged repo, we attach this label to the original (closed) one. Then
we can search for all PRs which have the 1st label but not the 2nd
one, and that gives us the TODO list of PRs which we still need to
port.

Thoughts?

[Thomas Boerger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/21/2015 12:53 PM, Adam Spiers wrote:
> There *is* potentially a big problem unless it is done in the
> right way. (This is why it is very good that we are discussing it
> - it is impossible for one person to think of all potential
> problems ;-)
>
> The problem is that closing a PR which contains valuable changes
> puts it in the same bucket as all PRs which have been rejected ...
>
>> The author only needs to reopen them against the new repo, for
>> the most cases should no rebase needed.
>
> You say "only" but it is not that easy. Firstly, when they are in
> the same bucket as rejected PRs, it is *way* too easy for an
> important PR to be forgotten about.
>
> So I suggest we create new labels 'pre-bc-repo-merge' or similar
> (ideas for better names welcome) and then attach it to all
> currently open PRs before closing them. That way we can easily
> obtain a list of all these PRs.
>
> Then we could create another label called something like
> 'transferred-post-bc-repo-merge', and every time we port a PR to a
> merged repo, we attach this label to the original (closed) one.
> Then we can search for all PRs which have the 1st label but not the
> 2nd one, and that gives us the TODO list of PRs which we still need
> to port.

I'm fine with adding some labels, than nobody can say he lost it.
But i would still suggest to close the pull requests. Every author
will get a notification that he needs to reopen it on another repo,
everybody else can keep track of it through the labels.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVridoAAoJEFo4j1UoOWC2fygQAMEYvVbOosGD7UHDe9nflx+G
F9E5rYgTsHOGo5USSrAjUmRVm74KAP6dyt76+5SSyzZQ48rfSvHx8U3DlDddt2bz
lzru+K/bCV9ntZrjim1BFQJdCzECLKluVfPVfqJ9Pd1lM/Mf/BUjoEKspjOIWelH
mepFqQXqQtN9KS1Bc2a6UK4osjF4E23xL4+h5qWpF5R3sq3onU8ZQFraZ3bBZl2N
rXR+Bku2mStsywMZVYkaycrHIrdp93nQiTep2hwFdkb4dHf4zKKKFPivOaRfHNXn
sslow1rj1QMqXFPL7ZViOAPuaejauR4mzPTSHY8deUcPUKleJ4tzjRA5wvK3t5Ub
XlrFLYiqGlytbU3P54N+2CPyCkEBgdFagbQDMMP6JnuP05UaaL5A/PrKNh81RVzQ
yHvr1x0QkPtn7Ku9/hR3VqDLcgldty12sjBxlxbahPlsDjZVmJ9IFUhaysZ8GmT8
8TCWDzi+ngnjOS6PlDDfMaW7ahGviRI9ajfE+5BVTqy336vlQTkbnkkoDwRNYFHH
VR6LPW890kJdt8uo7H//Io3vk+0oxZDFpF9vrZDiAEZYgNRbhvEmEq6P1HnInHuE
GPp/PUgxhSyEyybvcVs+ZN0oZvhKpBu8lwY43kDpVQtIqhxSsCm4Oqu/7cxfVUpg
R6wzQJRgob2MbhR5rEbs
=Wqef
-----END PGP SIGNATURE-----

[Rick Salevsky]

I talked with Thomas H. and he had a similar idea but we can combine
both. His idea was to not close the PRs but write a comment with
instructions. But at the same time we can use the script for adding the
label. But we should use not so complex names as you proposed maybe
'pre-merge' and 'transferred-merge'.

But then we have one open question. How long should be the extended
grace period? I would suggest maximum two weeks...

Ciao,
Rick

[Adam Spiers]

I agree - better to automatically append a comment explaining the
migration (including a URL to a document about the migration[0]) and then
close it to prevent anyone from accidentally doing further work in the
wrong place.

[0] This is necessary in case the info about the migration needs to be
updated. Otherwise we could append comments to 100 PRs, then
realise the comments are wrong and having missing info, and have
to append another comment to 100 PRs etc... With the info on a
github wiki page (say) it can easily be updated afterwards.

[Adam Spiers]

If you have labels, why not close the PRs? This prevents accidentally
working on an obsolete PR, and I can't think of any good reason to
keep them open.

> But we should use not so complex names as you proposed maybe
> 'pre-merge' and 'transferred-merge'.

Why? Doesn't this just make it more ambiguous? Are you 100% sure
there will never be another merge in the whole future of the Crowbar
project? I'm not, which is why I suggested more specific names.
And the labels will be created via a script not by manually typing ...

> But then we have one open question. How long should be the extended
> grace period? I would suggest maximum two weeks...

I think making everyone recreate their own PRs in the new repos
manually is probably a big waste of time. Wouldn't it be much nicer
to write a script which each person can run?

Secondly, I think 2 weeks is unrealistic because there will be a ton
of merge conflicts requiring a lot of rebasing.

[Thomas Boerger]

> Am 21.07.2015 um 13:55 schrieb Adam Spiers <asp...@suse.com>:
>
> Why? Doesn't this just make it more ambiguous? Are you 100% sure
> there will never be another merge in the whole future of the Crowbar
> project? I'm not, which is why I suggested more specific names.
> And the labels will be created via a script not by manually typing ...

I am totally sure that we won't migrate from this repo to somewhere else as these repos will die when the old releases are out of maintenance (No dieing in terms of deleted but in terms of moved to the archive organization). And the tags will be for the pull requests on barclamp-*, not for crowbar-* ;).

[Dirk Müller]

Hi all,

>> I talked with Thomas H. and he had a similar idea but we can combine
>> both. His idea was to not close the PRs but write a comment with
>> instructions.

That was my proposal as well, +1 on that :-)

>> But at the same time we can use the script for adding the
>> label.

Works for me as well. I want one way to query for things that haven't
been rebased against the new repo yet. Just closing something in the
hope that the original submitter has both time and tracktion on
reopening against the new repo is shifting the responsibilities quite
a bit.

> If you have labels, why not close the PRs? This prevents accidentally
> working on an obsolete PR, and I can't think of any good reason to
> keep them open.

As a reminder for rebasing them on top of the new repo, thats all. We
have tooling for tracking open PRs already..

> I think making everyone recreate their own PRs in the new repos
> manually is probably a big waste of time. Wouldn't it be much nicer
> to write a script which each person can run?

That is of course good as well, but I wouldn't expect the rebasing of
a PR being a scriptable effort, since Thomas and Rick also plan to
reorganize files right afterwards for the switch to rails engines..

> Secondly, I think 2 weeks is unrealistic because there will be a ton
> of merge conflicts requiring a lot of rebasing.

Two weeks is a lot more than the remaining one day for merging 100
open pull requests like originally proposed. And yeah, it would be
better to have more time since vacation season starts ..

Greetings,
Dirk

[Adam Spiers]

Dirk Müller <dmu...@gmail.com> wrote:
> Hi all,
>
> >> I talked with Thomas H. and he had a similar idea but we can combine
> >> both. His idea was to not close the PRs but write a comment with
> >> instructions.
>
> That was my proposal as well, +1 on that :-)
>
> >> But at the same time we can use the script for adding the
> >> label.
>
> Works for me as well. I want one way to query for things that haven't
> been rebased against the new repo yet. Just closing something in the
> hope that the original submitter has both time and tracktion on
> reopening against the new repo is shifting the responsibilities quite
> a bit.

Yes that was exactly my point, and what I was trying to address with
labels.

> > If you have labels, why not close the PRs? This prevents accidentally
> > working on an obsolete PR, and I can't think of any good reason to
> > keep them open.
>
> As a reminder for rebasing them on top of the new repo, thats all. We
> have tooling for tracking open PRs already..

That's a good point, closing them would totally skew the statistics.
So maybe it's good enough to just auto-append a comment to each PR
(with the appropriate URL like I already mentioned) and leave them
open.

[Thomas Hutterer]

Would it maybe be an feasible option to close the old ones after the new
ones where merged or rejected?
Or isn't that possible+sensible+practical after archiving?
We could at least ask people to mention the old PRs in a comment of the
new ones to have a reference.

[Adam Spiers]

No that doesn't make sense. Each old one should be closed immediately
after the corresponding new PR is created in the new repo, otherwise
you have two PRs simultaneously open both trying to make the same
changes to different generations of the same code.

> We could at least ask people to mention the old PRs in a comment of the
> new ones to have a reference.

Without any doubt, there need to be bidirectional links between each
(old, new) pair of PRs! This should be mentioned in the wiki page.

[Adam Spiers]

Oh yeah that's a good point actually :-) OK, so if you insist on it,
I'm OK with the simpler label names ... (although I still prefer the
more explicit ones, because any newbie looking at them has a slightly
greater chance of understanding what they're for).