Marco Hi,<div><br></div><div>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.</div><div><br></div><div>Mer makes regular releases and also pre releases so vendors can check that the next release won't break their code.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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 (<a href="http://wiki.meego.com/Release_Infrastructure/BOSS">http://wiki.meego.com/Release_Infrastructure/BOSS</a>) 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.</div>
<div><br></div><div>BR</div><div><br></div><div>Martin <br><br><div class="gmail_quote">On Fri, Mar 30, 2012 at 1:04 PM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com">notmart@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
this is a proposal on how to handle the development in a way where is easier<br>
to assure qa and have device specific images.<br>
<br>
from a short chat with some people it was seen there was a need of<br>
reorganizing a bit how git branches are kept and how this reflects on obs.<br>
I am explaining it now how i understood it, so please correct if wrong ;)<br>
<br>
* Need for a stable, always releasable master<br>
* How to do that? an "integration" branch<br>
* integration is kept always merged, up to date with master<br>
* features are developed in feature only branches<br>
* when a feature is almost ready is merged into integration, people test it,<br>
fixes are done in the feature branch, then re-merged<br>
* when tested enough, it gets merged into master<br>
* Device specific (Archos, vivaldi, whatever) releases are branches of master<br>
called like Device/Vivaldi (only a stable state needed? or integration/stable<br>
for that too?)<br>
<br>
This reflects in obs in the following way<br>
* integration project points to integration branch, (or devel can be<br>
repurposed to it)<br>
* testing project points to master: master became a stable branch now<br>
* Each device specific git branch has an own obs project<br>
<br>
this is just an idea, please comment ;)<br>
in the end a good final workflow document will need to be in place<br>
<br>
Cheers,<br>
Marco Martin<br>
_______________________________________________<br>
Active mailing list<br>
<a href="mailto:Active@kde.org">Active@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/active" target="_blank">https://mail.kde.org/mailman/listinfo/active</a><br>
</blockquote></div><br></div>