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