I was going by what Uwe said :)
But if indeed we can make our own fields, this seems like a great
solution? We could add a CHANGES entry field, and a maybe a CHANGES
category ("New feature", "Bug fix", "API change", "Back-compat
exception", etc.)?
Mike
On Tue, Dec 7, 2010 at 8:53 PM, Mattmann, Chris A (388J)
<[email protected]> wrote:
> Hey Mike real quick I'm not sure what you mean by not having full control
> over JIRA. I know that you can customize the field types, issue types etc.
> You just ask infra and they take care of enabling perms for whomever would
> like to manage this for the project.
>
> Cheers,
> Chris
>
> Sent from my iPhone
>
> On Dec 7, 2010, at 1:03 PM, "Michael McCandless" <[email protected]>
> wrote:
>
>> Both approaches have tradeoffs...
>>
>> I love that the CHANGES today is carefully edited and as a result very
>> consumable to users. The verbiage we put into a CHANGES entry is
>> necessarily different from the title we put into Jira since it's a
>> different audience.
>>
>> But I don't like the confusion over which section we put an entry into
>> on all our branches, the work the RM must do to "dedup" (thanks Uwe!),
>> etc. And we can't expect the RM to have to editorialize the changes
>> from "raw" Jira after the fact...
>>
>> Could we do something hybrid? Since we have no full control over
>> Jira, could we eg append a comment on the the Jira issue starting with
>> "CHANGES: ", if it needs a changes entry (many issues do not)?
>>
>> Then on releasing we can pull from all issues fixed on that release
>> and coalesce the CHANGES? This would fix the confusion of duping
>> CHANGES entries across releases, etc... it's just pushing a button.
>>
>> Mike
>>
>> On Mon, Dec 6, 2010 at 11:23 PM, Shai Erera <[email protected]> wrote:
>>> Jumping in late to this thread, though I've read most of it.
>>>
>>> As a user and committer, I find the current CHANGES very convenient!
>>> It's very easy for me to read what has changed in 3.0, and very easy
>>> for me to put a CHANGES entry whenever I work on something that
>>> warrants such entry.
>>>
>>> And if an issue is back ported all the way 'till 1.4, then IMO it
>>> should contain an entry in each CHANGES (of each release). Users who
>>> download 2.9.4 need to be able to read what has changed since 2.9.3,
>>> in a clear and concise way. Which as far as I'm concerned is the
>>> current situation and I'm happy with it.
>>>
>>> Back porting issues is usually a simple svn merge, and in more complex
>>> cases, even if it's done manually, the CHANGES entry is the easiest to
>>> copy over.
>>>
>>> I don't think we should work hard to make JIRA produce the CHANGES for
>>> us - in the end of the day, JIRA is our bug tracking system, and it
>>> should remain like that. The CHANGES entry need to summarize the
>>> change to the reader, and combined with the issue number it gives
>>> enough info. If one wants, one can load the issue in JIRA and read the
>>> full correspondence.
>>>
>>> So I'm +1 for keeping things as they are, and paying attention to put
>>> the entries in all applicable CHANGES.
>>>
>>> Shai
>>>
>>> On Monday, December 6, 2010, Mattmann, Chris A (388J)
>>> <[email protected]> wrote:
>>>> Hey Robert,
>>>>
>>>> I feel ya. +1 to releasing more often! :)
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On Dec 6, 2010, at 8:31 AM, Robert Muir wrote:
>>>>
>>>>> On Mon, Dec 6, 2010 at 11:20 AM, Mattmann, Chris A (388J)
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Yeah in the end all I can say is that you basically get out of JIRA what
>>>>>> you put into it. What you call extra work is just something that I would
>>>>>> do anyways working on some of my projects. I'm not saying it's *not
>>>>>> difficult* and super easy, but we've just decided in those cases to
>>>>>> invest time into the issue management system so that we can get the
>>>>>> reports we want out of it.
>>>>>>
>>>>>> I've seen this work both ways: in the early days of Nutch there were
>>>>>> intense debates on simply moving everything to JIRA versus maintaining a
>>>>>> disconnected CHANGES.txt file. I've heard all the arguments (many times
>>>>>> over) on both sides including tidbits like "oh I don't want to go to a
>>>>>> separate URL as a consumer of software just to see what changed in it"
>>>>>> to "what's so hard about doing a curl or wget on an Internet-connected
>>>>>> system which most of our software assumes nowadays"?, those types of
>>>>>> things.
>>>>>>
>>>>>> When the dust cleared, I think I like the approach we use in Tika (and
>>>>>> that I use in a number of projects at JPL) which is just to maintain the
>>>>>> information in JIRA. It's worked for us since it's a single source to
>>>>>> curate that type of information; it produces very useable reports (not
>>>>>> perfect, but useable) that are good enough for us in terms of trading
>>>>>> between the different properties we want to maximize (user contribution
>>>>>> acknowledgement, change history, etc.)
>>>>>>
>>>>>
>>>>> I agree with what you said, and as I mentioned before I'm not opposed
>>>>> to the idea at all.
>>>>>
>>>>> But if we are going to rely on JIRA more to produce this
>>>>> documentation, we need to make some major changes to how we use it, to
>>>>> avoid some of the problems I mentioned...
>>>>>
>>>>> The scariest part to me about this approach is that we unfortunately
>>>>> have very long release cycles. So i'm worried about this documentation
>>>>> being generated and fixed "at release time" versus incrementally where
>>>>> its fresh in our mind... thats a lot of editing and filtering to do.
>>>>>
>>>>> Obviously I feel this would be mitigated and other things much better
>>>>> if we released more often but thats a harder problem, this is just the
>>>>> situation as it is now.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Chris Mattmann, Ph.D.
>>>> Senior Computer Scientist
>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> Office: 171-266B, Mailstop: 171-246
>>>> Email: [email protected]
>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> Adjunct Assistant Professor, Computer Science Department
>>>> University of Southern California, Los Angeles, CA 90089 USA
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
