Moving to the new infrastructure

Moving to the new infrastructure

[Eric S. Raymond]

As I've previously noted, I was on the road with only spotty access to
email all last week.  Accordingly, I've somewhat lost track of the
discussion of potential choices for an issue tracker and a new VCS.
Has any consensus emerged that was not present last Sunday (13 Jan)?

The VCS survey I'm working on has turned into a major project.  I have over
a dozen reviewer/collaborators now and a huge backlog of contributions
and critiques to absorb.  I expect there's almost a week's worth of
catch-up I'll have to do before I can even get to the point of doing
more in the way of original writing and new evaluations.

Therefore, while I am still willing to do the grunt-work involved in
qualifying and installing an issue tracker for Emacs, it might be more
efficient for me to concentrate on getting the VCS evaluations done
and let someone else take the lead on the issue tracker.  Does anyone
want that job?
--
					>>esr>>

Re: Moving to the new infrastructure

[Karl Fogel]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> As I've previously noted, I was on the road with only spotty access to
> email all last week.  Accordingly, I've somewhat lost track of the
> discussion of potential choices for an issue tracker and a new VCS.
> Has any consensus emerged that was not present last Sunday (13 Jan)?
>
> The VCS survey I'm working on has turned into a major project.  I have over
> a dozen reviewer/collaborators now and a huge backlog of contributions
> and critiques to absorb.  I expect there's almost a week's worth of
> catch-up I'll have to do before I can even get to the point of doing
> more in the way of original writing and new evaluations.
>
> Therefore, while I am still willing to do the grunt-work involved in
> qualifying and installing an issue tracker for Emacs, it might be more
> efficient for me to concentrate on getting the VCS evaluations done
> and let someone else take the lead on the issue tracker.  Does anyone
> want that job?

