webchick.net

very helpful lioness

Drupal 7.0 Alpha 1: Coming soon to a downloads page near you!

Wed, 12/30/2009 - 00:47 -- webchick

Drupal 7 first opened for development back in February 2008. At Drupalcon Boston a month later, we brainstormed on how to tackle some of Drupal's toughest challenges: our usability was not up to par, we were burning time fixing the same bugs over and over, our database abstraction layer suffered many limitations, upgrades were a nightmare, and critical modules such as CCK not being ported were harming our adoption rates of Drupal 6. Drupal 7 has made tremendous strides since then to solve each of these problems, as well as many others. Among the improvements are a revamped UI, a testing framework, a new database abstraction layer, a browser-based upgrade system for contributed modules and themes, and CCK in core.

Now it's time to head into the final stretch: stomping down the list of critical bugs, so that we can release Drupal 7.0 out into the world! :D

To help this along, Dries and I will create the first alpha release of Drupal 7 on January 15, 2010, Drupal's ninth birthday. For developers working on Drupal 7 clean-ups, particularly around anything that is touching APIs or the UI in a fundamental way, your changes will need to be completed by then. Once the alpha is released, we will start to treat Drupal 7 as an actual stable release, which means nothing but non-API-breaking bug fixes.

The initial brainstorming at Drupalcon just a few weeks after development opened for Drupal 7 was instrumental in laying a strong foundation for the entire release, I would love to see Drupal 8 get the same opportunity. However, this means releasing Drupal 7 before Drupalcon SF (mid-April), so that our attention is not divided between getting our past efforts out into the world, and deciding what our future efforts will be.

And when does Drupal 7 come out? When the list of critical issues hits zero (currently at 340, though this will fluctuate all over the place for awhile as non-critical issues are marked such as and new critical issues are found). To spook you with a little math, if we want to see a Drupal 7.0 release by the end of March, at the current total we need to solve roughly 120 issues per month, or 30 issues per week, or 5 per day. Yipes! :)

Obviously, the more people we have helping out with fixing critical issues, the faster this number will go down. So if you haven't yet played around with Drupal 7, now's a great time to start! Pick a critical bug that looks interesting/achievable, and take the opportunity to learn a bit about the changes in Drupal 7 at the same time while you solve it. There are always folks in #drupal and #drupal-contribute on irc.freenode.net to help you, and there are a variety of bugs for all skill levels and areas of expertise.

Let's rock!

Comments

Submitted by drifter (not verified) on

So what's the process or etiquette for marking critical issues as non-critical? Are there any criteria for critical bugs? I assume many of them aren't actually critical, but demoting them may hurt feelings...

Submitted by webchick on

We have a definition of critical bug at http://drupal.org/node/45111, which for the most part says that if it's not causing Drupal to spew blood everywhere, it's not critical (ok, I might've paraphrased ;)). We do indeed have a massively inflated critical bug number at the moment, in part due to us abusing that status to mean "stuff we should fix before feature/code/UI freeze." OTOH, we also have a massively deflated number of critical bugs because actual "users" for the most part have yet to actually try Drupal 7; it's mostly been in the hands of the developers, UX team, etc. up until now, and we're all naturally blind to certain things since we tend to test the same things each time.

Removing artificial criticals would definitely be a really valuable thing to do. I would say etiquette is probably to go on IRC in either #drupal or #drupal-contribute, and discuss with one of the folks mentioned on the issue if it can indeed be downgraded.

It would be good to have some "official stand" in terms of the expected date of the string freeze. Dries' Drupalcon Paris schedule had November 15th for the end of string changes (http://buytaert.net/drupal-7-code-freeze-almost-upon-us) and then that was modified to December 1st (http://buytaert.net/drupal-7-code-freeze-status-update-and-next-steps). These dates were given for the phase *after* the API was *already* frozen, so we seem to be in a mix of the two phases still at the moment, where even API changes are allowed judging from your description.

Now your blog post indicates the end date of this mixed phase is January 15th, but does not indicate whether it is actually a new deadline for string changes as well. (Or more precisely, it says D7 will be treated as a stable release, so that implies it, but an explicit statement would be useful). Dries' figure on http://buytaert.net/drupal-7-code-freeze-almost-upon-us had extremely clear deadlines and lists of what is allowed when.

I'm asking because several people asked me and even set up translation sprints in expectation of Drupal 7 freezing its strings. I know the Hungarians set up a sprint exactly for the day of the original freeze plan (November 15th), but could not do much with core due to the still ever changing strings.

Thanks!

Is needed more up-to-date information. schedules dates, and at that means.

Starting with alpha Drupal 7 will have to upgrade him seft(core and data), without losing data? Or only in beta state?

The schedules dates can be changed, fine, but we need to know that means the 15 january 2010, and others dates.

Means?
UI freeze
String freeze
Suporting updates from Drupal 7 alpha/beta
Suporting update from Drupal 6
Performance fix
Only bugfixes

