launchpad-dev team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

On 28/06/12 01:36, Iain Lane wrote:
> Hi there,
> 
> [ I've tried to send this several times without success, so apologies if
> you receive multiple copies. This one should work. ]
> 
> I filed bug #1016776 about adding some extra flags to the Release file
> for the proposed pocket of pre-release distroseries, to improve the
> end-user experience there.

Bug #800515 requests the same thing for -proposed post-release. Bug
#888665 is probably a blocker for both; LP can't build packages against
build dependencies from a NotAutomatic suite.

> My proposed implementation is to generate these flags when:
> 
>   a) the distroseries is in development, which means that its status is
>      DEVELOPMENT or FROZEN
>   b) the flag proposed_not_automatic_pre_release is set for this
>      distroseries
> 
> But stub raised during his db review that the column name is horrible.
> One alternative (suggested by wgrant) would be to name it
> proposed_not_automatic, which would imply that the implementation would
> be to generate the flag in the Release file when:
> 
>   a) the flag proposed_not_automatic is set for this distroseries
> 
> This would mean that there would be a manual step to change the flag at
> release time.
> 
> I think I prefer the former implementation, as it matches what we are
> doing with proposed currently. Colin landed some patches to auto-accept
> uploads to proposed for such development distroseries and there will be
> some more work coming to redirect all uploads to proposed for
> development distroseries (which will then be copied to release). So,
> since we're already (going to be) treating it quite differently for
> development series, we might as well spell out the user part of the
> expectation too.
> 
> I'm not opposed to the other implementation though, if that's what
> people want. An argument in favour of that might be that we at some
> point hope to make proposed NotAutomatic post-release too (#1016454).
> We're not ready for that yet, though, until some more client-side work
> is done.
> 
> Another idea could be to have the shorter column name and the first
> semantics, with the status check being removed if it is later decided
> that this is desirable.

There's already lots of other manual changes that have to be made around
release. What's the problem with changing the flag too, given that
nobody seems to be sure what the actual post-release behaviour should be
anyway? Changing code is easy, but changing DB columns is much harder,
so if the behaviour isn't set in stone we probably shouldn't codify it
in the DB schema.

Attachment: signature.asc
Description: OpenPGP digital signature