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

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.

And the corresponding ticket in the tracker.

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.

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

Reply via email to