|
Rockbox mail archiveSubject: Re: idea for formalising committal of new features.Re: idea for formalising committal of new features.
From: alex wallis <alexwallis646_at_googlemail.com>
Date: Mon, 23 Aug 2010 17:00:12 +0100 On 8/23/10, Dave Hooper <dave_at_beermex.com> wrote: > I would say that it's about more than just committing it. If nobody with > commit access cares enough about committing a patch, then who is going to > maintain, bugfix, and document (and translate) that feature, and going > forward ensure that the feature remains correctly documented and tested? I > would suggest we don't need to formalise a procedure to get patches > committed; but we might need to formalise something more on ownership after > something has been committed. For patches that already include full > documentation and no bugs, maybe all that's required indeed is agreement > amongst developers that the patch gets committed and becomes an accepted > part of rockbox trunk, but that might be less likely if it's a feature that > developers themselves have no interest in. But also (speaking generally now) > there are probably a number of patches that don't tick these boxes > currently, and for those the trick might be to do all the work upfront and > then try to convince devs that it is ready for inclusion. That's all very true, but at the moment, the tracker is a mess full of old patches, with nobody making a clear decision about what to do with them. The bug tracker is even worse than the patch tracker for this. The reason I suggest formalising inclusion of new features is because it seems to me that you can ask for things to be committed, and nine times out of ten, either there is no will to actually do anything even if people like the idea, or a few people say they don't like an idea and it gets rejected just on their say so. Received on 2010-08-23 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |