hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: migrating private branches to the new git repo
Date Wed, 03 Sep 2014 19:10:55 GMT

OK, it does, but only under certain conditions. Hmm.

On Sep 3, 2014, at 12:04 PM, Allen Wittenauer <aw@altiscale.com> wrote:

> 
> 
> Looks like the web UI doesn't allow for bulk change of Fix Version.
> 
> *cries*
> 
> On Sep 3, 2014, at 11:56 AM, Andrew Wang <andrew.wang@cloudera.com> wrote:
> 
>> Allen, if you're willing to do the legwork, that'd be great. I feel we
>> should start by getting a JIRA script checked into dev-support that
>> generates a changelog for a release. We could then use that to make sure
>> the various fields are set properly for previous releases, remove
>> CHANGES.txt once we're confident, and then use said script to generate the
>> changelog for future releases.
>> 
>> 
>> On Wed, Sep 3, 2014 at 11:47 AM, Allen Wittenauer <aw@altiscale.com> wrote:
>> 
>>> 
>>> On Sep 3, 2014, at 11:42 AM, Allen Wittenauer <aw@altiscale.com> wrote:
>>> 
>>>> 
>>>> On Sep 3, 2014, at 11:07 AM, Chris Douglas <cdouglas@apache.org> wrote:
>>>> 
>>>>> 
>>>>> As long as release notes and incompatible changes are recorded in each
>>>>> branch, we gain no accuracy by maintaining this manually. Commit
>>>>> messages that record the merge revisions instead of the change are
>>>>> similarly hateful. -C
>>>> 
>>>> We’ll also need to get much more strict about Fix Version really only
>>> listing the earliest version.  Many of list (next release) + (trunk),
>>> myself included, which after looking through some of the commit docs, is
>>> not correct.
>>>> 
>>>> I’m going to make it a point to go through JIRA today and fix my
>>> mistakes in this regard.
>>> 
>>> 
>>> Or, if we agree, I can bulk change them for everyone too.  I think I’ve
>>> got the necessary JIRA search to locate dupe fix versions.
> 


Mime
View raw message