post FOSDEM
Gabor Szabo
Gervase,
it was nice meeting you on FOSDEM and thanks for the short overview
of where Bugzilla stands.
Unfortunately there was no Bugzilla related action on FOSDEM but I have
not gave up trying to have more cooperation between the Bugzilla
developers and the Perl community but I need your help as well.
So where do you people think the Perl community could help Bugzilla?
Gabor
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps...@lists.mozilla.org>
Gervase Markham
> So where do you people think the Perl community could help Bugzilla?
Hi Gabor,
It was great to meet you at FOSDEM too.
IMO, the Bugzilla community is most in need of additional developers.
Where in the Perl community might we ask to see if anyone is interested
in lending a hand?
Other than that, did you have any ideas about how we could collaborate
better?
Gerv
Max Kanat-Alexander
> So where do you people think the Perl community could help Bugzilla?
Hmm, if you could send some developers our way, that would certainly be
helpful! :-) We're very helpful to people who are relatively-new Perl
coders, and we have a pretty good introductory system for getting into
coding on Bugzilla, so you're welcome to advertise Bugzilla as a Perl
project that's friendly to relatively-new developers. (Though they do
have to be able to read and write Object-Oriented Perl.)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Nitish Bezzala
Can you please tell us what you think attracted so many developers to Padre?
Maybe, we'll be able to borrow some ideas from you...
Thanks,
Nitish
Nitish Bezzala
Gabor Szabo
I basically just got lucky that I started a project that seemed to be
interesting to some developers but as this happened now I try to play
the expert on the subject.
Also I think it is much easier to make people enthusiastic about a new
project than an existing project that has been in use for more than 10
years.
So please take my suggestions with the appropriate grain of salt.
Anyway, I think the main issue was *publicity* and my earlier
involvement in the Perl community helped in that. I gave a talk about
it on FOSDEM last week but managed to use more time than allocated so
I skipped the most 2-3 import slides which said:
Publicity:
- blog about your project
- talk about it on YAPCs, Perl Workshops, Perl Monger meetings, wherever you can
- encourage other developers and users to blog about it and talk about it.
Create positive feeling towards your project.
Regarding Bugzilla:
I still recall this blog entry:
http://avatraxiom.livejournal.com/58084.html and the discussion it
created on http://use.perl.org/~TeeJay/journal/33269
Maybe it is just me and no one of the other use.perl.org readers think
the same but I am still not sure if the Bugzilla team likes the fact
that it is written in Perl or that you hate every inch of it?
IMHO this image need to be changed if you'd like to attract people to
work on Bugzilla.
For one thing if the Bugzilla web site (and the product itself) was
proudly saying that it is based on Perl (with logo, link to
www.perl.org) that would certainly start creating some warm feelings
in the community.
That would also help drive more people in the direction of Perl.
(e.g. see how every mailman installation has the Python icon even
here: http://mail.pm.org/mailman/listinfo/ )
Also - again IMHO - Bugzilla needs to send the message of using
*modern tools* in its development. (e.g. CVS still being the
recommended way to fetch the source code is NOT sending this
messages). While I think Git would have been a more attractive vcs for
many perl developers I think Bazar is also good in being modern.
(And I am still using SVN for most of my stuff.)
Make it familiar to CPAN authors and people who are used to the CPAN
style stuff.
e.g.
I was happy to see that you are using Test::More but some items I saw
were not as I would expect
the local::lib/PERL5LIB stuff I am trying to patch,
not using Makefile.PL or Build.PL,
not using "standard" CPAN layout:
modules in ROOT/lib/
command line scripts in ROOT/script
cgi scripts in some other directory (e.g. I use ROOT/www)
I'll try to allocate some time and look at the project to give you
more unwanted suggestions and maybe even a few patches.
I think if you would like to attract more people from that community
you should start blogging about Bugzilla and how its Perl code works.
What are your main challenges in the code base, what are you going to
do about it. How people could get involved.
I personally will try to see how Bugzilla is tested.
I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
the entires should appear on both http://ironman.enlightenedperl.org/ and on
http://perlsphere.net/ that are read by many people.
I am sorry if this got a bit too long and if it sounds too paternalistic
but the project I started is called Padre, so you might blame it on that ;-)
regards
Gervase Markham
> Maybe it is just me and no one of the other use.perl.org readers think
> the same but I am still not sure if the Bugzilla team likes the fact
> that it is written in Perl or that you hate every inch of it?
I personally am very happy it's written in Perl.
I have experience using Catalyst for the BzAPI project
(https://wiki.mozilla.org/Bugzilla:REST_API) and I would second the
comments of those who say it is extremely poorly documented. I even
bought the book "The Definitive Guide to Catalyst" and thought I could
take them to the Advertising Standards Authority about both the words
"Definitive" and "Guide". It was terrible.
> For one thing if the Bugzilla web site (and the product itself) was
> proudly saying that it is based on Perl (with logo, link to
> www.perl.org) that would certainly start creating some warm feelings
> in the community.
I'd be happy to see that.
> Also - again IMHO - Bugzilla needs to send the message of using
> *modern tools* in its development. (e.g. CVS still being the
> recommended way to fetch the source code is NOT sending this
> messages).
I agree. We have switched to bzr for development, and should be
recommending this to everyone, even anonymous checkers-out.
We use a product called Bugzilla for bug tracking - do you think that's
modern enough?
;-P
> not using Makefile.PL or Build.PL,
Could you explain a bit more about what we would be using them for? We
don't have any compiled bits...
> not using "standard" CPAN layout:
> modules in ROOT/lib/
> command line scripts in ROOT/script
> cgi scripts in some other directory (e.g. I use ROOT/www)
Now that we are in a proper SCM, moving files around has suddenly got a
whole lot easier. I guess the issue with switching to this layout is
that everyone upgrading would have to change their Apache configuration.
Wouldn't they?
> I'll try to allocate some time and look at the project to give you
> more unwanted suggestions and maybe even a few patches.
Thank you :-)
> I think if you would like to attract more people from that community
> you should start blogging about Bugzilla and how its Perl code works.
> What are your main challenges in the code base, what are you going to
> do about it. How people could get involved.
Sounds great.
> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
> the entires should appear on both http://ironman.enlightenedperl.org/ and on
> http://perlsphere.net/ that are read by many people.
Are those aggregators? I'm sure we could submit the Bugzilla updates
blog to them.
> I am sorry if this got a bit too long and if it sounds too paternalistic
> but the project I started is called Padre, so you might blame it on that ;-)
Everyone's opinion, politely expressed, is welcome.
Gerv
Gabor Szabo
> On 11/02/10 22:22, Gabor Szabo wrote:
> We use a product called Bugzilla for bug tracking - do you think that's
> modern enough?
>
> ;-P
We'll discuss this separately ;-)
>> not using Makefile.PL or Build.PL,
>
> Could you explain a bit more about what we would be using them for? We
> don't have any compiled bits...
>
>> not using "standard" CPAN layout:
>> modules in ROOT/lib/
>> command line scripts in ROOT/script
>> cgi scripts in some other directory (e.g. I use ROOT/www)
>
> Now that we are in a proper SCM, moving files around has suddenly got a
> whole lot easier. I guess the issue with switching to this layout is
> that everyone upgrading would have to change their Apache configuration.
> Wouldn't they?
I guess yes.
The advantage of the slight reorganization of the layout and the addition of
Makefile.PL or Build.PL is that then Bugzilla could be packaged to be uploaded
to CPAN just as any other CPAN distribution and then you would gain the
various additional features the CPAN ecosystem provides and the mind-share (!)
of the CPAN authors.
e.g. you would automatically get and RT queue.
Err. That might not be so convincing :-)
But you would get the reporting of the CPAN Testers which can be very nice.
With some more work the installation of Bugzilla might be changed so that in
addition to the current way it will also work using
cpan> install Bugzilla
Again, I think this will raise karma of Bugzilla among the CPAN authors.
Of course blogging about the plan, and then about the execution would
further help.
(There is a notion called GrayPAN and BlackPAN - relating to code that
is either open source but not on CPAN or to code that is behind corporate
firewall. Moving Bugzilla from GrayPAN to CPAN would allow it to be
included in various automatic analytical systems)
e.g. see http://ali.as/top100/index.html
>> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
>> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
>> the entires should appear on both http://ironman.enlightenedperl.org/ and on
>> http://perlsphere.net/ that are read by many people.
>
> Are those aggregators? I'm sure we could submit the Bugzilla updates
> blog to them.
Yes, http://ironman.enlightenedperl.org/ and http://perlsphere.net/ are
blog aggregators and especially the former one is now very central to the
core perl readers. Lots of discussion is going on there.
Gabor
ps. Why do the replyes go to both
devel...@bugzilla.org and on dev-apps...@lists.mozilla.org ?
Max Kanat-Alexander
> Maybe it is just me and no one of the other use.perl.org readers think
> the same but I am still not sure if the Bugzilla team likes the fact
> that it is written in Perl or that you hate every inch of it?
I think that we talked about this in one of our Bugzilla Meetings, and
basically, Bugzilla is written in Perl, and it's written in Perl no
matter whether each of us loves it or hates it. Perl has some awesome
things about it, and some bad things about it. (By the way, as a side
note, every programmer should have experience writing professionally in
multiple languages, so that they can understand what's good about each
language and what's bad about it--with only single-language experience
it's hard to make such a judgment.)
It's a programming language, a tool to and end. I don't think it's an
emotional issue, it's just a technical fact that Bugzilla is in Perl.
> Also - again IMHO - Bugzilla needs to send the message of using
> *modern tools* in its development. (e.g. CVS still being the
> recommended way to fetch the source code is NOT sending this
> messages).
The switch happened just days ago, and pretty much all the developer
documentation is written by me, in addition to almost all the
administrative details of the project being done by me, in addition to
50% or more of the development of the project being done by me, and I'm
not getting paid for any of it. So yes, I agree that the documentation
needs to be fixed, and it will be done soon.
However, CVS is still going to be easier for some people than bzr,
because far more people are familiar with CVS. So we'll keep around some
CVS instructions as well.
> the local::lib/PERL5LIB stuff I am trying to patch,
You're actually the first person ever to mention a problem with it, I
believe. :-) Otherwise we would have fixed it earlier.
> not using Makefile.PL or Build.PL,
> not using "standard" CPAN layout:
Mmm, I tend to think that, at the moment, installation would actually
become more difficult than it is now, with Module::Install, particularly
on Windows. There have been a few other people who have made this
suggestion when they were new to Bugzilla, but usually as people become
more familiar with the codebase, the community, and Bugzilla's install
process on various platforms, they see that it's better the way that it
is. However, if you can demonstrate to us that in the context of
Bugzilla's userbase and community, that there would be significant
technical advantages to restructuring to a more normal CPAN layout, then
it's something that we could certainly do now, since we're using a VCS
that understands renames. It would be a lot of work and a big change for
us, though, so we'd definitely want to see some strong technical advantages.
> I'll try to allocate some time and look at the project to give you
> more unwanted suggestions and maybe even a few patches.
Hahahaha. Your suggestions are not unwanted at all, I'm really glad to
have them, personally. :-)
> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
> the entires should appear on both http://ironman.enlightenedperl.org/ and on
> http://perlsphere.net/ that are read by many people.
This is certainly something to think about, and it's cool to have
experienced suggestions from somebody with good experience in the area.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander
> The advantage of the slight reorganization of the layout and the addition of
> Makefile.PL or Build.PL is that then Bugzilla could be packaged to be uploaded
> to CPAN just as any other CPAN distribution and then you would gain the
> various additional features the CPAN ecosystem provides and the mind-share (!)
> of the CPAN authors.
This is true, but currently all of our pages are separate CGI files, so
it's not like other web apps where there's a single .pl file that runs
under FastCGI and can reasonably installed in /usr/sbin/. Also, all of
our static web files are really static files, not handlers called
through a single point of access. The CPAN modules that I'm familiar
with don't provide any decent way of putting everything into a web
space, and with the current Bugzilla layout, all you have to do is untar
the tarball and you're basically good to go, in terms of layout.
> But you would get the reporting of the CPAN Testers which can be very nice.
That would be good for sure.
By the way, Bugzilla Extensions (that will be appearing in 3.6) are
designed in such a way that they can be packaged and distributed on CPAN.
developers@ was originally a majordomo list. Then we moved to using a
newsgroup with a gateway, but we wanted to keep the primary address as
devel...@bugzilla.org.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Gabor Szabo
<mka...@bugzilla.org> wrote:
> On 02/11/2010 02:22 PM, Gabor Szabo wrote:
>> Maybe it is just me and no one of the other use.perl.org readers think
>> the same but I am still not sure if the Bugzilla team likes the fact
>> that it is written in Perl or that you hate every inch of it?
>
> I think that we talked about this in one of our Bugzilla Meetings, and
> basically, Bugzilla is written in Perl, and it's written in Perl no
> matter whether each of us loves it or hates it.
If you mean the one that I was also involved then yes I remember a statement
similar to this one.
> It's a programming language, a tool to and end. I don't think it's an
> emotional issue, it's just a technical fact that Bugzilla is in Perl.
I read this once in a while but then I see many people - maybe different ones,
maybe the same - act as if it was emotional.
Personally I think without emotions most people would not be involved in the
Perl (or any other) community.
>> Also - again IMHO - Bugzilla needs to send the message of using
>> *modern tools* in its development. (e.g. CVS still being the
>> recommended way to fetch the source code is NOT sending this
>> messages).
>
> The switch happened just days ago, and pretty much all the developer
> documentation is written by me, in addition to almost all the
> administrative details of the project being done by me, in addition to
> 50% or more of the development of the project being done by me, and I'm
> not getting paid for any of it. So yes, I agree that the documentation
> needs to be fixed, and it will be done soon.
>
> However, CVS is still going to be easier for some people than bzr,
> because far more people are familiar with CVS. So we'll keep around some
> CVS instructions as well.
Err, I think there was a miscommunication on my part.
I was trying the stress that fact that the move to Bazar is a very
positive step.
Maybe technically it would be easier for many people to use CVS than to
learn the few basic commands Bazar needs to get started but I think the
emotions will quickly kick in. (Even with SVN I keep getting comments that
people are not involved in Padre because they want to use Git)
>> the local::lib/PERL5LIB stuff I am trying to patch,
>
> You're actually the first person ever to mention a problem with it, I
> believe. :-) Otherwise we would have fixed it earlier.
Someone has to be the first one for every issue :-)
>> not using Makefile.PL or Build.PL,
>> not using "standard" CPAN layout:
>
> Mmm, I tend to think that, at the moment, installation would actually
> become more difficult than it is now,
We could try to build a CPAN distro but explicitly turning off the
"install" target and telling people the installation is still the same
as earlier. That one could be uploaded do CPAN as a developer release
and then we could work out the specific issues with frequent new
developer releases to CPAN that mostly will try to address the
packaging and installation issues.
regards
Max Kanat-Alexander
>> It's a programming language, a tool to and end. I don't think it's an
>> emotional issue, it's just a technical fact that Bugzilla is in Perl.
>
> I read this once in a while but then I see many people - maybe different ones,
> maybe the same - act as if it was emotional.
>
> Personally I think without emotions most people would not be involved in the
> Perl (or any other) community.
Mmm, I think there are definitely a lot of people who get emotional
about it for sure. But ultimately it is a technical thing-- it's not
really like a painting or a song, where your emotional response and your
artistic sensibilities are *all* that matter, really. Still, I do
understand that people can have an emotional attachment to a programming
language. I don't, although I have spent some time with some members of
the Perl community and I like them quite a bit. :-) There's certainly an
emotional aspect to a community, so I agree with you there. :-)
> Err, I think there was a miscommunication on my part.
> I was trying the stress that fact that the move to Bazar is a very
> positive step.
Ahh, thanks! :-)
> Maybe technically it would be easier for many people to use CVS than to
> learn the few basic commands Bazar needs to get started but I think the
> emotions will quickly kick in. (Even with SVN I keep getting comments that
> people are not involved in Padre because they want to use Git)
Well, I think that we'll offer both for a while, so we'll see how
people respond.
> We could try to build a CPAN distro but explicitly turning off the
> "install" target and telling people the installation is still the same
> as earlier. That one could be uploaded do CPAN as a developer release
> and then we could work out the specific issues with frequent new
> developer releases to CPAN that mostly will try to address the
> packaging and installation issues.
Yeah, but I'm worried that it would just increase our support burden,
which is something that I try to avoid. That is, there would be a lot of
people on the support list and in IRC going "I tried to install Bugzilla
and it didn't work...." and then we'd ask them what they did and they'd
say "I did 'install Bugzilla'....".
One of the most important things to know about Bugzilla is that the
vast, vast majority of our users know nothing at all about Perl or CPAN,
so they have to always be provided installation options that are
straightforward, simple, and always work, or they run into a lot of
trouble and either decide not to use Bugzilla or decide to come to us
for support.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Gabor Szabo
<mka...@bugzilla.org> wrote:
> On 02/13/2010 07:41 AM, Gabor Szabo wrote:
>> Maybe technically it would be easier for many people to use CVS than to
>> learn the few basic commands Bazar needs to get started but I think the
>> emotions will quickly kick in. (Even with SVN I keep getting comments that
>> people are not involved in Padre because they want to use Git)
>
> Well, I think that we'll offer both for a while, so we'll see how
> people respond.
That's the best.
>> We could try to build a CPAN distro but explicitly turning off the
>> "install" target and telling people the installation is still the same
>> as earlier. That one could be uploaded do CPAN as a developer release
>> and then we could work out the specific issues with frequent new
>> developer releases to CPAN that mostly will try to address the
>> packaging and installation issues.
>
> Yeah, but I'm worried that it would just increase our support burden,
> which is something that I try to avoid. That is, there would be a lot of
> people on the support list and in IRC going "I tried to install Bugzilla
> and it didn't work...." and then we'd ask them what they did and they'd
> say "I did 'install Bugzilla'....".
As long as the version number on CPAN has an _ underscore in it,
the package is not included in the main index so regular people can not
install it but you can already collect the karma for uploading to CPAN.
Just make it clear in the CPAN upload and the accompanying blog entry
that it is the first experimental upload and full installation from CPAN
was not yet implemented.
> One of the most important things to know about Bugzilla is that the
> vast, vast majority of our users know nothing at all about Perl or CPAN,
> so they have to always be provided installation options that are
> straightforward, simple, and always work, or they run into a lot of
> trouble and either decide not to use Bugzilla or decide to come to us
> for support.
Then I guess most of them won't install from CPAN anyway.
Also I think we (let me include myself in this) would like to increase
the number of Perl programmers using Bugzilla as that could lead more
volunteers to code.
Anyway, I'll first try to install Bugzilla so I won't just talk in the air and
then I'll try create the appropriate files and submit as a patch.
Max Kanat-Alexander
> As long as the version number on CPAN has an _ underscore in it,
> the package is not included in the main index so regular people can not
> install it but you can already collect the karma for uploading to CPAN.
>
> Just make it clear in the CPAN upload and the accompanying blog entry
> that it is the first experimental upload and full installation from CPAN
> was not yet implemented.
Okay, if you want to investigate the possibility of making Bugzilla
CPAN-installable and come up with a plan for it, then I'm open to the
possibility. I don't want to put it up on CPAN if we're eventually going
to abandon it there for unfeasability, though--I think that it would be
worse to have an abandoned package there than no package at all.
> Also I think we (let me include myself in this) would like to increase
> the number of Perl programmers using Bugzilla as that could lead more
> volunteers to code.
Yeah, that's true for sure. :-)
> Anyway, I'll first try to install Bugzilla so I won't just talk in the air and
> then I'll try create the appropriate files and submit as a patch.
Okay, sounds cool. :-)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Gervase Markham
> However, CVS is still going to be easier for some people than bzr,
> because far more people are familiar with CVS. So we'll keep around some
> CVS instructions as well.
Is it really true that CVS will be easier for some people?
I see two constituencies:
- Users (that is, admins)
- Hackers
For users, it's just bzr co <url> <directory>, copied and pasted from
the installation web page. I can't see much advantage there. OK, if you
are in Windows, you have to install bzr - but you have to install CVS too.
For hackers, we don't allow them to commit to CVS anyway! So starting
with a CVS checkout just means you have to port your patches over later.
>> I am not sure if it should be done on http://bugzillaupdate.wordpress.com/
>> or on some other blog (maybe on http://blogs.perl.org/ ) but I am quite sure
>> the entires should appear on both http://ironman.enlightenedperl.org/ and on
>> http://perlsphere.net/ that are read by many people.
>
> This is certainly something to think about, and it's cool to have
> experienced suggestions from somebody with good experience in the area.
Bugzilla Update is low enough traffic that I think we should just submit
it to both these aggregators now, without worrying.
Gerv
Gervase Markham
> ps. Why do the replyes go to both
> devel...@bugzilla.org and on dev-apps...@lists.mozilla.org ?
Historical reasons.
Gerv
Frédéric Buclin
> Is it really true that CVS will be easier for some people?
>
> the installation web page. I can't see much advantage there. OK, if you
> are in Windows, you have to install bzr - but you have to install CVS too.
There are some external tools or scripts which use CVS. And in the short
term, we have more urgent things to do than updating them to point to
and use bzr. So it still makes sense to keep CVS for now as a mirror,
and consequently CVS instructions.
LpSolit
Colin Ogilvie
> There are some external tools or scripts which use CVS. And in the
> short term, we have more urgent things to do than updating them to
> point to and use bzr. So it still makes sense to keep CVS for now as a
> mirror, and consequently CVS instructions.
- Keep CVS for the scripts.
- Update instructions to use BZR.
Reasoning:
If CVS is staying as a permanent read-only access utility, then it's not
an issue.
However, if the plan is to ditch CVS such that it's not even
automatically updated from BZR, then the instructions should be changed
ASAP so that people don't start using CVS read-only versions, then find
they need to move it to BZR as that would just annoy them.
I'd also have said that updating the scripts should have been considered
as part of the CVS -> BZR move...
Colin
Gervase Markham
> There are some external tools or scripts which use CVS. And in the short
> term, we have more urgent things to do than updating them to point to
> and use bzr. So it still makes sense to keep CVS for now as a mirror,
> and consequently CVS instructions.
How does that "consequently" follow? If we need a CVS mirror for our own
purposes, sure. But why do we need to make people wanting to use
Bugzilla use CVS?
Gerv
Frédéric Buclin
> How does that "consequently" follow? If we need a CVS mirror for our own
> purposes, sure. But why do we need to make people wanting to use
> Bugzilla use CVS?
People already using CVS to update their installation are external to
the core team. I have some scripts myself which also use CVS, and from
time to time I need to refresh my memory when I need to do something
manually. And I don't have the time currently to play with my scripts
and installations to make them work with bzr.
Max Kanat-Alexander
> Is it really true that CVS will be easier for some people?
Yes, people on old distros who can't install a new-enough version of
bzr, or where they don't have a distro package for bzr.
> Bugzilla Update is low enough traffic that I think we should just submit
> it to both these aggregators now, without worrying.
Sure, that sounds reasonable. Do you want to do that, or should I?
Max Kanat-Alexander
> On 15/02/2010 11:37, Frédéric Buclin wrote:
>> There are some external tools or scripts which use CVS. And in the
>> short term, we have more urgent things to do than updating them to
>> point to and use bzr. So it still makes sense to keep CVS for now as a
>> mirror, and consequently CVS instructions.
>
> - Keep CVS for the scripts.
> - Update instructions to use BZR.
That's essentially what's going to happen, yes. Remember, it's only
been about a week since we switched. :-)
Max Kanat-Alexander
> If we need a CVS mirror for our own
> purposes, sure. But why do we need to make people wanting to use
> Bugzilla use CVS?
All the the tarballs that we ship are primed for CVS, and my current
plan is that stable branches will continue that way until they EOL, so
there are some places where we will need to keep around CVS
instructions--probably just in the docs and on the Download page.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Jean-Marc Desperrier
> With some more work the installation of Bugzilla might be changed so that in
> addition to the current way it will also work using
>
> cpan> install Bugzilla
Bugzilla has a Himalaya of bad karma about not being easy to install.
And developers who don't *really* care about that.
At my company, that's one of the reason we're not using it. Not the only
reason, there's also the fact it had from start the image of being ugly
looking and complex (and based on perl I have to say, but if all the
rest had been right ...) , but when the person in charge of having a go
at all the tools tried to install it, failed, spent more time trying,
failed again, then ended the report with "I couldn't install it", when
he had had success installing most of the other tools in minutes, it was
the final nail in the coffin.
Joel Peshkin
> <snip>
>
> At my company, that's one of the reason we're not using it. Not the
> only reason, there's also the fact it had from start the image of
> being ugly looking and complex (and based on perl I have to say, but
> if all the rest had been right ...) , but when the person in charge of
> having a go at all the tools tried to install it, failed, spent more
> time trying, failed again, then ended the report with "I couldn't
> install it", when he had had success installing most of the other
> tools in minutes, it was the final nail in the coffin.
Jean-Marc,
I hear this a lot and it baffles me. Could you be more specific
about where he failed? Did he have problems with CPAN? Was he trying
to install on Windows? Did he have trouble setting mysql privileges or
apache webserver configuration?
-Joel
Jean-Marc Desperrier
> I hear this a lot and it baffles me. Could you be more specific about
> where he failed? Did he have problems with CPAN? Was he trying to
> install on Windows? Did he have trouble setting mysql privileges or
> apache webserver configuration?
I think he was trying under Windows. I'm not saying he was *very*
motivated to install it from start.
I think the easiest solution would be to make available, and very
visible, one setup package with everything included that you just click
through to install with a default database.
Easybugzilla is what's needed, just like Easyphp (which install just
like I described PHP+Apache+MySql+PhpMyAdmin, together with a
start/stop/configure icon in the task bar).
Max Kanat-Alexander
> Bugzilla has a Himalaya of bad karma about not being easy to install.
> And developers who don't *really* care about that.
Hey Jean-Marc. I absolutely care about whether or not it's easy to
install. It's currently far easier to install on *nix than it is on
Windows, though, and that's something that I want to fix.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Gabor Szabo
<jmd...@alussinan.org> wrote:
> Easybugzilla is what's needed, just like Easyphp (which install just like I
> described PHP+Apache+MySql+PhpMyAdmin, together with a start/stop/configure
> icon in the task bar).
IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
and distributed that way.
On Ubuntu I can just type
$ sudo aptitude install bugzilla3
but I have not tried it yet so I am not sure what will be the end result.
In any case it would be nice if that was working on all the major
Linux distributions
if it is not yet already.
Gabor
Gabor Szabo
<jmd...@alussinan.org> wrote:
> Easybugzilla is what's needed, just like Easyphp (which install just like I
> described PHP+Apache+MySql+PhpMyAdmin, together with a start/stop/configure
> icon in the task bar).
IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
and distributed that way.
On Ubuntu I can just type
$ sudo aptitude install bugzilla3
but I have not tried it yet so I am not sure what will be the end result.
In any case it would be nice if that was working on all the major
Linux distributions
if it is not yet already.
Gabor
Max Kanat-Alexander
> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
> and distributed that way.
The reason that Bugzilla can't currently use Strawberry Perl is that
explaining how to compile DBD::mysql (or any other CPAN module dependent
upon external headers) is too complicated and difficult.
> On Ubuntu I can just type
>
> $ sudo aptitude install bugzilla3
>
> but I have not tried it yet so I am not sure what will be the end result.
The Ubuntu package seems to have a lot of issues, and is, I believe,
unmaintainted. The Fedora package is kept up-to-date, though, and seems
to work fine.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Dan Wierenga
<mka...@bugzilla.org> wrote:
> On 02/16/2010 01:29 PM, Gabor Szabo wrote:
>> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
>> and distributed that way.
>
> The reason that Bugzilla can't currently use Strawberry Perl is that
> explaining how to compile DBD::mysql (or any other CPAN module dependent
> upon external headers) is too complicated and difficult.
But if you were making an installer package that bundled Strawberry
Perl, wouldn't you be doing the DBD::mysql compile for the end-user
anyway?
Gabor Szabo
> On Tue, Feb 16, 2010 at 1:34 PM, Max Kanat-Alexander
> <mka...@bugzilla.org> wrote:
>> On 02/16/2010 01:29 PM, Gabor Szabo wrote:
>>> IMHO for windows Bugzilla could be integrated with Strawberry Perl Professional
>>> and distributed that way.
>>
>> The reason that Bugzilla can't currently use Strawberry Perl is that
>> explaining how to compile DBD::mysql (or any other CPAN module dependent
>> upon external headers) is too complicated and difficult.
>
> But if you were making an installer package that bundled Strawberry
> Perl, wouldn't you be doing the DBD::mysql compile for the end-user
> anyway?
According to the web site DBD::mysql is part of Strawberry Perl already.
see http://strawberryperl.com/
Gabor
Max Kanat-Alexander
> But if you were making an installer package that bundled Strawberry
> Perl, wouldn't you be doing the DBD::mysql compile for the end-user
> anyway?
You can't--it depends on the version of MySQL in use. (It might also
depend on the Windows version in use? I'm not sure. I suspect 32-bit vs.
64-bit would be an issue, but Perl is already compiled differently for
those, so that's not a problem.) If we bundled MySQL also, we could
build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
have a hard time.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander
> According to the web site DBD::mysql is part of Strawberry Perl already.
> see http://strawberryperl.com/
Oh, that's new since the last time we tried it out. Maybe we can try
again--it would be nice to be able to use normal CPAN tools on Windows.
What about other things that depend on external libraries, like the GD
modules that we use?
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Dan Wierenga
<mka...@bugzilla.org> wrote:
> If we bundled MySQL also, we could
> build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
> have a hard time.
>
People who want choices of which database to use, or which webserver
to use, or where your files install to, can install everything
manually.
On the other hand, the people who want to use a
just-a-few-clicks-and-it-WORKS Windows installer probably don't care
if they end up using MySQL or PostgresSQL, or Apache or IIS, or
ActiveState Perl or Strawberry Perl. What they will care about is
that they're suddenly using *BUGZILLA*.
Gabor Szabo
<mka...@bugzilla.org> wrote:
> On 02/16/2010 01:54 PM, Gabor Szabo wrote:
>> According to the web site DBD::mysql is part of Strawberry Perl already.
>> see http://strawberryperl.com/
>
> Oh, that's new since the last time we tried it out. Maybe we can try
> again--it would be nice to be able to use normal CPAN tools on Windows.
>
> What about other things that depend on external libraries, like the GD
> modules that we use?
I don't know but if they are missing we could talk to Adam Kennedy
and/or Curtis Jewell who build Starwberry and ask them to make
Strawberry - or Strawberry Professional ready for Bugzilla.
They might also be able to help building a distribution that will
include everything Bugzilla needs including the database.
BTW can Bugzilla use SQLite? Can it use a perl based web server? If
those could work then you could have a much slimmer installation for
Windows.
Gabor
Max Kanat-Alexander
> BTW can Bugzilla use SQLite?
Not yet, but I'd like it to:
https://bugzilla.mozilla.org/show_bug.cgi?id=337776
> Can it use a perl based web server?
Well, theoretically it can use any web server, but I prefer that users
use Apache, because it will use our .htaccess files and is something
that we know well and can provide support for.
> If
> those could work then you could have a much slimmer installation for
> Windows.
Yeah, I've actually thought about that before, and thanks for reminding
me, because that's something I definitely want.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander
> On the other hand, the people who want to use a
> just-a-few-clicks-and-it-WORKS Windows installer probably don't care
> if they end up using MySQL or PostgresSQL, or Apache or IIS, or
> ActiveState Perl or Strawberry Perl. What they will care about is
> that they're suddenly using *BUGZILLA*.
Yeah, that makes sense.
Also, somebody would have to maintain this installer and promptly
update it every release, or it wouldn't be that useful. I suspect that
that person wouldn't be me, so we'd need somebody willing to dedicate
themselves to producing the installer every time we have a release.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Steve Wendt
>> On the other hand, the people who want to use a
>> just-a-few-clicks-and-it-WORKS Windows installer probably don't care
>> if they end up using MySQL or PostgresSQL, or Apache or IIS, or
>
> Also, somebody would have to maintain this installer and promptly
> update it every release, or it wouldn't be that useful.
Which means chasing down the latest MySQL and Apache for bundling in.
And what do you do if there's an important Apache security fix? Release
a new package, even if there's not a new Bugzilla? If not, how do you
handle user-installed updates? It's a can of worms...
Byron Jones
> [..] If we bundled MySQL also, we could build a DBD::mysql
we can't bundle mysql because bugzilla isn't gpl.
--
byron.jones :: http://glob.com.au
Dan Wierenga
On Tue, Feb 16, 2010 at 3:15 PM, Max Kanat-Alexander
<mka...@bugzilla.org> wrote:
> Also, somebody would have to maintain this installer and promptly
> update it every release, or it wouldn't be that useful. I suspect that
> that person wouldn't be me, so we'd need somebody willing to dedicate
> themselves to producing the installer every time we have a release.
I think that's the wrong way to go about this, and IMO it's indicative
of the entire thought process of the Bugzilla Project in regards to
Windows. It's fairly obvious that Windows is the red-headed stepchild
platform. Too little effort goes into making things work on Windows
for it to be really, truly considered a "supported platform".
A command-line script is The Way You Install Things on Linux, and you
wouldn't ship a Linux release with a broken checksetup.pl. Similarly,
an installer package (.msi or .exe) is The Way You Install Things on
Windows, and yet here you're talking about "promptly updating it every
release". In other words, there's a Bugzilla release, and then the
installer would have to be nudged along.
From my perspective, the release isn't RELEASABLE until the installer
is done. It's what the release manager is doing from the time the
code base freezes in preparation for the release until the release
actually happens.
Yes, that means that the release management for a Windows build is a
whole lot more complicated than just some command-line perl scripts.
But that's the price of reaching the Windows audience; you either
support Windows and its relatively un-technical userbase, or you
don't. But you can't say "we support Windows" and then have a high
failure rate on installation. All it does is give Bugzilla some
really bad press, because the Windows crowd doesn't think, "Bugzilla
doesn't work on Windows", they think "Bugzilla doesn't work".
I'd like to help on a Windows installer, I really would. I sent you
my thoughts on why I wasn't contributing to the community, and I saw
your email thread on your research results. You'll notice that thread
was enough to keep me here on the mailing list :) , but I'm still not
*really* contributing. A couple of things need to happen from the
Bugzilla developers before I'd really want to devote any time to a
Windows packager (and by "developers", I mean the real ones, not just
the members of the mailing list; I guess for my purpose the list of
code reviewers is "the real developers"):
- A simple clarion call to the list(s) for some help in sprucing up
the process of installing Bugzilla on Windows. It's okay that none of
the reviewers knows much about making things install gracefully on
Windows; what's not okay is that you KNOW that, and you still haven't
put out a call for help.
- A commitment to a Windows installer, and the general treatment of a
Windows installation as "just as important as another platform". You
can't make a release and then say the release is waiting for one
person to create an installer. (Just think of the Firefox Project.
If they "released" Firefox 4 and said, "oh yeah, you can get the code
from CVS, but the Windows installer isn't ready yet", the majority of
the Internet would think "Firefox 4 isn't released", and the rest of
the Internet would think the Firefox Project has a screw loose for
even announcing it was.)
Basically, the Bugzilla Project needs to show it *wants* to be part of
the Windows community before the Windows community can be expected to
want to be part of the Bugzilla community.
-Dan
Dan Wierenga
email that I'm excited about.... Ah well.
Joel Peshkin
>
> A command-line script is The Way You Install Things on Linux, and you
> wouldn't ship a Linux release with a broken checksetup.pl. Similarly,
> an installer package (.msi or .exe) is The Way You Install Things on
> Windows, and yet here you're talking about "promptly updating it every
> release". In other words, there's a Bugzilla release, and then the
> installer would have to be nudged along.
>
>
to do? Does it need to install Apache and Mysql and ActivState Perl?
Or does it presume certain things were previously set up before it is run.
Would it be reasonable to provide an installer that does the following....
1) Checks for perl ... if no Perl ... pop up instructions to install
Perl first and quit
2) Check for perl modules, if modules are missing, ask PPM to install them.
3) Prompt the user for Mysql connection information. Test the
connection, if it doesn't work, pop up instructions to install/configure
MySQL
4) Offer to start a perl-based Webserver for Bugzilla.
Max Kanat-Alexander
> I think that's the wrong way to go about this, and IMO it's indicative
> of the entire thought process of the Bugzilla Project in regards to
> Windows. It's fairly obvious that Windows is the red-headed stepchild
> platform. Too little effort goes into making things work on Windows
> for it to be really, truly considered a "supported platform".
Hey Dan. Here's the problem:
Nobody pays me to work on Bugzilla. Nobody is paid to do Bugzilla
releases. (In fact, *nobody* is paid to work on Bugzilla full time, at
all.) The current release package process is very simple, whereas an MSI
that would install and configure Bugzilla, Apache, MySQL and Perl all at
once is an incredibly complex undertaking requiring an immense amount of
specialized skill that I don't currently have. It's not that I don't
understand the importance or the utility of such a project, it's simply
that I *cannot do it*. So I need somebody else to do it, and then I
would be *really glad* to have it.
> - A simple clarion call to the list(s) for some help in sprucing up
> the process of installing Bugzilla on Windows. It's okay that none of
> the reviewers knows much about making things install gracefully on
> Windows; what's not okay is that you KNOW that, and you still haven't
> put out a call for help.
Every time somebody has suggested this I've said that I would gladly
accept help. It would be one of the most valuable contributions that
anybody could make to Bugzilla. I think that the last time somebody
suggested it was before you were on the list, though, or it's possible
that the discussions happened on IRC.
So yes, if you want to do this, it would be totally awesome, and I will
help review it and talk about how it should be done.
> - A commitment to a Windows installer, and the general treatment of a
> Windows installation as "just as important as another platform".
In fact, we'd be making a commitment to Windows, in this case, as being
*more* important than other platforms. We don't provide distro packages
for any other OS.
> You
> can't make a release and then say the release is waiting for one
> person to create an installer.
If you think that you could get me an MSI simultaneously with every
Bugzilla release, then I'd be happy to commit to it. Alternately, the
Windows installer could come a few days after the release, and I would
post it then.
> Basically, the Bugzilla Project needs to show it *wants* to be part of
> the Windows community before the Windows community can be expected to
> want to be part of the Bugzilla community.
I'm extremely interested in contributions from Windows developers--I
think that Windows may be the most popular platform to install Bugzilla on.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Michael Thomas
apache, perl, etc..) and Custom Install (pick and choose)
So yes, I would expect those options to some extent or another, either
prompting for their existance and give instructions or to simple do
the install.
On Tue, Feb 16, 2010 at 4:48 PM, Joel Peshkin <bugr...@peshkin.net> wrote:
>
> The part that hangs me up here is what do we expect a Windows installer to
> do? Does it need to install Apache and Mysql and ActivState Perl? Or does
> it presume certain things were previously set up before it is run.
>
> Would it be reasonable to provide an installer that does the following....
>
> 1) Checks for perl ... if no Perl ... pop up instructions to install Perl
> first and quit
> 2) Check for perl modules, if modules are missing, ask PPM to install them.
> 3) Prompt the user for Mysql connection information. Test the connection,
> if it doesn't work, pop up instructions to install/configure MySQL
> 4) Offer to start a perl-based Webserver for Bugzilla.
>
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=mock...@gmail.com>
Max Kanat-Alexander
>> [..] If we bundled MySQL also, we could build a DBD::mysql
>
> we can't bundle mysql because bugzilla isn't gpl.
Hmm, is that actually true? I mean, we can't include it in the same
installer as a non-GPL program? I think that would prevent distros from
shipping both GPL and non-GPL software on the same medium, which isn't
prohibited.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Byron Jones
>>> [..] If we bundled MySQL also, we could build a DBD::mysql
>>
>> we can't bundle mysql because bugzilla isn't gpl.
>
> Hmm, is that actually true? I mean, we can't include it in the same
> installer as a non-GPL program? I think that would prevent distros from
> shipping both GPL and non-GPL software on the same medium, which isn't
> prohibited.
when i was looking at building a windows installer for bugzilla i emailed
mysql for clarification. the response was that unless the open source
product is licensed as gpl, you're not able to bundle mysql in your
installer. this was several years ago however.
http://www.mysql.com/about/legal/licensing/index.html
i suspect they have different licensing terms for distros vs open-source
projects.
--
byron.jones :: http://glob.com.au
Max Kanat-Alexander
> when i was looking at building a windows installer for bugzilla i emailed
> mysql for clarification. the response was that unless the open source
> product is licensed as gpl, you're not able to bundle mysql in your
> installer. this was several years ago however.
>
> http://www.mysql.com/about/legal/licensing/index.html
>
> i suspect they have different licensing terms for distros vs open-source
> projects.
Ohh, no, actually, distros used to have the same problem, I remember
this now! I thought that the FOSS Exception was supposed to resolve this:
http://www.mysql.com/about/legal/licensing/foss-exception/
Except that it appears that it only applies to the client libraries.
However, this item in the FSF FAQ:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLCompatInstaller
Particularly "the installer and the files it installs are separate
works" would be enough for me to suspect that Bugzilla and MySQL, though
both being installed by the same installer, would be considered separate
works. Otherwise no distro could ship GPL'ed software that was installed
by its installer along with GPL-incompatible software (which, I believe,
every distro does).
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Frédéric Buclin
> Would it be reasonable to provide an installer that does the following....
>
> 1) Checks for perl ... if no Perl ... pop up instructions to install
> Perl first and quit
> 2) Check for perl modules, if modules are missing, ask PPM to install them.
> 3) Prompt the user for Mysql connection information. Test the
> connection, if it doesn't work, pop up instructions to install/configure
> MySQL
> 4) Offer to start a perl-based Webserver for Bugzilla.
I filed a bug 6 months ago on my local Bugzilla about creating an
installer for Windows. Then I had no time to look at it in greater
details, so I still have no idea whether it's relatively simple or not
to build. When I filed my bug, I had three ideas in mind:
- NSIS
- Inno Setup
- Perl::Win32::GUI on Win32 and Gtk2 on Linux.
Then it seemed to me that NSIS was more powerful than Inno Setup.
I don't think we need to update our installer for each new release. What
I had in mind was to combine the current Bugzilla tarball with the
installer in a single NSIS executable, and the executable would untar
the Bugzilla tarball, then do what Joel proposed:
1) Check for Perl. If no Perl installed, suggest to install it (with a
URL to the download page of ActivePerl). We should only point to the
download page rather than to a specific Perl version so that we always
point to the more recent ActivePerl release.
2) Check for Perl modules, and call PPM itself if needed to install
missing modules.
3) If the MySQL is not running, offer to download it, and offer a URL to
the MySQL download page, again to always point to the more recent release.
4) Same for Apache.
So the installer wouldn't need to be updated as it wouldn't include any
specific software with it. It would simply point to the download pages
of MySQL, Apache and ActivePerl when they are missing.
I don't know if NSIS can do it. Else I don't know how MSI works, but I
would be happy to try. I would just need some free time and why not
someone with some experience with MSI to help. :)
LpSolit
Jean-Marc Desperrier
> I absolutely care about whether or not it's easy to
> install. It's currently far easier to install on *nix than it is on
> Windows, though, and that's something that I want to fix.
OK, I need to check again under *nix.
- I hope it's now, as much as possible, *obvious* that ImageMagick only
brings a really minor functionality, so that people know that if they
have some problem with it, it's no use spending time solving them
- that the "Just tell me what to install to get everything" option is
clearly documented and the default, in all the doc and not just in some
parts of it
- that the "Just tell me what to install to get everything" option in
fact does *not* really get everything, and instead in the first steps
leads to choosing the db format used, instead of by default leading you
to install everything for every supported db format
Frédéric Buclin
> - I hope it's now, as much as possible, *obvious* that ImageMagick only
> brings a really minor functionality
ImageMagick has been removed from Bugzilla 3.6. I moved it into an
extension.
LpSolit
Dan Wierenga
>
> when i was looking at building a windows installer for bugzilla i emailed
> mysql for clarification. the response was that unless the open source
> product is licensed as gpl, you're not able to bundle mysql in your
> installer. this was several years ago however.
Ok, fine. MySQL has issues. However, PostgreSQL is released under a
MIT/BSD style license.
The idea of a Windows installer isn't to give the full-fledged
spectrum of choices to the naive Windows user. The idea is to give
them SOMETHING that's fully supported by the Bugzilla Project, and
give it to them in an easy to install clickable package.
So, the installer gives them Apache, and PostgreSQL, and
ActiveState/Strawberry Perl as well. Those who truly need the
installer won't care what DB or webserver they use, those who like the
installer probably won't either, and those who are technically savvy
enough to not need and not like the installer can configure things
manually.
Sure, it'd be nice if the installer grew to something that offered the
full array of choices (assuming licensing can be worked out in the
future). But seriously... baby steps! Let's get SOMETHING working
before we try to get everything working.
Jean-Marc Desperrier
> Le 17. 02. 10 14:21, Jean-Marc Desperrier a �crit :
>> - I hope it's now, as much as possible, *obvious* that ImageMagick only
>> brings a really minor functionality
>
> ImageMagick has been removed from Bugzilla 3.6. I moved it into an
> extension.
That's a good thing !
Gervase Markham
> On Ubuntu I can just type
>
> $ sudo aptitude install bugzilla3
>
> but I have not tried it yet so I am not sure what will be the end result.
As Max says, the price of that is that Debian rearrange our stuff to
conform to their file system standard, and things have a tendency to
break. :-(
Gerv
Gervase Markham
> At my company, that's one of the reason we're not using it. Not the only
> reason, there's also the fact it had from start the image of being ugly
> looking and complex
This is another complexity penalty we pay, even before people get it
installed and try to use it. Having 20 or more fields on the default
show_bug page scares people away.
> (and based on perl I have to say, but if all the
> rest had been right ...) , but when the person in charge of having a go
> at all the tools tried to install it, failed, spent more time trying,
> failed again, then ended the report with "I couldn't install it", when
> he had had success installing most of the other tools in minutes, it was
> the final nail in the coffin.
It doesn't help that our install documentation is hard to follow due to
layout limitations caused by our technical solution, and that's hard to
fix because the technical solution also makes refactoring it hard. (And
because it's compiled, we review it like code rather than like
documentation - or, at least, we used to last time I tried to refactor it.)
All of these little bumps in the road add up. If people can just install
trac using a single command, many people will just be happy with that.
Gerv
Gervase Markham
> You can't--it depends on the version of MySQL in use. (It might also
> depend on the Windows version in use? I'm not sure. I suspect 32-bit vs.
> 64-bit would be an issue, but Perl is already compiled differently for
> those, so that's not a problem.) If we bundled MySQL also, we could
> build a DBD::mysql. But then if people wanted to use PostgreSQL, they'd
> have a hard time.
If people want to choose particular database software, then this sort of
bundle isn't for them anyway.
I suspect at least 90%, and maybe even 95% of people installing Bugzilla
don't give a stuff which database it uses, they just want it to work. I
myself certainly didn't care when I started hacking on Bugzilla that it
used MySQL as opposed to PostgreSQL. I still use MySQL out of habit, but
it doesn't matter to me.
Gerv
Gervase Markham
> Hi Max (noticably, not to the list),
There wasn't anything in this email that wasn't list-appropriate. It was
fine to post it (even if it was accidental).
Gerv
Byron Jones
> don't give a stuff which database it uses, they just want it to work. I
> myself certainly didn't care when I started hacking on Bugzilla that it
> used MySQL as opposed to PostgreSQL. I still use MySQL out of habit, but
> it doesn't matter to me.
i agree that most users won't care about the bundled database, however
there will be a significant impact on support.
as we are currently most familiar with mysql, it would make sense to try
getting mysql as the bundled database first.
--
byron.jones :: http://glob.com.au