Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming Bug

Drupal 8 Development Begins — 15 Bugs At a Time 88

Posted by timothy from the just-don't-rename-them-all-features dept.
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."'"
This discussion has been archived. No new comments can be posted.

Drupal 8 Development Begins — 15 Bugs At a Time More

Drupal 8 Development Begins — 15 Bugs At a Time

Comments Filter:

  • brilliant (Score:1)

    by Anonymous Coward

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

  • Let there be no critical bugs. That was easy!

  • go faster by going slower? (Score:3, Informative)

    by sparetiredesire ( 465731 ) on Thursday March 10, 2011 @07:27PM (#35448942) Homepage

    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.

    • 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.

    • 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.

  • They're calling 7.1, 8.
  • 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.
    • 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.

    • 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! (Score:5, Informative)

    by /dev/trash ( 182850 ) on Thursday March 10, 2011 @07:34PM (#35448990) Homepage Journal

    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.

    • 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: (Score:2, Informative)

        by Anonymous Coward

        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

      • 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: (Score:1)

        by Mouldy ( 1322581 )
        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 th

    • Re: (Score:2)

      by wrook ( 134116 )

      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 t

      • Re: (Score:2)

        by wrook ( 134116 )

        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 delaye

        • Re: (Score:2)

          by Shimmer ( 3036 )

          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.

          • 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 r

      • "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"
        F

  • No one (Score:3)

    by JustOK ( 667959 ) on Thursday March 10, 2011 @07:46PM (#35449062) Journal

    No one needs more than 15 critical bugs.

  • scary (Score:3, Interesting)

    by nethenson ( 1093205 ) on Thursday March 10, 2011 @07:56PM (#35449124) Journal

    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: (Score:2)

      by Crouty ( 912387 )

      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.

  • 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.

    • 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

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

  • 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
  • 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 requirement

    • 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 criti

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

    • 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.

  • 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.

  • 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?

    • 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.

Slashdot Top Deals

Basic is a high level languish. APL is a high level anguish.

Close