Should we aim to clear dla-needed list?

2020-06-21 Thread Utkarsh Gupta
Hi all,

As we're nearing the Jessie (as LTS) EOL, should we aim to clear the
dla-needed list?
Or will this get passed on to ela-needed?


Best,
Utkarsh



Re: stretch EOL point release (9.13) and 10.5 planning

2020-06-21 Thread Salvatore Bonaccorso
Hi security team, LTS team members,

On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam D. Barratt wrote:
> stretch transitions from oldstable-with-security-support to LTS support
> on Saturday July 4th. As usual, we should aim for the final point
> release to be soon after that, most likely pulling in any remaining
> updates from security.d.o that are still in oldstable-new.

FTR, the current needing changes for the security-tracker part are
baking up in 
https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/55
 (still keeping the WIP tag).

LTS team, double check in particular the parts affecting the LTS
workflow.

Regards,
Salvatore



Re: [RFC] Proposal: Migrate LTS/TODO wiki page to GitLab issues

2020-06-21 Thread Salvatore Bonaccorso
Hi Roberto,

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
> meeting.
> 
> After some back-and-forth discussion I would like to make the following
> proposal.
> 
> Proposal: Migrate the issues and items from the LTS/TODO page into
> GitLab issues on Salsa (in a yet-to-be-created project,
> lts-team/lts-extra-tasks).
> 
> 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
> tooling.
> 
> 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
mailinglist.

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:

https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/48

Kudos again for Emilio.

Regards,
Salvatore