Re: [RFC] Proposal: Migrate LTS/TODO wiki page to GitLab issues
On Mon, May 25, 2020 at 03:18:17PM -0400, Roberto C. Sánchez wrote:
> Hello fello LTS folks,
> I have been discussing with Raphael some things which we can do to
> improve the state of the LTS/TODO page in the Debian wiki. This arose
> from part of the discussion during the April LTS Contributors IRC
> After some back-and-forth discussion I would like to make the following
> Proposal: Migrate the issues and items from the LTS/TODO page into
> GitLab issues on Salsa (in a yet-to-be-created project,
> Rationale: The nature of a wiki makes it suboptimal for managing
> discrete work units. As developers, we are all familiar with
> interacting with the Debian BTS and other similar systems (e.g., Jira,
> GitHub issues, etc.). While the Debian BTS would be a natural first
> choice, the best mechanism for grouping related issues that do not
> belong to a single package is usertags. However, there is currently not
> a way to subscribe to usertags in order to receive notification of new
> bugs created with the tag or of existing bugs which have the tag added
> to them. With that in mind, the creation of a new Salsa project for
> grouping and managing these issues is the best choice given available
> Objective: Remove all content from LTS/TODO which can reasonably be
> captured in one or more GitLab Salsa issues. Then, from this point
> forward manage non-package-specific LTS tasks as issues within the
> lts-team/lts-extra-tasks project.
> Please reply with any objections, concerns, comments, or suggestions.
> Barring any objections or major unresolved issues between now and then,
> I intend to start migrating the content on or after 1st June.
Could you lease do make somehwere clear that tough any work on those
task in almost all (but not all) cases would need to coordinate and
work together with the other team around. Maybe this is implicitly
clear, but just want to make sure there is no work vasted.
Change proposals please also done via merge requests (requested by a
fork, to make the work-in-progress and later "git split" easier not
having to handle other branches, altough that comes to a cost of a
longrunning fork until ready) and/or posting to the security-tracker
To not make it seem I'm complaining, I want to point a highly positive
and very constructive example of such an LTS team contribution done by
Emilio Pozuelo Monfort, which was the "Distro config reuniication"
work done by him:
Kudos again for Emilio.