Re: Moving away from (unsupportable) FusionForge on Alioth?
- Date: Tue, 16 May 2017 17:05:36 +0000
- From: Sean Whitton <spwhitton@xxxxxxxxxxxxxx>
- Subject: Re: Moving away from (unsupportable) FusionForge on Alioth?
On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> I've got some different ideas. While it makes sense that packaging-only
> projects on the new VCS hosting system should not enable the issue tracking
> system (people should use Debian BTS instead. Pull Requests should be enabled
> to allow external contribution.), there are many semi-native and native
> packaging projects directly related to Debian.
> For example, there are documentation projects like debian-reference and
> debian-handbook, native packages like dpkg, apt and reportbug. In that case,
> the issue tracking *should* be enabled and used. Issue tracking here will act
> as the replacement of mailing lists from lists.alioth.debian.org. (Issue
> tracker acts just like mailling lists. The sole difference is that you must
> start a thread on web interface.)
> My opinion is that the use of issue tracking systems should be decided by the
> maintenance/packaging team (for team-maintained pkg) or the repository owner.
Firstly, as noted by Benjamin, disabling issue tracking does not mean
losing the merge/pull request workflow (which is what we really want out
of all this). You do lose some integration between issues and
pull/merge requests, but that's minor.
I think that we should disable issue tracking across the Pagure
instance. I disagree that it should be up to the package maintainers.
This is for two reasons.
(1) Please don't underestimate the confusion and inconvenience of having
two issue trackers for Debian. This is not a migration: we will not
drop the Debian BTS because it is heavily customised for our needs --
even for native and pseudopackages, which you suggest replacing. So we
should try really, really hard to avoid the situation where code
contributors have to look in two places.
I'm even more concerned for those who only report bugs and test fixes,
who might not know where to report. If it is clear that pagure is for
code/doc contributors only, and those who only report bugs never need
look at pagure, we can minimise the frustration of our pure bug
reporters, who are an extremely valuable group of contributors.
(2) A web interface is much less accessible than our BTS. We have
contributors on poor network connections, and we shouldn't force them to
use pagure's interface. Perhaps it has GitHub-style e-mail support, but
in my experience you always end up having to access the web issue tracker.