This is a record of a discussion between mkanat and LpSolit on April 21, 2011. It describes the problems that we are facing with Perl and CPAN, our reasons for deciding to move away from Perl, our discussions of possible languages, and our decisions for how to move forward. This was mostly one long conversation, but it has been edited and split into pieces for ease of navigation and reading.
The Problem With Dependencies
<LpSolit> ok, so I have data: http://landfill.bugzilla.org/active/ shows that the more dependencies we have, the more likely something will go wrong
<mkanat> I agree that the data shows a problem.
I also agree that a larger codebase means that there are more likely to be more problems.
But there's a question to ask of "whose larger codebase?"
That is, an external library has usually had more focused testing and long experience than code we write ourselves.
<LpSolit> and I complained often enough about these dependencies
<mkanat> Now, of course, aspects that are logically critical to the design of a bug-tracker, those we probably have more experience with than external libraries.
<mkanat> So although it's theoretically true that bringing in a dependency leads to a lot of code, it also gives us a lot of power and often greater testing than we could do ourselves.
However, there is a problem that I've been seeing, which is that we seem to be one of the last major "shipping" applications written in Perl.
That is, the CPAN developers seem to care less and less whether or not it's easy for people to *install* their modules.
They aren't testing it, they don't care when I report bugs, etc.
More or less what I'm seeing is that Perl is becoming less and less a good language for us to be writing a shipping app in, because the Perl community as a whole doesn't seem to care about our use case.
<LpSolit> well, we can honestly hope that CPAN developers want their modules to be installable
<mkanat> Yeah, we can certainly *hope* so. :-)
But it hasn't really played out. I mean, every single bug that I reported so far as part of bug 646578 hasn't been fixed.
<mkanat> I also reported a bug against Dist::Zilla (that it makes modules require ExtUtils::MakeMaker 6.31 even when it didn't need to) and nothing has been done about that.
<LpSolit> that's exactly the reason why I hate dependencies so much
and that we don't always need new ones, even if they look great
<mkanat> This doesn't happen in other languages.
In Python, I've almost never had a module fail to install.
<LpSolit> well, this wouldn't be a problem if all our dependencies were in the core Perl distribution
nor would it be a problem if they were bug-free
<LpSolit> but the fact is that we have no control on them, as you said above
so we have to keep that in mind when deciding to include new ones
<mkanat> Okay, I think that's a good point.
See, in an ideal world, since everything is open-source, the maintainers would just accept my patches quickly and release new versions.
And actually, even just a few years ago, they did.
<mkanat> But I'm sure you've experienced it with some of your CPAN bug reports lately, too, that they just don't get fixed.
<LpSolit> oh, I report bugs to CPAN and then forget them, because they indeed end in a black hole, most of the time
(except the one about ISAAC)
<mkanat> Okay, now let's talk about Moose.
So, more or less, all modern Perl development happens with Moose.
There are a few other similar frameworks, but Moose is pretty much dominant.
One of the ways you can tell is that nearly every major CPAN module maintainer is an operator in #moose on irc.perl.org.
I think it actually might be the largest channel on that network, even.
<LpSolit> Moose has many dependencies which are not in the core, including the problematic MRO
(and it has the reputation to be slow on startup)
<mkanat> Okay. So, slow on startup is true. However, mod_cgi is the past, and we should find effective ways to move away from it that are equally-simple for people to use.
It's actually slow during compilation, is what it is.
Now, it's possible that there is going to be a version of Moose coming out that eliminates that problem.
They're actually working to do some significant changes to Moose that may actually solve that. So I think we can put that question aside for now, and just talk about the dependencies, yeah?
<LpSolit> well, people want Bugzilla to be easy to install. If you tell them they need half a day to configure their web server to have some reasonable speed, they will give up
<mkanat> I agree, difficulty of installation is probably the most significant barrier to our user adoption.
So we need to find ways that are not only effective, but ways that are easy.
<mkanat> And honestly, I don't think that those ways exist in Perl, at least not ways that are both *effective* and easy.
mod_cgi is pretty easy (relatively) but it's not so good. :-)
<LpSolit> well, everytime I need to look at the Bugzilla doc to do something, I consider this as being too complicated because I still have to look at it after 7 years contributing to the project
<mkanat> Hahaha, agreed.
<LpSolit> or even worse: look at the source code because the doc isn't clear enough
<mkanat> Yeah, I totally agree.
<LpSolit> everytime I see a new dependency, I have this in mind
very strongly! :)
so yes, I pester in comments everytime I see a new requirement which is not important
<mkanat> Okay. So I suppose we should have a discussion about dependencies in general.
So, from a software engineering perspective, it's always better to re-use code than to write it. We agree on that, right?
<mkanat> (Just from a pure theoretical perspective.)
<LpSolit> right, if it's bug free and authors are responsive
(TT author was, for instance)
<mkanat> Sure, totally agree there.
<mkanat> So, the frustrating thing about Math::Random::Secure is that the code that *I* wrote works fine.
There are no problems with it.
<LpSolit> ... so far ;)
<mkanat> Hahahaha. Well, I had some pretty good input from some pretty good security experts on it. :-)
But the dependency chain had like four problems in it.
One of them being a problem with CPAN.pm itself. :-/
<LpSolit> if some problems are fixed in Perl 5.10, I would honestly say that we should require it for Bugzilla 5, and we could support Bugzilla 4 a bit longer than usual for those who don't have 5.10 or higher
<mkanat> Yeah, I was considering that.
But I don't think that 5.10 would have fixed enough problems.
The CPAN.pm problem happens in its very latest release.
<LpSolit> it's fine that Perl 5.8.1 fixed all our problems with Unicode, for instance
<LpSolit> it was the right decision to require it
<mkanat> Totally. I don't really see anything in 5.10 that seems important to us, though.
Same for 5.12; that release seemed totally uninteresting to me.
I think that some of what we're seeing is fundamental problems with CPAN and the Perl ecosystem.
There just aren't enough people maintaining CPAN--single people have these massive responsibilities.
<LpSolit> well, if they maintain modules they don't use themselves, they clearly won't improve them
<LpSolit> just wait for users to report bugs
<mkanat> And they also have day jobs that have nothing to do with those modules.
<LpSolit> I suspect there are too many modules, and several are "dupes" of other ones
<mkanat> That's totally true.
There's a lot of re-inventing the wheel on CPAN.
<LpSolit> which makes the choice of the correct one even harder
<mkanat> Yeah. Also, a lot of them suck in some fundamental way.
Like, I wrote RPC::Any because there were a lot of XML-RPC modules and a lot of JSON-RPC modules, but none that combined them or even worked in a good way that we would want to use.
<LpSolit> RPC::Any which depends on.... Moose!! :(
<mkanat> True, because Moose is awesome for developers. And lots of people install it, so that one actually *should* be installable without problems, one would hope.
The Future of CPAN and Installation Troubles
<mkanat> I think that this problem with CPAN is going to get worse and worse over time.
I mean, even SOAP::Lite, a totally standard module, has had this critical bug in it for over a YEAR now with no fix.
This is a situation we just can't continue to operate in.
<LpSolit> is the maintainer still responsive?
<mkanat> Not really.
A lot of what I'm concerned about, when I bring in dependencies, is that we want to keep our development effort as low as possible.
That is, we operate on volunteer time, and not a whole lot of it.
That time should be spent as valuably as possible, not on implementing things that already exist, if we can help it.
<LpSolit> sure, but then having to work around their problems costs time too
<mkanat> That's what I was just about to say, yeah.
When we become the maintainers of all of CPAN, ourselves, that totally defeats the purpose.
And it leaves us with two really bad choices:
(1) Write everything ourselves, which is a maintenance nightmare and even more than we have time to implement. (2) Bring in dependencies and then work around their problems in our code.
(Or (3) Annoy CPAN maintainers continuously until they fix their code, which doesn't always work.)
And really, this problem gets worse and worse over time.
If it continues like this, every single one of our dependencies will be broken.
And we will become the maintainers of all of them.
We won't spend any time on improving Bugzilla itself, and we will spend all our time on just the basics of getting Bugzilla working for our users.
<LpSolit> without XS, we could have everything in lib/, and we could do what we want with them
and upgrade them when we want too to sync with CPAN
this would be ideal
<LpSolit> kind of "statically linked"
<mkanat> Although some sites would have a policy against that.
And they would have to remove them all anyway.
Like Mozilla, Red Hat.
<LpSolit> for security reasons, yeah
So we couldn't really have custom patches on them, which is what we'd need.
But I agree it would be nice if we could just ship all our dependencies.
With Python we could almost do that, actually. Very few modules have C dependencies.
Also, Python has really great systems for setting up a whole separate Python installation just for your program, if you want to.
<LpSolit> wouldn't this still be a problem with the policy you mentioned above?
<mkanat> Yeah, it still would be. But it would still help a lot of our users.
It's not something we can do at *all* right now, in Perl. :-)
So I was just saying that we *could* do it in Python for a lot of things, if we wanted to.
<mkanat> So anyhow, I've done a lot of language research over the last few years, in thinking about places we could move to. Are you interested in hearing anything about it?
<mkanat> Okay, cool.
So, basically, the major languages in use for web apps today seem to be Java, Ruby, and Python.
And PHP, I suppose.
Java has great Unicode support and a lot of developers, but it's not quite as fast to develop in as the other languages.
Also, it's a compiled language, so we have to run the compiler every time before running the code.
And from what I've heard, deploying a Java application is terrible.
Also, Java has *nothing* like CPAN, and doesn't even support having something like that.
If you want a library, you always have to manually install it.
So from my perspective, all those downsides seem like Java is out of consideration for us, agreed?
<LpSolit> you have to compile it only once, AFAIK
but yes, I agree
<mkanat> True, but every time you make a change, also.
<LpSolit> ah sure, but that's also true for mod_perl, isn't it? ;)
<mkanat> It adds some delay to development. I agree that's not the most significant downside, though.
<LpSolit> you have to restart it
<mkanat> Haha, I suppose so. :-)
So I can agree that's not a major issue.
I used to have an objection that Java wasn't FOSS, but that's gone now.
It is owned by Oracle, though, which is a concern.
But do you agree that the other downsides mean that we definitely wouldn't want to rewrite in Java?
<LpSolit> Java's future is unclear
<mkanat> Yeah, that's true for sure.
<mkanat> Okay, cool.
So next I suppose we can talk about PHP.
Do we even need to talk about this? :-D
It's a terrible language.
<LpSolit> no need
<mkanat> Hahahaha, okay.
PHP is out.
<LpSolit> easy to make things unsecure, from what I heard
<mkanat> Yeah, and just really bad in so many ways.
So next is Ruby.
There are currently two major versions of Ruby, 1.8 and 1.9.
1.8 is slow, but 1.9 is fast.
Ruby as a language is fantastic. It's my favorite language to program in. It has a lot of features similar to Perl, but is a lot cleaner to read and use in general.
The deployment story is bad.
Also, many of the libraries are immature.
We would be taking a significant step backward in terms of even our database support, I think, if we started using Ruby.
Also, last time I checked, Unicode support was poor or nonexistent in most parts of the language and libraries.
LpSolit notes that http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html says that its usage is divided by two in two years
<LpSolit> well, not exactly usage, but hits
<mkanat> Wow, that's surprising, yeah.
I mean, Ruby does have Rails, which is pretty awesome. But from what I understand of it, it's too simplistic for us.
Also, Ruby has rubygems, which is like CPAN and works pretty well, in my testing.
Also, I'd be really concerned about people trying to install on shared hosting.
I've heard people give up on installing Redmine because its installation was too hard or because their host didn't support Ruby.
<LpSolit> I doubt Ruby is broadly available
<mkanat> Yeah, that's probably my biggest concern about it.
In fact, I think purely because of availability, I have to eliminate Ruby from consideration.
<LpSolit> and the plot above may indicate that Ruby looked exciting, but finally isn't good enough or immature, yeah
<mkanat> Yeah, that sounds pretty likely.
I think even Twitter is moving away from Ruby for some of its public-facing stuff.
<LpSolit> did they explain why?
<mkanat> Performance, I think.
They needed to scale more and perform better.
<LpSolit> Perl is still good at that ;)
<mkanat> Absolutely. :-)
Perl is SUPER fast, particularly under mod_perl.
And Perl has great Unicode support.
So, we agree that Ruby is out?
<mkanat> Okay, cool.
<LpSolit> at least for the next few years :)
And possibly forever, if it doesn't pick up in usage.
<mkanat> Okay, so, Python.
Now, Python is pretty great.
It is a very clean language, easier to develop in than Perl.
It's used in a LOT of huge web applications.
There are a lot of people who have jobs that contribute to Python and work on Python libraries, in a lot of places.
I used to think that Python was slow, but actually recently I wrote an app that returned a page in 50ms.
And that was using bzr to grab a file and return it to the user.
So that even includes going through all of bzr and the whole web application to return the data.
Python has a lot of stuff available for web applications, and also some really great frameworks for writing web applications in.
There are some things about Python that are pretty annoying or difficult at first.
Like the lack of curly braces on blocks--a block is a block if it's indented with whitespace.
<LpSolit> yeah, I'm really not used to this
<mkanat> Yeah, I wasn't at first, either.
It took a while to get used to it.
<LpSolit> and if you insert another block, you have to indent them all again
Theoretically we'd be doing that anyway.
It's not my favorite part of the language, but actually, once I got used to it I was totally fine with it.
<LpSolit> I mean when you test a patch you write, you don't bother fixing the indentation ;)
<mkanat> Hahaha. :-)
<LpSolit> you only fix it right before uploading to bmo
<mkanat> Yeah. That's just a practice that would have to change.
(I mean, I do indentation as I go anyhow, but partially that's because Komodo makes that easier--just select a bunch of text and hit Tab.)
So that's a little annoying, but it's not a deal-breaker, really.
And I've actually sort of come to like it, after writing a lot of Python.
I don't *always* like it, but I often do.
It does end up making *most* code easier to read.
<mkanat> One other problem is that you never declare variables, so typos can be really easy.
The variables problem is handled by "pyflakes" or "pylint" though, which are tools that can analyze the code and find problems with it.
And they're actually really good.
Tools like that could never be written for Perl, because Perl can't be parsed by anything but perl.
<LpSolit> does it have a taint mode?
<mkanat> I don't think that it does, but I think there are libraries available to implement it.
Also, depending on how we implement things, the libraries we use might do those sorts of checks for us.
I do want to make sure we retain our security features.
It *used* to also have the problem that installing modules had to be done manually, but now there is the "Python Cheeseshop" and a tool called easy_install that works really well.
One of the most interesting things about the Cheeseshop and easy_install is that it works no matter where the module is hosted, so it includes almost every piece of Python software in the world.
The only real significant problem that I've ever had with Python is its Unicode support. It supports Unicode, but you have to be really careful about how that works.
Now, that problem is solved in Python 3.0.
But using Python 3 isn't really practical right now.
It actually turns out that also, most Python web frameworks solve the problem for you.
That is, they make Unicode magically "just work" behind the scenes, and you don't have to worry about it.
So as long as we use one of those frameworks, that problem pretty much goes away.
One of the major advantages of Python is that it has a system for interacting with webservers called "WSGI" that *every single* major Python framework supports, and that a lot of webservers work with, too.
There are also pre-existing libraries that will run WSGI applications in fastcgi, giving support for all the other webservers that don't support WSGI.
Also, unlike Ruby, Python is deployed pretty much everywhere.
<LpSolit> by the time Bugzilla would be converted to Python (assuming we do it one day), Python 3 would be common
<mkanat> Yeah, that was one of my thoughts as well.
I don't think that Python deployment is quite as common as, say, PHP, but I think it's on enough hosting servers that people wouldn't have to worry about finding support.
There are also a lot of Python developers out there, and (as I think I mentioned before) a lot of actively-maintained major applications written in it.
So my feeling is, as far as languages go, if we're going to do a re-write, Python seems like our best choice.
<LpSolit> C++ would be faster, no? :-p
mod_c++ doesn't exist? ;)
<mkanat> Hahahaha. :-)
I can't imagine the pain of writing a web app in C++.
So anyhow, do you agree with me about that, about Python?
<LpSolit> I just looked at a well known web host here in Switzerland, and it has Perl 5.8.8, Python 2.4.4, and PHP 5.2.17
<mkanat> Okay, cool.
<LpSolit> well, I agree that Python seems a better candidate than Java, PHP or Ruby, but I cannot say if this is the way to go, nor if we should rewrite Bugzilla in another language
<mkanat> Okay. So we at least agree that Python is the best candidate.
Is a Rewrite a Good Idea?
<mkanat> So let's talk about whether or not a rewrite is a good idea at all.
So, I think that we both agree that CPAN maintainers are becoming less and less responsive, yeah?
Remember that we used to report bugs in the Email:: modules and they'd get fixed.
Even some of the SOAP::Lite bugs we reported got fixed.
Same for TT, etc.
And now it seems like nothing gets fixed, except for CGI.pm (which is only as of recently) and modules where I know the maintainers directly on IRC and I bug them until they fix it.
Also, would you agree that the features in new versions of Perl don't seem useful or worthwhile? That is, Perl doesn't seem to really be getting better.
I don't know if you saw the "what's new in Perl 5.12," but it seemed totally uninteresting to me.
<LpSolit> I like the new // operator :)
<mkanat> Yeah, I do like that. :-)
That'd be a nice reason to go to 5.10.
<LpSolit> and switch works correctly now
<mkanat> Yeah, Perl 5.10 did have some nice things.
<LpSolit> Perl 5.14 doesn't look exciting
So, I've been monitoring the situation pretty carefully ever since my blog post all those years ago.
I really tried hard to work with the Perl community and to attempt to learn everything I could about CPAN and really understand everything about modern Perl development.
And even despite all of that, I see the situation getting worse and worse.
As Perl becomes less and less popular, it will become harder and harder to find new contributors. But even more importantly, it will become harder and harder for Bugzilla admins to install Bugzilla.
Because support for Perl and CPAN modules will become less and less.
I really feel like a huge portion of the difficulty users have in installing Bugzilla right now is because of Perl.
What Would It Actually Take to Move Bugzilla to a New Language?
<LpSolit> now moving Bugzilla to another language is mostly a new application
we cannot copy each feature one by one in the new Bugzilla
<mkanat> Yeah, no matter how you slice it, it's a huge amount of work.
And we can't stop maintaining the Perl Bugzilla while we do it.
<LpSolit> and we cannot have some pieces of the code in Python and the rest of the code in Perl, because you would have to install both
<mkanat> Right, that would be terrible.
<LpSolit> so it would be a completely separate branch (or project)
kind of fork
<mkanat> More or less, yeah.
<LpSolit> with new developers and new project leaders
<mkanat> What we would have to do is maintain both versions for a while, and then eventually switch.
Well, I have some thoughts about that, too.
We would definitely need some new developers.
<LpSolit> on the other hand, the rewrite would let us remove what's broken
"you had this feature in Bugzilla? Ok, but that's Pyzilla now, so don't cry"
If we're going to do a rewrite, I think that to a large degree, it's important that we do it like a refactoring.
That is, we don't change the functionality at the same time as we're changing the language.
<LpSolit> oh, this would be a nightmare for sure
There are certainly times when we could make the decision to *remove* a feature along the way, though, simply by not rewriting it.
<LpSolit> can we easily add extensions in Python, as we have with Bugzilla::Extensions?
<mkanat> Yes, possibly even easier, in fact.
Trac has a great plugins system.
And actually, there's a particular framework that I was thinking of using that supports plugins as part of the framework.
<LpSolit> I honestly think that the way to go would be to fork Bugzilla 4.x as a separate project
<mkanat> Okay, fundamentally that's what I was thinking too.
Basically, my plan was that first we do Bugzilla 5.0, we implement Pretty (the new UI).
So, first Bugzilla 5.0, then doing some stuff to make 5.0 easier to port over to Python (just fixing up some architecture stuff) and then forking.
Although before forking, there would be a lot of experiments with basic architecture stuff.
<LpSolit> the risk with the fork is that people may want to implement new features from the beginning, and it would quickly diverge from Bugzilla
and it would simply be another BTS
<mkanat> Right, that's just something we'll have to control very carefully.
Also, we'll have to keep up with features that the Perl version has.
So we'll need a way to keep track of what we still need to implement.
<LpSolit> we could have a keyword for that
or use the status whiteboard [parity-bugzilla]
<mkanat> Yeah, I like the keyword idea. Or Whiteboard, sure.
<LpSolit> as they have for Firefox and [parity-opera], [parity-chrome]
<mkanat> Okay, good idea.
At some point, we'd declare "Pyzilla is now Bugzilla", once we had good feature parity, stability, etc.
Because like you said, we don't want two products.
And we'd start slowly bringing over devs from the Perl side.
<LpSolit> honestly, it would be a good thing that Bugzilla core devs don't move to the fork, else Bugzilla will die before the fork is ready
and we aren't sure people will like the fork better, despite it's using Python
<mkanat> Yeah, totally true.
We may end up doing the whole fork and then throwing it away. Haha. :-)
<LpSolit> after 10 years of portage, like Perl 6
<mkanat> Yeah, that would be pretty lame. :-(
Hopefully we'd be able to get lots of people to help with Pyzilla, though.
I won't stop working on Perlzilla.
<LpSolit> it must be 1) trivially easy to install, 2) fast, 3) nice and usable
<mkanat> Totally agreed.
And it should be a serious improvement over Perlzilla in #1, roughly as good as Perlzilla in #2, and at least as good as Perlzilla in #3.
So are we agreed on the general outline for this plan?
Is This Still Bugzilla or a New Product?
<LpSolit> as long as we are clear that it's a fork
not the same project
and that Bugzilla 7 or 8 or higher will always be written in Perl
<mkanat> Ah, this project will be Bugzilla 6 or 7, I was thinking.
<LpSolit> I don't think we should reuse the same name when moving to another language
<mkanat> Oh, the name is our most important asset.
The idea is to eventually stop working on the Perl one, and switch the devs over slowly to the Python one.
<LpSolit> because both projects will live side by side for some years, IMO
<mkanat> Sure. While they're living side by side, the Python one will be Pyzilla as an unofficial code name.
<LpSolit> haha, Pyzilla already exists: http://pypi.python.org/pypi/PyZilla/0.1.0
<mkanat> Oh right, hahaha. :-)
I guess we could call it PyBugzilla.
But once the project is really ready and meets the criteria above, it should simply be the "next" major release of Bugzilla, whatever version that may be.
Because otherwise people won't upgrade.
They'll think, "Oh, this is some new project and not Bugzilla."
<LpSolit> it's not an upgrade, all requirements are different
<mkanat> But the database would be the same, it would be essentially the same product, just in another language.
<LpSolit> it's like upgrading from Windows XP to Snow Leopard, you have to change everything :)
<mkanat> No, it's not like that, because those are totally different products.
It's like translating a book from English to Spanish.
It's the same book, just in a different language.
<LpSolit> note that depending on the usage, we may have to support Bugzilla in Perl despite Bugzilla in Python is ready
<mkanat> Yeah, we'll have to support it for quite some time, I agree.
<LpSolit> those who don't upgrade easily
<mkanat> Probably longer than our normal support period.
At the very least, we'll support older releases just like we do now.
<LpSolit> but still implementing new features, most likely
at least some trivial ones
and do bug fixes in addition to security fixes
<mkanat> Depends what state the two projects are in when we "release" the Python one, I suppose.
But bug fixes for sure.
<LpSolit> with the rewrite, we could rethink how we want to create templates, for translators
<mkanat> Oh, yeah, that one I TOTALLY want to do, yeah.
The framework that I'm thinking of using supports gettext.
<LpSolit> we should have a TODO list on wiki
<mkanat> Totally agreed.
<LpSolit> a whole new section would make sense
<mkanat> Or at least a sub-section.
<LpSolit> requirements, TODO, features?, etc...
<LpSolit> Mageia, LibreOffice, and now Pyzilla
everybody wants to fork these days
<mkanat> Hahaha. :-)
Well, I think ours is a little more "friendly" than some of those other ones.
Also, eventually ours will become the official product, it's more like a branch than a fork.
<LpSolit> do you want me to create Bugzilla::Python on wiki?
<LpSolit> I will write in bold that this the current state of the discussion, and that nothing is written in stone, including the choice of the language and the way to do things
I was thinking that I'd send out an email about it soon; I have some stuff written up already for it.
<LpSolit> you could paste it to wiki
<mkanat> And I was thinking maybe I'd just put up a transcript of our talk about the rewrite part, somewhere, and link people to it?
Yeah, that's a reasonable idea.
<LpSolit> Bugzilla:Fork is better than Bugzilla:Python, isn't it? It's language-neutral
<mkanat> Ah, no, let's do Bugzilla:Pytohn
Because we don't really want to enforce the idea that this is a separate product.
We do agree that at some point this branch will become Bugzilla once it is good enough, yes?
<LpSolit> I'm still not sure
<mkanat> Well, this is a pretty important point; we have to be sure before we launch the project.
The point here is to actually *move* to another language.
<LpSolit> ultimately, it would become Bugzilla, I suppose, but this won't happen before many years
<mkanat> I would expect about 1.5-3 years, yeah, after the project starts.
Unless we get a zillion contributors and it somehow happens more quickly.
<LpSolit> oh, more than that
you need time to rewrite Bugzilla, and then support Bugzilla in Perl for some additional years
<mkanat> Sure, but supporting Bugzilla in Perl would just mean supporting older releases like we do now.
Maybe one more major feature release.
Honestly, I think most sites would be glad to move to Python.
Expertise in installing Python apps is considerably more common than expertise in installing Perl apps.
I think that in some other situations, a longer period of doing feature releases would be worthwhile, but here we're sort of talking about continuing to write our books in Latin as well as English.
Sure, there are going to be some users who want Latin for a little while still, but most users will be happy to use English instead.
<LpSolit> well, some users will probably want Perl longer than a year or two (I compare this to SeaMonkey vs Firefox)
<mkanat> That's possible. I mean, also, the community is always welcome to maintain whatever they want.
But it's mostly a question of what we do with naming and versions.
We could do a Perl Bugzilla as 6.0 and a Python Bugzilla as 7.0 simultaneously.
Then people could maintain the 6.0 branch for as long as they wanted to.
this is going to be a nightmare to separate bugs about Bugzilla and bugs about Pyzilla, but that's doable
Okay, so we agree on two "simultaneous" major releases as the solution there?
<mkanat> Okay, cool.