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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Max's Response (Score:1)
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.
-Max
Reply to This
Re: (Score:2)
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
Re: (Score:1)
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
Re: (Score:1)
Except when they don’t (because ¾ of it are optional at compile time).
Re: (Score:1)
They also have PEAR, which works pretty well.
-Max
Re: (Score:2)
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;
Re: (Score:1)
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
Re: (Score:2)
Six Apart have solved this problem rather nicely by bundling all modules with MovableType [sixapart.com]. It's a breeze to install too.
Off the top of my head, you could also take a peek at how Krang [krangcms.com], Bricolage [bricolage.cc], and *cough* RT [bestpractical.com] *cough* have handled the module install issue.
Re: (Score:1)