I think we're almost ready for a release. Most release critical bugs have been fixed and we need to make a shiny new release on drupal.org to complete the transition.

The issue I feel we should resolve first:

* #1068280: Update order issue during migration from 0.3 to 0.4-beta2 - the upgrade path! master has some fixes to test, otherwise we should consider reverting to the old nasty weight = 10 setting
* migration of the docs to the handbook - we should finish moving the documentation to the community site before making this release, that will also serve as a test for the documentation
* fix the branch/tag naming convention - we need to revert to the old 6.x-0.x way, unfortunately, as this could take months to settle: #322626: META: Package and version non-modules for download

We should also review the release process to see if everything is in order.

Comments

anarcat’s picture

anarcat CreditAttribution: anarcat commented

I tried creating (renaming from provision-0.4 actually) the 6.x-0.x branch on drupal.org and while it allowed me to do it, it doesn't get picked up by the frontend. I also tried creating a tag for a release (6.x-0.4-alpha99) and it didn't get picked up by the release creation form either.

So it looks like we can't release on the 0.x branch. Maybe we'll have to head for the 1.x branch after all... ?

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

As for "migration of the docs to the handbook," I'll get the bulk of it done this week, along with submitting some patches to clean up the /docs folder.

Since the docs are now leaving the code-base to reside on the community site, I wonder if the d.o issue queues remain the best place to manage them (the docs). This dovetails with another question I've had recently as to how to coordinate tasks/issues for the community site itself (such as feedback on the recent Mollom implementation). With consensus of the project maintainers, I'd like to set up the case-tracker on the site for both documentation and site-related issues.

I suspect everyone's initial reaction to this would be: "No! That'll just encourage more bug reports and support requests to the community site instead of the d.o issue queues where they belong!" This is happening anyway, and needs to be addressed regardless of anything else we do.

I'd like to implement something like the "Looking for help?" block here: http://dev.ergonlogic.org/. This is just a quick prototype, but it should help with the problem. It can be repeated in both the "Discussion" and "Case Tracker" sections, and potentially turned-off by those who've internalized the guidelines.

I hope a full release will result in lots of new users. I believe helping to channel their engagement in the community to be more productive should be part of our release strategy.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

I'll also add a page for Aegir here: http://drupal.org/node/417192

anarcat’s picture

anarcat CreditAttribution: anarcat commented

As you predicted, I think that "No! That'll just encourage more bug reports and support requests to the community site instead of the d.o issue queues where they belong!" ;)

That's because I actually think the situation is different. With the docs/ files, we're *moving* them to the handbook, we're not duplicating efforts, we're opening them to a broader community and allowing everyone to participate. That's a huge plus. Note how the scripts and code will stay on the git repositories, however, and will *not* be duplicated to the community site. (Although i don't think we should *censor* initiatives there..)

To make the parallel, if we actually *allow* people to report issues in a case tracker, then we have two issue queues. Actually, worse than that, we have 5 - one (or more!) on the community site and 4 here. I think that's a bad idea because we'll have to manage duplicates between the two systems and it's going to be hard to prioritize all of this. I, for example, would probably not look at the casetracker for release critical issues.

Furthermore, I think that the two examples you gave for the need to have such a space can be accommodated otherwise. Documentation maintenance can be done in-line: it's a wiki, so people can just edit the pages straight up, or add comments to it, just like in the drupal.org handbook. For the mollom example, I believe we need a special "announcement" content type and block that will be distinct from the general discussion type and that will allow for feedback for meta-announcements about the site, releases, branching strategies and so on.

(In fact, why can't we have multiple forums in there? Or is that separate groups in the OA?)

I love the "Looking for help?" block on your site, and I love how it redirects to the drupal.org queues too. :) We could have a similar block to look into the issue queue and a separate one to look in the forums which are, in my mind two distinct things that should be distinct.

Finally, why are we talking about this here? Maybe we should create a seperate (release critical) issue for the community site organisation or have a discussion item about it... ;)

Let's keep this thread for coordination.

And I'm all for adding us to #417192.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Regarding branching - I wanted to talk about this during the scrum and well, I missed the scrum. :)

