+1 for using git log instead of CHANGES.txt.
Colin
On Wed, Sep 3, 2014 at 11:07 AM, Chris Douglas wrote:
> On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang wrote:
>> Not to derail the conversation, but if CHANGES.txt is making backports more
>> annoying, why don't we get rid of it? It seems like we
On Sep 3, 2014, at 4:57 PM, Chris Douglas wrote:
> On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote:
>> 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 looki
Sorry, if I wasn't clear. I find Target and Fix versions useful. I find
CHANGES.txt redundant.
On Wed, Sep 3, 2014 at 2:55 PM, Karthik Kambatla wrote:
>
> On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang
> wrote:
>
>> Not to derail the conversation, but if CHANGES.txt is making backports
>> more
>>
On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote:
> 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.
Is thi
I personally find Target Version to be useful for tracking which version a
change is intended for.
On Wed, Sep 3, 2014 at 2:55 PM, Karthik Kambatla wrote:
> On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang
> wrote:
>
> > Not to derail the conversation, but if CHANGES.txt is making backports
> more
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang
wrote:
> Not to derail the conversation, but if CHANGES.txt is making backports more
> annoying, why don't we get rid of it? It seems like we should be able to
> generate it via a JIRA query, and "git log" can also be used for a quick
> check (way faste
Not sure it is sufficient reason to keep the field around given the
confusion it causes. :-)
Thanks for volunteering to cleanup the existing Jiras.
On Wed, Sep 3, 2014 at 1:09 PM, Allen Wittenauer wrote:
>
> I always used target version as "I hope to get this patch in by then". :D
>
>
> On Sep
I always used target version as "I hope to get this patch in by then". :D
On Sep 3, 2014, at 1:07 PM, Arpit Agarwal wrote:
> Thanks, good to know.
>
> So in the spirit of simplification can we just eliminate the 'Target
> Version' field from Jira?
>
>
> On Wed, Sep 3, 2014 at 1:01 PM, Allen
Thanks, good to know.
So in the spirit of simplification can we just eliminate the 'Target
Version' field from Jira?
On Wed, Sep 3, 2014 at 1:01 PM, Allen Wittenauer wrote:
> I was doing that too, but I went "to the source":
>
> https://wiki.apache.org/hadoop/HowToCommit says:
>
> "Resolve the
I was doing that too, but I went "to the source":
https://wiki.apache.org/hadoop/HowToCommit says:
"Resolve the issue as fixed, thanking the contributor. Always set the "Fix
Version" at this point, but please only set a single fix version, the earliest
release in which the change will appear. S
Allen, I think the correct field you are looking for is 'Target Version'.
If a fix is committed to both branch-2 and trunk, the fix version must
include both 2.x.0 and 3.0.0. However the target version would be 2.x.0 as
that is the earliest release that includes the fix.
On Wed, Sep 3, 2014 at 12
Figured it out. Basically can only do bulk fix version edits of one project at
a time since the versions are technically different for every project.
i.e.,: you can edit all of YARN-xxx, but you can not do YARN-xxx and HDFS-xxx
together. FWIW, there are 372 issues that have a fixVersion for
OK, it does, but only under certain conditions. Hmm.
On Sep 3, 2014, at 12:04 PM, Allen Wittenauer 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 wrote:
>
>> Allen, if you're willing to do the legwo
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 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 fo
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'r
On Sep 3, 2014, at 11:42 AM, Allen Wittenauer wrote:
>
> On Sep 3, 2014, at 11:07 AM, Chris Douglas 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 revi
On Sep 3, 2014, at 11:07 AM, Chris Douglas 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 als
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang wrote:
> Not to derail the conversation, but if CHANGES.txt is making backports more
> annoying, why don't we get rid of it? It seems like we should be able to
> generate it via a JIRA query, and "git log" can also be used for a quick
> check (way faster
On 3 September 2014 02:47, Todd Lipcon wrote:
> On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang
> wrote:
>
> > Not to derail the conversation, but if CHANGES.txt is making backports
> more
> > annoying, why don't we get rid of it? It seems like we should be able to
> > generate it via a JIRA query,
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang
wrote:
> Not to derail the conversation, but if CHANGES.txt is making backports more
> annoying, why don't we get rid of it? It seems like we should be able to
> generate it via a JIRA query, and "git log" can also be used for a quick
> check (way faste
Not to derail the conversation, but if CHANGES.txt is making backports more
annoying, why don't we get rid of it? It seems like we should be able to
generate it via a JIRA query, and "git log" can also be used for a quick
check (way faster than svn log).
On Tue, Sep 2, 2014 at 12:38 PM, Steve Lou
>
> Maybe at the end add the action I will ultimately take (git branch remote
> rename asflive origin && git branch rename live/trunk trunk)
>
> +1, that'd be great
>
> > Somewhat related, it'd be nice to update the GitAndHadoop instructions on
> > how to generate a patch using git-format-patch. I
I've now done my first commits; one into trunk (10373), one into branch-2
and cherry picked (fix in
hadoop-common-project/hadoop-common/src/main/native/README ; no JIRA).
I made an initial attempt to cherry pick the HADOOP-10373 patch from trunk
into branch-2, with CHANGES.TXT being a dramatic eno
On 2 September 2014 19:01, Andrew Wang wrote:
> This is basically what I did, make patches of each of my branches and then
> reapply to the new trunk. One small recommendation would be to make the
> remote named "apache" rather than "asflive" so it's consistent with the
> GitAndHadoop wikipage. I
This is basically what I did, make patches of each of my branches and then
reapply to the new trunk. One small recommendation would be to make the
remote named "apache" rather than "asflive" so it's consistent with the
GitAndHadoop wikipage. IMO naming branches with a "/" (e.g. "live/trunk")
is als
25 matches
Mail list logo
