Soyuz should send announce messages for backports to different list

High priority due distro-team request

Each week, LWN publishes a list of updates to Dapper, and lately this list has been long despite there being no non-backports updates. This is confusing for readers, and makes Dapper look like it has more churn than it actually does.

This week's LWN just went out with more announcements of backports which aren't recommended for general use.

Matt,

After some discussion we (malcc and I) decided that the best approach to reach this feature soon is to hardcode this policy in the UploadPolicy.announcelist property.

It should return None for uploads to pocket BACKPORTS, default recipient (drescher mbox) and uploader will continue to recieve the email. Anything else related you want you to consider before start the implementation ?

It will require some modification in nascentupload to not reach "Empty To:" error when dispathing email. (old problem, though)

It also remembers me that we could extend this to avoid announcements of laguage-packages as well, which currently are done by hand to avoid spamming the announcelist with 600 emails every time.

More ideas coming soon...

On Wed, Oct 04, 2006 at 06:42:48PM -0000, Celso Providelo wrote:
> Matt,
>
> After some discussion we (malcc and I) decided that the best approach
> to reach this feature soon is to hardcode this policy in the
> UploadPolicy.announcelist property.
>
> It should return None for uploads to pocket BACKPORTS, default recipient
> (drescher mbox) and uploader will continue to recieve the email.
> Anything else related you want you to consider before start the
> implementation ?

Sounds fine to me.

> It also remembers me that we could extend this to avoid announcements of
> laguage-packages as well, which currently are done by hand to avoid
> spamming the announcelist with 600 emails every time.

Very good point, with that process becoming more frequent and regular, they
should follow a more normal upload procedure.

--
 - mdz

Queue tool is fixed to not send emails to announcelist when accepting BACKPORTS items, it continue to send the email to the uploader and the drescher inbox (default_recipient specified in config).

Work is done in my `soyuz-fixes`.

About the language-packs, the only way I can see is to:

 * skip announcement if upload is target to "translation" section.

Does it makes sense ?

It will require fix in nascentupload/uploadpolicy (for auto-approved uploads, target to RELEASE pocket) and in queue (for new, unapproved uploads target to UPDATES/BACKPORTS/PROPOSED pockets).

The system clearly needs unification, but I'm not sure it's the time to do it.

Is this not rolled out yet? These are still going to dapper-changes and LWN:

https://lists.ubuntu.com/archives/dapper-changes/2006-October/012213.html

RF 4166

I've just released it in drescher.

This is still not working.

https://lists.ubuntu.com/archives/dapper-changes/2006-December/thread.html

Right, the fix didn't cover BACKPORTS uploads coming from `backport-source` script.

Since they are processed using `sync` policy and this policy *auto-approve* everything, the email message is sent earlier (in nascentupload.py yet).

As discussed with Colin, the "auto-approve behaviour" is wanted, since the packages were already reviewed before the backport process starts.

A sensible solution would be to reproduce the "don't announce backport upload in changeslist" behaviour in nascentupload.

It still *quick & dirty*, because the best thing to do would be consolidate the queue messaging system in one place, keeping the fixes introduced in the queue processing system.

I will see what I can do in short-term timeframe.

Promoting to *critical*, since it's clearly a regression (well, a half-done task, at least)

On Mon, Dec 04, 2006 at 01:34:08PM -0000, Celso Providelo wrote:
> It still *quick & dirty*, because the best thing to do would be
> consolidate the queue messaging system in one place, keeping the fixes
> introduced in the queue processing system.

I agree. I don't see this as being such a big task if we actually do the
nascent upload refactoring; what do you think?

Christian Robottom Reis wrote:
> On Mon, Dec 04, 2006 at 01:34:08PM -0000, Celso Providelo wrote:
>> It still *quick & dirty*, because the best thing to do would be
>> consolidate the queue messaging system in one place, keeping the fixes
>> introduced in the queue processing system.
>
> I agree. I don't see this as being such a big task if we actually do the
> nascent upload refactoring; what do you think?
>

Yes, good point, doing this we can maximize the results. I will investigate
which tasks should be accomplished.

[]
--
Celso Providelo <email address hidden>
Gwyddion Intelligent Devices - http://www.gwyddion.com

demoted to *High* as agreed in LP meeting.

Well, I've decided to land the simple short-term solution, otherwise it would take ages until we get enough entropy to change whole nascentupload.
Fix is pending review in my `trivialities`

It's been another month and this problem still exists.

Sorry, code is waiting for review since 22th Dec, I will try to be more effective.

Branch was relocated to another reviewer ...

New code to accomplish the another distro-team request was added:

{{{
Uploads targeted to SECURITY pocket will be announced in the configured 'changeslist' (acceptance email will be skipped in this case).
}}}

RF 4511

There is still having a problem with the last fix, it will generate 'announcements' for binary uploads using security policy.
I have the fix in ready for review in my `trivialities` (it also improves the test with extra use cases)

RF 3810 (new tree) drescher cherrypick.