On 15 Jan 2011, at 16:34, Arjan van de Ven wrote:
> On 1/15/2011 7:48 AM, Nashif, Anas wrote:
>> Hi,
>> As a measure of cleanup and to better reflect the MeeGo architecture in the
>> build system, we are planning to redo the project structure.
>> The restructuring would happen in three steps, starting with the least
>> intrusive one:
>>
>> 1) Step 1: Start 2011-01-20
>> - Create Trunk:UX and Trunk:UX:Testing
>> - Move Trunk:{Handset|Netbook|IVI}/* to Trunk:UX
>> - Make Trunk:Testing a link to Trunk
>> - Initial package cleanup of new Trunk:UX project.
>> Result:
>> - Trunk
>> - Trunk:UX
>> - Trunk:non-oss
>> With corresponding *:Testing projects.
>>
>> How will this affect you?
>>
>> * This step will produce one single repository for UX and application on
>> top of Core instead of the many we have right now.
>> * Image configurations will need to be changed and would point to at least
>> 3 repos: core, ux and non-oss (if needed)
>> * If you have been developing against one of the Trunk sub-projects
>> (Netbook,Handset, IVI), then you will need to re-branch or relink to the new
>> Trunk:UX project
>>
>> 2) Step Two: Start 2011-01-21 - End 2011-03-23
>> - move non-core packages to Trunk:UX, optionally drop or move
>> non-supported packages from both Trunk and Trunk:UX to Community if needed
>
> has this been reviewed with the architecture team?
Restructuring the projects was discussed with architecture team back in October.
Moving packages one level up is a direct consequence of the above, since many
of the packages we have in Trunk now are there because they had to be shared by
many UX projects.
>
> I don't recall it has been, and I'm not very fond of this to be honest.....
> while I appreciate moving from 4 to 2 projects, I'd rather even go to one
> project. Already, anything not in Trunk should be an extreme exception, and
> that should remain so...
>From a structural point, I also prefer to have just one project and thats it,
>there was a request however to be able to have a minimal, compliant package
>set that would make it easy to build compliant packages without running the
>risk of including dependency on none core meego libraries or packages.
Personally, I am also for the one project approach, provided we go through a
major cleanup of the packages to make sure everything is maintained and
supported.
Anas
>
> _______________________________________________
> MeeGo-packaging mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-packaging
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
