post FOSDEM

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
On 02/15/2010 03:59 AM, Colin Ogilvie wrote:
> 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.
> Surely that means the solution is to then:
>
> - 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
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
In reply to this post by Gervase Markham
On 02/15/2010 07:14 AM, Gervase Markham wrote:
> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Jean-Marc Desperrier
In reply to this post by Gervase Markham
Gabor Szabo wrote:
> 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.
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Joel Peshkin
Jean-Marc Desperrier wrote:

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

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Jean-Marc Desperrier
In reply to this post by Jean-Marc Desperrier
Joel Peshkin wrote:
> 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).
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
In reply to this post by Jean-Marc Desperrier
On 02/16/2010 09:43 AM, Jean-Marc Desperrier wrote:
> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Gabor Szabo
In reply to this post by Jean-Marc Desperrier
On Tue, Feb 16, 2010 at 9:18 PM, Jean-Marc Desperrier
<[hidden email]> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
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.

> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Dan Wierenga-2
On Tue, Feb 16, 2010 at 1:34 PM, Max Kanat-Alexander
<[hidden email]> 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?
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Gabor Szabo
On Tue, Feb 16, 2010 at 11:37 PM, Dan Wierenga <[hidden email]> wrote:

> On Tue, Feb 16, 2010 at 1:34 PM, Max Kanat-Alexander
> <[hidden email]> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
In reply to this post by Dan Wierenga-2
On 02/16/2010 01:37 PM, Dan Wierenga wrote:
> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
In reply to this post by Gabor Szabo
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?

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Dan Wierenga-2
In reply to this post by Max Kanat-Alexander
On Tue, Feb 16, 2010 at 2:31 PM, Max Kanat-Alexander
<[hidden email]> 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*.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Gabor Szabo
In reply to this post by Max Kanat-Alexander
On Wed, Feb 17, 2010 at 12:32 AM, Max Kanat-Alexander
<[hidden email]> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
On 02/16/2010 02:55 PM, Gabor Szabo wrote:
> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Max Kanat-Alexander
In reply to this post by Dan Wierenga-2
On 02/16/2010 02:46 PM, Dan Wierenga wrote:
> 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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Steve Wendt
In reply to this post by Dan Wierenga-2
On 2/16/2010 3:15 PM, Max Kanat-Alexander wrote:

>> 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...
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Byron Jones-4
In reply to this post by Max Kanat-Alexander

> [..] 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Dan Wierenga-2
In reply to this post by Max Kanat-Alexander
Hi Max (noticably, not to the list),

On Tue, Feb 16, 2010 at 3:15 PM, Max Kanat-Alexander
<[hidden email]> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: post FOSDEM

Dan Wierenga-2
I suppose I should double-check my recipient list when I'm typing an  
email that I'm excited about....  Ah well.



On Feb 16, 2010, at 4:38 PM, Dan Wierenga <[hidden email]> wrote:

> Hi Max (noticably, not to the list),
>
> On Tue, Feb 16, 2010 at 3:15 PM, Max Kanat-Alexander
> <[hidden email]> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
123