Hi, I deleted the second level of response markers (> ) for easier reading.
Milan Vancura, 22.01.2009: > Hi. > > I'm sorry I'm in hurry as I must go for my ill daughter. So, in short: > > > Oh, I meant a replacement for join-lines-improved (I wrote: after the > > "feat/"), but I think it's OK. > > "feat" was just inspired from Vim's "FEAT_..." compiler switches. > > I vote for fix/fast_join. It is a fix, not a feature, I think. > Feature == new option or something like that. This is a fix of the slow > algorithm. I know that better word would be "an improvement" but in case I > have > just three words I must match in (fix, feat, dev), I vote for fix. Yes, it's a fix. I rather thought about the two namespaces to distinguish between fast-forward and rebase-able branches. I didn't want to get too many namespaces and I think, since fixes should go upstream, it doesn't make too much sense. But on the other hand I think it's OK, we can put upstream stuff into vim_extended to get it mature till inclusion. So we could have "fix" and "feat" with non-rebasing policy and "dev" for everything one can dream of. > Adding me to the project: my name at repo.cz is 'milan', so you can add me to > your project. Thank you. OK, I will do it in the near future and send you a mail then. > About other ideas: > > 1. your subscription is still missing in > http://repo.or.cz/r/vim_extended.git/README.html Still? Nobody has asked about it yet. However, this is not the proper web URL. In http://repo.or.cz/w/vim_extended.git there is my email address in the owner field. But nevertheless, I will adjust it. > and it would be very nice to have your name there so a contact to the > maitainer will be well known. Do you agree? Yes. > 2. what about other patches from > http://groups.google.com/group/vim_dev/web/vim-patches > > and the integration of them to vim_extended? No problem, start working on it. I'd still like to see some involvement of the authors. That would make it even more valuable. > 3. what about a promo of vim_extended at vim-patches page? John Beckett has added an entry today. > 4. putting more git trees together: you can either pull from my git tree > instead of me pushing to your one. This has an advantage that you have your > git > tree under control. Just because of the current DVCS hype, it doesn't mean that we cannot work in centralized fashion. Given the low traffic of vim_extended (among others not being an upstream project also is a reason for it) and the few people contributing, pulling from other repos doesn't seem to be necessary. So I think there shouldn't arise problems in keeping the repo clean with more than one person having push access. We just have to set some rules for clean commit logs, who is allowed to push to which branch and so on. You asked me for push access, but if you prefer having your own tree, then I'd be fine with that as well. > 5. what about a cooperation with Christian and pul his git tree as > vim_upstream? There is no dependency on svn, nice tags for vim versions are > there... Would it be possible? No, it wouldn't. It looks nice at first sight, but it isn't really useful for development. Look at the branches, they each have their own root, they don't have any relation to each other. With Vim 7.3, the master branch will be rewritten from scratch. You can't merge and forward-port the feature branches to the next minor release. In fact you'd end up with a rebase of all your branches as well. vim_extended will be based on tarballs and patches one time, as mentioned in the README.html. I just don't have so much time. And I'm not quite sure how much history to include, in what way using branches... I have integrated the latest runtime files in a branch and it's possible to merge it, which actually adds real value. That was more important, because from time to time you can read problems or complaints regarding the runtime files overwriting your custom changes. But the reworked repo should yet come during the 7.2 lifetime :) > 6. if you want to see more about git (in practice), there are documents > describing a work of kernel hackers with git (sections for developers, > subsystem maintainers etc.). For example this one looks good: > > http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development > > - just for inspiration what workflows are possible. I don't dare to compare vim_extended with a project with over 100 commits per day. So even if all these workflows are possible and acceptable for me, I don't think the fate of vim_extended is dependend on the kind of workflow, whereas at the kernel development it surely is. Before the arrival of the DVCSes I guess most of the projects were developed on subversion (and probably still are) with many people with commit access. It worked. KDE for example still lives on SVN and it is a huge project. To be clear in one sentence: I'm not opposed to use a real distributed workflow, but I don't think it's necessary. Greetings, Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
