Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> [jira] [Comment Edited] (BIGTOP-1110) Define BOM for 0.8.0 release of Bigtop


Copy link to this message
-
[jira] [Comment Edited] (BIGTOP-1110) Define BOM for 0.8.0 release of Bigtop

    [ https://issues.apache.org/jira/browse/BIGTOP-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883908#comment-13883908 ]

Bruno Mahé edited comment on BIGTOP-1110 at 1/28/14 8:55 AM:
-------------------------------------------------------------

I am short on time, so forgive me for the briefness:
tl;dr: I am with Mark on that one. I don't mind deprecating CentOS 5 and Ubuntu 12.04 if 14.04 is out. But I would rather keep JDK 6 for now (maybe deprecate it for 0.9.0, but not sure).
"deprecating" means we keep it for 0.8.0 but drop them afterward.

* Even if Ubuntu 12.04 gets out in time for Apache Bigtop 0.8.0, I doubt it will be ready for use before a few weeks have past. It has been my experience for most releases I have been through regardless of the GNU/Linux distributions and do not see a reason to be different in that case (.0 vs .1 releases :) )
* If we are to drop support so abruptly, then users don't have much incentive to use us (too unstable, demanding) and we are just going to be upstream of other distributions. Which can be fine if this is what this community wants. But I believe this is not the case.
* There is a whole continent, or two, between suddenly dropping a jdk version along with a few GNU/Linux distributions and supporting CentOS 5 until 2020. So let's do things in between. A proposal could be to send an email first to the user and dev mailing list and ask if anyone cares about X. Then if we still want to drop it, let's deprecate X for a release so it can be dropped in the one after. This should help us keep a balance between not supporting centos 5 forever and removing stuff too fast.
* Source artefacts can have some if/else for different versions. Also convenience artefacts are really convenient in the case of Apache Bigtop :)
* {quote}Redhat did lotta work around the what they call proper packaging of Hadoop which never been contributed here{quote} Where is the isssue? Also note that at least for Fedora, patches must be contributed upstream. Not sure about RHEL itself.
was (Author: bmahe):
I am short on time, so forgive me for the briefness:
tl;dr: I am with Mark on that one. I don't mind deprecating CentOS 5 and Ubuntu 12.04 if 14.04 is out. But I would rather keep JDK 6 for now (maybe deprecate it for 0.9.0, but not sure).
"deprecating" means we keep it for 0.8.0 but drop them afterward.

* Even if Ubuntu 12.04 gets out in time for Apache Bigtop 0.8.0, I doubt it will be ready for use before a few weeks have past. It has been my experience for most releases of all the distributions have been through and do not see a reason to be different in that case (.0 vs .1 releases :) )
* If we are to drop support so abruptly, then users don't have much incentive to use us (too unstable, demanding) and we are just going to be upstream of other distributions. Which can be fine if this is what this community wants. But I believe this is not the case.
* There is a whole continent, or two, between suddenly dropping a jdk version along with a few GNU/Linux distributions and supporting CentOS 5 until 2010. So let's do things in between. A proposal could be to send an email first to the user and dev mailing list and ask if anyone cares about X. Then if we still want to drop it, let's deprecate X for a release so it can be dropped in the one after. This should help us keep a balance between not supporting centos 5 forever and removing stuff too fast.
* Source artefacts can have some if/else for different versions. Also convenience artefacts are really convenient in the case of Apache Bigtop :)
* {quote}Redhat did lotta work around the what they call proper packaging of Hadoop which never been contributed here{quote} Where is the isssue? Also note that at least for Fedora, patches must be contributed upstream. Not sure about RHEL itself.

> Define BOM for 0.8.0 release of Bigtop
> --------------------------------------
>
>                 Key: BIGTOP-1110
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1110

This message was sent by Atlassian JIRA
(v6.1.5#6160)