and much more...

Submitted by webchick on

Is needed more up-to-date information. schedules dates, and at that means.

Unfortunately, it's not really possible to schedule dates since we are a totally volunteer-run project. We can shoot for targets and target functionality, but at the end of the day it's going to depend on who pitches in, what they pitch in on, and when they get it done.

Our main focus now is to get more people involved, because the more folks there are finding and fixing bugs, the faster we can release. Releasing an alpha is an important part of this, because it makes Drupal 7 a lot more "real" for people.

Starting with alpha Drupal 7 will have to upgrade him seft(core and data), without losing data? Or only in beta state?

Given that we don't have a functioning upgrade path at all atm, I wouldn't count on that. :) We don't start writing HEAD -> HEAD upgrades until around release candidate time, iirc.

I would say, roughly:

- alpha: install it on your local environment, poke at it a bit, start playing around and learning some of the new changes.
- beta: start building practice sites for your own use
- rc: begin building more "real" sites, perhaps for client use, though not actually released until there is something stable.
- 7.0: start using Drupal 7 "for real". But expect there to be a few critical bugs that didn't get found during testing in the first couple point releases.

How quickly these phases come depends on how quickly people jump in to help out. The difference between alpha and beta or beta and RC is largely a gut check thing.

The schedules dates can be changed, fine, but we need to know that means the 15 january 2010, and others dates.

It means everything freeze, and we shift our focus solely to fixing critical bugs. Certain performance fixes may be allowed as critical bug fixes, but they will need to be subject to the same restrictions as a stable release.

Submitted by Bojhan Somers (not verified) on

As far as string freeze, we have changed very little over the past few weeks. There are a few more in the loop, but those are very little and should be in by January 15th. So as far as the UX-Team goes translation could be underway already - there will be perhaps 5 more required string changes.

Submitted by webchick on

Given that all strings were supposed to be finished up by 12/1, I would definitely like 1/15 to be the last time we commit any string fixes that aren't critical bugs, same as D5 and D6.

Yikes, I should probably start working on my remove all lower-case lone 'operation' strings like 'edit' and 'delete' on tables like the admin content or comments pages.

Submitted by webchick on

We tried something new this release of having sort of "phased" freezes. I still am not sure whether that was a good idea or not; I guess we'll talk about it in a big retrospective at Drupalcon SF. ;)

One thing I think we learned is if we're going to do this again, it's a much better idea to keep separate, focused freezes than jamming multiple initiatives together at once. For example, instead of having both the feature freeze and "clean-up" phase, as well as the string and UI freeze coupled, do them in phases, spread out. This is what actually ended up happening, even though it's not what we originally planned for. Oh, the joys of herding cats.. ;)

The goal with the alpha though is to finally lock down all of these various threads that are currently going on: UI fixes, string clean-up, API adjustments, etc. and focus on the one thing that'll actually get us to a 7.0: critical bug fixes. :) We'll need everyone's help.

By the way... I've been graphing D7's critical issues at http://www.drupalvqs.com , updating the numbers twice a week (usually on Tuesdays and Fridays).

Only the graph is public on that site right, now, because it's also used for editorial purposes for the upcoming book, "Drupal 7: Visual QuickStart Guide. (The site will be public when the book is done.)

The sharp drop-off occurred after the code freeze, of course, as some issues were reclassified en masse as non-critical (e.g. "won't fix").

For the string freeze, I'm with bojhan. While there are still some walls of text I'd like to fix, it should be fine with if it is not done by Jan 15, it is too late. A badly or not translated Drupal is worse than one with some ugly strings.

What about these small changes that can always occur, like changing currences from "Settings" to "Configuration" (and maybe back again :P ) or tiny new texts: how painful is this for translation teams? Cause it would be a pain to not being allowed to change this (in justified situations). Maybe the core maintainers could set a number: 20 more string changes allowed and everyone has to get a ticket at the desk...

Submitted by webchick on

It means that module developers need to update their own help text, as well as menu items, to point to the right place.

Let's focus on hammering this out once and for all before 1/15.

And the plan is to treat Drupal 7 as a stable release from the first alpha, so that means no string fixes that don't fix bugs, same as Drupal 5 & 6.

Submitted by David Rothstein (not verified) on

Seems like it would be a good idea to annouce this January 15 deadline on the front page of drupal.org, or on the development list, or somewhere else more official? I have to say I almost missed this announcement completely.

Guess I better start coding hard the next couple of weeks :)

Submitted by webchick on

I did send this out to the devel list just after I posted this entry (wanted to hit both the devel list and planet, since not everyone reads the devel list...), but I see it never made it. :( Just re-posted again and now it's there. Very sorry about that!

Submitted by webchick on

1/15th is the deadline to basically finish up changes that are already in the queue. We do not want to start more big new initiatives now; there were plenty of other opportunities early in the release cycle to do so. But that said, if you have some minor clean-up string or UI or API affecting patches still lingering out there, now's the time to get them in.