* On 22 Nov 2015, Kevin J. McCarthy wrote: > > As the experienced committers have gotten busy, Mutt has had a problem > the past few years accepting patches. However, since becoming a > committer I have personally tried my damnedest to review and accept > patches, and to give attribution to contributors.
(And IMO you've done an excellent job.) > > Given the timescale of mutt (4 releases in 5 years), I can't imagine > > when the 'right time' may be. > > Personally, and I haven't discussed this with the other committers yet, > I would like to release a 1.5.25 around February and try for a 1.6.0 > August of next year. My feeling has long been that because 1.5 has become considerably more complete than 1.4, and because it's been in common non-development use for so long, it has already become the de facto "production" release. I think we could relegate the even/odd versioning to history, apply a 1.6 tag as soon as we clear all in-flight bugfix patches, and continue with only one tagged series from there. (Development would simply be untagged.) I would want to see 1.6 out the door before starting anything so pivotal as a complete reformatting of code. (Comments are another matter; see below.) > During that time, I would like to take a look at a few of the external > patches. Someone requested the trash patch, for one. I agree this would be a good step. We started that review with Debian patches a while back but I don't think we finished. Mutt is a pretty aged project, with a lot of third-party patches. A major consideration with patch merges at this stage of a project's lifespan is maintenance responsibility - committer time is in short supply, so we must be cautious what committers take full responsibility for. Anything that's enabled in a default build needs committer ownership. Other features can be mainlined but off by default, and ownership diverted to a third party. I think some of these patches would be fine as permanent parts of the code with committer responsibility. But many would be acceptable if they come with --with or --enable options in configure. > So, no, there is never going to be a right time, but that doesn't mean > now is as good as any. > > I like Arnt's suggestion of writing a tool. At least the tool can > be audited and applied by a committer, as opposed to reviewing > multi-thousand line patches from a new contributor. +1 to both. Commenting the code and reformatting the code are separate tasks, and should be committed separately. Comments are reviewable, and I can support that without argument. Reformatting will impose a lot of catch-up burden on a lot of people in a short time. That is something to approach carefully. An tool would make this more predictable and more auditable. The tool doesn't even need to be hard -- it could just be a configuration for an existing code formatter. (I would be -0 to indent though, because there are too many incompatible variants. We can work around this with documentation, but it'll still be a PITA.) -- David Champion • d...@bikeshed.us
signature.asc
Description: PGP signature
