Excerpts from Kirill Elagin's message of Tue Jun 26 20:05:21 +0200 2012: > Just to note: I don't get this gist idea either. Gist is, you know, > slightly enhanced pastebin, and using it for collecting contributions looks > weird. Yes - I'm abusing it :) But its fine to understand whether the idea works - to have one place to push unfinished work to without asking for commit access. That's whats it is for.
Its meant for cooperatively improving patches in an agile fast non verbose manner till they can be merged upstream. If you don't like the changes somebody else proposed suffix the branch by your name and continue. Its meant for all those small changes which are no worth creating pull requests for, too. They could then be merged in every 3 days or so (maybe even by cherry-picking only if the patch is simple). The mailinglist is the "progress" of discussions whereas the gist could represent the summary (current state of proposals). Its like "I don't need a wiki - I'm reading the mailinglist". In the wiki you can delete old content - you should not do so on the mailinglist. Have a look at this repo: https://github.com/msanders/snipmate.vim/network and you may understand that its not the view helping you to understand what's going on - what is ready to be merged etc. That's what I don't want to happen. This repo is a snippet engine for Vim - and that old version also contained the snippets. Thus 300 people forked to add 3 lines of personal snippet stuff. If you're the maintainer looking for changes on the core engine it may take longer than it should. By using the gist we can ask for categories ready-to-be-merged/... need-help/ personal/marc/php .... Branches which don't get updated for 20 days could be moved to attick/ And in many cases doing a git grep | php might even be enough. Yes - this idea is an experiment. Marc Weber _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev