Yes, I think all of our customers don't use internal build systems but work
off GitHub directly. I can't go into details about it, but usually we work
together with them and then our team submits the necessary fixes.
Mu Li schrieb am So., 10. Juni 2018, 03:54:
> Very curious to hear that. I cont
Very curious to hear that. I contacted several customers, most of them are
waiting for 1.2 to be ready on the internal system. Did they fork by their
own? If they changed the codes, will them submit their changes?
On Sat, Jun 9, 2018 at 2:51 PM, Marco de Abreu wrote:
> We received a few pull req
We received a few pull requests for the 1.2 branch which are not from key
contributors. I'm also aware of a few Amazon internal customers who are
currently actively working off the 1.2 branch to prepare for 1.2.1 release,
so I'd rather err on the side of caution here.
-marco
Mu Li schrieb am Sa.
The proposal is squash commits made from May 21 to June 7 into a single commit
for the 1.2 branch. https://github.com/apache/incubator-mxnet/commits/v1.2.0 t
should not affect the master branch. But it may affect developers if they
cloned and 1.2 some day between May 21 and June 7 and want to P
Would there be any benefit besides cosmetics? I'd propose to just leave it
as-is.
Tianqi Chen schrieb am Sa., 9. Juni 2018, 22:28:
> This would only happen if somebody pushed some changes on these new commits
> pushed 1.2.0 branch.
>
> That is if I checked out 1.2.0 before the change is pushed,
This would only happen if somebody pushed some changes on these new commits
pushed 1.2.0 branch.
That is if I checked out 1.2.0 before the change is pushed, and rebase
against the code after squash, it will be fine. The problem will only
happen if someone checked out 1.2.0 after these commits get
I agree we should never rewrite history on the master branch, master
branch is protected so you won't be able to push to it without a PR. The
issue here was the release branch was not protected.
I am only squashing commits that are after the tag creation.
On Sat, Jun 9, 2018 at 1:24 PM, Tianqi
It would be a history rewrite. Everybody would receive an error if they
checked out the branch and try to merge or rebase.
Naveen Swamy schrieb am Sa., 9. Juni 2018, 22:21:
> how would it be devastating? it is just squashing a bunch of commits
> together into 1 commit.
>
> On Sat, Jun 9, 2018 at
One potential problem is that, if a release is tagged to a certain hash
code, and that specific commit get squashed, the previous tagged release is
no longer valid, so at least make sure that did not happen
Tianqi
On Sat, Jun 9, 2018 at 1:23 PM, Tianqi Chen
wrote:
> You should never force push
You should never force push to master branch because it messes up people's
commit history. Ideally, you shall never push to the release branch and PR
is preferred. Given no people will continue work on the release branch, the
impact of squash commits is minimalized and is fine in this case, given
l
how would it be devastating? it is just squashing a bunch of commits
together into 1 commit.
On Sat, Jun 9, 2018 at 1:18 PM, Marco de Abreu wrote:
> I think we should never ever force push to a publish repository since we
> don't know what depends on it. I'd say we take this as a lesson learned
I think we should never ever force push to a publish repository since we
don't know what depends on it. I'd say we take this as a lesson learned and
leave it as it is.
The impact could be way more devastating than the benefits
-Marco
Naveen Swamy schrieb am Sa., 9. Juni 2018, 21:39:
> Hi Mu,
>
Hi Mu,
No, it isn't necessary to have those commits. I did not want to rewrite the
history, thats why I did not attempt. I can try to squash and force push,
I'll let you know if I am able to force-push.
Thanks, Naveen
On Sat, Jun 9, 2018 at 12:28 PM, Mu Li wrote:
> Hi Naveen,
>
> Thanks for
Hi Naveen,
Thanks for the clarification. Is there necessary to keep these commits
submitted by the maveen plugin in the repo? Otherwise, can we squash these
commits and force push it to a single commit? It's good to have a stable
release only patched with meaningful commits.
Best,
Mu
> On Ju
Ah yeah that's exactly what I mean :)
Naveen Swamy schrieb am Do., 7. Juni 2018, 23:54:
> May be, but I have disabled it taking any action, so I don't see a need to
> do it on a private fork. I am reviewing the local changes and make a PR
> after that.
>
> On Thu, Jun 7, 2018 at 2:41 PM, Marco d
May be, but I have disabled it taking any action, so I don't see a need to
do it on a private fork. I am reviewing the local changes and make a PR
after that.
On Thu, Jun 7, 2018 at 2:41 PM, Marco de Abreu wrote:
> Hello Naveen,
>
> thank you for addressing this. Is it possible to let the plugin
Hello Naveen,
thank you for addressing this. Is it possible to let the plugin point to a
private fork so you can review it's actions manually before they are
written to the main repository? That way, we could just open a PR and
double check everything is as expected.
Thanks a lot for taking care
Hello all,
I want to bring to your attention that there have been some accidental
commits to the 1.2.0 branch on my behalf. This was done by the Maven
apache-release plugin while I was working on building a package to publish
to Maven.
When you use apache-release profile in your profile by default
18 matches
Mail list logo