×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Drupal 8 Development Begins — 15 Bugs At a Time

timothy posted more than 3 years ago | from the just-don't-rename-them-all-features dept.

Programming 88

darthcamaro writes "It took nearly 3 years for the open source Drupal 7 content management system to hit general availability. The plan for pushing out Drupal 8 is to be faster. How are they going to do that? '"At no point in time will there be more than 15 critical bugs," Dries Buytaert, founder of Drupal said. "I will not pull in a big change if we know there are known bugs. This gives us the ability to do timely releases because we know at most the release is only 15 critical bugs away from being ready."'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

88 comments

Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35448734)

Good luck getting it down to 15...

Re:Blind leading the blind (1)

tomhudson (43916) | more than 3 years ago | (#35449146)

Good luck getting it down to 15...

That's easy.

1. select count(*) from bugstore where bug_level='critical';
2. 2914 rows selected
3. update bugstore set bug_level=non_critical where bug_level='critical' limit 2900;
4. "select count(*) from bugstore where bug_level='critical';
5. 14 rows selected

Okay, I'm joking, but you get the idea. It's like the lawyer who said he didn't care if the customer negotiated his hourly rate down, as long as HE controlled the clock.

Re:Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35449198)

And this is why there is no Linux desktop. Optimize that shit.

select count(1)...

Re:Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35449858)

In MySQL at least, and probably others, that does *exactly* the same thing.

Re:Blind leading the blind (1)

sdiz (224607) | more than 3 years ago | (#35449948)

COUNT(*) count non null.
COUNT(1) count all.

In MySQL and all ANSI compatible database.

Re:Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35450150)

If you said COUNT(col) instead of COUNT(*), sure. However, not only is COUNT(*) the same as COUNT(0) (which does the same thing as COUNT(1)), but MySQL actually turns COUNT(*) into COUNT(0) behind the scenes.

Re:Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35450180)

COUNT(*) includes null values. COUNT(1) counts all rows where 1=1, which would include null rows. On a modern RDMBS, they're synonymous.

"COUNT(*) is somewhat different in that it returns a count of the number of rows retrieved, whether or not they contain NULL values. " See MySQL 5.5 Reference [mysql.com]. Or Microsoft SQL Server [microsoft.com] saying "COUNT(*) returns the number of rows in a specified table without getting rid of duplicates. It counts each row separately. This includes rows that contain null values.". Asktom remarks, [oracle.com] for Oracle, (when asked what the difference is) "nothing, they are the same, incur the same amount of work -- do the same thing, take the same amount of resources."

(Apparently in Oracle 7 and below, COUNT(1) had performance advantages over COUNT(*). I have no idea why.)

