using gitlab (or other) issue tracker instead of mailing list?

using gitlab (or other) issue tracker instead of mailing list?

[Timothee Cour]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Spawned off from a separate discussion:
> regression: zsh completion stopped working after upgrading zsh 5.2=>5.3

What are your requirements for tracking zsh issues, and could this be
accomplished by a standard issue tracker (eg github/gitlab/bitbucket)
instead of this mailing list ?

To summarize:

* github/gitlab are widely used so no particular signup would be needed
* using github.gitlab, ppl can click on Watch to follow/unfollow individual
issues or all of zsh issues to choose how much email from github they
receive
* it would lower the barrier of entry to enter bugs, ie get bugs fixed
faster
* all benefits of bug tracker as opposed to mailling list [tracking bugs,
cross references, search, syntax highlighting etc]
* avoids revealing your email address
* this has been adoped by https://github.com/zsh-users [Zsh community
projects (not directly affiliated with the zsh project)] probably for a
combination of the above reasons


Daniel Shahaf's comment:

> For one, I assume we won't consider a bug tracker that doesn't have
bidirectional email integration with this mailing list.  (to minimise
workflow disruption)

The issue trackers I mentioned do have bidirectional email integration, eg
I can see github issues in my email and replying via email will also reply
in github issues, etc.

Re: using gitlab (or other) issue tracker instead of mailing list?

[Bart Schaefer]

On Dec 31,  5:10pm, Timothee Cour wrote:
}
} What are your requirements for tracking zsh issues, and could this be
} accomplished by a standard issue tracker (eg github/gitlab/bitbucket)
} instead of this mailing list ?

I think the answer to the "instead" part of that question is "no,"
if only because of the long-standing practice of linking changes to
discussion threads by use of the list archive article number.

My personal requirements for any tracker that isn't the zsh-workers
mailing list are (1) somebody else is responsible for operating it;
(2) it's at least as useful to those of us who are updating the code
as it is to the people who just want to report problems; and (3) I
no longer have to carry on this discussion.

By way of relatively recent analogy, we switched version control from
CVS to git because the people who were proponents of the change got
involved with the process, and provided suggestions/assistance/tools,
and in several cases actually became involved in code maintenance.
Without that degree of commitment to whatever bug tracker you propose
we adopt, continuing to push it is just a distraction.

Re: using gitlab (or other) issue tracker instead of mailing list?

[Timothee Cour]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

>> But I feel I have to advocate for those who oppose any solution which
requires signing up anywhere as I can understand those people very well.

On this topic:

when I try to send an email to zsh-users@zsh.org from my main gmail
(foo@gmail) using a different 'From' field (foo2@gmail) it sends an
automated response:
Delivery to the following recipient has been delayed: zsh-users@zsh.org Message
will be retried for 0 more day(s)
[and keeps failing]

so i need to log to my other gmail (foo2@gmail) that i signed-up with to
this mailing list. So looks like there is still a need to sign-up with this
approach?
[not using my primary email because this mailing list shows email in the
open, unlike bug-trackers like the ones I listed]

Or am i doing something wrong?


On Mon, Jan 2, 2017 at 1:42 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Dec 31,  5:10pm, Timothee Cour wrote:
> }
> } What are your requirements for tracking zsh issues, and could this be
> } accomplished by a standard issue tracker (eg github/gitlab/bitbucket)
> } instead of this mailing list ?
>
> I think the answer to the "instead" part of that question is "no,"
> if only because of the long-standing practice of linking changes to
> discussion threads by use of the list archive article number.
>
> My personal requirements for any tracker that isn't the zsh-workers
> mailing list are (1) somebody else is responsible for operating it;
> (2) it's at least as useful to those of us who are updating the code
> as it is to the people who just want to report problems; and (3) I
> no longer have to carry on this discussion.
>
> By way of relatively recent analogy, we switched version control from
> CVS to git because the people who were proponents of the change got
> involved with the process, and provided suggestions/assistance/tools,
> and in several cases actually became involved in code maintenance.
> Without that degree of commitment to whatever bug tracker you propose
> we adopt, continuing to push it is just a distraction.
>

Emailing this list from unsubscribed addresses (was: Re: using gitlab (or other) issue tracker instead of mailing list?)