I am thinking more and more we should head towards 1.0. Aegir is mature enough - we've done releases over releases. We know that multi-server kind of sucks right now, but that's the state of affairs as it is and nothing short of a rewrite is going to fix those issues, i believe, especially the performance issues (e.g. #1077022: optimize site cloning) or spoke model problems (e.g. #1079274: Sites data get lost on migrate or clone / dont "spoke" the site, #1079330: Allow sites to imported from remote servers).

Let's do what we can with 1.0: release it, support it as it is (somehow broken) and start working on a new design for a 2.0 branch that is going to support multi-server better.

How does that sound for everybody?

I am thinking of writing a post on the community site detailing a potential new multi-server design for 2.0...

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Title: 0.4-rc2 release coordination » 0.4-rc2 (1.0-rc2?) release coordination

renaming the issue to match what may really happen. oh and also, the docs updates are going along pretty well, we're only missing the upgrade part and some of the automated install/upgrade chunks.

i think we should let rc2 be a test case for that documentation.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I like the idea with 1.0-rc2. That big jump was planned for D7 upgrade initially, but I don't think we should hurry with D7 (especially with slow 7.0). We have now some more important stuff to fix/improve anyway, so let's go with 1.0-rc2.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

Yes, onward to 1.0! As much as I like the 0.x convention, I suspect it's discouraging adoption.

As for the previous (off-topic) discussions about the community site, I'm convinced by Anarcat's arguments. So I've posted: #1080112: Create "community site" component in hostmaster d.o issue queue.

For reference, I've also posted #1080118: Add a page on Aegir to the d.o Administration Guide, and #1080126: Add a block to the community site to direct people to d.o issue queues. I don't they're necessarily release critical for the upcoming RC, but I think they're important for a full 1.0 release. Either way, I'll try to get them done between today and tomorrow.

lloydpearsoniv’s picture

lloydpearsoniv CreditAttribution: lloydpearsoniv commented

Yes, onward to 1.0! As much as I like the 0.x convention, I suspect it's discouraging adoption.

I know for a fact that its discouraging adoption, people have told me in the drupal irc that they were scared to try it because of the version number.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Active » Needs work

We're in the process of finishing the release. What's left is:

1. review "needs review" issues
2. write the release notes and follow the rest of the release process: http://community.aegirproject.org/node/32

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

We need to ensure the Install docs reflect URLs to drupalcode.org to fetch the install.sh.txt etc. I can't fathom the drupalcode.org paths to tag-specific versions of files yet, other than HEAD.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The installation documentation will need to point to the install.sh.txt here:

http://drupalcode.org/project/provision.git/blob_plain/refs/tags/6.x-1.0...

This seems to be the format of tag-specific paths to files on drupalcode.org.

This presumably also affects our release.sh, if we still use it(?)

Speaking of which: the current tag for rc2, has an install.sh.txt that seems rc1-era (AEGIR_VERSION="0.4.-rc1")

Looks like we'll need to reroll that tag.. I have no idea how, so I'm afraid I'm going to leave this for anarcat (congrats Antoine, you are now our new bus factor! :) )

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Now that we are back on drupal.org, maybe it is time to make the new release 'recommended' on drupal.org, meaning we can go back to 'drush dl provision' in the install.sh script without any funny business.

What do you think? Or will we shoot ourselves in the foot there by assuming version there like we used to once upon a time.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The aegir.make, in the 6.x-1.0-rc2 tag, if i'm not mistaken, should also fetch hostmaster from a [tag] = 6.x-1.0-rc2 as opposed to the 6.x-1.x branch.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

I thought I fixed this - I ran the release script and retagged everything. Seems like we need to redo this.

And yes I agree that we should work with recommended releases from here on.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs work » Fixed

I released 1.0-rc2, with only one lingering screw-up on my behalf: I forgot about upgrade.sh.txt and that AEGIR_VERSION variable was pointing to 0.4-rc1.

Rather than be forced to roll out 1.0-rc3, I just made the fix to upgrade.sh.txt in 6.x-1.x branch and changed the docs to point to that version of the script for the moment.

I was in two minds about it but I didn't really want to roll out another rc just because of one variable in a script that only some people use anyway (and they should check the variables at the top of the script anyway, or the script shows them when prompted to confirm to proceed).

I also couldn't find a way to mark 6.x-1.0-rc2 of Provision as the 'recommended' release on the project page. (Edit: Figured it out. Next release, let's make the install.sh script just 'drush dl provision' as a result, and ensure we change the recommended release to the new one after we roll it. I've missed these good old catch 22's ! :) )

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Fixed » Needs work