While I eagerly await the VCS survey, I even more eagerly await a bug
tracker (and don't have time to set up debbugs or something myself).
If you're asking for other people to suggest how to prioritize your
time -- always a dangerous thing thing, of course -- I'd vote for
issue tracker first and *then* VCS evaluations.

YMMV, and of course it's entirely up to you.

-Karl

Re: Moving to the new infrastructure

[Richard Stallman]

Would you like to volunteer to try one of the candidate bug trackers
using only email, and see how well it works?
I can have the FSF forward bug-gnu-emacs mail and emacs-pretest-bugs mail
to an address of your choice.

Re: Moving to the new infrastructure

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> Would you like to volunteer to try one of the candidate bug trackers
> using only email, and see how well it works?
> I can have the FSF forward bug-gnu-emacs mail and emacs-pretest-bugs mail
> to an address of your choice.

No, I don't have time to take this on right now.

-Karl

Re: Moving to the new infrastructure

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Stallman wrote:
| Would you like to volunteer to try one of the candidate bug trackers
| using only email, and see how well it works?

In my experience, "e-mail - operated bug trackers" (e.g., RT) are much
worse than simple mailing lists.
specifically, if you use more than one e-mail address (as I do), they
turn into an unmitigated disaster because they tend to require that you
reply using the same address which was used when you first submitted the
issue &c.

the general rule is that communication with a machine is inherently
different from communication with a human being: a machine has low
latency (it does not eat, sleep, have a day job), but requires a fixed
format (majordomo commands have to be spelled correctly).
this is why I find e-mail a good way to communicate with humans (and
distribute notifications of changes to a bug in a tracker), and web a
good way to communicate with bug trackers.
specifically, I no longer subscribe to mailing lists that do not offer a
web interface to the subscription process (e.g., mailman) because I do
not use e-mail to talk to robots.
I will find it impossible to use an e-mail-only bug tracker, such as RT.

also, e-mail operated bug trackers will be infested with spam (and any
attempt to filter span _on entry_ will hamper legitimate bug reports).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHl1TRPp1Qsf2qnMcRAtYPAKClN7vZElBsETF2ln18twrUZM7yzwCeJVmD
YhfusHDO/+xF0S3wjsUOe6g=
=O02Y
-----END PGP SIGNATURE-----

Re: Moving to the new infrastructure

[Manoj Srivastava]

On Wed, 23 Jan 2008 09:53:05 -0500, Sam Steingold <sds@gnu.org> said: 

> Richard Stallman wrote:
>> Would you like to volunteer to try one of the candidate bug trackers
>> using only email, and see how well it works?

> In my experience, "e-mail - operated bug trackers" (e.g., RT) are much
> worse than simple mailing lists.  specifically, if you use more than
> one e-mail address (as I do), they turn into an unmitigated disaster
> because they tend to require that you reply using the same address
> which was used when you first submitted the issue &c.

        This is certainly not a limitation of the Debian bug tracking
 system, debbugs, since it does not require people to be "registered".
 Having used this for almost a decade, I can say that in my personal
 opinion, debbugs has outperformed any othe issue tracking system I have
 used (I ahve run bugzilla and request tracker for my day job).

        This is how it works:
 http://www.debian.org/Bugs/server-control


        Debbugs keeps track of which versions of the software various
 issues are related to, and has a web front end for viewing.  The web
 frontend can be ordered by various ways; please see the difference
 between:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=srivasta@debian.org&ordering=policy
        and
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy


        Same package, same bugs, but ordered in a totally different
 fashion; and any user can set up their own classification and order,
 independently of anyone else, and share the classification/order for
 the bugs.

        Also, people can track the same issue across different packages
 individually without needing sysadmin intervention; hewre are bugs that
 are deemed to be release critical and affect arm, m68k, s390, and sparc:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=debian-release@lists.debian.org&tag=rc-arm,rc-m68k,rc-s390,rc-sparc&nam0=Status&pri0=pending:pending,forwarded,pending-fixed,fixed,done&ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU,Resolved&nam1=Architecture&pri1=tag:rc-arm,rc-m68k,rc-s390,rc-sparc&ttl1=arm,m68k,s390,sparc&ord1=0,1,2,3

        Please do not think that debbugs is yet anotherrun of the mill
 system with the flaws of other bug systems; it truly stands alone.

        manoj
ps: here is a refcard for the system:
 http://www.debian.org/Bugs/server-refcard
-- 
"Unemployment is an inconvenience." John F. Haugh II
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Moving to the new infrastructure

[Stephen J. Turnbull]

Sam Steingold writes:

 > In my experience, "e-mail - operated bug trackers" (e.g., RT) are much
 > worse than simple mailing lists.
 > specifically, if you use more than one e-mail address (as I do), they
 > turn into an unmitigated disaster because they tend to require that you
 > reply using the same address which was used when you first submitted the
 > issue &c.

Roundup does not require that you use the same address to reply.  It
does require that you register all addresses you use in advance of
using them, or you'll get bounced as a possible spammer.  I suppose
that for infrequent users this would be equivalent.  Roundup *can* be
configured to automatically register the user (with the usual mailing
list style opt-in email confirmation), but I think this would be an
opening to spambots.

I don't know if other trackers have the feature of allowing a single
user to register multiple email addresses, though.  It turns out to be
trivial to implement in Roundup, so it's always been available as long
as I've been following Roundup.

 > specifically, I no longer subscribe to mailing lists that do not offer a
 > web interface to the subscription process (e.g., mailman) because I do
 > not use e-mail to talk to robots.
 > I will find it impossible to use an e-mail-only bug tracker, such as RT.

Nobody is suggesting that the tracker be email-only, merely that it be
tested that way so that email-only users can be confident that they
can use it.

BTW, AFAIK RT does have a web interface that can be used to submit
bugs.  Are you thinking of debbug?

 > also, e-mail operated bug trackers will be infested with spam (and any
 > attempt to filter span _on entry_ will hamper legitimate bug reports).

Filtering spam on entry is not negotiable, unfortunately, because the
reporting address must be public.  Taking reports by email is also
non-negotiable, some people will not use a web interface, and M-x
report-emacs-bug is just too convenient.  So those legit reports are
just going to have to lump it.

One possibility is to put a moderation interface in front of that.
This may be desirable from the point of view of eliminating not-a-bugs
and not-our-bugs from the database as well.  It is easy to write a
Mailman handler to send some traffic on to a specific address.  It
would probably require hacking Mailman's web interface to allow the
moderator to send the traffic on.

No, I'm not interested in volunteering the work for Emacs, but if I do
it for my project I'll try to remember to report back.

Re: Moving to the new infrastructure

[Richard Stallman]

    I will find it impossible to use an e-mail-only bug tracker, such as RT.

Perhaps you misunderstood the issue.  I did not say we should use an
email-only bug tracker.  I said I want someone to try out using various
bug trackers by email only.

If we use a bug tracker, I will have to use it by email only.  YOU are
welcome to use it by a web interface, but I can't.  If it is too hard
to use by email then I can't use it, so it is unacceptable.