By dries on
Get your text editors started: the next Drupal code freeze will be September 1st. This means all new features for the next Drupal release need to make it into the development version ("CVS HEAD") no later than August 31st. That is only 3 months from now! As of September 1st, we will start preparing for the next major release by focusing on performance, usability and stability. At that point, mainly bug fixes will be allowed.
Comments
Good news, I really hope
Good news, I really hope that a better release cycle can be worked out this time! The months of delay on 4.7 was a really big problem for various web projects I worked on. It will be interesting to see what cool stuff we get in 4.8 :)
4.7 could have been there
4.7 could have been there earlier if your various web projects had allocated some ressources to test and review patches...
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Ouch :) OK, so we did use a
Ouch :)
OK, so we did use a CVS checkout on one project and contributed back to some extent. I've tried to post bug reports, feedback on issues and even patches where possible.
But then again I don't have the time to do it extensively. Hey, you're largely a volunteer project, cool, I respect that and am in no way demanding anything. But just as horrendously complicated projects like Ubuntu, GNOME and KDE can have fairly reliable release schedules, it would be really great if Drupal could do the same, without introducing great big API changes at the last minute delaying things by months...
Indeed
There has been a lot of testing and patching going on.
The upload and file management tests, esp the mime bugs and more have been almost exclusively been tested on remixcommons.org (where telex4 is the founder and maintainer of). Telex provided a big installation, with live data and live users as testbed for some of our newest features. Quite some early bugs were found and fixed because of his hard work!
So hereby my apologies for Gerhards shot at you, Telex4, because *I* know the amount of testing and reviewing you did! He obviously did not know about this. Wchich should be a reason NOT to speak up like that (hint).
---
Professional | Personal
| Sympal: Development and Hosting
Just make sure to file your
Just make sure to file your bugs under your own name, so we can know who helps finding them.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
irrelevant
Um, surely that's immaterial?
As far as I can see, the most important things are that bugs are identified, confirmed, and ultimately patches are supplied and commited for fixing them.
Exactly who supplies the cat to kill the spider, that was swallowed to kill the fly, oh my, oh my is completely irrelevant. They can elect to remain anonymous as far as I care - fixing bugs is the goal, not ego massaging or scoring geek points.
An identified bug is an identified bug, period. The submitters user name does not give it added credence IMO. If it does, we're heading for an oligarchy...
--
/marky
earning respect is important
marky, i think you're (mostly) right about this. the important thing is finding and fixing bugs, not who found them or who fixed them. certainly drupal would be in trouble if the development community cared more about who reported a certain bug than the objective severity of the bug, but i don't think that's the case.
however, re-reading the trail of comments that led to yours, it started from telex4 saying "4.7.0 taking so long sure made my life difficult", to which killes replied "it wouldn't have taken so long if we got more help finding and fixing bugs". killes was (imho, rightfully) reacting to what seemed like a "you guys are taking too long doing free work for me" kind of comment, not knowing that the person was in fact a helpful contributor to getting 4.7.0 out. of course, ber is also right that if killes didn't know, he probably shouldn't have assumed the worst before writing his comment. ;) but, if telex4 was a "stealth" contributor towards the 4.7.0 release, it's also a little bit hard to fault killes for reacting the way he did. i've only been around a few months and i've already seen a *lot* of the sorts of comments killes seems to be reacting to. i can only imagine if i'd been as prolific and long-term a contributor to drupal as killes, how little patience i'd have for such comments.
while "geek points" (or whatever you want to call them) aren't the goal of drupal, they earn you a certain amount of credibility when you make requests on other people's time. if you're seen as a contributor (whether in the form of submitting patches, filing useful bug reports, reviewing/testing other people's patches, answering questions in the forums, documentation, translations, whatever), then people take you more seriously when you ask for something in return. if you just show up and condemn how long it takes other people to do free work for you, or make demands on their time, you're going to get ignored (or worse *grin*). i don't think telex4 was making any such condemnation or demand. however, i think killes was right to point out that people who contribute and use a consistent identifier are more likely to be considered a useful contributor, and therefore, earn some respect and trust from other contributors. such a system of trust and respect based on work done seems like a completely reasonable way to organize a community, and doesn't at all strike me as the beginnings of an oligarchy. this sort of trust and respect must be earned, and there seems to be no better way to earn it than doing some work.
___________________
3281d Consulting
One other thing...
Ahoy,
All true, though I think you miss one thing: no matter who the person is (excepting perhaps known idiots), you should at least pay a little attention to an argument they're putting forward :-)
Even if I was somebody using Drupal and providing very little feedback during the testing period, the fact remains that Drupal needs to take such a person's needs seriously if it wants to be credible. The 4.7 delay was really damaging not only for projects waiting on it but also for Drupal's credibility. Companies and organisations will come to depend upon Drupal, and they don't want to have their plans screwed up by an unreliable release schedule. Lots of other big projects can manage it, so Drupal should be able to.
So whilst I am extremely grateful to all the hackers who volunteer their time and/or share their paid work with the community, and whilst I personally have tried to participate in the process, it would be *really* nice if Drupal could come up with a clear and reliable release schedule with associated processes and roles to ensure it runs smoothly :-)
Not really
4.7's delay didn't damage it's credibility with me. Please don't assume that your needs are everyone's needs. The argument doesn't hold water nor everyone's interest. Oddly enough, neither will my opinion.
There are significant advantages to using Open Source products and there are some risks as well. That means that a high level of awareness of a projects status and participation in it to help it succeed is necessary if you are going to to tie your profit to somebodies else's unpaid work. Paticularly if you want to use spiffy features found in the cutting edge not released version instead of the whole reason it's there current stable release.
In the meantime, please understand that I will do what I do on my schedule. :)
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Not necessarily
I didn't :)
This isn't an issue in many other free software projects because they lay out feature roadmaps, they try to communicate a clear vision of where the project is going, and they fix and keep to release schedules. KDE, for example, even guarantees binary compatability in the libraries across an entire major release cycle (2.x, 3.x, etc.) for third-party developers. Just because you're a community project doesn't mean you can use that fact as an excuse for poor project management...
sigh
well what an interesting point of view. This last cycle was the first release that was longer than expected. There are a lot of reasons for that. One of them was a phenominal lack of resources contributing to this project in terms of bug fixes and QA testing because of the incredible changes wrought by a few of the core changes/contibutions this last rev. It had a freeze date. It was last year.
Of course, if you choose to NOT use the stable branch that is feature frozen and stable for that very reason strongly to be avoided, that's a risk you choose to take now isn;t it?
Of course we're not KDE. The fact that KDE garuntees this binary compatibility means more kruft. IIRC there has also been whining about KDE slipping release schedules in the past hasn't there? In reality I could care less about KDE though.
As I said originally, the delayed release didn't hurt Drupal in my opinion. It seems to have really done so in your opinion. You have three options. One, garuntee hours at qa and bug fix for each release cycle. two, NOT use the development releases in your sale pitch BECUASE they are not meant for it. The third option isn't really realavant.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
content not presentation
no matter who the person is (excepting perhaps known idiots), you should at least pay a little attention to an argument they're putting forward :-)
definitely. i don't think i said anything contrary to that, and i certainly agree. even really annoying people sometimes make valid points, and we'd be fools to ignore something useful they happened to say, just because they were so annoying. ;) [that's definitely *not* directed at anyone in this thread, of course...]. an argument like "lots of important sites are getting screwed by this delay and it's tarnishing drupal's reputation" (even if made poorly) is worth hearing (even if we don't all think it's true). that said, there's absolutely no reason whatsoever to pay attention to an argument like "i'm relying on your free work and you're taking too long for my tastes". ;) [repeat: NOT directed to people in this thread, please use your imagination, and don't think i'm talking about you. thanks!]. i think the core developers were fully aware of the impact the 4.7.0 delay was having, and they don't need to read between the lines of annoying demands for free labor to glean the potential value from those comments. ;)
that said, i think the entire drupal community (users, developers, contributors, etc) could benefit from focusing more on content and less on presentation in these sorts of discussions. between language barriers, cultural differences, personality differences, etc, i think a lot of people take things way too seriously, too personally, and get too wrapped up in how an argument is presented, losing site of what's actually being said. i know i've been on the receiving end of more than one of killes's imfamous emails, but he was never personally insulting me or attacking my character. he was just being blunt, and ruthless in his efforts to get 4.7.0 out. ;) so, i just got over the initial "wow, what a jerk" reaction, and realized he was right, and moved on with my life. if i was too focused on the presentation and lost sight of the content of the message, i would have missed the important point he made. the flip side is also true -- if active contributors completely ignore valid content that's wrapped in bad packaging, that's also a problem...
Even if I was somebody using Drupal and providing very little feedback during the testing period, the fact remains that Drupal needs to take such a person's needs seriously if it wants to be credible
here i disagree. if drupal wants to be credible, it must provide a working, secure system that does what people need (which it does). we don't necessarily have to take every request seriously to be credible. at this point, there are far more people making requests than there are people willing/able to fix bugs, add features, and keep the documentation updated. so, we prioritize as we each see fit. chasing after every last request (especially ones made by people who aren't seen as contributing to the project), is often less important than fixing bugs we already know about, adding features we desperately want, improving usability, etc. i don't think the metric for "credibility" must be "responsiveness to every last support request". responsive support is 1 element in a project's overall credibility (and honestly, drupal is amazingly responsive to support requests, given the resources available), but i don't think it's the most important element, and definitely not the only element.
___________________
3281d Consulting
On credibility
I was referring to the need for a reliable release schedule, not the quality of responses to support requests... sorry for my lack of clarity :)
For organisations running Drupal a reliable release schedule is really useful. It means, for example, that you can plan module development, site maintenance and the like around the schedule and not find your plans ruined when it slips by months with no end in sight (as happened with 4.7). I can just imagine a poor developer having to tell his superior: "well we were ready to roll out this module on Drupal 4.7 at the end of the month, but now they've reworked the form API without warning and pushed the release back with no firm dates. We could run a CVS checkout?" I've had this within KDE, which was embarrassing but at least I'm a volunteer.
I know of several organisations that passed Drupal by because there was no release schedule and no clear vision of where it is going, just an opaque development community with a hive of activity. It looks like 4.8 may improve on both already, which is nice!
It's not that Drupal has no credibility, or that the developers are lazy, or that the product is hopeless. It's just that I think Drupal would gain a lot of credibility and become a much more attractive proposition for many with a reliable release schedule.
Right, enough said about this... :)
drupal roadmap
sounds like you belong in http://groups.drupal.org/unofficial-drupal-roadmap. ;) ber already mentioned this in a different thread of comments you might not have seen. his post was cryptic enough that you probably didn't notice the "..." was really a link to a blog post about this topic. ;) now you know.
the open source software we develop at my day job (a university research project with a bunch of funding, 20+ full time staff, etc) has a "roadmap". once a year, we put on a week-long conference about the project. users from all over the world come. one of the highlights is the "roapmap to future releases" talk. at this point, everyone on the staff (including, the faculty PI for the project) now refers to this as "the talk of lies". ;) having a roadmap we can't keep (because of shifting priorities from the people giving us the grant money, turn-over in the staff, things taking longer than we hoped, support emergencies from high-priority users turning into major time sinks, whatever) probably does more harm to our credibility as a project than not having one at all. of course, we have ideas about where things should go in the future, and we could definitely give accurate talks about our future design goals, etc. but, after over 10 years of working there, any attempt to attach a date to when a stable version was going to be on the web that provided one of these major new features or design changes has proven nearly impossible, no matter what we do. i don't think it's just poor planning on our part, i think it's inherently difficult to solve this problem in the real world, where things are constantly changing. that's my perspective, at least...
___________________
3281d Consulting
changes to API?
Having come to Drupal only at the tail end of the 4.7 development, I get the sense that the changes to the API (while certainly good in the long run) have tended to mean that contributed module upgrades are lagging. Do you forsee 4.7->4.8 as involving similarly significant changes to the API?
---
Work: BioRAFT
Pwolanin: generally
Pwolanin: generally speaking, we don't think about that. We care about making Drupal core as good as possible, with ill-regard to backwards compatibility (of the API, mind - we always provide converters for data changes) and then writing documentation that facilitates modules becoming that same standard by matching the API.
http://www.disobey.com/
http://www.gamegrene.com/
Developer of Drupal's GameAPI
http://www.disobey.com/
Upgrade path but no backwards compatibility
"with ill-regard to backwards compatibility (of the API, mind - we always provide converters for data changes)"
Above is a very important distinction which should be advertised a little more IMNSHO, because it will let clients know that the compatibility problem will not affect their sites as much as they fear (if they are educated enough to even consider such matters - that is).
Best
BTW: I know that 4.7 was on its way for a very long time. But the result....
:-)
Keep rocking guys
Code freeze date works as well as a roadmap - but it is fundamentally different. I like Timeboxing.
Gunnar Langemark
http://www.langemark.com
upgrade path vs backwards compatibility
Gunnar,
Could you please explain the difference between having an upgrade path vs backwards compatibility? why is it not as much a problem as people fear?
Drupal ecommerce, at http://www.drupalecommerce.com
http://www.drupalecommerce.com/troubleshooting
http://www.drupalecommerce.com/modulesexplained
http://www.drupalecommerce.com/47vs46
http://www.drupalecommerce.com/howto
The phrase "backwards
The phrase "backwards compatibility" implies that your existing data will continue to work without modification with the new codebase. It does not imply that your data can take advantage of any code enhancements.
An "upgrade path" provides a way to migrate your data into a format compatible with the new codebase, so that not only is data integrity maintained, but that data is now open to new functionalities introduced by the updated codebase.
In a general sense, providing "backwards compatibility" reduces the opportunity for enhancements in the functionality of the program, because the program must always function at the lowest common denominator. By providing an "upgrade path" for your data, your data will always be in a position to take advantage of any advancements in the functionality of the program.
For example, if Drupal had always worked on a 2 digit year format (06 for 2006), "backwards compatibility" would imply that all date calculations expected your data to have only 2 digits. An "upgrade path" would be, for example, to convert your stored data into a 4 digit year format. Whilst this would have a minimal effect on your actual data, it would allow Drupal to provide more accurate date calculations.
In my experience, Drupal eschews "backwards compatibility" as a philosophy, and it's exactly this philosophy that allows Drupal to progress. As long as a clear "upgrade path" is provided there is no risk to your data.
--
/marky
sounds like a...
...
--
groets
bertb
--
groets
bert boerland
Feature requests, where and how-to...
How does one view the current feature requests and/or get a request on the list? I tried searching the site and looking in the handbook ... perhaps I just over looked it.
Thanks.
Use the issues tracker (link
Use the issues tracker (link on the right, under your name). Specificly, set the category to Feature Requests when posting or searching. If you've got some large-scale proposal that you're writing up, you might post a forum thread first, for additional discussion.
issue: feature request
I think the right route is to create an issue and label it as a "feature request". At least, that's what I did ;-)
For something major, look at: http://drupal.org/node/39407
---
Work: BioRAFT
Thanks!
Thanks for the links guys... fortunately the couple of things I have in mind should be small things. I think.
Sept. 1 = 4.7.1 or 4.8?
Pardon my ignorance, but I have noticed LOTS of bug fixes entering CVS since 4.7.0 came out. Does this mean there will be no official release for a subversion until 9/1, or is this just the freeze date for 4.8 functionality and 4.7.1 is right around the corner? If the latter, when?
Thanks, John
this is about 4.8.0, but not a release date, a code freeze date
a) 4.7.1 will probably be out any day now. other 4.7.x releases will happen as needed. anything that's going into 4.7.1 and beyond will happen on the DRUPAL-4-7 branch of core, not in the CVS HEAD.
b) this post is about a code freeze for 4.8.0. that's not the same as a release date. ;) that's the day that the doors will slam shut on any new features being committed to the CVS repository, and when we start the (sometimes long) process of only testing, hardening, translating, documenting, and preparing the final release. during this period, there will also be a flurry of activity to update contrib modules to the (then finalized) 4.8 drupal core's API. it could be weeks or months between the code freeze and the official 4.8.0 release. hopefully, it'll be closer to weeks this time. ;)
hope that helps,
-derek
___________________
3281d Consulting
Good starategy
However, a clearer Drupal-forge would be a plus i think...
Jan
----
Support Drupal! - Drupal at Free Scripts Forum
The Linux Boy - Free Scripts and Linux Guides
define forge?
what do you mean with this?
--
groets
bertb
--
groets
bert boerland
Preoaring for the next release
Well, September 1st is just over 3 weeks away now, so a couple of questions:
And I know it's as long as a piece of string (would that be in centimeters or inches?), but going on past form, how long is the process from the code freeze to production release likely to be?
_
You do realize this thread is over 3 years old right?
In anycase, see http://drupal.org/update/modules.
Oops.Though it would help if ...
Oops.
Though it would help if all the theme authors out there didn't insist on making the Submitted Date hard to read via the use of a light coloured font.
Sorry, getting old; my eyesight isn't what it used to be :-(