Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.2.0
    • Component/s: None
    • Labels:
      None

      Description

      Tachyon (tachyon-project.org) was somewhat recently renamed to Alluxio (alluxio.org), requiring many changes in Apache Bigtop in order to continue to support this package.

      1. BIGTOP-2414.patch.2
        111 kB
        Jonathan Kelly
      2. BIGTOP-2414.patch.1
        110 kB
        Jonathan Kelly
      3. BIGTOP-2414.patch
        110 kB
        Jonathan Kelly

        Issue Links

          Activity

          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user ejono closed the pull request at:

          https://github.com/apache/bigtop/pull/104

          Show
          githubbot ASF GitHub Bot added a comment - Github user ejono closed the pull request at: https://github.com/apache/bigtop/pull/104
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user c0s commented on the issue:

          https://github.com/apache/bigtop/pull/104

          Can the author close this PR? Has been committed a long time ago. Thanks!

          Show
          githubbot ASF GitHub Bot added a comment - Github user c0s commented on the issue: https://github.com/apache/bigtop/pull/104 Can the author close this PR? Has been committed a long time ago. Thanks!
          Hide
          asanjar Amir Sanjar added a comment -

          thank you Olaf, that fixed it..

          Show
          asanjar Amir Sanjar added a comment - thank you Olaf, that fixed it..
          Hide
          oflebbe Olaf Flebbe added a comment -

          Amir Sanjar : Thanks for reporting. I forgot to change the https://ci.bigtop.apache.org/job/Bigtop-trunk-packages-ppc64le/ config. Or do you see some other specific problems?

          Show
          oflebbe Olaf Flebbe added a comment - Amir Sanjar : Thanks for reporting. I forgot to change the https://ci.bigtop.apache.org/job/Bigtop-trunk-packages-ppc64le/ config. Or do you see some other specific problems?
          Hide
          asanjar Amir Sanjar added a comment -

          regression - This patch breaks ppc64le build.

          Show
          asanjar Amir Sanjar added a comment - regression - This patch breaks ppc64le build.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Thanks Jonathan Kelly for the patch!

          Committed.

          Show
          oflebbe Olaf Flebbe added a comment - Thanks Jonathan Kelly for the patch! Committed.
          Hide
          cos Konstantin Boudnik added a comment -

          Sorry Olaf Flebbe for not being completely clear: I am not opposing the rename, I just hate backward incompatible changes like that. It isn't a fault of the patch of course, but rather the component community making knee-jerking moves like that. Yet another reason to develop the software under the open governance policies, rather than having a commercial entity usurping the decision making process.

          +1 on getting the patch in

          Show
          cos Konstantin Boudnik added a comment - Sorry Olaf Flebbe for not being completely clear: I am not opposing the rename, I just hate backward incompatible changes like that. It isn't a fault of the patch of course, but rather the component community making knee-jerking moves like that. Yet another reason to develop the software under the open governance policies, rather than having a commercial entity usurping the decision making process. +1 on getting the patch in
          Hide
          jayunit100 jay vyas added a comment -

          It would be great if alluxio is going to be a part of the bigtop family.

          I guess first step would be compilation like olaf said.

          Show
          jayunit100 jay vyas added a comment - It would be great if alluxio is going to be a part of the bigtop family. I guess first step would be compilation like olaf said.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Hi Konstantin Boudnik , you have raised concerns. But what should we do , we either have to accept this patch or remove tachyon. Otherwise noone cannot build the next bigtop release.

          Show
          oflebbe Olaf Flebbe added a comment - Hi Konstantin Boudnik , you have raised concerns. But what should we do , we either have to accept this patch or remove tachyon. Otherwise noone cannot build the next bigtop release.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Right now we have little plan of upgrading bigtop, indeed.

          But my priorities are : First the code should compile. Second it should be deploy on greenfield. ... and somewhere beyond that is should behave sane while upgrading.

          Right now the code fails to meet the first criteria. So we have to fix it.

          The patch supplied tries to adress the second criteria as well.

          If one chooses to simply exchange repositories and puppet recipies while upgrading, it may work (but we have not tested it so far). Only if a user chooses to create derivatives of Apache Bigtop he has additional work to do. But this is almost always true, even for small changes. We can only suply limited support of others creating derivatives of our work.

          Show
          oflebbe Olaf Flebbe added a comment - Right now we have little plan of upgrading bigtop, indeed. But my priorities are : First the code should compile. Second it should be deploy on greenfield. ... and somewhere beyond that is should behave sane while upgrading. Right now the code fails to meet the first criteria. So we have to fix it. The patch supplied tries to adress the second criteria as well. If one chooses to simply exchange repositories and puppet recipies while upgrading, it may work (but we have not tested it so far). Only if a user chooses to create derivatives of Apache Bigtop he has additional work to do. But this is almost always true, even for small changes. We can only suply limited support of others creating derivatives of our work.
          Hide
          cos Konstantin Boudnik added a comment -

          Olaf, all I am trying to by raising this conversation is to make sure we have a plan for handling incompatible changes (now or in the future). I don't believe we need to vote on anything - voting isn't a method of reconciling differences of opinions.

          Show
          cos Konstantin Boudnik added a comment - Olaf, all I am trying to by raising this conversation is to make sure we have a plan for handling incompatible changes (now or in the future). I don't believe we need to vote on anything - voting isn't a method of reconciling differences of opinions.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Personally I do not think that the issue at hand justifies a new major release. I presume that every downstream user of tachyon already knows about the renaming of the project and will handle it accordingly. So why bother?

          I have no special feelings about version numbers. They do not mean anything to me. If a major release makes you more comfortable regarding this ticket, please proceed with a discussion or vote on dev@. We'll either have to remove or to rename this package, either way. I'll vote for renaming.

          BTW: we'll should integrate (or least try to integrate) hive-2.0 as well.

          Show
          oflebbe Olaf Flebbe added a comment - Personally I do not think that the issue at hand justifies a new major release. I presume that every downstream user of tachyon already knows about the renaming of the project and will handle it accordingly. So why bother? I have no special feelings about version numbers. They do not mean anything to me. If a major release makes you more comfortable regarding this ticket, please proceed with a discussion or vote on dev@. We'll either have to remove or to rename this package, either way. I'll vote for renaming. BTW: we'll should integrate (or least try to integrate) hive-2.0 as well.
          Hide
          cos Konstantin Boudnik added a comment -

          Would it be such an awful idea? Also, Spark 2.0 is coming and is likelty to be breaking stuff left and right as well.... Thought?

          Show
          cos Konstantin Boudnik added a comment - Would it be such an awful idea? Also, Spark 2.0 is coming and is likelty to be breaking stuff left and right as well.... Thought?
          Hide
          oflebbe Olaf Flebbe added a comment -

          Do you suggest to do a major release instead? Bigtop-2.0 yeah!

          Show
          oflebbe Olaf Flebbe added a comment - Do you suggest to do a major release instead? Bigtop-2.0 yeah!
          Hide
          cos Konstantin Boudnik added a comment -

          Yes, that's my point. While in this case we don't have much options beyond remove the component or breaking the downstream users' automation, we are setting a precedent of doing the incompatible change in the minor release. And that exactly what I don't like.

          Show
          cos Konstantin Boudnik added a comment - Yes, that's my point. While in this case we don't have much options beyond remove the component or breaking the downstream users' automation, we are setting a precedent of doing the incompatible change in the minor release. And that exactly what I don't like.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Sorry Konstantin Boudnik , i do not get your point exactly. Fact is that a new run to build release artifacts for Bigtop-1.2.0 will not succeed. I only see two options: Removing Tachyon or applying something like this patch.

          Any downstream user of bigtop-tachyon has to decide what to do with tachyon now: Removing automation or Renaming packages for automation. Applying this patch offers the user both options.

          Show
          oflebbe Olaf Flebbe added a comment - Sorry Konstantin Boudnik , i do not get your point exactly. Fact is that a new run to build release artifacts for Bigtop-1.2.0 will not succeed. I only see two options: Removing Tachyon or applying something like this patch. Any downstream user of bigtop-tachyon has to decide what to do with tachyon now: Removing automation or Renaming packages for automation. Applying this patch offers the user both options.
          Hide
          cos Konstantin Boudnik added a comment -

          On the other hand, since the Alluxio community made the release artifacts even for older Tachyon releases now contain a folder called alluxio-(version), the already released Bigtop 1.x versions are broken.

          How these guys have decided to break their own legs is not our responsibility. If they have released something that breaks a downstream integration - I don't really care much. However, I care a lot about the experience of our users. And if some of them are unfortunate enough to have any automation around bigtop's packages tachyon - it will break with this JIRA getting released.

          That exactly why I want to make sure we have the upgrade decision made explicitly and not to become a laughing stock of the Internet, like Scala and a couple of other projects we know about. Does that make sense?

          Show
          cos Konstantin Boudnik added a comment - On the other hand, since the Alluxio community made the release artifacts even for older Tachyon releases now contain a folder called alluxio-(version), the already released Bigtop 1.x versions are broken. How these guys have decided to break their own legs is not our responsibility. If they have released something that breaks a downstream integration - I don't really care much. However, I care a lot about the experience of our users. And if some of them are unfortunate enough to have any automation around bigtop's packages tachyon - it will break with this JIRA getting released. That exactly why I want to make sure we have the upgrade decision made explicitly and not to become a laughing stock of the Internet, like Scala and a couple of other projects we know about. Does that make sense?
          Hide
          cos Konstantin Boudnik added a comment -

          It does for comments, not for replies.

          Show
          cos Konstantin Boudnik added a comment - It does for comments, not for replies.
          Hide
          jonathak Jonathan Kelly added a comment -

          sigh again I wish JIRA provided some way of previewing your comment or editing it if the formatting got messed up or you had a typo. Apparently I shouldn't use two dashes in the middle of a sentence.

          Show
          jonathak Jonathan Kelly added a comment - sigh again I wish JIRA provided some way of previewing your comment or editing it if the formatting got messed up or you had a typo. Apparently I shouldn't use two dashes in the middle of a sentence.
          Hide
          jonathak Jonathan Kelly added a comment -

          What about this patch are you saying is a backward incompatible change that shouldn't be in the Bigtop 1.x line? (I'm not saying there's nothing, and I'm not disagreeing with you-the patch definitely changes a lot and effectively removes the tachyon targets in order to replace them with alluxio targets-I'm just wondering what specifically you are taking issue with.)

          On the other hand, since the Alluxio community made the release artifacts even for older Tachyon releases now contain a folder called alluxio-(version), the already released Bigtop 1.x versions are broken. Try checking out a fresh copy of the bigtop package from the release-1.1.0 tag and running "gradle tachyon-pkg". It will fail because the source tarball will be extracted to a directory called alluxio-0.6.0 instead of tachyon-0.6.0 as expected.

          Show
          jonathak Jonathan Kelly added a comment - What about this patch are you saying is a backward incompatible change that shouldn't be in the Bigtop 1.x line? (I'm not saying there's nothing, and I'm not disagreeing with you- the patch definitely changes a lot and effectively removes the tachyon targets in order to replace them with alluxio targets -I'm just wondering what specifically you are taking issue with.) On the other hand, since the Alluxio community made the release artifacts even for older Tachyon releases now contain a folder called alluxio-(version), the already released Bigtop 1.x versions are broken. Try checking out a fresh copy of the bigtop package from the release-1.1.0 tag and running "gradle tachyon-pkg". It will fail because the source tarball will be extracted to a directory called alluxio-0.6.0 instead of tachyon-0.6.0 as expected.
          Hide
          jonathak Jonathan Kelly added a comment -

          Thank you, Olaf Flebbe for all the help!

          Show
          jonathak Jonathan Kelly added a comment - Thank you, Olaf Flebbe for all the help!
          Hide
          cos Konstantin Boudnik added a comment -

          I would still want to have at least some exchange about the incompatible changes being introduced in the minor releases. I don't like that idea, and re-posting this question again to make sure it isn't lost in action

          Show
          cos Konstantin Boudnik added a comment - I would still want to have at least some exchange about the incompatible changes being introduced in the minor releases. I don't like that idea, and re-posting this question again to make sure it isn't lost in action
          Hide
          oflebbe Olaf Flebbe added a comment -

          Build https://ci.bigtop.apache.org/job/BIGTOP-2414/ is o.k. now. I only had a quick look at the patch, it looks reasonable. Testing the packages is a different job

          If noone complains, will commit it tomorrow.

          Jonathan Kelly thank you for improving the patch!

          Show
          oflebbe Olaf Flebbe added a comment - Build https://ci.bigtop.apache.org/job/BIGTOP-2414/ is o.k. now. I only had a quick look at the patch, it looks reasonable. Testing the packages is a different job If noone complains, will commit it tomorrow. Jonathan Kelly thank you for improving the patch!
          Hide
          oflebbe Olaf Flebbe added a comment -

          Jonathan Kelly: Updated the CI job.

          Show
          oflebbe Olaf Flebbe added a comment - Jonathan Kelly : Updated the CI job.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Hi I already did a github branch CI job in the past. (For flink) I prefer github pull requests for CI jobs.

          This can be automated for testing if the pull requestor is updating is pull requests. I have no idea how to automate this for JIRA patch files.

          I am still experimenting with improving the build process, so you may get false negative build results, sorry. I am trying to force a rebuild if I happen to make a mistake while setup the CI job. (I may not be at the keyboard the next 4 days)

          Show
          oflebbe Olaf Flebbe added a comment - Hi I already did a github branch CI job in the past. (For flink) I prefer github pull requests for CI jobs. This can be automated for testing if the pull requestor is updating is pull requests. I have no idea how to automate this for JIRA patch files. I am still experimenting with improving the build process, so you may get false negative build results, sorry. I am trying to force a rebuild if I happen to make a mistake while setup the CI job. (I may not be at the keyboard the next 4 days)
          Hide
          jonathak Jonathan Kelly added a comment -

          One more thing: if you do have any more things you want me to change, would it be possible to change the https://ci.bigtop.apache.org/job/BIGTOP-2414/ Jenkins job to pull from my Github fork instead of applying the BIGTOP-2414.patch file manually? That way I'd be able to force push my BIGTOP-2414 branch in my Github fork in order to trigger a rebuild (if you have Git polling enabled) instead of waiting for you to update the build config to point to a newer patch file attached to the JIRA.

          (This is why I'm hoping that someday we can move to a model that other projects use, where new PRs automatically trigger CI builds. I know Konstantin Boudnik is resistant to Bigtop using Github PRs, but this workflow seems to have been really successful in projects like Spark. Anyway, I'll stop debating it here on this one random JIRA. Maybe we can have a dev@ conversation about this?)

          Show
          jonathak Jonathan Kelly added a comment - One more thing: if you do have any more things you want me to change, would it be possible to change the https://ci.bigtop.apache.org/job/BIGTOP-2414/ Jenkins job to pull from my Github fork instead of applying the BIGTOP-2414 .patch file manually? That way I'd be able to force push my BIGTOP-2414 branch in my Github fork in order to trigger a rebuild (if you have Git polling enabled) instead of waiting for you to update the build config to point to a newer patch file attached to the JIRA. (This is why I'm hoping that someday we can move to a model that other projects use, where new PRs automatically trigger CI builds. I know Konstantin Boudnik is resistant to Bigtop using Github PRs, but this workflow seems to have been really successful in projects like Spark. Anyway, I'll stop debating it here on this one random JIRA. Maybe we can have a dev@ conversation about this?)
          Hide
          jonathak Jonathan Kelly added a comment -

          JIRA is messing up the formatting of my post. The exclusion I added is for debian/(two asterisks)/(one asterisk).

          Show
          jonathak Jonathan Kelly added a comment - JIRA is messing up the formatting of my post. The exclusion I added is for debian/(two asterisks)/(one asterisk).
          Hide
          jonathak Jonathan Kelly added a comment -

          sigh These license check plugins cause so much trouble in Bigtop from time to time. Unfortunately, I see no way to disable it other than to patch the source in Bigtop.

          Rather than disable it though, I just tried out patching the exclusions list so that debian/*/ would be excluded, and that seemed to work fine.

          I'll upload another patch that contains two changes:
          1) The error output you linked me to (https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=debian-8,label=docker-slave/console) made me realize that I missed renaming two files that had tachyon in the name but did not contain the word "tachyon", so I missed them in my grepping. That is, I missed renaming bigtop-packages/src/deb/alluxio/tachyon-tfs.

          {postinst,prerm} => alluxio.{postinst,prerm}

          . I'm not an Ubuntu/Debian user, so I sometimes don't give the DEB builds enough love. Glad you always do though, Olaf Flebbe!
          2) I added a patch file for adding debian/*/ to the license exclusions. I don't really like having to do this and am open to suggestions, but I think I'd like this better than disabling it altogether (which seems like it would require a patch file anyway, so it wouldn't be any "easier").

          Show
          jonathak Jonathan Kelly added a comment - sigh These license check plugins cause so much trouble in Bigtop from time to time. Unfortunately, I see no way to disable it other than to patch the source in Bigtop. Rather than disable it though, I just tried out patching the exclusions list so that debian/* / would be excluded, and that seemed to work fine. I'll upload another patch that contains two changes: 1) The error output you linked me to ( https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=debian-8,label=docker-slave/console ) made me realize that I missed renaming two files that had tachyon in the name but did not contain the word "tachyon", so I missed them in my grepping. That is, I missed renaming bigtop-packages/src/deb/alluxio/tachyon-tfs. {postinst,prerm} => alluxio.{postinst,prerm} . I'm not an Ubuntu/Debian user, so I sometimes don't give the DEB builds enough love. Glad you always do though, Olaf Flebbe ! 2) I added a patch file for adding debian/* / to the license exclusions. I don't really like having to do this and am open to suggestions, but I think I'd like this better than disabling it altogether (which seems like it would require a patch file anyway, so it wouldn't be any "easier").
          Hide
          oflebbe Olaf Flebbe added a comment -

          Anyway: The patch does not build for debian and ubuntu (at least)

          https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=debian-8,label=docker-slave/console
          https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=ubuntu-14.04,label=docker-slave/console

          Maven license plugin breaks because of the debian directory which is needed. One may switch off this insane plugin ?

          Show
          oflebbe Olaf Flebbe added a comment - Anyway: The patch does not build for debian and ubuntu (at least) https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=debian-8,label=docker-slave/console https://ci.bigtop.apache.org/job/BIGTOP-2414/6/BUILD_ENVIRONMENTS=ubuntu-14.04,label=docker-slave/console Maven license plugin breaks because of the debian directory which is needed. One may switch off this insane plugin ?
          Hide
          cos Konstantin Boudnik added a comment -

          BTW, it seems unsustainable to create CI jobs for individual patches

          It is. That's why we have one off job and manual components test

          Show
          cos Konstantin Boudnik added a comment - BTW, it seems unsustainable to create CI jobs for individual patches It is. That's why we have one off job and manual components test
          Hide
          jonathak Jonathan Kelly added a comment -

          BTW, it seems unsustainable to create CI jobs for individual patches. I see that the Spark project uses Jenkins for automatically verifying pull requests, and I've also seen a few projects that use Travis CI for doing the same, including Zeppelin and Presto. I think Travis CI seems much cleaner, but I have never actually used it or set it up myself.

          Show
          jonathak Jonathan Kelly added a comment - BTW, it seems unsustainable to create CI jobs for individual patches. I see that the Spark project uses Jenkins for automatically verifying pull requests, and I've also seen a few projects that use Travis CI for doing the same, including Zeppelin and Presto. I think Travis CI seems much cleaner, but I have never actually used it or set it up myself.
          Hide
          jonathak Jonathan Kelly added a comment -

          Oh, and thanks for creating the CI job. However, they are all failing due to something that seems unrelated to the patch.

          e.g., from https://ci.bigtop.apache.org/job/BIGTOP-2414/BUILD_ENVIRONMENTS=centos-6,label=docker-slave/5/console:
          Failed to create parent directory '/usr/share/gradle.home/caches/2.7/scripts/defaultBuildSourceScript_e6528ds75r98uqesruh04mz8k' when creating directory '/usr/share/gradle.home/caches/2.7/scripts/defaultBuildSourceScript_e6528ds75r98uqesruh04mz8k/cp_dsl'

          Show
          jonathak Jonathan Kelly added a comment - Oh, and thanks for creating the CI job. However, they are all failing due to something that seems unrelated to the patch. e.g., from https://ci.bigtop.apache.org/job/BIGTOP-2414/BUILD_ENVIRONMENTS=centos-6,label=docker-slave/5/console: Failed to create parent directory '/usr/share/gradle.home/caches/2.7/scripts/defaultBuildSourceScript_e6528ds75r98uqesruh04mz8k' when creating directory '/usr/share/gradle.home/caches/2.7/scripts/defaultBuildSourceScript_e6528ds75r98uqesruh04mz8k/cp_dsl'
          Hide
          jonathak Jonathan Kelly added a comment -

          New patch with JIRA issue id prefix in subject line.

          Show
          jonathak Jonathan Kelly added a comment - New patch with JIRA issue id prefix in subject line.
          Hide
          jonathak Jonathan Kelly added a comment -

          Do you just mean that you want "BIGTOP-2414. " in front of the subject line? Sorry, I'd forgotten that. I will add it.

          Show
          jonathak Jonathan Kelly added a comment - Do you just mean that you want " BIGTOP-2414 . " in front of the subject line? Sorry, I'd forgotten that. I will add it.
          Hide
          jonathak Jonathan Kelly added a comment -

          But only if you don't rebase onto the latest master then do a fast-forward rather than a merge. I too hate useless merge commits, so that's why I always use rebasing rather than merges, unless I really want to indicate that something (usually a longer running branch) is being merged.

          Yeah, though I said that the "Git repo redirects", I still meant the release artifacts too. Olaf Flebbe explained above.

          Show
          jonathak Jonathan Kelly added a comment - But only if you don't rebase onto the latest master then do a fast-forward rather than a merge. I too hate useless merge commits, so that's why I always use rebasing rather than merges, unless I really want to indicate that something (usually a longer running branch) is being merged. Yeah, though I said that the "Git repo redirects", I still meant the release artifacts too. Olaf Flebbe explained above.
          Hide
          jonathak Jonathan Kelly added a comment -

          Ah, that makes sense. I didn't realize that the CI jobs run in such a way that the source tars are kept across builds. (I assume that's what you are saying.)

          Doesn't this cause a problem when apps are upgraded? I think I remember Bigtop having a problem where if you build an app, change its version in bigtop.bom, then try to build the app again without doing a "realclean", it will still use the older source tar because it thinks it has already been downloaded. That is, the Gradle logic has no way of tracking which version of an app's source tar had been downloaded previously, just that some version had been downloaded.

          Show
          jonathak Jonathan Kelly added a comment - Ah, that makes sense. I didn't realize that the CI jobs run in such a way that the source tars are kept across builds. (I assume that's what you are saying.) Doesn't this cause a problem when apps are upgraded? I think I remember Bigtop having a problem where if you build an app, change its version in bigtop.bom, then try to build the app again without doing a "realclean", it will still use the older source tar because it thinks it has already been downloaded. That is, the Gradle logic has no way of tracking which version of an app's source tar had been downloaded previously, just that some version had been downloaded.
          Hide
          oflebbe Olaf Flebbe added a comment -

          Thanks for this patch. I added a job in the CI https://ci.bigtop.apache.org/job/BIGTOP-2414
          (Hopefully correctly)

          Could you please update the subject line on the patch to correctly match the JIRA title ?

          Show
          oflebbe Olaf Flebbe added a comment - Thanks for this patch. I added a job in the CI https://ci.bigtop.apache.org/job/BIGTOP-2414 (Hopefully correctly) Could you please update the subject line on the patch to correctly match the JIRA title ?
          Hide
          oflebbe Olaf Flebbe added a comment -

          Bigtop does not download again the source tars. Since it downloaded it at first, it will never retry.

          Show
          oflebbe Olaf Flebbe added a comment - Bigtop does not download again the source tars. Since it downloaded it at first, it will never retry.
          Hide
          cos Konstantin Boudnik added a comment -

          Why do they make a mess of the Git history?

          Because (mostly) useless merge commits are retained, carrying nothing but noise.

          We are not using git repo, we are using a release artifact, which sits somewhere and has "correct" tachyon name in it.

          Show
          cos Konstantin Boudnik added a comment - Why do they make a mess of the Git history? Because (mostly) useless merge commits are retained, carrying nothing but noise. We are not using git repo, we are using a release artifact, which sits somewhere and has "correct" tachyon name in it.
          Hide
          jonathak Jonathan Kelly added a comment -

          Why do they make a mess of the Git history? Can't the committer just rebase the PR on the latest master before pushing (as long as there are no conflicts)? Other Apache projects like Spark and Zeppelin use exclusively PRs and don't seem to have any problems with the Git history.

          One thing I've been wondering about is how the Tachyon Bigtop CI builds are even working still after the rename. The old Tachyon Git repo redirects to the Alluxio repo now, so if I try to run `gradle tachyon-rpm` while on master, it fails pretty quickly because the downloaded tachyon-0.6.0.tar.gz contains a directory named alluxio-0.6.0 instead of the expected tachyon-0.6.0.

          Show
          jonathak Jonathan Kelly added a comment - Why do they make a mess of the Git history? Can't the committer just rebase the PR on the latest master before pushing (as long as there are no conflicts)? Other Apache projects like Spark and Zeppelin use exclusively PRs and don't seem to have any problems with the Git history. One thing I've been wondering about is how the Tachyon Bigtop CI builds are even working still after the rename. The old Tachyon Git repo redirects to the Alluxio repo now, so if I try to run `gradle tachyon-rpm` while on master, it fails pretty quickly because the downloaded tachyon-0.6.0.tar.gz contains a directory named alluxio-0.6.0 instead of the expected tachyon-0.6.0.
          Hide
          cos Konstantin Boudnik added a comment -

          People are using GH PRs for doing their contributions, but I personally dislike that because GH way of merging PRs makes a mess from the git history.

          At any rate, this change gets us to an interesting point: this is a backward incompatible change. Which shouldn't be done in a minor release (we aren't Scala, for crying out loud). Hence, thoughts?

          Show
          cos Konstantin Boudnik added a comment - People are using GH PRs for doing their contributions, but I personally dislike that because GH way of merging PRs makes a mess from the git history. At any rate, this change gets us to an interesting point: this is a backward incompatible change. Which shouldn't be done in a minor release (we aren't Scala, for crying out loud). Hence, thoughts?
          Hide
          jonathak Jonathan Kelly added a comment -

          Here's a patch for this, though I've also submitted a Github pull request. What do you guys prefer? The Bigtop "How to Contribute" page still doesn't mention pull requests, though I think I've seen some Bigtop JIRAs using them, and of course they're pretty common with most other Apache projects.

          Show
          jonathak Jonathan Kelly added a comment - Here's a patch for this, though I've also submitted a Github pull request. What do you guys prefer? The Bigtop "How to Contribute" page still doesn't mention pull requests, though I think I've seen some Bigtop JIRAs using them, and of course they're pretty common with most other Apache projects.
          Show
          jonathak Jonathan Kelly added a comment - https://github.com/apache/bigtop/pull/104

            People

            • Assignee:
              jonathak Jonathan Kelly
              Reporter:
              jonathak Jonathan Kelly
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development