Release 1.7

If we upgrade core to 6.24 in the update, we need to ship with those two bugfixes:

http://drupal.org/node/1425868
http://drupal.org/node/1425260

We should make people aware of this issue: #1421356: Wrong variables for files paths hardcoded for D7 sites because it has the potential to break things, although that is very unlikely.

We might need to only go to 6.23 because of this bug: #1425868: Duplicate entry of themes primary key in systems table of Drupal 6.24 (using Drush or Ægir)

I'm not sure why we should, unless we need something in 6.24?

It's not entirely clear if that patch will get into Drupal 6 core, so would rather not patch Aegir to include it :)

Let's release with this at least #1435144: get rid of the debian branch, make a native package.

This is a pretty major bug, hope this patch makes it in for 1.7 ...

http://drupal.org/node/1083366

Without it, people will lose data on backup, clone or migrate for files with the same name. The master overwrites the remote file of the same name.

So let's wait until next week.

6.25 is out now, so I've kicked off a build of 6.x-1.x on PHP 5.2, which should test that out:
http://ci.aegirproject.org/job/D%20aegir%206.x-1.x%20install%20-%20PHP%2...

That test passed, so you are all clear for a release I think.

Alright. I still need to finish the branch cleanup, i'll try to do this today or monday (no releases on friday! ;)­.

relnotes being written here: https://pad.riseup.net/p/aegir-1.7

alright, mostly done with the release notes.

rackspace is being a dick and timing out my builds, so I can't test the new debian branching stuff, followup in that issue: http://drupal.org/node/1435144

there are two RTBC issues we should look at:

1. should we ship with #1083366: Make the spokes authoritative for files/ and private/ directories? it seems to fix some files syncing, not sure what it does
2. it seems we should just commit #1334210: Ipv6 support for _hosting_valid_ip too, IPv6 = good, and it's a simple tested fix

there's also a bunch of issues that needs review, if people are bored.

Ah, and I reviewed the critical issue queue and it seems we're good there.

Alright, I committed two issues but not #1083366: Make the spokes authoritative for files/ and private/ directories, which has an API change and has some cosmetic issues. I will not block the release for this issue, and I am not sure we should even commit it at all in 1.x because of the API change.

I have pushed the debian packaging issue a bit forward, but we're pretty much blocked on Rackspace for this release, as it times out on most jobs. Also, the debian package building script fails because the latest tags on the branch are the debian tags, which wrecks havoc in the autobuild script. I assume that once we lay down the 1.7 tags, this will fix itself.

So basically, we're block on rackspace/jenkins now. See #1435144: get rid of the debian branch, make a native package for followup.

I have pushed the 1.7 tag of provision to fix the debian package build. I also pushed a 1.7 tag for hostmaster. Jenkins seems to be unstuck now.

I closed the Debian branch merge issue, as the merge is done and pushed. Now the remaining issue is with the release process itself.

I am kind of stuck on the S_aegir-debian-official jenkins job. It will not work anymore with the new debian branch merge, as there is now no branch that has the "latest release code". So it will either needs to:

1. take a tag as an argument and build from that, or
2. just disappear and let release.sh build the package

This goes back to whether or not we want jenkins to do the actual official release.

The more I look at this, the more I feel that the jenkins scripts and the release.sh are duplicates and we need to decide between the two: do we want our core team to interact with the Debian archive and sign packages, or do we want jenkins to do all that for us?

Right now I think that release.sh should just call git-buildpackage right after it lays down the tags. That will produce a nice, neat and precious .deb that then needs to be uploaded to the archive (that could also be scripted), and then go on its way with the rest of the script.

Since I am unsure I want to scrap hard work others have done in Jenkins, I will wait for feedback on that. Besides, I need to test those debian packages somewhere so I'll need more time before the release.

In the meantime: the release is *not* finished, and those tags I pushed could still move around. Do *not* create the release nodes on drupal.org until we decide on the above issues.

The more I look at this, the more I feel that the jenkins scripts and the release.sh are duplicates and we need to decide between the two: do we want our core team to interact with the Debian archive and sign packages, or do we want jenkins to do all that for us?

I don't build debian packages at any other time than for Aegir, so the process is a bit of a mystery to me to be honest, so I'd rather have some other tool that ran the correct commands and had the correct keys set up etc. But I can see that a real person do these things is also attractive.

alright, so the issue is weird debian black magic. i think i agree with that: while the tagging part of the release process keeps logs and accountability (through git history), building the packages through release.sh makes it actually more obscure, because it kicks in more dependencies from outside our regular toolchain.

so i'll try to work on #1: make a job that will build a debian package from a tag.

I have fixed the package build scripts and the documentation. Now there is a 1.7 package in place in the testing archive. I guess the only thing left is to test that package, create the release nodes and pull that package into stable, then publish the announcements and we're released.

I don't have time to test anymore today, but I hope to release tomorrow...

taken the release notes out of the pad and into the wiki: http://community.aegirproject.org/1.7

next steps:

* wait for all those last jenkins tasks I created to go green
* test the release in real servers
* create the release nodes (from the text in the provision tag)
* A link to the release notes on the frontpage block
* An event in the calendar
* A discussion post (don't forget to make it 'sticky' & remove stickiness from the previous announcement)
* Update the version in the script upgrade page
* The topic of the IRC channel
* The aegir-announce mailing list
* Twitter as @aegirproject

Note that this job fails because it depends on the packages being built on d.o, seems to me that's the wrong way of going about it...

http://ci.aegirproject.org/job/U%20aegir%206.x-1.0%20to%206.x-1.x%20upgr...

i have moved the tags to include #1062168: chained certificates support in the release, updated the release notes too.

also pushed #1463948: Show automatic domain aliases in the site form separately as it was RTBC.

there was something weird with the 1.7 tag in provision - it was really not laid in the right place. i have moved it and rebuilt the packages in jenkins, now running new tests.

* wait for all those last jenkins tasks I created to go green

done.

* test the release in real servers

done.

* create the release nodes (from the text in the provision tag)

done. now doing the last tests, will do:

* A link to the release notes on the frontpage block
* An event in the calendar
* A discussion post (don't forget to make it 'sticky' & remove stickiness from the previous announcement)
* Update the version in the script upgrade page
* The topic of the IRC channel
* The aegir-announce mailing list
* Twitter as @aegirproject

release is *done*, have fun everyone. release process docs updated too.