Review request for actions outlined in bug 801714

[Max Bowsher]

On 12/07/11 01:50, Martin Pool wrote:
> On 12 July 2011 08:02, Max Bowsher <_ at maxb.eu> wrote:
>> This bug: https://bugs.launchpad.net/udd/+bug/801714 is a miscellany of
>> import repairs falling under the common heading of removing incorrectly
>> done imports of new upstream versions.
>>
>> I now have jubany access, so can enact these myself - but before I start
>> wielding ./delete_branches_from_lp.py, I wouldn't mind someone glancing
>> over my proposed actions and confirming they're happy.
> 
> Thanks for addressing that and for asking for review.  I want to make
> sure I understand the impact of these changes.
> 
> The key point is
> 
> maxb>> In all cases, the fix involves truncating the imports back to
> before the mistake was made, so that the importer can proceed normally
> again.
> 
> So what are the revisions that will be evicted from these branches
> when they're truncated, and does it matter that they are?
> 
> Looking at for instance
> <https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/accerciser/oneiric>
> vs <https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/accerciser/maverick>,
> it seems it's always a commit by an Ubuntu developer bringing in a new
> upstream with a simple commit, which is pretty much what bug 494481
> says.  So those revisions will be lost, but the moral equivalent will
> be recreated by the updated import of the package.
> 
> It seems reasonably safe to me.

Yes, the above summation is correct.

> 494481 is getting to be quite a long bug because of the specific
> packages discussed there.  I'm not sure how we would specifically
> detect someone trying to bring in a new upstream without using
> merge-upstream.  Do you have an idea?

I think user education would probably suffice. Whilst there is quite a
long list of imports to fix *now*, that list has built up over years.

With the overall number of failures being driven down, it will become
much more likely to spot such issues soon after they arise, and let the
person generating the bad non-merge know how to do it properly.


If we wished to add active prevention, we could probably come up with a
partially successful heuristic, but I'm not convinced we could avoid
false-positives reliably enough.

Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20110712/27fb08a3/attachment.pgp>