[Daniel Shahaf]

Timothee Cour wrote on Thu, Jan 12, 2017 at 09:34:23 -0800:
> On this topic:
> 
> when I try to send an email to zsh-users@zsh.org from my main gmail
> (foo@gmail) using a different 'From' field (foo2@gmail) it sends an
> automated response:
> Delivery to the following recipient has been delayed: zsh-users@zsh.org Message
> will be retried for 0 more day(s)
> [and keeps failing]

_Why_ was delivery delayed?  There should be a technical explanation in
there.

> so i need to log to my other gmail (foo2@gmail) that i signed-up with to
> this mailing list. So looks like there is still a need to sign-up with this
> approach?
> [not using my primary email because this mailing list shows email in the
> open, unlike bug-trackers like the ones I listed]
> 
> Or am i doing something wrong?

I suspect that the "subscribed" / "not subscribed" distinction might
a red herring.  That said, you could try emailing zsh-users-allow-subscribe[at]zsh.org
from foo2, to whitelist that address as a sender without subscribing it.
(You'll need to reply to the autoreply)

Re: Emailing this list from unsubscribed addresses (was: Re: using gitlab (or other) issue tracker instead of mailing list?)

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

Gmail servers are on a blacklist that the zsh list servers use.

On Jan 12, 2017 12:06 PM, "Daniel Shahaf" <d.s@daniel.shahaf.name> wrote:

> Timothee Cour wrote on Thu, Jan 12, 2017 at 09:34:23 -0800:
> > On this topic:
> >
> > when I try to send an email to zsh-users@zsh.org from my main gmail
> > (foo@gmail) using a different 'From' field (foo2@gmail) it sends an
> > automated response:
> > Delivery to the following recipient has been delayed: zsh-users@zsh.org
> Message
> > will be retried for 0 more day(s)
> > [and keeps failing]
>
> _Why_ was delivery delayed?  There should be a technical explanation in
> there.
>
> > so i need to log to my other gmail (foo2@gmail) that i signed-up with to
> > this mailing list. So looks like there is still a need to sign-up with
> this
> > approach?
> > [not using my primary email because this mailing list shows email in the
> > open, unlike bug-trackers like the ones I listed]
> >
> > Or am i doing something wrong?
>
> I suspect that the "subscribed" / "not subscribed" distinction might
> a red herring.  That said, you could try emailing
> zsh-users-allow-subscribe[at]zsh.org
> from foo2, to whitelist that address as a sender without subscribing it.
> (You'll need to reply to the autoreply)
>

Re: Emailing this list from unsubscribed addresses (was: Re: using gitlab (or other) issue tracker instead of mailing list?)

[Timothee Cour]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

> you could try emailing zsh-users-allow-subscribe[at]zsh.org from foo2, to
whitelist that address as a sender without subscribing it. (You'll need to
reply to the autoreply)

I did that a few hours ago, but it still doesn't work:
On gmail [logged in as my primary foo@gmail.com], I replied to this message
[http://www.zsh.org/mla/users//2017/msg00041.html] but it's not appearing
in that list [http://www.zsh.org/mla/users//2017/index.html]. So I have to
log in to my other gmail [foo2@gmail.com] to send messages to zsh-users.
Not sure if I'm missing something.

On Thu, Jan 12, 2017 at 12:07 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> Gmail servers are on a blacklist that the zsh list servers use.
>
> On Jan 12, 2017 12:06 PM, "Daniel Shahaf" <d.s@daniel.shahaf.name> wrote:
>
>> Timothee Cour wrote on Thu, Jan 12, 2017 at 09:34:23 -0800:
>> > On this topic:
>> >
>> > when I try to send an email to zsh-users@zsh.org from my main gmail
>> > (foo@gmail) using a different 'From' field (foo2@gmail) it sends an
>> > automated response:
>> > Delivery to the following recipient has been delayed: zsh-users@zsh.org
>> Message
>> > will be retried for 0 more day(s)
>> > [and keeps failing]
>>
>> _Why_ was delivery delayed?  There should be a technical explanation in
>> there.
>>
>> > so i need to log to my other gmail (foo2@gmail) that i signed-up with
>> to
>> > this mailing list. So looks like there is still a need to sign-up with
>> this
>> > approach?
>> > [not using my primary email because this mailing list shows email in the
>> > open, unlike bug-trackers like the ones I listed]
>> >
>> > Or am i doing something wrong?
>>
>> I suspect that the "subscribed" / "not subscribed" distinction might
>> a red herring.  That said, you could try emailing
>> zsh-users-allow-subscribe[at]zsh.org
>> from foo2, to whitelist that address as a sender without subscribing it.
>> (You'll need to reply to the autoreply)
>>
>

Re: Emailing this list from unsubscribed addresses (was: Re: using gitlab (or other) issue tracker instead of mailing list?)

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

It's not anything you are doing or can do.  A subset of Gmail servers have
been listed as a spam source by a widely-used anti-spam blacklist, so if
you use Gmail and have the bad luck to be sending through one of those
servers, your message will be rejected by the list server.

The only workaround is to not use Gmail, or send repeatedly and hope one
goes via a server that isn't blacklisted.

Re: using gitlab (or other) issue tracker instead of mailing list?

[Axel Beckert]

Hi,

On Sat, Dec 31, 2016 at 05:10:43PM -0800, Timothee Cour wrote:
> Subject: using gitlab (or other) issue tracker instead of mailing list?

That discussion isn't new, see e.g.
http://www.zsh.org/mla/workers/2015/msg03353.html (which is the last
mail in that thread and contains more or less the whole thread).

> * github/gitlab are widely used so no particular signup would be
>   needed

IMHO this is just wrong. Both, GitHub as well as GitLab require you to
sign up with them to file bug reports. Just because they're popular,
doesn't mean you can ignore their requirement to sign up to report
bugs.

> * using github.gitlab, ppl can click on Watch to follow/unfollow
> individual issues or all of zsh issues to choose how much email from
> github they receive

Definitely a feature we currently don't provide and which IMHO would
be nice.

> * it would lower the barrier of entry to enter bugs, ie get bugs fixed
> faster

That depends a lot on the point of view. I know enough people for whom
having to use GitHub or GitLab is a barrier high enough to not report
bugs at all, because they would have to create an account which they
don't want to do.

For the current system, no account is necessary. You could even submit
patches or bug reports anonymously since SMTP allows to use arbitrary
sender addresses.

> * all benefits of bug tracker as opposed to mailling list [tracking bugs,
> cross references, search, syntax highlighting etc]

Both, cross references as well as a search are available via
http://www.zsh.org/mla/.

> * avoids revealing your email address

Well, that's as good as you don't need to reveal your real address to
send a mail via SMTP.

Don't get me wrong: I do have both, GitHub and GitLab accounts and I
would also use GitHub for issue tracking (but personally aren't too
happy with GitLab). But I feel I have to advocate for those who oppose
any solution which requires signing up anywhere as I can understand
those people very well. E.g. I stopped years ago to report bugs to any
project who's using Bugzilla.

My most favourite bug tracker so far is debbugs, the bug tracking
system developed for and used by Debian, but also used by e.g. the GNU
Project. You control everything by e-mail there. And control by e-mail
is IMHO mandatory for Zsh's use case, too. But debbugs is no
bug-tracking system for a single open source project. It's rather made
for a collection of projects and totally overkill if you want to use
you own instance just for a single project.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: using gitlab (or other) issue tracker instead of mailing list?

[Daniel Shahaf]

Timothee Cour wrote on Sat, Dec 31, 2016 at 17:10:43 -0800:
> Spawned off from a separate discussion:
> > regression: zsh completion stopped working after upgrading zsh 5.2=>5.3
> 
> What are your requirements for tracking zsh issues, and could this be
> accomplished by a standard issue tracker (eg github/gitlab/bitbucket)
> instead of this mailing list ?

Thanks for starting this thread.

For what it's worth, I do support having some list of bugs: we do from
time to time run into bugs, but those that we don't patch immediately
are only recorded in the list archives.

Bug trackers are generally open to the public and so serve some user
support role as well.  However, as far as I know, the existing support
channels work well, and only a "repository of known, acknowledged,
unfixed bugs" functionality is missing.

As Eric points out, we could simply start using Etc/BUGS to fill that
functionality.  Let's adopt the convention that every entry be tagged
with an X-Seq number for ease of reference:

diff --git a/Etc/BUGS b/Etc/BUGS
index 9991ad9..96958f9 100644
--- a/Etc/BUGS
+++ b/Etc/BUGS
@@ -12,6 +12,13 @@ the nonomatch and nullglob options.
 ------------------------------------------------------------------------
 It is currently impossible to time builtins.
 ------------------------------------------------------------------------
-The comp* completion-related builtins (compadd, compset, etc) are run with
-$_comp_options in effect, rather than the user's options.
+40106: The comp* completion-related builtins (compadd, compset, etc) are
+run with $_comp_options in effect, rather than the user's options.
+------------------------------------------------------------------------
+40240: vcs_info: percent escapes in payloads are interpreted
+
+Example: hg branch names and quilt patch subjects that contain the literal
+string '%F{blue}', cause $vcs_info_msg_N_ to be rendered in blue.
+
+40240 has a patch, but 40241 explains why that patch is incomplete.
 ------------------------------------------------------------------------

... and to be clear, the venue for support questions and bug reporting
will [under this proposal] continue to be the zsh-users@ mailing list.

Cheers,

Daniel

Re: using gitlab (or other) issue tracker instead of mailing list?

[Frank Terbeck]

Hey!

Daniel Shahaf wrote:
[...]
> --- a/Etc/BUGS
> +++ b/Etc/BUGS
> @@ -12,6 +12,13 @@ the nonomatch and nullglob options.
[...]
> +40240: vcs_info: percent escapes in payloads are interpreted
> +
> +Example: hg branch names and quilt patch subjects that contain the literal
> +string '%F{blue}', cause $vcs_info_msg_N_ to be rendered in blue.
> +
> +40240 has a patch, but 40241 explains why that patch is incomplete.

This particular one is documented in the contrib manual in the
"Oddities" subjection of the vcs_info documentation.


Regards, Frank
-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: using gitlab (or other) issue tracker instead of mailing list?

[Daniel Shahaf]

Frank Terbeck wrote on Mon, Jan 02, 2017 at 16:58:10 +0100:
> This particular one is documented in the contrib manual in the
> "Oddities" subjection of the vcs_info documentation.

I'm aware of this, but I still consider it a bug that vcs_info — with
the default configuration, i.e., no special hooks or styles — interprets
%F{blue} sequences in branch names.

That is, ignore 40241 for the moment, which is about user hooks;
consider the reproducer in 40240, which involves no hooks.

Cheers,

Daniel

Re: using gitlab (or other) issue tracker instead of mailing list?

[Ray Andrews]

On 02/01/17 07:38 AM, Daniel Shahaf wrote:
>
> ... and to be clear, the venue for support questions and bug reporting
> will [under this proposal] continue to be the zsh-users@ mailing list.

I'm hardly competent to have an opinion, but indeed why would that 
change?  Bugs reported here are most efficiently dealt with as it is.  
One might imagine some sort of log or list but the basics of the thing 
are ideal just as they are.

Re: using gitlab (or other) issue tracker instead of mailing list?

[Peter Stephenson]

On Mon, 2 Jan 2017 15:38:30 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> For what it's worth, I do support having some list of bugs: we do from
> time to time run into bugs, but those that we don't patch immediately
> are only recorded in the list archives.
> 
> Bug trackers are generally open to the public and so serve some user
> support role as well.  However, as far as I know, the existing support
> channels work well, and only a "repository of known, acknowledged,
> unfixed bugs" functionality is missing.
> 
> As Eric points out, we could simply start using Etc/BUGS to fill that
> functionality.  Let's adopt the convention that every entry be tagged
> with an X-Seq number for ease of reference:

For what it's worth, I agree with all the above.

Just to repeat what Bart already says for form's sake: the crucial thing
missing for use of a more formal bug tracker is someone to operate it,
and anyone who reads the mailing list, can use a web interface and prod
the developers for info and has time to be diligent is suitable.  None
of the usual suspects has time to be diligent enough to make it more tha
a millstone around the neck.

There's a similar danger with the BUGS file, of course, but it's easily
found and fixed and if we edit it ourselves it doesn't have the key
danger that someone raises a bug that then just sits doing nothing for
ever.  (Of course, if no one fixes it is *does* sit around, but, to coin
a phrase, duh.)

pws