[hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests
Github now offers an option to not create the "merge commit" when you want to merge a PR from the web ui. It comes at a significant cost though: it will merge the PR but squash all commits in one. While initially thinking that doesn't help us at all, at second thought: we really want any non-trivial code change to be checked out locally, run the testsuite, and only then push. But let's say there's a trivial PR fixing some typos in documentation! You look at it, looks good and then you really just want to say "go ahead" and get back to more important matters. Besides, we have Jenkins carefully testing these too and it will grey out the button if the build fails, so there's some kind of last defence in case you didn't notice that the "docs typo" PR actually sneaks in some real problem. So I'd say we could enable this option with the "squashing" ? We would still refrain from using the green button for most patches, but it could save some "boring process" minutes for those simpler patches. I've enabled this option for Hibernate Search. We can seek team consensus before actually using it (you're not supposed to use the "green button" at all currently), I might at least have it default to the less annoying option: if you do use it by mistake, it will squash it all. The open question remains if we're ok to use it regularly for trivial PRs, and if you want this switched on all Hibernate repositories. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests
+1 It seems sensible to me to use it for trivial pull request or where it makes sense to have a single commit. On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero wrote: > Github now offers an option to not create the "merge commit" when you > want to merge a PR from the web ui. > > It comes at a significant cost though: it will merge the PR but squash > all commits in one. > > While initially thinking that doesn't help us at all, at second > thought: we really want any non-trivial code change to be checked out > locally, run the testsuite, and only then push. > > But let's say there's a trivial PR fixing some typos in documentation! > You look at it, looks good and then you really just want to say "go > ahead" and get back to more important matters. Besides, we have > Jenkins carefully testing these too and it will grey out the button if > the build fails, so there's some kind of last defence in case you > didn't notice that the "docs typo" PR actually sneaks in some real > problem. > > So I'd say we could enable this option with the "squashing" ? > > We would still refrain from using the green button for most patches, > but it could save some "boring process" minutes for those simpler > patches. > > I've enabled this option for Hibernate Search. We can seek team > consensus before actually using it (you're not supposed to use the > "green button" at all currently), I might at least have it default to > the less annoying option: if you do use it by mistake, it will squash > it all. > > The open question remains if we're ok to use it regularly for trivial > PRs, and if you want this switched on all Hibernate repositories. > > Thanks, > Sanne > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests
Since this feature does not support rebase, what happens if the master has newer commits that the PR does not. Will it do a merge commit in this case? On Fri, Apr 8, 2016 at 2:46 PM, Davide D'Alto wrote: > +1 > > It seems sensible to me to use it for trivial pull request or where it > makes > sense to have a single commit. > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > wrote: > > > Github now offers an option to not create the "merge commit" when you > > want to merge a PR from the web ui. > > > > It comes at a significant cost though: it will merge the PR but squash > > all commits in one. > > > > While initially thinking that doesn't help us at all, at second > > thought: we really want any non-trivial code change to be checked out > > locally, run the testsuite, and only then push. > > > > But let's say there's a trivial PR fixing some typos in documentation! > > You look at it, looks good and then you really just want to say "go > > ahead" and get back to more important matters. Besides, we have > > Jenkins carefully testing these too and it will grey out the button if > > the build fails, so there's some kind of last defence in case you > > didn't notice that the "docs typo" PR actually sneaks in some real > > problem. > > > > So I'd say we could enable this option with the "squashing" ? > > > > We would still refrain from using the green button for most patches, > > but it could save some "boring process" minutes for those simpler > > patches. > > > > I've enabled this option for Hibernate Search. We can seek team > > consensus before actually using it (you're not supposed to use the > > "green button" at all currently), I might at least have it default to > > the less annoying option: if you do use it by mistake, it will squash > > it all. > > > > The open question remains if we're ok to use it regularly for trivial > > PRs, and if you want this switched on all Hibernate repositories. > > > > Thanks, > > Sanne > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] A warmup task: HSEARCH-2207
Hi Mincong, Gunnar suggested that I find a first task for you to familiarize with the project, and to have you practice the process of creating patches and proposing them for integration over GitHub. I think this issue could be suited: - https://hibernate.atlassian.net/browse/HSEARCH-2207 I hope it's not too boring! It's not just an exercise, we need that done so it would be a valuable contribution already. Do you have an account on our JIRA server? If not create one, then let me know your user id so I can assign the issue to you. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Master
I'm curious if Search/OGM master branches would likely align with 5.2? Or some other branch? On 04/07/2016 11:34 AM, Steve Ebersole wrote: > As a follow up to this... > > Sanne had a great suggestion on HipChat. What about turning all this work > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be > 5.2 would include: > > 1. Move to Java 8 > 2. Consolidation of hibernate-entitymanager into hibernate-core > 3. Deprecations, lots of deprecations :) > > > The idea is that then we could start 6.0 off "clean" by removing all the > deprecations and layering in SQM work. > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > wrote: > >> Hi, >> >> Until the merge is done, I'll take a break integrating the PRs that are >> also relevant to the master branch. >> >> Vlad >> >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >> wrote: >> >>> I agree that would be best. If everyone agrees to stop pushing to master >>> for the time being to allow me to finish this consolidation then I can not >>> rush it as much >>> >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: >>> I have to concur with Sanne, a hold on master pushes until this merge of artifacts is complete makes the most sense from an all around logistics perspective. On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero wrote: > Sounds reasonable. Do you think it will be unstable, i.e. should we > temporarily disable complaint emails from Jenkins, or even the full > build tasks? > > Also, this implies that any future backport becomes similarly harder, > so you could also simply ask others to hold pushing on master, then > have people forward-port when it's done.. it's the same really but > that's why I mention it: as the complexity is interchangeable it's a > fair request, with the difference you have: > - others help you port the other patches forward rather than doing it all > alone > - the authors of the original patch doing it, that should make it a >>> bit > simpler > > > > On 6 April 2016 at 17:15, Steve Ebersole wrote: >> Obviously consolidating hibernate-entitymanager into hibernate-core >>> is a >> fairly big effort. And I am getting concerned about the continuing > pushes >> to master in the meantime, many of which I know touch on code I have >> changed. My concern is obviously getting done all this refactoring work >> and then having to sift through all of the changes that have been pushed > in >> the interim and attempting to work out the proper integration >>> strategy. >> >> Long story short... I am contemplating pushing to master sooner >>> rather > than >> later even though my refactoring may not be completely finished, > especially >> as we get towards the end of the week. >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Master
On 8 April 2016 at 15:04, Scott Marlow wrote: > I'm curious if Search/OGM master branches would likely align with 5.2? > Or some other branch? Good question, time for an update on these. We'll certainly have a version of Search compatible, at some point. Not sure though about which version that shall be as we want to be feature complete with our Elasticsearch work, and that will take a couple more months at least so we'll see a bit longer than usual gap between stable releases. Generally speaking we need at least a minor release for OGM or Search to happen to upgrade the minor of ORM. Since we didn't release yet, Search is still building with ORM 5.0.x as a target.. we can then decide if we should skip ORM 5.1 and jump to 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As far as I know only some test helpers broke though, so while I couldn't test it all on both versions 5.0 and 5.1 of ORM, I think that they are compatible at runtime and we also expect to be compatible with ORM 5.2. With OGM we're now in candidate release phase for a ORM 5.0 compatible version so not really thinking to bump it to ORM 5.1 yet. OGM tends to release less frequently, so in this case it is possible that we might want to skip ORM 5.1 and go on 5.2 already to catch up, but we can work on aiming a specific version if and when need arises. If you need any of these aligned let us know? Thanks, Sanne > > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >> As a follow up to this... >> >> Sanne had a great suggestion on HipChat. What about turning all this work >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be >> 5.2 would include: >> >> 1. Move to Java 8 >> 2. Consolidation of hibernate-entitymanager into hibernate-core >> 3. Deprecations, lots of deprecations :) >> >> >> The idea is that then we could start 6.0 off "clean" by removing all the >> deprecations and layering in SQM work. >> >> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea >> wrote: >> >>> Hi, >>> >>> Until the merge is done, I'll take a break integrating the PRs that are >>> also relevant to the master branch. >>> >>> Vlad >>> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >>> wrote: >>> I agree that would be best. If everyone agrees to stop pushing to master for the time being to allow me to finish this consolidation then I can not rush it as much On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: > I have to concur with Sanne, a hold on master pushes until this merge of > artifacts is complete makes the most sense from an all around logistics > perspective. > > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero > wrote: > >> Sounds reasonable. Do you think it will be unstable, i.e. should we >> temporarily disable complaint emails from Jenkins, or even the full >> build tasks? >> >> Also, this implies that any future backport becomes similarly harder, >> so you could also simply ask others to hold pushing on master, then >> have people forward-port when it's done.. it's the same really but >> that's why I mention it: as the complexity is interchangeable it's a >> fair request, with the difference you have: >> - others help you port the other patches forward rather than doing it > all >> alone >> - the authors of the original patch doing it, that should make it a bit >> simpler >> >> >> >> On 6 April 2016 at 17:15, Steve Ebersole wrote: >>> Obviously consolidating hibernate-entitymanager into hibernate-core is > a >>> fairly big effort. And I am getting concerned about the continuing >> pushes >>> to master in the meantime, many of which I know touch on code I have >>> changed. My concern is obviously getting done all this refactoring > work >>> and then having to sift through all of the changes that have been > pushed >> in >>> the interim and attempting to work out the proper integration strategy. >>> >>> Long story short... I am contemplating pushing to master sooner rather >> than >>> later even though my refactoring may not be completely finished, >> especially >>> as we get towards the end of the week. >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-de
Re: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests
+1 from me as well. As is, we don’t use the existing merge button, so we might as well change it to something we*may* use in a handful of situations. And those situations tend to be squashed anyway... On 04/08/2016 07:46 AM, Davide D'Alto wrote: > +1 > > It seems sensible to me to use it for trivial pull request or where it makes > sense to have a single commit. > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > wrote: > >> Github now offers an option to not create the "merge commit" when you >> want to merge a PR from the web ui. >> >> It comes at a significant cost though: it will merge the PR but squash >> all commits in one. >> >> While initially thinking that doesn't help us at all, at second >> thought: we really want any non-trivial code change to be checked out >> locally, run the testsuite, and only then push. >> >> But let's say there's a trivial PR fixing some typos in documentation! >> You look at it, looks good and then you really just want to say "go >> ahead" and get back to more important matters. Besides, we have >> Jenkins carefully testing these too and it will grey out the button if >> the build fails, so there's some kind of last defence in case you >> didn't notice that the "docs typo" PR actually sneaks in some real >> problem. >> >> So I'd say we could enable this option with the "squashing" ? >> >> We would still refrain from using the green button for most patches, >> but it could save some "boring process" minutes for those simpler >> patches. >> >> I've enabled this option for Hibernate Search. We can seek team >> consensus before actually using it (you're not supposed to use the >> "green button" at all currently), I might at least have it default to >> the less annoying option: if you do use it by mistake, it will squash >> it all. >> >> The open question remains if we're ok to use it regularly for trivial >> PRs, and if you want this switched on all Hibernate repositories. >> >> Thanks, >> Sanne >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests
I had the same question as Vlad. Do these have to be forward-only merges to not create the "merge commit"? I would assume so if they are still not supporting rebase of pull requests. In which case this becomes quickly useless unless we dont let these sit. +1 from me either way for ORM. As Brett said it makes the "easy button" something i might possibly maybe use as opposed to something i would never ever use. On Fri, Apr 8, 2016, 12:49 PM Brett Meyer wrote: > +1 from me as well. As is, we don’t use the existing merge button, so we > might as well change it to something we*may* use in a handful of > situations. And those situations tend to be squashed anyway... > > > On 04/08/2016 07:46 AM, Davide D'Alto wrote: > > +1 > > > > It seems sensible to me to use it for trivial pull request or where it > makes > > sense to have a single commit. > > > > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > > wrote: > > > >> Github now offers an option to not create the "merge commit" when you > >> want to merge a PR from the web ui. > >> > >> It comes at a significant cost though: it will merge the PR but squash > >> all commits in one. > >> > >> While initially thinking that doesn't help us at all, at second > >> thought: we really want any non-trivial code change to be checked out > >> locally, run the testsuite, and only then push. > >> > >> But let's say there's a trivial PR fixing some typos in documentation! > >> You look at it, looks good and then you really just want to say "go > >> ahead" and get back to more important matters. Besides, we have > >> Jenkins carefully testing these too and it will grey out the button if > >> the build fails, so there's some kind of last defence in case you > >> didn't notice that the "docs typo" PR actually sneaks in some real > >> problem. > >> > >> So I'd say we could enable this option with the "squashing" ? > >> > >> We would still refrain from using the green button for most patches, > >> but it could save some "boring process" minutes for those simpler > >> patches. > >> > >> I've enabled this option for Hibernate Search. We can seek team > >> consensus before actually using it (you're not supposed to use the > >> "green button" at all currently), I might at least have it default to > >> the less annoying option: if you do use it by mistake, it will squash > >> it all. > >> > >> The open question remains if we're ok to use it regularly for trivial > >> PRs, and if you want this switched on all Hibernate repositories. > >> > >> Thanks, > >> Sanne > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
