Am Mittwoch, 21. Januar 2015 21:02:36 UTC+1 schrieb Ben Fritz: > On Wednesday, January 21, 2015 at 1:33:35 PM UTC-6, Tim Lebedkov wrote: > > > For a beginning, you could maintain a separate installer so that people > > > can actually try that it works and you get feedback. Then you can also > > > gradually change further things, if this is required. > > > > I did, but everything I hear is that the changes will be merged maybe in > > 2016 (and maybe not). > > > > What is your opinion as an active Vim developer? Are you OK with current > > state of the development model or do you think it should be changed (for > > example to be more like the Linux one)? > > > > Many open-source projects do not accept major new features or potentially > breaking changes except at minor or major version updates. Vim is the same > way. 7.4.600 to 7.4.601 can fix bugs. 7.4 to 7.5 can introduce big > potentially breaking things. > > Your installer has the potential to break compatibility with old Windows > versions which Bram still wants to support. > > So I support the idea that it should not be merged until it can either be > fully tested, or until the next version increase, in which case we have a > "last version compatible with Windows XXX" release still. > > Many of the patches to the list post within days, especially those that are > bugfixes with easy reproduction/test scenarios and little risk of breaking > backwards compatibility. > > > > > > > BTW: What kind of 1000 lines code change you are talking about? > > > > If my changes will be merged with speed of 20 lines every 2 years, it would > > take 100 years to merge 1000 lines. > > > > I don't think number of lines has much to do with it. I've submitted 1-line > patches that took months or longer to include, but I've seen patches that > cover hundreds of lines get included within days. It all has to do with: > > 1. How much does Bram trust you based on past submissions? For first-time > patches, I imagine he spends a lot longer reviewing. For Christian, who > submits several patches a day it seems like, it tends to go faster. > 2. How likely is this to break compatibility with some systems or existing > scripts? > 3. How *complex* are the changes? > > and finally: > > 4. How many people really care about this change? How much benefit does the > change give? Bram has limited time, so he prioritizes things a lot of people > ask for, or things with obvious benefit. > > Now, your situation: > > 1. You're a pretty new contributor to the list. Bram does not trust you (yet) > as much as other developers. > 2. New installers are quite likely to break compatibility with one version of > Windows or another. And it's hard to get a large number of Windows > installations to test on. > 3. I cannot comment on this, I haven't looked at your patch. > 4. Your patch makes the GUI for the installer stop looking "outdated". My > guess is maybe 2 out of every 1000 Vim users care about that *at all*.
There are surely many explanations why Bram is so slow at merging patches. In my opinion he is the bottleneck. I do not mean this offensive. We are all just people. I'd like to see the Vim improving faster. My suggestion would be to have a dedicated Windows maintainer (lieutenant?). He should be responsible for Windows and would process the Windows-related patches faster than Bram. Bram would merge the patches from this maintainer without delays. This way we could improve the whole pipeline. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