the rc2 release wasn't done right on hostmaster. i'm trying to do so now and am getting this:

The drupal-org.make file for project Hostmaster (Aegir) failed verification for Git tag 6.x-1.0-rc2.

http://drupal.org/node/642116 -- to learn more about correcting these errors.

Unable to parse file [error]
An error occurred at function : drush_drush_make_d_o_verify_makefile [error]

Once these errors are fixed, commit the changes to your drupal-org.make, move the release tag for your project (check the Git manual to learn how to move tags if necessary), and submit the release node again.

I think this is because we don't have a drupal-org.make ... maybe we need to create that and should start using that tarball instead?

I guess someone needs to read up on http://drupal.org/node/642116

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I didn't think the drupal.org.make was mandatory (thought it was only for packaged distributions).

And crap, sorry, I just realized I never did a release node for hostmaster :( I think the fact that it Just Worked since the aegir.make fetches from git, made me forget about it :/

anarcat’s picture

anarcat CreditAttribution: anarcat commented

This seems to be related to #751242: Install profiles cannot create releases with a non drupal-org makefile.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

So, from what I can tell, we're not actually releasing profiles on d.o at this point, but rather distributions. While there appears to be a patch in #751242: Install profiles cannot create releases with a non drupal-org makefile to fix this, it won't help for a 1.0-rc2 release.

Anyway, here's the result of running our makefile through the d.o conversion utility:

; Logged conversion messages follow. The final converted .make file follows these messages.
; [ok]: 	 Setting version for project 'admin_menu' to '1.6'
; [ok]: 	 Setting version for project 'openidadmin' to '1.2'
; [ok]: 	 Setting version for project 'install_profile_api' to '2.1'
; [ok]: 	 Setting version for project 'jquery_ui' to '1.3'
; [ok]: 	 Setting version for project 'modalframe' to '1.6'
; [warning]: 	 The 'api' make file attribute is not allowed, removing.
; [warning]: 	 The 'libraries' make file attribute is not allowed, removing.
core = 6.20
projects[admin_menu] = 1.6
projects[openidadmin] = 1.2
projects[install_profile_api] = 2.1
projects[jquery_ui] = 1.3
projects[modalframe] = 1.6

Note that I had to change the "core = 6.x" in hostmaster.make to "core=6.20" for this to work. As expected it choked on the jquery.ui library.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

It appears that the packaging script generates 6 downloads for each .profile release (e.g. http://drupal.org/node/1048898), a .tar.gz and a .zip for each of:

1) the profile packaged with core and contrib modules;
2) the profile packaged with just contrib modules;
3) just the profile.

By default, it appears that the recommended download links point to 1). It seems to me that this will set the expectation that you'll have something useful by downloading the recommended release, whereas in fact, it isn't involved in an aegir install at all. As long as we can change the download link to 3), I think we'll be in okay shape, but we may want to rewrite the description of the hostmaster project to better explain this.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

According to the docs, 1 and 2 are not generated if there's no drupal-org.make file. That is what fails right now. Maybe we should just not bother with that makefile...

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

Wait, I'm confused... Not bother with which makefile? drupal-org.make or hostmaster.make? I'm guessing the latter.

Okay, so then, rather than relying on Drush Make's ability to recursively run makefiles, we just post the contents of hostmaster.make into provision/aegir.make?

anarcat’s picture

anarcat CreditAttribution: anarcat commented

the former (drupal-org.make). ie. maybe we shouldn't bother making a release node for hostmaster as things work as is right now anyways, wait for the fix from drupal.org and make the next release without the drupal-org.make file, ie. release only the profile.

note that from what i understand, drupal.org is supposed to be able to release non drupal.org files like jquery - not sure how that works...

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

In that case, is there anything left to do for rc2?

I see that Drush 4.3 is out, so I guess we should start planning for rc3?

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Needs work » Fixed

yeah, we should start looking at rc3.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.