Re: OT: mail-based interfaces and web-based interfaces (Re: Extract Git classes from git-svn (1/10))
On 2012.7.24 10:54 PM, Jonathan Nieder wrote: And again, it *does not have to be zero sum*. It doesn't have to be email VS GUI. You can have your cake and eat it too. I assume you're talking about web-based interfaces that have gateways to email, that produce inboxes like this: 24 Jul 02:46 GitHub [github] msysgit/msysgit was forked by peters 23 Jul 10:27 GitHub [msysgit/git] ce8ebc: vcs-svn: rename check_o 23 Jul 10:01 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:50 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:33 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:39 GitHub [github] Comment created on issue 24 (Long fi 23 Jul 09:31 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:30 GitHub [github] Comment created on issue 24 (Long fi 22 Jul 23:57 GitHub [github] Comment created on issue 44 (new git I call that pretending to have my cake, rather than having it. :) That's kind of like pointing at RCS and saying version control sucks and its pointless to try and make it better! Mail gateways built by web sites suck because they live in the web browser and email is an after thought. Sound familiar? Here is a much better example of the RT mail gateway that Perl 5 development uses. They're a dev community still centered around email, so it has to integrate well. http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189716.html And the corresponding ticket in the tracker. https://rt.perl.org/rt3/Public/Bug/Display.html?id=113684 The initial report comes in either via the web tracker or via a command line program (perlbug) that sends an email to the list. Replies on either the tracker or the mailing list are mirrored. Duplicates are detected etc... That's the sort of mail gateways I'm used to. Maybe some day someone will prove me wrong and make a nice web-based tool that I don't even need to know about that mines project mailing lists. If I have to tweak my subject lines a little to help it out, that's fine with me. I think patchwork is supposed to work this way. But unless we're talking about splitting the mailing list into a bunch of mini mailing lists (like some bug trackers do), it doesn't change anything fundamental, so I'm not sure why we're discussing this. I don't follow the bit about splitting the mailing list. -- emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
Michael G Schwern schw...@pobox.com wrote: On 2012.7.24 7:55 PM, Eric Wong wrote: Except git is also a new specialized tool. Your examples are exactly why I'm saddened many projects only adopted git, but not the workflow which _built_ git (and Linux). Github also has broad spectrum utility. I learn how to fork and work with a Github pull request once, and I can repeat that on thousands of different projects of all different sorts of things. This commonality of tools and techniques is very important to easing the on ramp for new (to-your-project) developers. I agree commonality is important. But to me, it's not worth the cost of reliance on centralized, single-vendor solutions. My distrust and dissatisfaction with centralized/single-vendor solutions is the reason I'm involved with Free Software (and decentralized version control) in the first place. Email is integral to Free/Open Source development and remains one of the few things on the Internet not (yet) controlled by any central entity. Once setup, the same email setup can work across all projects which use email. These projects need not be hosted on the same websites/servers at all. While I hear your concern about being centrally controlled, it is largely irrelevant to the new user experience. And remaining independent does not mean you can't use web tools. Be wary of a false dichotomy between Free and web. Of course, I'd be in favor of shifting development to something less centralized than a mailing list. OStatus may become a good choice one day, but the adoption/tools just aren't there right now. We use a mailing list is by no means an indication of commonality. Every project of the send patches to the list form has their own quirks and ways of doing it. Usually they're not written down. This is what I've been struggling with. I've been sending patches to mailing lists for decades and I can tell you everybody does it differently. Send a patch to the list is one of the steeper project on-ramps. Sure, every project/culture has different norms. It's no big deal, learn them, or avoid them. Projects all have different coding styles, different conventions for writing commit messages, changelogs and so on... I live with that and I'll do my best to adjust my style/editor settings/grammar/vocabulary accordingly for each project I contribute to. I won't send patches to mailing lists of projects which prefer patches/pull-requests on their web tracker, either. If the project is important enough to me, I'll (grudgingly) use whatever tools/formats the maintainers prefer. How about we educate users about a proper email setup instead? If they're capable of learning git, they're surely capable of setting up an email client properly, and perhaps more projects can adopt an email-centric workflow. SubmittingPatches would be helped by that, particularly with a clear step-by-step example of using git-send-email and all its numerous command line switches. It's documented in the gitworkflows(7) manpage. They should probably be linked somehow. And, finally, the last thing most people want is more email. Seriously. It sounds like you live in your mailer, but fewer and fewer people do that. Me? I don't want to join another mailing list. My email management is a disaster! I live in my mailer/$EDITOR/shell and I'm happy with that. The last thing I want is more cookies, non-Free JavaScript code, logins, user tracking/profiling, memory/CPU usage. I doubt either of us will get what we want, though : What it comes down to is this: is it enough to contribute to git.git to know how to work on git.git? Or do you also need to live in your mailer? Bolt on that extra requirement and you lose a large swath of contributors. We need to use something. Right now our choice of mailer is the best choice for _existing_ contributors. For me, the whole social network followers/timeline thing also has a _huge_ creepiness factor to it. How one prioritizes and spends time between different different (especially unrelated) projects should be nobody else's business. I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking off on my git work to hack on ProjectNoOneUses :) You want to know what's creepy? That you'd think people work like that. It doesn't work out that way. People have far better things to do than stalk your Github commits to see how you're spending your time. You're just not that interesting. Neither am I! (If I really wanted to I could just compile your activity from public list archives and repositories, so you're really not broadcasting any less information about yourself by staying off Github. But I wouldn't want to, because you're just not that interesting and I have better things to do with my time!) There's a big difference between making information easy-to-access vs. merely possible-to-access. For the most part, people don't
Re: OT: mail-based interfaces and web-based interfaces (Re: Extract
Michael G Schwern schw...@pobox.com wrote: On 2012.7.25 4:48 PM, Eric Wong wrote: We need to use something. Right now our choice of mailer is the best choice for _existing_ contributors. I believe this entire discussion can be reduced to that right there. If your process is optimized for existing contributors, it will work well for existing contributors, who will want to optimize it for themselves. Repeat. If the main way you evaluate your process is asking is this more convenient for me then you're probably in that spiral. This creates a process very well tuned to the existing contributors, and its very convenient for them. But the consequence is it becomes more and more work for a new contributor to join. The process is _not_ a lot of work. At least no more than any other project: observe the regulars - imitate the regulars Many/most regular git contributors are not Linux kernel developers, yet were able to quickly able to get up-to-speed with git. AFAIK, the Linux kernel gets plenty of new contributors every year, too. Before talking about anything else, the existing contributors have to ask themselves a simple question: Do we care about getting new contributors? Yes, if contributors are willing to learn/respect existing conventions. We do take time to help new contributors out :) For me, it's certainly no if there's any endorsement of non-Free Software or centralized/commercial services involved. The answer can be no (yes, but not if I'm inconvenienced is a no). Maybe you're happy with the people you've got. But there's no point in getting into detail until that's settled. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OT: mail-based interfaces and web-based interfaces (Re: Extract Git classes from git-svn (1/10))
Michael G Schwern wrote: And again, it *does not have to be zero sum*. It doesn't have to be email VS GUI. You can have your cake and eat it too. I assume you're talking about web-based interfaces that have gateways to email, that produce inboxes like this: 24 Jul 02:46 GitHub [github] msysgit/msysgit was forked by peters 23 Jul 10:27 GitHub [msysgit/git] ce8ebc: vcs-svn: rename check_o 23 Jul 10:01 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:50 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:33 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:39 GitHub [github] Comment created on issue 24 (Long fi 23 Jul 09:31 GitHub [github] Comment created on issue 44 (new git 23 Jul 09:30 GitHub [github] Comment created on issue 24 (Long fi 22 Jul 23:57 GitHub [github] Comment created on issue 44 (new git I call that pretending to have my cake, rather than having it. :) Maybe some day someone will prove me wrong and make a nice web-based tool that I don't even need to know about that mines project mailing lists. If I have to tweak my subject lines a little to help it out, that's fine with me. I think patchwork is supposed to work this way. But unless we're talking about splitting the mailing list into a bunch of mini mailing lists (like some bug trackers do), it doesn't change anything fundamental, so I'm not sure why we're discussing this. Ciao, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
