kde at michael-jansen.biz
Wed Jun 27 15:39:03 UTC 2012
On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote:
> That works fine for me, though unfortunately we usually have to re-package
> some tarballs due to fixes that are needed into the release. How do you fit
> this particularity into this way of working?
With my config manager head on i say "NEVER rerelease a version". Which in our
case includes everything that has been downloaded/used by anone not you
For KDE would say someone else should decide. We could make a release 18.104.22.168
if we have to repackage stuff. But the packagers distros should give input
here. I think they should say what is the easiest for them to handle.
> > I see one problem. As you can see the changed version information is only
> > committed AFTER build and test in this setup. That can take quite some
> > time. In a project as big as ours that opens the possibility that during
> > that time some else commits a change. Which makes it impossible for the
> > script to commits its change.
> > 1. Solution: Branch. The Script could create a branch for the release.
> Creating a branch for release would also probably "fix" the problem i spoke
> in the previous paragraph
You mean the repackaging?
I am btw. wondering that noone objected yet to this. I seem to remember
someone was unhappy about dirk branching some 4.8.x release. I don't remember
where and why.
> > 2. Solution: Lock the repo (A no go in my opinion)
> Yeah, locking kills babies
> > And a little problem. The feasability of beeing able to build our software
> > before packaging. I already have a solution to build the packages with
> > build- tool as a test. But no idea yet how to combine build-tool with this
> > script unless i add this into build-tool. And the admins would like to
> > have
> > python. Not ruby. And build-tool would not mash with the idea to use
> > jenkins to trigger the releases.
> "this script" == maven?
I will not use maven. I just steal some workflow there. This script is the
script which we currently try to hammer out how it should work.
> > 4. Allow the script to maintain the version increase. We have to decide
> > how
> > to solve the race condition inherent in this.
> Don't understand what you mean by this.
The race condition here is the part where i talked about the script checking
out some sources. Working for two hours (compiling, testing, packaging) and
then wanting to commit its changes. When someone else committed something in
that time it cannot do that on our KDE/4.x branch. The solution i prefer would
be to create a KDE/4.x.3 branch and commit there.
But that probably breaks
~/ws/src/KDE/kdelibs : git describe
Which i personally do not care about. I won't stop doing the right thing
because it is inconvenient.
> In general it seems a very well though out proposal, i don't see any obvious
> problem in what you are describing.
> One thing that is problematic with the current build scripts is the need of
> having up to date meinproc+kdoctools to build the packages that come after
> kdelibs, do you think that'd be an issue?
Not really. Because this script will not care. It only releases for now. The
build-tool recipe i develop for example would take care of that. It could
download and install the required version before going to work on the release
packages. Like it can do with soprano, sip, pyqt4, sdo ... .
Btw. the script will only tag if you ask it too. I still remember your work-
flow of packaging stuff a week before the release date and then on release
date only repackage stuff that got changes during that time. That has to be
supported by the script.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the release-team