--===============1076176323970760363==
Content-Type: multipart/alternative;
boundary="Boundary-01=_uihdPKK0EGcOQF9"
Content-Transfer-Encoding: 7bit
--Boundary-01=_uihdPKK0EGcOQF9
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
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/
--Boundary-01=_uihdPKK0EGcOQF9
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
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/
--Boundary-01=_uihdPKK0EGcOQF9--
--===============1076176323970760363==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
--===============1076176323970760363==--