You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Nigel Daley <nd...@yahoo-inc.com> on 2008/03/10 23:17:24 UTC
add incompatible flag to Jira
Can we add an incompatible checkbox in Jira? I think this would be
helpful in tracking incompatible changes.
Thoughts?
Nige
Re: add incompatible flag to Jira
Posted by Nigel Daley <nd...@yahoo-inc.com>.
On Mar 18, 2008, at 12:18 PM, stack wrote:
>>> -----Original Message-----
>>> From: Nigel Daley [mailto:ndaley@yahoo-inc.com]
>>> Sent: Tuesday, March 11, 2008 11:49 AM
>>>
>>> Good idea Rob. I think these 2 ideas are orthogonal. So I suggest
>>> these 2 additions to Jira:
>>>
>>> 1. an incompatible checkbox
>>> 2. a release note text box
>>>
>>> For an incompatible change, the submitter sets the field if the
>>> patch
>>> is an incompatible change w/ the last major release. The committer
>>> and submitter may need to discuss whether or not to set the
>>> incompatible flag once the actual "Fix Version" field is set.
>>> Guidance on what constitutes an incompatible change should be
>>> published on wiki.
>>>
>>>
>
> +1 Sounds good to me.
>
> (Would there be a means of ensuring all JIRAs with 'incompatible
> change' checked get mention in CHANGES.txt INCOMPATIBLE CHANGES?)
That could be arranged.
>>> For release notes, the submitter should fill in release notable
>>> information (if any) for the patch. An automated process can then
>>> put all the release notes into a file when a release is rolled.
>>> Guidance on what is release notable should be published on wiki.
>>>
>>>
>
> Also sounds good. Would the release notes file be different from
> CHANGES.txt?
Release notes would be the important/big/incompatible type changes.
It would be supplied by the *submitter* as opposed to the
*committer*. It's also likely that it would be more verbose than our
current CHANGES.txt.
> How would this file display when I click on 'Browse release notes
> now!' on the releases.html page?
No idea.
Re: add incompatible flag to Jira
Posted by stack <st...@duboce.net>.
>> -----Original Message-----
>> From: Nigel Daley [mailto:ndaley@yahoo-inc.com]
>> Sent: Tuesday, March 11, 2008 11:49 AM
>> To: core-dev@hadoop.apache.org
>> Subject: Re: add incompatible flag to Jira
>>
>> Good idea Rob. I think these 2 ideas are orthogonal. So I suggest
>> these 2 additions to Jira:
>>
>> 1. an incompatible checkbox
>> 2. a release note text box
>>
>> For an incompatible change, the submitter sets the field if the patch
>> is an incompatible change w/ the last major release. The committer
>> and submitter may need to discuss whether or not to set the
>> incompatible flag once the actual "Fix Version" field is set.
>> Guidance on what constitutes an incompatible change should be
>> published on wiki.
>>
>>
+1 Sounds good to me.
(Would there be a means of ensuring all JIRAs with 'incompatible change'
checked get mention in CHANGES.txt INCOMPATIBLE CHANGES?)
>> For release notes, the submitter should fill in release notable
>> information (if any) for the patch. An automated process can then
>> put all the release notes into a file when a release is rolled.
>> Guidance on what is release notable should be published on wiki.
>>
>>
Also sounds good. Would the release notes file be different from
CHANGES.txt? How would this file display when I click on 'Browse
release notes now!' on the releases.html page?
St.Ack
RE: add incompatible flag to Jira
Posted by Mahadev Konar <ma...@yahoo-inc.com>.
+1...
Regards
Mahadev
> -----Original Message-----
> From: Nigel Daley [mailto:ndaley@yahoo-inc.com]
> Sent: Tuesday, March 11, 2008 11:49 AM
> To: core-dev@hadoop.apache.org
> Subject: Re: add incompatible flag to Jira
>
> Good idea Rob. I think these 2 ideas are orthogonal. So I suggest
> these 2 additions to Jira:
>
> 1. an incompatible checkbox
> 2. a release note text box
>
> For an incompatible change, the submitter sets the field if the patch
> is an incompatible change w/ the last major release. The committer
> and submitter may need to discuss whether or not to set the
> incompatible flag once the actual "Fix Version" field is set.
> Guidance on what constitutes an incompatible change should be
> published on wiki.
>
> For release notes, the submitter should fill in release notable
> information (if any) for the patch. An automated process can then
> put all the release notes into a file when a release is rolled.
> Guidance on what is release notable should be published on wiki.
>
> Thoughts?
>
> Nige
>
> On Mar 10, 2008, at 6:15 PM, Robert Chansler wrote:
>
> > More helpful might be a "requires release note" flag. And perhaps a
> > convenient way to attach the release note itself.
> >
> >
> > On 10 03 08 15:17, "Nigel Daley" <nd...@yahoo-inc.com> wrote:
> >
> >> Can we add an incompatible checkbox in Jira? I think this would be
> >> helpful in tracking incompatible changes.
> >>
> >> Thoughts?
> >>
> >> Nige
> >
Re: add incompatible flag to Jira
Posted by Sanjay Radia <sr...@yahoo-inc.com>.
Doug Cutting wrote:
> Nigel Daley wrote:
>> 1. an incompatible checkbox
>
> This really only passes the buck, doesn't it? The real problem is
> correctly identifying all the incompatible changes. We already have a
> mechanism, a section in CHANGES.txt, but we don't always manage to
> correctly list all the incompatible changes there. A checkbox won't
> be any more reliable will it?
>
>> 2. a release note text box
>
> Shouldn't folks just include CHANGES.txt message in the patch? That's
> what I've always encouraged, but few are ever provided. Perhaps
> Hudson can bounce patches that don't touch CHANGES.txt?
>
> Both these would make sense if we intend to abandon CHANGES.txt and
> use them instead. Is that your intent?
>
>
> Doug
When I worked on the java vm at Sun, we used to list all interfaces
that have changed or added including internal ones.
Primarily one wants to identify all external interfaces (apis, config
files etc) that have been changed or introduced.
Secondarily one wants to also list changes to key internal interfaces -
this may not break the client but may break
the implementation due to internal dependencies that were overlooked; it
also help raise awareness of changes to the
internal structure.
We had a simple one pager form that was filled out; what was
interesting was that by just filling out the form
the writer became more aware of the impact of her change and often ended
up doing something different or
catching a problem.
It also helped the reviewer quickly get a better view of the impact of
the change and hence pay more attention to
certain parts of the patch to be reviewed.
It helped forge a culture and discipline in thinking about changing
system software.
While some java engineers complained about having to fill out the
"damn ccc form", in the end most agreed that the process was very useful.
So I suggest a simple template or form along the following lines:
External interfaces:
Have you changed/added/deleted any external facing interfaces including
APIs, CLIs, config files?
Changes in signatures?
Changes in semantics?
Internal Interfaces:
...same...
sanjay
Re: add incompatible flag to Jira
Posted by Michael Bieniosek <mi...@powerset.com>.
RPC protocol version changes are important, because they mean that clients and servers have to upgraded at the same time.
-Michael
On 3/18/08 2:14 PM, "Raghu Angadi" <ra...@yahoo-inc.com> wrote:
I think our current definition of a 'Incompatible Change' is so broad
that it is not useful for a user. I never understood why a protocol
version change should be in that list (I know, technically it is
incompatible).
Also automated release notes can never come close to human generated
release notes, however incomplete the human generated version is.
+1 if this is just a guideline and Hadoop requires a (not very long)
human generated end-user friendly release notes.
Raghu.
Nigel Daley wrote:
> I'm underwhelmed by the response to this thread. Any other
> input/opinions on how we track incompatibilities and create meaningful
> release notes?
>
> Nige
>
> On Mar 12, 2008, at 12:15 AM, Nigel Daley wrote:
>
>>
>> On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
>>
>>> Nigel Daley wrote:
>>>> 1. an incompatible checkbox
>>>
>>> This really only passes the buck, doesn't it?
>>
>> Ya, it passes it to the right people - the submitter and reviewer as
>> opposed to the committer (who is currently responsible for determining
>> if an issue goes in the INCOMPAT section of CHANGES.txt). We also
>> need to provide guidelines on what may be considered an incompatible
>> change.
>>
>>>> 2. a release note text box
>>>
>>> Shouldn't folks just include CHANGES.txt message in the patch?
>>> That's what I've always encouraged, but few are ever provided.
>>> Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
>>>
>>> Both these would make sense if we intend to abandon CHANGES.txt and
>>> use them instead. Is that your intent?
>>
>> No, I think we need CHANGES.txt (or some equivalent) that lists ALL
>> the changes in the release (as opposed to the release notes that only
>> list the important changes). I'm told, too, that it's also convenient
>> to have a complete list of changes IN the workspace so that a
>> developer can quickly see what has been recently committed. So I
>> think CHANGES.txt stays. My proposal is to add an additional files
>> (release notes) that is auto generated from the new field in Jira.
>>
>> Nige
>>
>
Re: add incompatible flag to Jira
Posted by Raghu Angadi <ra...@yahoo-inc.com>.
I think our current definition of a 'Incompatible Change' is so broad
that it is not useful for a user. I never understood why a protocol
version change should be in that list (I know, technically it is
incompatible).
Also automated release notes can never come close to human generated
release notes, however incomplete the human generated version is.
+1 if this is just a guideline and Hadoop requires a (not very long)
human generated end-user friendly release notes.
Raghu.
Nigel Daley wrote:
> I'm underwhelmed by the response to this thread. Any other
> input/opinions on how we track incompatibilities and create meaningful
> release notes?
>
> Nige
>
> On Mar 12, 2008, at 12:15 AM, Nigel Daley wrote:
>
>>
>> On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
>>
>>> Nigel Daley wrote:
>>>> 1. an incompatible checkbox
>>>
>>> This really only passes the buck, doesn't it?
>>
>> Ya, it passes it to the right people - the submitter and reviewer as
>> opposed to the committer (who is currently responsible for determining
>> if an issue goes in the INCOMPAT section of CHANGES.txt). We also
>> need to provide guidelines on what may be considered an incompatible
>> change.
>>
>>>> 2. a release note text box
>>>
>>> Shouldn't folks just include CHANGES.txt message in the patch?
>>> That's what I've always encouraged, but few are ever provided.
>>> Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
>>>
>>> Both these would make sense if we intend to abandon CHANGES.txt and
>>> use them instead. Is that your intent?
>>
>> No, I think we need CHANGES.txt (or some equivalent) that lists ALL
>> the changes in the release (as opposed to the release notes that only
>> list the important changes). I'm told, too, that it's also convenient
>> to have a complete list of changes IN the workspace so that a
>> developer can quickly see what has been recently committed. So I
>> think CHANGES.txt stays. My proposal is to add an additional files
>> (release notes) that is auto generated from the new field in Jira.
>>
>> Nige
>>
>
Re: add incompatible flag to Jira
Posted by Nigel Daley <nd...@yahoo-inc.com>.
I'm underwhelmed by the response to this thread. Any other input/
opinions on how we track incompatibilities and create meaningful
release notes?
Nige
On Mar 12, 2008, at 12:15 AM, Nigel Daley wrote:
>
> On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
>
>> Nigel Daley wrote:
>>> 1. an incompatible checkbox
>>
>> This really only passes the buck, doesn't it?
>
> Ya, it passes it to the right people - the submitter and reviewer
> as opposed to the committer (who is currently responsible for
> determining if an issue goes in the INCOMPAT section of
> CHANGES.txt). We also need to provide guidelines on what may be
> considered an incompatible change.
>
>>> 2. a release note text box
>>
>> Shouldn't folks just include CHANGES.txt message in the patch?
>> That's what I've always encouraged, but few are ever provided.
>> Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
>>
>> Both these would make sense if we intend to abandon CHANGES.txt
>> and use them instead. Is that your intent?
>
> No, I think we need CHANGES.txt (or some equivalent) that lists ALL
> the changes in the release (as opposed to the release notes that
> only list the important changes). I'm told, too, that it's also
> convenient to have a complete list of changes IN the workspace so
> that a developer can quickly see what has been recently committed.
> So I think CHANGES.txt stays. My proposal is to add an additional
> files (release notes) that is auto generated from the new field in
> Jira.
>
> Nige
>
Re: add incompatible flag to Jira
Posted by Nigel Daley <nd...@yahoo-inc.com>.
On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
> Nigel Daley wrote:
>> 1. an incompatible checkbox
>
> This really only passes the buck, doesn't it?
Ya, it passes it to the right people - the submitter and reviewer as
opposed to the committer (who is currently responsible for
determining if an issue goes in the INCOMPAT section of
CHANGES.txt). We also need to provide guidelines on what may be
considered an incompatible change.
>> 2. a release note text box
>
> Shouldn't folks just include CHANGES.txt message in the patch?
> That's what I've always encouraged, but few are ever provided.
> Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
>
> Both these would make sense if we intend to abandon CHANGES.txt and
> use them instead. Is that your intent?
No, I think we need CHANGES.txt (or some equivalent) that lists ALL
the changes in the release (as opposed to the release notes that only
list the important changes). I'm told, too, that it's also
convenient to have a complete list of changes IN the workspace so
that a developer can quickly see what has been recently committed.
So I think CHANGES.txt stays. My proposal is to add an additional
files (release notes) that is auto generated from the new field in Jira.
Nige
Re: add incompatible flag to Jira
Posted by Rick Cox <ri...@gmail.com>.
On Tue, Mar 11, 2008 at 12:17 PM, Doug Cutting <cu...@apache.org> wrote:
>
> > 2. a release note text box
>
> Shouldn't folks just include CHANGES.txt message in the patch? That's
> what I've always encouraged, but few are ever provided. Perhaps Hudson
> can bounce patches that don't touch CHANGES.txt?
>
I like this idea, though would be concerned about the ability of
patch(1) to properly apply diffs containing the CHANGES.txt entry ---
it seems like they'd quickly be obsolete just because another patch
has added an entry. Perhaps they could be included a second (non-diff)
attachment?
rick
Re: add incompatible flag to Jira
Posted by Doug Cutting <cu...@apache.org>.
Nigel Daley wrote:
> 1. an incompatible checkbox
This really only passes the buck, doesn't it? The real problem is
correctly identifying all the incompatible changes. We already have a
mechanism, a section in CHANGES.txt, but we don't always manage to
correctly list all the incompatible changes there. A checkbox won't be
any more reliable will it?
> 2. a release note text box
Shouldn't folks just include CHANGES.txt message in the patch? That's
what I've always encouraged, but few are ever provided. Perhaps Hudson
can bounce patches that don't touch CHANGES.txt?
Both these would make sense if we intend to abandon CHANGES.txt and use
them instead. Is that your intent?
Doug
Re: add incompatible flag to Jira
Posted by Nigel Daley <nd...@yahoo-inc.com>.
Good idea Rob. I think these 2 ideas are orthogonal. So I suggest
these 2 additions to Jira:
1. an incompatible checkbox
2. a release note text box
For an incompatible change, the submitter sets the field if the patch
is an incompatible change w/ the last major release. The committer
and submitter may need to discuss whether or not to set the
incompatible flag once the actual "Fix Version" field is set.
Guidance on what constitutes an incompatible change should be
published on wiki.
For release notes, the submitter should fill in release notable
information (if any) for the patch. An automated process can then
put all the release notes into a file when a release is rolled.
Guidance on what is release notable should be published on wiki.
Thoughts?
Nige
On Mar 10, 2008, at 6:15 PM, Robert Chansler wrote:
> More helpful might be a “requires release note” flag. And perhaps a
> convenient way to attach the release note itself.
>
>
> On 10 03 08 15:17, "Nigel Daley" <nd...@yahoo-inc.com> wrote:
>
>> Can we add an incompatible checkbox in Jira? I think this would be
>> helpful in tracking incompatible changes.
>>
>> Thoughts?
>>
>> Nige
>
Re: add incompatible flag to Jira
Posted by Robert Chansler <ch...@yahoo-inc.com>.
More helpful might be a ³requires release note² flag. And perhaps a
convenient way to attach the release note itself.
On 10 03 08 15:17, "Nigel Daley" <nd...@yahoo-inc.com> wrote:
> Can we add an incompatible checkbox in Jira? I think this would be
> helpful in tracking incompatible changes.
>
> Thoughts?
>
> Nige