Automatically associate DD and DM accounts with GPG keys in keyring packages to allow DDs to use the Launchpad Email interface

See http://permalink.gmane.org/gmane.linux.debian.devel.general/130575 for additional background of this idea.

comments from debian on how this could be implemented:

http://comments.gmane.org/gmane.linux.debian.devel.general/130693

This is a great idea. In order to make this useful, though, we need to do changes that are a bit more invasive. Basically, we need to "half-validate" these accounts: they won't have passwords, but in other ways they would be mostly like activated accounts and we can:

  - Associate them to bug reports and other bits of data in Launchpad
  - Email them when their subscriptions would cause them to be mailed
  - Allow them to post emails and gpg-signed modifications
  - Provide homepages for them in Launchpad so they can figure out what they are subscribed to, etc.

The main issue here is subscribing and emailing them. The alternative would be to simply accept gpg-signed email from them, but not actually email them back (or allow them to be subscribed). But I find that such an unuseful compromise I'm not inclined to set it up unless there's a good reason to.

Kiko: I think accepting GPG-signed email would be better than nothing; and one up on needing to fake the email sender address.

Another one today:

  08:21 < Hydroxide> sladen: and of course I'd have to create a launchpad account to file a bug ... (yes I know it's a common malady for most non-debian bugtracking systems and ubuntu isn't worse than most in that regard)

After talking to the Ubuntu LP Stakeholder, it sounds like LP development has stopped, and there are no plans for additional features. This means this bug either needs to go to "Won't Fix", fixed by another team, or get escalated through some higher path.

On Tue, Jul 24, 2012 at 9:21 AM, Kees Cook <email address hidden> wrote:
> After talking to the Ubuntu LP Stakeholder, it sounds like LP
> development has stopped, and there are no plans for additional features.
> This means this bug either needs to go to "Won't Fix", fixed by another
> team, or get escalated through some higher path.

Thats a misrepesentation.

Canonical isn't funding large new features right now (there are other fish to fry in the short term). This != 'stopped'.

Maintenance is continuing, in the same structure with the same resources (a full squad) that its had for quite some time.

Escalated bugs are still being accepted, but the queue / WIP limit for them has been hit: to put another bug into the escalated queue requires the stakeholders as a whole to remove one (or for one to be completed by the maintenance squad). The Ubuntu LP Stakeholder is entirely capable of undertaking that negotiation on the stakeholders list.

The assigned importance on this bug is 'low' for the LP team itself, which is accurate: its not escalated, its not a regression and its not on the (admittedly short) roadmap. Marking it 'Won't Fix' would be saying that patches would not be welcomed: this is false, patches for it would indeed be welcomed.

-Rob

This is not true. The extent of feature development in LP has slowed
with a refocusing of effort, but it certainly hasn't stopped.

That said, to be honest I see no particular reason why this bug should
be prioritised over many of the others we care about.

(Sorry, if I'd seen Robert's reply I'd have added quoting. For clarity, I was replying to Kees.)

Development of new features as escalated by the Ubuntu stakeholders has indeed stopped quite completely. We had several features requested by Ubuntu on LP's roadmap last year, all of which were ended late last year when the LP teams were refocused onto other project, with no plans at all that I am aware of to restart those or add any new ones. I have no plans to propose any new features for escalation at this time. I'm surprised there's any controversy on this at all.

As far as bug escalations go, contrary to what Robert says, the maintenance was reduced from two teams to one late last year. When this happened, the WIP limit was likewise reduced. But the queue size was (and is) larger than that limit, so even as bugs get fixed, no new bug escalations will be accepted until it's dropped below that limit. Robert is correct that the only way to get it on the bug escalation list is to bump another bug. Yet even so, escalated bugs get fixed only very occasionally; it used to be we'd see 5-10 bugs fixed per quarter, but I think only 3-4 escalated bugs have been fixed the past three quarters since the staffing change. Effectively, stakeholder escalation is blocked.

The only alternative I know of is for another team to "send a patch". As I understand it, you would also be required to submit a second patch to retire tech debt (i.e. delete some lines). Maybe that requirement is waived on stakeholder escalations, I don't know. Judging from the recent work on blueprints and some of Colin's work, this is IMHO the only feasible way to get things into launchpad these days.