On 1/3/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote: > Geir Magnusson Jr. wrote: > >>> I disagree. For cheiron.org I do most of the work myself, but >>> nevertheless anything substantial is going through JIRA if it was >>> only >>> to keep track of things done for the release notes. Especially >>> when you >>> already have a stable codebase gradually improving and getting >>> bug-fixed. But I admit with complete new projects I tend to be less >>> bureaucratic. >> Do you mean >> a) you make all the changes, make a patch, submit it to JIRA, >> download the patch, apply the patch to a fresh tree, and then commit > > Not exactly. I work either on the main codeline or in some version > branch, but not before there is an JIRA issue created for the task, > bug > or improvement at hand. The JIRA issue is sent to the developer > mailing > list (no seperate list for generated artifacts) so other interested > people can see whether they think the issue is relevant or not. I see > > When I start working on it, JIRA sends a message to the dev list so > people know I'm about the start coding. After I check in my code > directly into the repository I resolve the issue which leads to a post > from JIRA to the dev list. In case of commit before review I > suggest one > waits a while with resolving the issue. > > No patches are submitted to JIRA, for those that have no commit > rights I > also think that sending the patch to the dev list is the best thing to > do. No need to attach that one to the isse. When the patch is accepted > and committed by one of the committers the issue can be resolved. That's one thing you may want to modify - ask that patches are posted to the JIRA, as it requires the submitter to explicitly acknowledge that the stuff is contributed under the terms of the Apache License. Keeps any questions about what's a contribution to a minimum... > > I realize this won't work exactly the same way as for the projects I'm > working on, but still hope to see maybe a somewhat more formal way of > working or at least for some parts of the project. It's up to you guys.
+1 (its up to you guys) and it doesn't have to be written in stone
>> b) note changes in JIRA afterwards > > Or during the process of receiving patches, discussing and > committing them. > >> c) something else? >> I think b) is fine, if you are simply looking for a change >> tracking tool, although if you build a decent commit message >> discipline into the community, you can also just ask SVN what >> changed between releases... and that should be far more accurate. > > Often it requires multiple changes to the code for the same issue > before > everybody is happy (I think/hope this will be a very picky > community :-) > and I admit I'm an infant with SVN (Perforce addict) but wouldn't a > report generated by SVN contain a lot of clutter in that case. Also > for > release notes I really like the issue description instead of the > comments people in general use for their commit. > > If I recall correctly the Jini team didn't write a single character > before there was an issue in their tracking system. I adopted this > style > and found it worth while on a rather stable codebase. I'm curious to > know what the others think of this. > > And maybe I'm completely out of bounds here but I think that even some > form of issue planning (in what version to expect what) can be > beneficial as well, JIRA is great for that too. Yep. It is. But be careful to keep things as open and welcoming to volunteers. Rigid process is off-putting to some people.
+1 There is a balance here to be struck. The process that I outlined was for submissions by non-committers, which requires that patches be submitted and I think it is in general much better to have the patches attached to Jira tickets than to have them arrive in emails. Different apache projects use Jira differently and the benefits of always opening tickets for non-trivial changes that Mark describes make life easier for release managers and some would argue for volunteers looking for things to work on. I personally favor creating tickets for all significant changes. Others don't want so much process. Its really up to you the community to decide. We just need to remember to be open and patient with new contributors learning whatever process we agree on and not feel compelled to formalize everything immediately (or ever, actually ;-)
>>>> JIRA is great for tracking, but there are things to be cautious >>>> of - I've experienced technical discussion moving into the JIRA >>>> itself, which I think is not good, because it loses the bigger >>>> audience (IMO). I hate having to read JIRA discussions on the >>>> JIRA-generated emails, and it makes it hard to participate >>>> offline (unlike email) or search (unlike email...) >>> >>> I'm aware of that but in case of tasks to be implemented >>> somewhere in >>> the future I like to see any conclusions of discussion in JIRA >>> versus >>> digging them from my email archive. >> That's fine - that's a good use of JIRA. But you can simply just >> put a URL to the mail archive in the JIRA... easy to find later. > > That is possible, but I'm inclined to describe the summary of such an > issue neatly in JIRA. But as I've not that much experience with > working > in an ASF style project opposed to playing a dictator I really don't > know what will work the best.
That's a great practice (discuss on list, summarize in ticket); but hard to get volunteers to do uniformly. Good examples tend to get followed, though ;-) Phil
