Workflow and integration

[martin brook]

Marco Hi,

Just to throw another axis into the discussion we need to consider Mer core
in this workflow as not to end up in the tied to MeeGo 1.2 situation.

Mer makes regular releases and also pre releases so vendors can check that
the next release won't break their code.

Maurice I know has been building against these 'next' Mer releases and this
I would say that needs to continue with any change in workflow.

>From your proposals from my point of view a place to pull from to build a
stable Vivaldi / Archos image would be great and we could get the IMG tool
(which runs on the openslx machine) automatically creating stable. images.

Talking about the process automation side of things the new proposal means
potentially more repos and more activity in SR between them,  maybe the
BOSS (http://wiki.meego.com/Release_Infrastructure/BOSS) tool can help a
bit here, I'm copying in David (lbt) from Mer who has great knowledge in
this area of automated release management for products.

BR

Martin

On Fri, Mar 30, 2012 at 1:04 PM, Marco Martin <notmart at gmail.com> wrote:

> Hi all,
>
> this is a proposal on how to handle the development in a way where is
> easier
> to assure qa and have device specific images.
>
> from a short chat with some people it was seen there was a need of
> reorganizing a bit how git branches are kept and how this reflects on obs.
> I am explaining it now how i understood it, so please correct if wrong ;)
>
> * Need for a stable, always releasable master
> * How to do that? an "integration" branch
> * integration is kept always merged, up to date with master
> * features are developed in feature only branches
> * when a feature is almost ready is merged into integration, people test
> it,
> fixes are done in the feature branch, then re-merged
> * when tested enough, it gets merged into master
> * Device specific (Archos, vivaldi, whatever) releases are branches of
> master
> called like Device/Vivaldi (only a stable state needed? or
> integration/stable
> for that too?)
>
> This reflects in obs in the following way
> * integration project points to integration branch, (or devel can be
> repurposed to it)
> * testing project points to master: master became a stable branch now
> * Each device specific git branch has an own obs project
>
> this is just an idea, please comment ;)
> in the end a good final workflow document will need to be in place
>
> Cheers,
> Marco Martin
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120330/f954e067/attachment.html>