Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by avatraxiom (7875) on 2007.05.07 19:38 (#54924)
    I actually have heard of and did know about most of the modules and frameworks that were suggested by many of the commenters on my blog, as do several other Bugzilla contributors. Remember, Bugzilla is written by a community, not by just me.

    When I first started to work on Bugzilla's code several years ago, it was not in a state where a project like "Use DBIx::Class and Catalyst" was a feasible project. A huge amount of cleanup was required before anybody could even see the architecture of Bugzilla.

    I'm glad to take a look at some of these modules now and consider them.

    One of the differences between Bugzilla and many other Perl projects though, is that Bugzilla is actually something that a lot of people want to install on their own machine. There aren't a *lot* of people who want to install LJ or Slashcode on their own machine, and if they do they're usually experienced sysadmins with a background in Perl.

    So if we start to add lots of required modules to the Bugzilla project, that's a big problem for our users. I know that to you and every other Perl guru I've talked to, installing modules is not a big deal. It's not a big deal to me, either. But to many users who want to install Bugzilla, it *is* a big deal.

    I also know we can bundle the modules, and we actually are going to probably start doing that.

    Think of the post as, "If I were writing Bugzilla today from scratch, would I write it in Perl?" I certainly wouldn't. So is there some advantage to looking at the *possibility* of moving to some other language? Sure, research never hurt. It's also sparking a lot of interesting suggestions from the community, which I really appreciate.

    Also, many of the people who attack Bugzilla's code base haven't seen it in many years, and should take a look at what the current CVS HEAD looks like. I agree it's not ideal, but it's a HUGE improvement over Bugzilla 2.16.

    • The module installation problem is real. Yes, Perl folks in the know are comfortable with CPAN, but it's true that many aren't.

      As have been mentioned in various threads, there are solutions to that, including "bundle them manually", PAR, automating the install off CPAN, distro packages, etc.

      This is not a language problem. Ruby and Python will both have similar issues. PHP doesn't because nobody uses any modules, they just write everything from scratch.

      Reiventing all the wheels is of course another viable op
      • Hahahaha. :-) Yeah, I hate being stuck between that divide of "reinvent all the gears, wheels, and rods" or "require more modules than anybody wants to deal with." :-)

        It's true that it's a problem in any language, though some languages have things like email handling bundled in their standard library.

        That's also one reason why PHP users require few modules--they have a ridiculously extensive standard library.

        I agree that it's better to spread the work out on libraries across the community, though. It just m
        • they have a ridiculously extensive standard library.

          Except when they don’t (because ¾ of it are optional at compile time).

          • Yeah, good point! :-) I've run into that from time to time. Thankfully I'm usually using the packaged versions that either have them all built-in or compiled as separate packages that are pretty easy to get with the packaging system of whatever distro I'm using.

            They also have PEAR, which works pretty well.

    • I'm not sure how it can be easier to port to a new language that the developers and users know less, than to a framework written in a language the system is written in and developers and users already have some familiarity with.

      As it happens, if I was to write Bugzilla again tomorrow, it's not the language I would change, it's the database schema, relationships and workflow - I'd be looking at closer integration with project documentation (specifications, screenshots, UML documentation), version control and

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • Hi TeeJay. I think more of our users know Python than Perl, but it's true that more of our developers know Perl than Python.

        Have you looked at the database schema of Bugzilla in any depth?

        We're working on custom workflow right now.

        Our goal is to be a bug-tracker, not a project management system, so we don't work on those other things. If we had three times as many programmers, and we had them consistently available, we could consider branching out into those project-management areas, but right now our focus
    • So if we start to add lots of required modules to the Bugzilla project, that's a big problem for our users.

      Six Apart have solved this problem rather nicely by bundling all modules with MovableType []. It's a breeze to install too.

      Off the top of my head, you could also take a peek at how Krang [], Bricolage [], and *cough* RT [] *cough* have handled the module install issue.