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

Switch to Threaded View
Pig, mail # dev - CHANGES.txt in branches


Copy link to this message
-
Re: CHANGES.txt in branches
Gianmarco De Francisci Mo... 2012-10-18, 19:00
OK, I fixed a bunch of them.
There was also some misspelling on Pig issue numbers, which made
everything even more confusing :)

Cheers,
--
Gianmarco
On Tue, Oct 16, 2012 at 10:59 PM, Bill Graham <[EMAIL PROTECTED]> wrote:
> Also guilty as of about 15 minutes ago. I just moved my entry for PIG-2976
> to the Pig 0.11 section on the trunk. Great catch.
>
> On Tue, Oct 16, 2012 at 9:46 PM, Dmitriy Ryaboy <[EMAIL PROTECTED]> wrote:
>
>> Guilty.. I guess we should be putting them under 0.11 in trunk.
>>
>> On Tue, Oct 16, 2012 at 8:18 PM, Jonathan Coveney <[EMAIL PROTECTED]>
>> wrote:
>> > AFAIK (and I don't really know), I thought that if we put it in both,
>> that
>> > it'd go in the pig 11 section in trunk, and if not, we don't.
>> >
>> > Is this correct?
>> >
>> > Good job noticing this.
>> >
>> > 2012/10/16 Gianmarco De Francisci Morales <[EMAIL PROTECTED]>
>> >
>> >> Hi devs,
>> >>
>> >> I noticed there is a misalignment in CHANGES.txt between 0.11 and trunk.
>> >> It seems some people are putting patches on top in both versions of
>> >> the file, while other are putting changes that get into 0.11 in the
>> >> 0.11 section of the trunk file.
>> >>
>> >> Let me show an example:
>> >>
>> >> This is 0.11
>> >>
>> >> Pig Change Log
>> >>
>> >> Release 0.11.0 (unreleased)
>> >>
>> >> INCOMPATIBLE CHANGES
>> >> PIG-1891 Enable StoreFunc to make intelligent decision based on job
>> >> success or failure (initialcontext via gates)
>> >>
>> >> IMPROVEMENTS
>> >> PIG-2947: Documentation for Rank operator (xalan via azaroth)
>> >>
>> >> PIG-2943: DevTests, Refactor Windows checks to use new Util.WINDOWS
>> >> method for code health (jgordon via dvryaboy)
>> >>
>> >> PIG-2794: Pig test: add utils to simplify testing on Windows (jgordon
>> via
>> >> gates)
>> >>
>> >> PIG-2908: Fix unit tests to work with jdk7 (rohini via dvryaboy)
>> >>
>> >> PIG-2965: RANDOM should allow seed initialization for ease of testing
>> >> (jcoveney)
>> >>
>> >> PIG-2964: Add helper method getJobList() to PigStats.JobGraph. Extend
>> >> visibility of couple methods on same class (prkommireddi via
>> >> billgraham)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> And this is trunk:
>> >>
>> >> Pig Change Log
>> >>
>> >> Trunk (unreleased changes)
>> >>
>> >> INCOMPATIBLE CHANGES
>> >>
>> >> IMPROVEMENTS
>> >>
>> >> PIG-2943: DevTests, Refactor Windows checks to use new Util.WINDOWS
>> >> method for code health (jgordon via dvryaboy)
>> >>
>> >> PIG-2966: Test failures on CentOS 6 because MALLOC_ARENA_MAX is not
>> >> set (cheolsoo via sms)
>> >>
>> >> PIG-2793: Pig test: add utils to simplify testing on Windows (jgordon
>> via
>> >> gates)
>> >>
>> >> PIG-2908: Fix unit tests to work with jdk7 (rohini via dvryaboy)
>> >>
>> >> OPTIMIZATIONS
>> >>
>> >> BUG FIXES
>> >>
>> >> PIG-2928: Fix e2e test failures in trunk: FilterBoolean_23/24
>> >> (cheolsoo via dvryaboy)
>> >>
>> >> Release 0.11.0 (unreleased)
>> >>
>> >> INCOMPATIBLE CHANGES
>> >> PIG-1891 Enable StoreFunc to make intelligent decision based on job
>> >> success or failure (initialcontext via gates)
>> >>
>> >> IMPROVEMENTS
>> >>
>> >> PIG-2947: Documentation for Rank operator (xalan via azaroth)
>> >>
>> >> PIG-2910: Add function to read schema from outout of Schema.toString()
>> >> (initialcontext via thejas)
>> >>
>> >> PIG-2965: RANDOM should allow seed initialization for ease of testing
>> >> (jcoveney)
>> >>
>> >> PIG-2964: Add helper method getJobList() to PigStats.JobGraph. Extend
>> >> visibility of couple methods on same class (prkommireddi via
>> >> billgraham)
>> >>
>> >>
>> >>
>> >> Notice how PIG-2943, PIG-2793, PIG-2908 are marked as appearing in
>> >> trunk in trunk and in 0.11 in 0.11.
>> >> PIG-2910 is in 0.11 in trunk but not in 0.11 (I guess it is a small
>> >> mistake).
>> >>
>> >>
>> >> So, what's the correct behavior?
>> >> Do we mark a patch in CHANGES.txt at the earliest place it appears in
>> >> the code (so that CHANGES.txt is consistent across releases)?
>> >> Or do we treat the branches independently, and thus we put each patch