Release Script

[Albert Astals Cid]

El Dimecres, 27 de juny de 2012, a les 17:39:03, vau escriure:
> 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
> (You=Packager).

I do not disagree here, BUT have in mind that since we have private packages 
(used/tested by distro packagers before the release actually happens) so YOU 
is a broad term including the packagers.

> For KDE would say someone else should decide. We could make a release
> 4.8.80.1 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'm sure having a micro release is going to break their scripts that just 
expect 3 numbers.

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

Yes.

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

No, Dirk didn't branch any release, he created a 4.8.x branch, which doesn't 
make sense since KDE/4.8 branch is exactly that.

What i'm saying is create a 4.8.80 branch where we can cherry-pick the needed 
fixes for re-packaging 4.8.80 because right now this can happen

Imagine the 4.10 Beta 1 release in a few months, current behaviour would be
 * Package 4.9.80 from master branch
 * People keep adding fixes and whatnot to master
 * You realize there's some compile problem in platform X
 * You need to repackage 4.9.80 to include the fix, but since you have no 
4.9.80 branch you have two options:
   - Update wholesale to the mater branch including not only the fix but all 
the other commits too
   - Manually include the fix in the tarball, making git tagging impossible 
since there's no hash commit anymore with the contents you are releasing

If we create a 4.9.80 branch this issue is fixed, since you cherry-pick there 
and re-create the tarball.

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

Not sure I see the problem then, can't you just invoke build-tool from the 
script that you/us are creating?

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

That works for me.

> But that probably breaks
> 
> ~/ws/src/KDE/kdelibs : git describe
> v4.8.90-26-g1dd5c9d
> 
> Which i personally do not care about. I won't stop doing the right thing
> because it is inconvenient.

I'm not a git knowledgeable person, what would exactly break and why?

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

Sure, it only does releases, but our releases include running meinproc right 
now to create the index cache files for documents.

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

It'd be cool to support this workflow since we have some big packages like 
kde-artwork or oxygen-icons that don't change much, so by doing that we can 
"cache" some work.

Cheers,
  Albert

> 
> Mike