Workflow and integration

[Lamarque V. Souza]

Em Friday 30 March 2012, Aaron J. Seigo escreveu:
> 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 am asking this because I use obs to compile packages and it removes 
all dependencies from the build directory when compiling a new package. How 
can I prevent it from doing that?
 
> > 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 :)

	No, you copy only the files that need changes. I am not talking about 
diffs, you copy the whole file, not diffs.
 
> > 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.

	Ok then, forget my suggestion.
 
> > 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?

	With branches we will have to apply them by hand using git anyway. The 
difference is that if the change affects affect a file that has never been 
compiled to a sub-directory then we need to apply it only once. If we use 
branches for configuration files we will need to apply the change to all 
branches.
 
> 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.

	If you say so.
 
> > 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.

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

	Again: forget my suggestion then.

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