I am -1. 1. Voting system in a bug tracker has its purpose: prioritizing of issues.
http://www.atlassian.com/software/jira/docs/v3.13.2/voterswatchers.html What you are proposing abuses that system. 2. There are all kinds of votes: +1,-1,+0,-0, with and without arbitrary comments. 3. Patches can be trivial and non-trivial. E.g. several patches to be applied in a sequence. 4. A TC 6.0 patch is usually a merge of some revision from trunk. Attaching that to JIRA is an overkill. 5. We should vote for the proposed patches, not for some "feature". Can JIRA collect votes for attachments?? 6. Can JIRA be used to track the same feature being proposed and applied for 6.0 and for 5.5 at the same time? 7. Does JIRA send an e-mail when vote is added? With STATUS file we can cast several votes in one commit. With status file, when we update STATUS, changelog, and actual code in the same commit (like we usually do) we get a history record of what was proposed and who voted for it. Also I like that I can see all patches that are proposed, and not yet voted by me at one glance, even if I am offline. 2010/3/14 Mladen Turk <mt...@apache.org>: >>> Nice thing is that patches can be directly attached without the need to >>> scp to the people.a.o. Add an issue to Bugzilla, and attach your patch there. You can do it now, and it easies documenting. Though scp is still faster for small things; and I do not like that Bugzilla forces me to download a patch when I just want to look at it. BTW, I am using WinSCP, and it is a nice GUI tool. > > The problem with status file is that it gets constantly > recycled. There is no clear way to obtain actual patches > applied without going trough SVN log between versions. Do svn diff, and ignore what changed in STATUS. Or look for log/diff of some subtree, e.g. for /java > Changelog is fine but it doesn't contain a reference to > the actual commit. It does. Use "annotate". Though some patches are applied in several commits, or have followups. But JIRA won't record the patch, unless you have JIRA issue reference in the commit message. How many commits have Bugzilla bug number in them? (Most do have, though sometimes it can be omitted, or an issue can be covered by several bugs). > There is also no way to record why some feature wasn't > applied. I can clearly show that at some time one feature > vas vetoed and one year later it passed (proposed by another > committer). So either the original veto was not appropriate, > that person changed opinion, or was on vacation :) Or the patch was new / explanation was different / more experience gained. If that happened, than it is good. Go on. > Also when there are 3 +1 in status one that proposed > a patch can apply it and recycle status. Again if > you are not fast enough, you might just skip that > and find yourself chasing sudden bugs all over the SVN. JIRA won't prevent your need to chase "sudden" bugs. There are still the same patches and the same people who vote. One thing that can prevent that is to extend our test suite. > you are not fast enough Most patches are present in status for more than a week. Should be enough time for review. Also, all commits go to dev@, so it is advisable to read them through. There still can be issues with how the patch was applied. Also, dev@ archives are searchable. > I personally find JIRA much easier to work with cause > everything needed is at one place. Subversion also keeps everything in one place. Some other thought: The Subversion project was recently choosing what Bug tracking system they will be using at Apache, when migrating from Tigris. They choose Bugzilla, not JIRA: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2415808 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
