Workflow and integration

[Lamarque V. Souza]

Em Friday 30 March 2012, Marco Martin escreveu:
> Hi all,

	Hi,
 
> 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

	What happened if a feature from on repo depends on a feature from 
another repo's integration branch? I use obs to compile packages and test 
features here. In my case I would need to hack obs to compile two (or more) 
packages whose .tar.bz2 are not in obs. I usually do that for one package, but 
when I need to do that for two packages at the same time it gets way more 
complicated because of the dependencies. People who use Mer SDK would have the 
same problem too.

> * 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

	Why use a git branches instead of sub-directories? With sub-directories 
we can use only one obs project to build all rpm packages for all devices and 
minimize the burden of maintaining different copies of the same files. For 
instance, we can create a "shared" sub-directory which contains all 
configuration files, if a device needs a different configuration file we 
create a sub-directory for that device and copy only the files that it needs. 
Then we configure the .spec to, during installation phase, copy the shared 
directory to the BUILD_ROOT and then override the files there with the ones 
from the device's sub-directory. This way we only duplicate the files that 
needed to be duplicated and not all of them. Moreover we also avoid 
duplicating several .spec (for each device) that in other way would me almost 
equal to each other.

	There is only one problem with that approach, all sub-packages would 
have the same version, so when doing a change for one device that would 
trigger a sub-package creation for all other devices and probably an update 
that is not really needed. As long as the configuration packages are small 
(and they are for now) I do not see a big problem here.

-- 
Lamarque V. Souza
http://www.basyskom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120330/dc27d160/attachment.html>