Workflow and integration

[Aaron J. Seigo]

On Friday, March 30, 2012 11:19:32 Lamarque V. Souza wrote:
> Em Friday 30 March 2012, Marco Martin escreveu:

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

if you are doing devel, you probably want to be running the integration 
branch(es).

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

obviously we need to have one of the obs projects tracking the integration 
branches. it makes no sense otherwise.

> more complicated because of the dependencies. People who use Mer SDK would
> have the same problem too.

no, because they'd be tracking one of:

* master
* integration
* a device specific target
 
> > * 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?

because these branches need to track the existing code from a "known good" 
point and stabilize around that. that is precisely what branches are for.

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

so we'd have a complete copy of all the source code in each subdirectory? and 
then manually merge diffs between the sub-directories? that makes no sense :)

> For instance, we can create a "shared" sub-directory which contains all
> configuration files,

this has nothing to do with configuration files. this is the code: the shell, 
the applications, etc.

> if a device needs a different configuration file we
> create a sub-directory for that device and copy only the files that it
> needs. 

and when changes are made to the original files that are globally applicable? 
we just copy those changes by hand? how long do we keep those subdirectories?

this also ignore the reality that each device target will end up having its 
own OBS project anyways, so nothing is really to be gained here.

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

and what about files specific to the device? right: you'll need a different .spec 
file.

and again: this is not about configuration. this is about changes in the source 
code in plasma-mobile and stabilization for specific device targets.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20120330/a500406e/attachment.sig>