On Sep 10, 2014, at 6:17 PM, Allen Wittenauer wrote:
> Here’s a (merged) 3.x changes.txt file from the current output built off of
> JIRA. (The unmerged versions are also created, but look pretty much
> identical.)
>
> http://pastebin.com/fEUKSDG4
Woops, that’s only common.
Here’s the m
Fixed the subtasks.
Hacked on my changes generator a bit more. Source is in my github repo if
anyone wants to play with it.
Here’s a (merged) 3.x changes.txt file from the current output built off of
JIRA. (The unmerged versions are also created, but look pretty much identical.)
http://pas
FWIW, I’ve gone through a 2nd pass of JIRA for 3.0.0. I’m reasonable confident
that as of this very second that the 155 non-sub-tasks are only in trunk. I
did not do a pass over the 35 sub-tasks claiming to be in 3.x.
Fun fact: the oldest patch is from 2011 and turned 3 years old this month.
On Sep 5, 2014, at 9:19 AM, Karthik Kambatla wrote:
> On Thu, Sep 4, 2014 at 8:37 AM, Allen Wittenauer wrote:
>>
>>We do need to have a talk about 3.x though. Looking over the
>> list, it would appear that a lot of (what became) early 2.x JIRAs were
>> marked as Fixed against 3.x. Pr
On Thu, Sep 4, 2014 at 8:37 AM, Allen Wittenauer wrote:
>
> I hacked on it some more and yes, it’s very easy to detect:
>
> * type of jira (improvement, bug, new feature, wish, task, sub-task)
> * incompatible or not (regardless of type)
> * reviewed or not (regardless of type)
>
>
I hacked on it some more and yes, it’s very easy to detect:
* type of jira (improvement, bug, new feature, wish, task, sub-task)
* incompatible or not (regardless of type)
* reviewed or not (regardless of type)
A key question is what to do about tasks, sub-tasks, and wishes. I
is there any way of isolating compatible/incompatible changes, & new
features?
I know that any change is potentially incompatible —but it is still good to
highlight the things we know are likely to cause trouble
On 4 September 2014 02:51, Allen Wittenauer wrote:
> Nothing official or clean or
Oh, it's in hdfs. Sneaky.
On Sep 3, 2014, at 7:10 PM, Allen Wittenauer wrote:
>
> I don't see HADOOP-10957 in hadoop-common-project/hadoop-cmmon/CHANGES.txt on
> github in the 2.5.1 branch.
>
> On Sep 3, 2014, at 7:00 PM, Karthik Kambatla wrote:
>
>> 2.5.1 - I believe all the commits here
I don't see HADOOP-10957 in hadoop-common-project/hadoop-cmmon/CHANGES.txt on
github in the 2.5.1 branch.
On Sep 3, 2014, at 7:00 PM, Karthik Kambatla wrote:
> 2.5.1 - I believe all the commits here are in CHANGES.txt of 2.5.1. Which
> one is missing?
>
>
> On Wed, Sep 3, 2014 at 6:51 PM, Al
2.5.1 - I believe all the commits here are in CHANGES.txt of 2.5.1. Which
one is missing?
On Wed, Sep 3, 2014 at 6:51 PM, Allen Wittenauer wrote:
> Nothing official or clean or whatever, but just to give people an idea of
> what an auto generated CHANGES.txt file might look like, here are some
Nothing official or clean or whatever, but just to give people an idea of what
an auto generated CHANGES.txt file might look like, here are some sample runs
of the hacky thing I built, based upon the fixVersion information. It doesn't
break it down by improvement, etc. Also, the name on the en
11 matches
Mail list logo
