[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: release branch?
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-03-01 17:43:15
Message-ID: 1674906.gAf8rxDITo () xps
[Download RAW message or body]

El Dissabte, 1 de mar=E7 de 2014, a les 11:05:07, David Faure va escriure:
> Hi,
> =

> I have a question about the release process.
> =

> It seems to me that we currently have to completely freeze the branch that
> is about to be released, for the few days between making the first set of
> tarballs and the day of the official release, so that we can update
> tarballs with any critical fix meanwhile ("respin") without grabbing other
> unrelated changes that people might have been committing meanwhile.
> Right?

We simply get the other changes that may have been commited, since well, wh=
y =

would you not want other bugfixes? :-)

I understand this may be a bit different for the current frameworks scenari=
o =

where you're still doing SIC/BIC changes but for the rest of the branches, =

well, if we have to retag and due to that we get a few more bugfixes, i thi=
nk =

that's a win :-)

> It seems to me that this kind of kills productivity during that week, and
> creates the risk that someone forgot that this was the week where they're
> not supposed to push commits, etc.

Also note that for Betas of the SC we've killed that week (haven't checked =

what you guys are doing in KF), packages are released as soon as they've be=
en =

tarballed and compiled by one person (which nowadays is me).

For the x.y.z releases we mostly have a week to give time to distros to =

compile their packages, since with both me compiling them and jenkins doing =

it, it's hard that they won't compile. Of course it may happen that some hu=
ge =

regression is found in that week but from what i remember lately that hasn'=
t =

happened much.

> Shouldn't we use a "release" branch to fix this?
> E.g. when releasing 4.13.1, first have the release scripts make a
> KDE/4.13.1-release branch in all affected repos, then make tarballs from
> that, then give a week for packaging, and cherry-pick any urgent bugfixes
> into that branch, to make new tarballs from there.
> This prevents accidental commits during that time -- and in fact we could
> even go further and use ACLs so only the "release team" can push to the
> release branch.
> =

> I suppose this has been discussed before - in that case I apologize for
> missing that or forgetting it :)
> =

> But if there's an agreement I volunteer to adjust the release-tools scrip=
ts
> accordingly.

I see were you're going and it seems more "professional and rational" to do =

what you suggest, but as I said i don't think getting a few more bugfixes i=
s a =

bad thing if we have to respin a package, so i think it's better that you =

invest your time in something else other than doing bash coding :-)

Cheers,
  Albert
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]