This afternoon I was looking at the tickets posted in Trac, and I saw that there we quite a few stale tickets and patches. A lot of these are filed against very old versions of Rails, I think it''s fair for the people posting these tickets that they get resolved. Either by just removing them all or by weeding them out. I understand that closing tickets is not very glamorous work and can certainly take up a lot of time, but I would very much like to see this cleaned up. I''m certainly willing to put some time into this. What is the current process the core team uses for accepting patches and handling tickets? There are a few loose notes somewhere about this, but it might be good to publish this somewhere so people know what to expect. Thanks, Manfred
> What is the current process the core team uses for accepting patches > and handling tickets? There are a few loose notes somewhere about > this, but it might be good to publish this somewhere so people know > what to expect.There''s no formal procedure per se. The ticket has to be tested, follow style conventions, be backwards compatible, and hopefully something that has meaning for most people most of the time. But all of these rules go out the window some times, if there''s a stroke of genius found in the submission. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On Jun 1, 2006, at 7:03 AM, David Heinemeier Hansson wrote:>> What is the current process the core team uses for accepting patches >> and handling tickets? There are a few loose notes somewhere about >> this, but it might be good to publish this somewhere so people know >> what to expect. > > There''s no formal procedure per se. The ticket has to be tested, > follow style conventions, be backwards compatible, and hopefully > something that has meaning for most people most of the time. But all > of these rules go out the window some times, if there''s a stroke of > genius found in the submission.That''s good to know, and pretty much what I expected to hear too. But I''m curious about how much people use the Trac reports. Does anyone really sit down and look at the Unprocessed Patches report to figure out what patches to look at? If someone submits a patch with the e.g. "tiny" keyword, that puts it in the Tiny report - does that mean it might not get, um, processed? I''m just now writing up some notes on keywords and it would be useful to tell folks whether adding those keywords helps or hinders their effords. -- Josh Susser http://blog.hasmanythrough.com
On Thu, Jun 01, 2006 at 11:38:03AM -0700, Josh Susser wrote:> > On Jun 1, 2006, at 7:03 AM, David Heinemeier Hansson wrote: > > >>What is the current process the core team uses for accepting patches > >>and handling tickets? There are a few loose notes somewhere about > >>this, but it might be good to publish this somewhere so people know > >>what to expect. > > > >There''s no formal procedure per se. The ticket has to be tested, > >follow style conventions, be backwards compatible, and hopefully > >something that has meaning for most people most of the time. But all > >of these rules go out the window some times, if there''s a stroke of > >genius found in the submission. > > That''s good to know, and pretty much what I expected to hear too. > But I''m curious about how much people use the Trac reports. Does > anyone really sit down and look at the Unprocessed Patches report to > figure out what patches to look at? If someone submits a patch with > the e.g. "tiny" keyword, that puts it in the Tiny report - does that > mean it might not get, um, processed? I''m just now writing up some > notes on keywords and it would be useful to tell folks whether adding > those keywords helps or hinders their effords.I use the reports but not religiously. I use them once-in-a-whilely. On the occasion when I do, though, it is appreciated and allows me to quickly process a lot of tickets. marcel -- Marcel Molina Jr. <marcel@vernix.org>