Bug 7574

Summary:	The project release change process deletes imported layers without warning
Product:	[Build System, Metadata & Runtime] Toaster	Reporter:	Belen Barros Pena <belen.barros.pena>
Component:	toaster	Assignee:	Michael Wood <michael.g.wood>
Status:	RESOLVED OBSOLETE	QA Contact:	Libertad <libertad.gonzalez.de.la.cruz>
Severity:	normal
Priority:	Medium+	CC:	alexandru.damian, belen.barros.pena, cristiana.voicu, jessica.zhang, jose.perez.carranza
Version:	unspecified
Target Milestone:	2.2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)
Bug Depends on:	8429
Bug Blocks:

Description Belen Barros Pena 2015-04-07 15:55:23 UTC

Steps to reproduce:

1. With Toaster in build mode, create a project with release 'Yocto Project master'

2. Add a layer that exists in master but does not exist for the fido branch yet (for example, meta-raspberrypi). 

3. Import a layer

4. Change the project release to 'Yocto Project 1.8 Fido'. A modal dialog will come up warning you that if you change the release meta-oe and meta-raspberrypi will be deleted from your project because they don't exist for fido. 

5. Change the release

meta-oe and meta-raspberrypi will be deleted from the project layers, as the dialog warned you, but your imported layer will be deleted too (without prior warning in this case). 

Imported layers are not governed by the same rules as layer source layers, and they should never be deleted from the project layers when you change the release.

Comment 1 Michael Wood 2015-07-23 21:48:02 UTC

Part of the issue is that Imported layers get a release set on them, which makes them seem like incompatible layers after the release has been changed.

Maybe they shouldn't get a release set at all.

Note to self:
views.py:2191
...
def project
...
if 'projectVersion' in request.POST

Comment 2 Belen Barros Pena 2015-07-24 09:31:59 UTC

(In reply to comment #1)
> Part of the issue is that Imported layers get a release set on them, which
> makes them seem like incompatible layers after the release has been changed.
> 
> Maybe they shouldn't get a release set at all.

This sounds good to me. The goal is keeping imported layers in the project, to avoid user confusion.

From the UI side of things, these layers would need to show a revision, like all other layers do, but they would inherit the revision matching the project release. 

> Note to self:
> views.py:2191
> ...
> def project
> ...
> if 'projectVersion' in request.POST

Comment 3 Michael Wood 2016-02-05 19:20:19 UTC

Wider reworking of the import layer mechanism has been identified so this will be part of that work

Comment 4 Belen Barros Pena 2016-02-16 10:35:49 UTC

We are removing the ability to change the project release (see bug 8917).