在 2017年5月16日星期二 +08 下午2:51:16，Benjamin Drung 写道： > Am Dienstag, den 16.05.2017, 13:47 +0530 schrieb Pirate Praveen: > > On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote: > > > Thank you for updating us, Alex. > > > > > > On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote: > > > > - Git Hosting - we want to give pagure [1] a try, which uses > > > > gitolite, which is a > > > > nice git solution. > > > > > > Ah, that's nice. > > > > > > > Pagure also has issue tracking. > > > > > > Is it possible to turn this off? > > > > > > I think it would be bad if we ended up with some people filing > > > issues on > > > the BTS, and others filing them on Pagure. > > > > I think issue tracking and merge/pull requests go together. The main > > attraction of the github/gitlab/pagure workflow is merge/pull > > requests. > > No. They are not necessarily go together. For example, GitHub allows > projects to disable issue tracking, but allow merge proposals. This is > what I would expect for a VCS hosting for Debian.
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. -- Boyuan Yang
signature.asc
Description: This is a digitally signed message part.