(I prefer COUNT(*) because it makes it especially clear I'm really not caring what the value is.)

I don't know exactly what the ANSI spec says, but I assure you that MySQL, Oracle and MSSQL all treat them the same.

Re:Blind leading the blind (0)

Anonymous Coward | more than 3 years ago | (#35450680)

A decent SQL server should optimize count(*) to be as efficient as possible.

Re:Blind leading the blind (1)

larpon (974081) | more than 3 years ago | (#35451712)

1. select count(*) from bugstore where bug_level='critical';

That's soooo Drupal 6 in Drupal 7 we do awesomo stuff like:
db_select('bugstore', 'b')->fields('b')->condition('bug_level', 'critical')->execute();

that must have been the system that took them the 2,5 years from D6 to D7 - wrapping various home rolled PHP functions to SQL statements.

Drupal hungry. News at 11. Drupal loves papa. (-1, Offtopic)

unity100 (970058) | more than 3 years ago | (#35448740)

This is the 5th drupal psuedo-story in the duration of a month ?

REALLY ?

Mod Parent Up (0)

Anonymous Coward | more than 3 years ago | (#35448964)

If I didn't see another Drupal story for the rest of the year, that would make me very happy.

Re:Drupal hungry. News at 11. Drupal loves papa. (1)

inpher (1788434) | more than 3 years ago | (#35448966)

Don't worry. We will soon resume the normal Apple & Google schedule. Can't have enough of those though!

Re:Drupal hungry. News at 11. Drupal loves papa. (5, Funny)

Anonymous Coward | more than 3 years ago | (#35449066)

This is the 5th drupal psuedo-story in the duration of a month ?
REALLY ?

And on EVERY ONE OF THEM, unity100 whines about it and slips in more links to his pet framework that nobody uses.

Re:Drupal hungry. News at 11. Drupal loves papa. (0)

unity100 (970058) | more than 3 years ago | (#35451334)

actually, if you are treating the small codebase i wrote as a 'framework', it shows the degree of drupal foolery.

what i coded is just an easy codebase. some of you fools are the ones dubbing it 'framework'. but hey, thanks.

Re:Drupal hungry. News at 11. Drupal loves papa. (2)

icebraining (1313345) | more than 3 years ago | (#35451682)

The definition of framework has nothing to do with the size or difficulty of the codebase. From what I can tell from the project's website, it fits the definition.

Drupal, on the other hand, is a CMS which includes a framework (for the modules/plugins).

Re:Drupal hungry. News at 11. Drupal loves papa. (0)

Anonymous Coward | more than 3 years ago | (#35449086)

And this is the fifth time you whined about it.

Shaddup already and move on with your life.

Re:Drupal hungry. News at 11. Drupal loves papa. (0)

Anonymous Coward | more than 3 years ago | (#35449462)

And yet your framework is still irrelevant.

Yeah seriously, WTF??? (5, Informative)

cultiv8 (1660093) | more than 3 years ago | (#35449594)

Look at who started using Drupal in the last year or two: The Economist [economist.com], The Grammys [grammy.com], Fast Company [fastcompany.com], The Examiner [examiner.com], House.gov (and all ~535 house websites) recently moved to Drupal [oreilly.com], Energy.gov [energy.gov], WhiteHouse.gov [whitehouse.gov], and here's a list of some 120 national governments [drupal.org] using Drupal.

But hey, Drupal only has 2% market share [builtwith.com] of all sites on the web, is being adopted by government and corporate organizations at a maddening pace, and just had their first major release in 3 years. There's no reason why this Drupal shit should be discussed on Slashdot.

Re:Yeah seriously, WTF??? (3, Funny)

Curunir_wolf (588405) | more than 3 years ago | (#35450156)

But hey, Drupal only has 2% market share [builtwith.com] of all sites on the web...

And yet has almost 22% of the CMS market share (from the link you provided). It's second only to [*cough* ahem! *cough*] WordPress.

Maybe there should be more WordPress [*ack* *ack*] stories?

Re:Yeah seriously, WTF??? (1)

Adayse (1983650) | more than 3 years ago | (#35450686)

Maybe there should be more WordPress [*ack* *ack*] stories?

So there are a lot more Drupal advocates on /. why? Drupal is harder than than WP so when I don't feel up to battling with my Drupal module code I come here. I might come here after just installing a few module upgrades for a rest and to drum up some new business. Drupal is more work for the same result so it gets more attention.

Re:Yeah seriously, WTF??? (1)

Rhaban (987410) | more than 3 years ago | (#35451050)

So there are a lot more Drupal advocates on /. why? Drupal is harder than than WP so when I don't feel up to battling with my Drupal module code I come here. I might come here after just installing a few module upgrades for a rest and to drum up some new business. Drupal is more work for the same result so it gets more attention.

Wordpress is easier because it is not a "real" CMS, just a glorified blog engine with a few CMS features. Sure, if your projet is within what wordpress can do, there's no reason to use drupal instead.

But a lot of sites need features beyond what wordpress can offer, and that's where you want drupal or another cms.

And if your site need a different structure from that of a cms, the next step is frameworks.

Re:Yeah seriously, WTF??? (1)

lwsimon (724555) | more than 3 years ago | (#35453306)

This is truth. I started in web dev as a coder, and went to CMS Made Simple, then Django, and loved it. After getting the Internet Marketing bug, I realized that there is no need to code everything from scratch - my motto is "Get Shit Done, Then Code For Fun"

I do 95% of my work in Wordpress, because there is just no need for more in a small site. If I need more, I go custom in Django or CodeIgniter. I'm looking at Drupal and Joomla now as a stopgap between WP and 100% customer work - so far, I think Joomla is going to win.

Re:Yeah seriously, WTF??? (1)

Rhaban (987410) | more than 3 years ago | (#35453394)

I'm looking at Drupal and Joomla now as a stopgap between WP and 100% customer work - so far, I think Joomla is going to win.

This would be a big mistake.

Joomla is tempting at first because it's easy to begin with, but it's going to break as soon as you try to do real work with it.

Re:Yeah seriously, WTF??? (1)

lwsimon (724555) | more than 3 years ago | (#35453926)

Well... I did just install Drupal and am learning to play with it now.

Frustrating, but of course it would be - it's new to me. I installed a Gravatar plugin, and only want them on posts - no option to turn them off on the ID string for articles. I figure I could SSH in and yank that code section, but there has to be a legit way to do things like this. After all, it is touted as "You don't have to know how to code..."

Post a Question to Drupal.org Forum (0)

Anonymous Coward | more than 3 years ago | (#35455412)

>a legit way to do things like this

If you post your question(s) to Drupal.org forum, you'll get a good answer, usually very soon.

Good and pleasant community support is a hallmark of the Drupal community.

Re:Yeah seriously, WTF??? (1)

drinkypoo (153816) | more than 3 years ago | (#35451714)

So there are a lot more Drupal advocates on /. why? Drupal is harder than than WP

I see this claim often (usually with only one "than", however) with nothing to back it up. All I know about WP vs. Drupal is that I followed the install instructions for both back in the Drupal 4 days, and Drupal installed and WP didn't. To me that says WP is harder than Drupal. Can you provide some sort of citation that suggests that Drupal is "harder" than WP, along with some sort of indication of what that actually means? They're not minerals or even physical objects, so clearly one is not "harder" than the other.

Re:Drupal hungry. News at 11. Drupal loves papa. (1)

nate nice (672391) | more than 3 years ago | (#35450144)

Yeah why would they want to cover a framework that is widely used, insanely great and of interest to a lot of people?

Re:Drupal hungry. News at 11. Drupal loves papa. (0)

Anonymous Coward | more than 3 years ago | (#35450976)

phpBB?
Wordpress?

Both widely used, and I'm sure you can find plenty of people (using google) who think that they're insanely great (and also believe that they're frameworks).
For some reason, /. doesn't cover them as often though.

Re:Drupal hungry. News at 11. Drupal loves papa. (2)

kuzb (724081) | more than 3 years ago | (#35454604)

That framework you're constantly advertising ... dear god, it's the most terrible abuse of singletons I've ever seen in my life. Please, for the love of all that is holy, learn design principles.

brilliant (1)

Anonymous Coward | more than 3 years ago | (#35448748)

why don't microsoft decide that there are only 15 critical bugs left in windows 8 and release it next week?

go faster by going slower? (3, Informative)

sparetiredesire (465731) | more than 3 years ago | (#35448942)

Two bad side effects may be:

- Less merging (which will slow progress)
- More critical bugs triaged as non-critical to avoid blocking releases.

I like the Chrome team's ideas to have multiple branches, only do merges in one direction (towards more stable branches), and making features easily removable so they can be nuked if they are not stable enough to make a release. I'm not sure of a clean way to do the easy code disabling with PHP.

http://goo.gl/G2uDn

  In general, though, more merging is better than less merging. It will be interesting to see how this pans out for Drupal.

Re:go faster by going slower? (0)

Anonymous Coward | more than 3 years ago | (#35449694)

I'm not sure of a clean way to do the easy code disabling with PHP.

I dunno, most of the PHP code I've encountered was already pretty "disabled", if you get my drift.

Re:go faster by going slower? (1)

icebraining (1313345) | more than 3 years ago | (#35451732)

If you implement the features as plugins/modules, they can easily be disabled. This isn't specific to any language, although OOP languages have some well known patterns that can be implemented easily.

Re:go faster by going slower? (1)

NightHwk1 (172799) | more than 3 years ago | (#35453892)

They would get a lot more done when they finish their transition over to Git (although they should seriously consider Github instead of whatever custom thing they're building). I've had things to contribute, mostly bugfixes for modules, but the whole community is still stuck on CVS and patch files, so it was too much of a pain to do.

So... (1)

msauve (701917) | more than 3 years ago | (#35448950)

They're calling 7.1, 8.

Re:So... (0)

Anonymous Coward | more than 3 years ago | (#35449036)

Umm no. 7.1 will be the next security-type release for 7. 8 will be the next major release of core, I believe with a focus on mobile and different screen sizes.

Re:So... (0)

Anonymous Coward | more than 3 years ago | (#35449130)

Whoosh!

Re:So... (0)

Anonymous Coward | more than 3 years ago | (#35449228)

How so?

Re:So... (1)

Anonymous Coward | more than 3 years ago | (#35449380)

Correcting an attempt at funny or sarcastic with facts = whoosh, no?

Re:So... (0)

Anonymous Coward | more than 3 years ago | (#35451322)

No. Correcting funny (and [/or]? sarcastic) post with facts == whoosh. (And the original doesn't seem to be either funny nor particularly sarcastic)

Re:So... (1)

kuzb (724081) | more than 3 years ago | (#35454546)

I was under the impression he was correcting stupid, since it wasn't actually funny.

15 bug limit (2)

pellik (193063) | more than 3 years ago | (#35448952)

Because I always know about all of my bugs and keep track of them while I'm programming. In fact I sometimes even plan them ahead of time.

Re:15 bug limit (1)

bigsexyjoe (581721) | more than 3 years ago | (#35449096)

Of course! I actually think he should go further and say at no point will the team inject the critical bugs in the first place.

Re:15 bug limit (0)

Anonymous Coward | more than 3 years ago | (#35449586)

reported bug + triage = bug.

will the pedanticism never cease?

Re:15 bug limit (1)

TheCoders (955280) | more than 3 years ago | (#35453048)

No really, we only have fifteen bugs! Trust us...

At one company I used to work at, we had a "last bug award." Every once in a while, somebody would claim to have fixed the "last bug" in a section of the software. They were treated to a round of ridicule, plus the award token (some kind of stuffed animal, if I recall), until someone else was foolish enough to make the same claim.

Awesome! (5, Informative)

/dev/trash (182850) | more than 3 years ago | (#35448990)

This was like when they said that once there were no more critical bugs 6 and then 7 would be released. Which is what happened. They moved the level down to major and voila! No more critical bugs.

Now, a few days after 7 was released, 7 criticals appeared. 2 were new. The others? Just old bugs that could be bumped up again.

Re:Awesome! (2)

hansamurai (907719) | more than 3 years ago | (#35449272)

Maybe it's all about context? They weren't critical in the fact that they were stopping the release, but they're critical now that the general release is out, features are done, and this is what needs to be worked on now.

I'm sticking with Drupal 6, modules are what makes Drupal so great and until everything is ported or there's something equivalent available... not bothering.

Re:Awesome! (2, Informative)

Anonymous Coward | more than 3 years ago | (#35449322)

I've used Drupal 7 on some simple sites and it's sweet. There's a bit more debugging going into unknown territory, but it's worth the trade-offs if you're comfortable with Drupal and know beforehand what you can/cannot do in D7 yet. Some D7 modules are still waiting for a final release, like Relations, Media module, Internationalization and Drupal Commerce, but most are usable, and they're going to be kick-ass when they reach a final release.

Yay Droopal

Re:Awesome! (1)

cinderellamanson (1850702) | more than 3 years ago | (#35449376)

I'm not current in drupaleze, but modules that are outside of core might cause critical bugs for things that are outside of Drupal's field of support - therefore not actually being critical, but still saved for the next release.

Re:Awesome! (1)

cyphercell (843398) | more than 3 years ago | (#35449480)

I wasn't a developer on Drupal, but in 5 you could setup developer, editor, writer, reader, publisher, as different users and the ACLs with basic Drupal. You can use Drupal as code to manage your own php and most likely have ported that over rather than relying on modules. I was also just noticing the other day that, that's what kernel trap is running, so it can't be that bad.

Re:Awesome! (1)

Idimmu Xul (204345) | more than 3 years ago | (#35450902)

I'm sticking with Drupal 6, modules are what makes Drupal so great and until everything is ported or there's something equivalent available... not bothering.

I've just ported a project from 7 to 6 for exactly this reason, core might be stable but loads of modules, including gmap, calendar, date are all screwed up in some way.

Re:Awesome! (1)

Mouldy (1322581) | more than 3 years ago | (#35451680)

Modules is why I think this is a bad idea. During the 3 years that Drupal 6 was the latest-and-greatest, a lot of great modules were developed for it. If 7 has a shorter amount of time as the latest-and-greatest, it follows that there will be less amazing modules for it.

If they're going to speed up the release cycle, they should maintain compatibility with older modules. Otherwise, we're just going to end up with lots of versions of vanilla drupal (which in itself, is quite bland) and not many modules that make it as powerful as Drupal 6.

Re:Awesome! (1)

wrook (134116) | more than 3 years ago | (#35449496)

The thing is that bugs are not really different than new functionality. The only real difference is expectation. With a bug, somebody (somewhere) expected the software to already work in a certain way, and it doesn't. With new functionality, there is no expectation that it already works that way.

My own personal opinion is that all work should be organised the same way. It should be ordered by priority and tackled with the top priority issue first (whether or not you already expect the software to work that way). The whole idea that you will stop adding critical new work until you have some arbitrary amount of "I thought this already worked" stuff left is kind of strange.

Similarly, there is always a lack of functionality in a piece of software. There may be an expectation that it works in a certain way, but that is not a reason in and of itself to delay a release. You release when the software does what you need it to do for that release. The expectation is mostly irrelevant. So, for instance, a user may say, "Oh, I thought that was supposed to work/not crash/etc. But it doesn't matter because I don't need it". That's totally OK. But if the user says, "I need it to do X, and it doesn't", it is irrelevant if they originally expected it to work. They still can't do what they need to do.

From a development process, bugs are useful because they point to a breakdown in process. Why is there an expectation that the software does something, when in fact it doesn't do it? But confusing this with release planning is rather stupid IMHO.

Re:Awesome! (1)

wrook (134116) | more than 3 years ago | (#35449526)

I'm bad today, replying to my own post.

Just had the typical image of a software team that doesn't actually know all of the requirements of the software until after it gets shipped off to QA/Beta test. Then a whole raft of "bugs" come back indicating what the requirements should actually be. But because they are labelled as "bugs", there is an implied expectation that the software already should work that way. The priorities are then set by the QA team rather than the design team and the release is delayed until the QA team gets the requirements it wants fulfilled.

Yes, there are better ways to do software development...

Re:Awesome! (1)

Shimmer (3036) | more than 3 years ago | (#35450168)

My old boss wanted to start a software project with a single bug called "Nothing works yet". The dev team then would, in theory, then go to work "fixing" this problem, which would lead to new "bugs" with slightly more detail in them. Rinse, repeat.

We assumed he was joking and ignored him.

Re:Awesome! (1)

silanea (1241518) | more than 3 years ago | (#35451092)

I am not so sure this is a universally bad idea. Ubuntu does something similar [launchpad.net] which, while of course being irrelevant for the software itself, sets a certain goal or mindset for the project. When writing a software for a non-profit we filed "x does not like it" (with x being the least, ahem, mentally flexible and most problematic user in the organisation) as first bug and marked it as release blocker. So in order to get the software out to the users we were forced to interact with the "worst" of them and really reflect on this person's feedback, which resulted in an application that everyone actually wanted to use.

For a big commercial product such a nontechnical bug may be unproductive, but for the right team it may actually add a motivation or direct focus at something that usually would be an afterthought at best.

Re:Awesome! (1)

turbidostato (878842) | more than 3 years ago | (#35449590)

"It should be ordered by priority and tackled with the top priority issue first (whether or not you already expect the software to work that way). The whole idea that you will stop adding critical new work until you have some arbitrary amount of "I thought this already worked" stuff left is kind of strange."

I think you have a point. This way, *any* software, no matter how complex it might be would be ready to release within hours:

Functionality #1: print "hello, world"
Functionality #2: print "hello, world"
Functionality #3: print "hello, world"

There, done. Maybe you had a different expectation about how F #1 to #3 should work, maybe even because I, the developer, told that F #1 to #3 were due to work in a different way but, hey, that makes no difference, does it?

The fact is that there *is* a difference between something not being there and something expected to be there working in a different way than expected.

"Similarly, there is always a lack of functionality in a piece of software. There may be an expectation that it works in a certain way, but that is not a reason in and of itself to delay a release"

There is exactly the same reason to delay a release because functionality X, which is a landmark for the release not being there, and then more since "working as it's said to be working" is a landmark for each and every release.

"Why is there an expectation that the software does something, when in fact it doesn't do it?"

You aren't seriously saying that, are you?

scary (3, Interesting)

nethenson (1093205) | more than 3 years ago | (#35449124)

I will not pull in a big change if we know there are known bugs.

At no point in time will there be more than 15 critical bugs

I find that differentiation between 'bugs' and 'known bugs' scary (to say the least).

Does he mean that there will be no more than 15 critical bugs (whether known or unknown)? Or, does he mean that all bugs are always known (and that when the 15 errors mark is reached, one simply has to stop writing new code to keep on that mark -since undetected bugs don't exist-?)

In any case, it is very naïve. Naïve and frightening.

Re:scary (1)

Crouty (912387) | more than 3 years ago | (#35449436)

He means "no more than 15 known bugs", of course. (How could you guess wrong twice?)

Dries' wording was unfortunate (he is Belgian ;-) ) but I can assure you he knows the difference between known, unknown and critical bugs very well.

Re:scary (0)

Anonymous Coward | more than 3 years ago | (#35449516)

huh? What the hell did you just say?

I find that differentiation between 'bugs' and 'known bugs' scary (to say the least).

What's so 'scary' about that? If you are a software writer, then it should be clear to you that bugs are hidden till found. Just because you fix all bugs reported to you does not mean that the software is bug free; it just means that you have fixed all known bugs. There could very well be bugs hidden somewhere, maybe a bug that only manifests at a certain date or time that no one has yet reached. I am not sure what is scary to you.

Does he mean that there will be no more than 15 critical bugs (whether known or unknown)?

How could he even mean that? If there are UNKNOWN bugs, then how could those bugs be added to the count if no one knows if they exist? There could very well be 100 unknown critical bugs and 0 unknown critical bugs. But if no one knows those 100 critical bugs exist, then he has to keep moving forward and find them at some later time.

Or, does he mean that all bugs are always known (and that when the 15 errors mark is reached, one simply has to stop writing new code to keep on that mark -since undetected bugs don't exist-?)

Again, he never said this. He has already made a distinction between bugs that are known and unknown and he'll only fix bugs that are known. How the hell is he supposed to fix a bug that is unknown? If he has fixed all known critical bugs, then he'll move forward with working on new features. However, that does not mean that there are no more bugs. It just means that any bugs that are left are unknown. Since they are unknown, he can't fix them so he'll just continue working on new features. When the unknown bugs become known, he'll work on them

In any case, it is very naïve. Naïve and frightening.

Seriously, please elaborate why it is naïve and frightening.

PS: I realise I could have been more courteous in my reply. But I am just confused with what you said, I mean no malice nor insult.

Re:scary (0)

Anonymous Coward | more than 3 years ago | (#35450728)

What are you talking about about? Are you intentionally trying to misunderstand everything?

How about 0 critical bugs? (0)

RocketRabbit (830691) | more than 3 years ago | (#35449148)

This is why most software sucks. The new features are more important than bug free code. I'm not sure if this Drupal guy is joking or not but I now know to avoid it for my next project.

Re:How about 0 critical bugs? (1)

winomonkey (983062) | more than 3 years ago | (#35449326)

Reading comprehension fail. Dries is saying that they will not develop new features if they have 15 critical bugs - they will keep the count beneath the stated number. They are doing this so that "at most the release is only 15 critical bugs away from being ready" ... the basic premise of this statement is that the release will not be ready until the 15 critical bugs are resolved.

The new features are more important than bug free code.

What was stated in the article is the exact inverse of the problem you are claiming. They are stating that they will stop new feature development if there are more than 15 critical bugs. Their statement is about bug-free code being more important than new features.

Re:How about 0 critical bugs? (1)

AndrewNeo (979708) | more than 3 years ago | (#35449410)

They mean at any given time, they can stop, fix the 15 bugs, and release. Not release WITH 15 bugs.

A little slack? (1)

steve317 (2013724) | more than 3 years ago | (#35449220)

Oh, come on, guys, give them a break. I watched Dries' keynote address streamed online in which he made this declaration. The point is it's a standard, a declaration of intent. He essentially expressed regret at the unexpected quagmire of the 3-year dev cycle for v7 that was caused by accepting component builds with a sum total of hundreds of *known* bugs. So, now, the aspiration and protocol is to not accept new builds of core pieces if they can find more than 15 total bugs among them. How is that any different or worse than any other policy statement. They're not saying they will cure a different genetic disorder with each new build. And I guess the assumption can be that they are prioritizing the stability level of the status quo build over new bells, whistles, or expansion. I'm as frustrated as anyone about the many challenges a developer faces getting all the parts of a f*ing Drupal site to all work at once and reliably, but version 7 leaves a lot of the chaos behind it, and the 15-bug rule for version 8 is an applaudable new policy to continue in this more modern and stable direction.

Understanding the Drupal development process (1)

Crouty (912387) | more than 3 years ago | (#35449396)

Some of the people posting sarcastic comments fail to understand the development process of Drupal. The very core of Drupal is lean - but useless. And then there are modules to add functionality like blogging features, XML-sitemap for search engines or a system that lets you create custom content types. Some of these modules that are useful for most potential users become part of Drupal. These are called "core modules", the rest "contributed modules". What Dries probably meant was to tighten the requirements for a module to go into core, i.e. a buggy module must be fixed before the release maintainer can consider it going into core.

This is just a tweak in Drupal's lifecycle model with the aim to be more agile. It means that new features will be available sooner for novice users. For Drupal pros there will be no change because they install their favorite collection of modules anyway.

Re:Understanding the Drupal development process (1)

Curunir_wolf (588405) | more than 3 years ago | (#35450198)

That's not the way I see it. I've worked with Drupal for some time, and I think the problem he's trying to solve here is to get the development community a little more focused on the boring stuff that really needs work, rather than their own little world of modules and the patches for those modules. This happens a lot - there's a critical bug that needs to be fixed, and it's blocking not just a release, but also several patches with new features that are required by various modules. That means that critical but is holding up a *lot* of work. But often it's a boring problem, or the core maintainers are so swamped with stuff they don't have time for it.

I think Dries is hoping that by rejecting more stuff when there are critical bugs to work on in the core that it will motivate more developers to divert additional time to getting those bugs fixed.

Web Dev Question (1)

oldhack (1037484) | more than 3 years ago | (#35449616)

How prevalent are Drupal, Joomla, etc. in web dev sector?

Re:Web Dev Question (0)

Anonymous Coward | more than 3 years ago | (#35449958)

Wordpress, Drupal, and Joomla are the big three OSS content management systems. Any website with numerous pages styled identically uses a CMS.

Re:Web Dev Question (2)

nate nice (672391) | more than 3 years ago | (#35450132)

Big and getting larger. Drupal is pretty awesome once you figure it out. I hated it at first and couldn't understand why it was loved by some but definitly understood why other loathed it. But then one day it all made sense and I couldn't believe the amount of power afforded the developer in making insanely cool Websites relatively fast and the few defects you're left with because a lot of the things that would cause problems are taken care of for you.

Open saice (0)

Anonymous Coward | more than 3 years ago | (#35449762)

Open sauce, only 15 critical bugs!

So if I find a critical bug (1)

Arancaytar (966377) | more than 3 years ago | (#35450024)

And there are already fifteen being worked on, all that this means is that I need to wait until one of them is fixed to report it? (No, of course not, but seriously, the thing about many regressions is that they somehow fall outside the functionality covered by unit tests, and aren't noticed in patch review.)

Though I appreciate that the development process will involve closer attention to regressions and unit test failures known at the time of the commit.

Greater success = Greater failure? (0)

Anonymous Coward | more than 3 years ago | (#35450364)

We have been using Drupal for our corporate sites since 2007 and in general, have enjoyed seeing releases 5 and 6 come out. That said, I can understand why there is concern over the release process as Drupal 7 was the most ridiculously managed release in the project's short history. The following are some of the poorer aspects of this release:
  • 3 years: Nobody thought to just "revert" the introduction of a feature and maintain the release schedule? Isn't this what project managers are around for?
  • Bloat, bloat, and more bloat: Rather than elaborate on this, I'll just list the compressed size of the last three major releases: Drupal 5 (750KB), Drupal 6 (1.06MB), Drupal 7 (2.6MB).
  • Most of the contributed modules still haven't seen a Drupal 7 release. Many of them seem to have been party to a "pledge" to time their release along with the Drupal 7 release and have reneged on it.
  • The most important module outside Drupal's core release is Views [drupal.org] which is supposedly used by at least 300000 sites. The vast majority of sites - beyond simple brochure sites - rely on Views and it has still not seen a Drupal 7 release. In other words, even with Drupal 7 being released, nobody is really using it as most developers are waiting for Views to see the light of day. Furthermore, this module, I'm told, was deemed important enough slated to be included in the core Drupal release ...
  • A few years ago, when Drupal was small and flexible and touting slogans similar to we eat our own dogfood, the primary Drupal site [drupal.org] would always run "the latest and greatest". Now, however, it's been 2 months since the release and drupal.org [drupal.org] is still running Drupal 6 [drupal.org] (and an outdated version at that). An integral community site, groups.drupal.org [drupal.org] is still running Drupal 6.16 [drupal.org] and has been pending a security update for months.

I think that I'll stop there :/ But I believe that all these issues are symptomatic of an inefficiency and backslap-happy community complacency that has crept into Drupal thanks to its recent success. The people behind Drupal seem to be busy chasing the almighty dollar and losing sight of what made the project interesting in the first place.

Good development model (0)

Anonymous Coward | more than 3 years ago | (#35450454)

Back when I was in university, I got in the habit of writing programs by building a framework, then adding only the code needed by a single block at a time, testing the block, debugging if required, then move on to the next block. I remember helping another student debug a cobol program. She had written the entire thing as more than 300 lines of code, and it didn't do what she wanted. By the time she called me over, I had handed my program in 3 days earlier, there was one day left till deadline, she was very upset and looked like she had been staring at the program for more than a few hours. I added a gob of breakpoints (print statements) to divide/conquer the thing and find where things were breaking. In about 10 minutes I had pulled out at least 6 bugs. Things started to work. About 10 minutes later, she was starting to get (incorrect) output. Another few minutes, she was pulling out her own bugs. I left her with semi-correct output (I wasn't about to debug the whole thing for her, I only wanted to get her on her way and get on my own way). You can build monolithic and then start the almighty job of fixing if you want, but its more fun to only have one thing to look at at a time. 15 bugs at any time sounds like a recipe for success.

A better way to speed it up (1)

Adayse (1983650) | more than 3 years ago | (#35450628)

If Dries were to promise that Drupal 8 will be faster and leaner than Drupal 6 and 7 then I'm sure a lot of people would pitch in to get it out the door earlier.

If there are 15 critical bugs already and somebody finds a new bug in the existing code what happens then? Do they stop accepting bug reports?

Re:A better way to speed it up (1)

silanea (1241518) | more than 3 years ago | (#35451278)

No, they will continue to accept bug reports. But they will stop accepting new features until that bug counter goes below 15 again. The idea is to prevent a massive influx of new modules and patches while running up a backlog of bugs that no-one gets around to fixing.

Re:A better way to speed it up (0)

Anonymous Coward | more than 3 years ago | (#35451314)

Why are there so many people who are so fucking dense on slashdot? Even from ignoring the SUMMARY and reading only the title, you can easily guess that a 15 bug max implies no new features or no major changes until those bugs are fixed. In what universe would it make sense to only accept 15 bug reports?

Jesus fucking christ, it's like you're all trying to find problems just to see posts with your name on them.

Re:A better way to speed it up (1)

silanea (1241518) | more than 3 years ago | (#35451584)

People do not take the time to actually read a text as one coherent unit, they just quickly scan over it and pick up a few keywords. I see a lot of that at university. Makes me cringe every time.

Re:A better way to speed it up (0)

Anonymous Coward | more than 3 years ago | (#35455570)

>I see a lot of that at university

Get used to that; I've seen it for all my 25+ years in high tech documentation, even if the docs use small words. ;*(

Krap (0)

Anonymous Coward | more than 3 years ago | (#35451974)

I've used this and word press both suck.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...