New language discussion?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New language discussion?

"Andrés G. Aragoneses"
Can someone tell the latest state-of-affairs from the recent(?)
languages discussion to be used in Bugzilla in the future?

I proposed a big section about Mono on the discussion page, but I think
there has been no more news about this (neither anyone has updated the
"official" part page to include the Mono section).

Regards,

        Andrés [ knocte ]

--
P.S.: In case anyone asks, I am talking about this:
http://wiki.mozilla.org/Bugzilla_Talk:Languages
_______________________________________________
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: New language discussion?

Max Kanat-Alexander
On Thu, 25 Oct 2007 19:32:11 +0200 "Andrés G. Aragoneses"
<[hidden email]> wrote:
> Can someone tell the latest state-of-affairs from the recent(?)
> languages discussion to be used in Bugzilla in the future?

        We decided that we don't have the manpower to split the team
between a re-write and continuing maintenance of the current Bugzilla.

> I proposed a big section about Mono on the discussion page, but I
> think there has been no more news about this (neither anyone has
> updated the "official" part page to include the Mono section).

        I don't know C#, but that doesn't mean it wouldn't be a
reasonable contender. However, I think we were generally against
strongly-typed languages.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And 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: New language discussion?

"Andrés G. Aragoneses"
In reply to this post by "Andrés G. Aragoneses"
Max Kanat-Alexander escribió:

> On Thu, 25 Oct 2007 19:32:11 +0200 "Andrés G. Aragoneses"
> <[hidden email]> wrote:
>> Can someone tell the latest state-of-affairs from the recent(?)
>> languages discussion to be used in Bugzilla in the future?
>
> We decided that we don't have the manpower to split the team
> between a re-write and continuing maintenance of the current Bugzilla.
>
>> I proposed a big section about Mono on the discussion page, but I
>> think there has been no more news about this (neither anyone has
>> updated the "official" part page to include the Mono section).
>
> I don't know C#, but that doesn't mean it wouldn't be a
> reasonable contender. However, I think we were generally against
> strongly-typed languages.

Hey, but I proposed Mono. With that, we could write things in
IronPython, IronRuby... and have good stuff from contributors like C#,
all languages interacting together.

Well, I hope this gets discussed again.

Regards,

        Andrés [ knocte ]

--
_______________________________________________
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=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: New language discussion?

Arthur Barrett
In reply to this post by "Andrés G. Aragoneses"
Max et al,

Sorry 'bout the cross post - but since the original post was across both
newsgroups...

> > Can someone tell the latest state-of-affairs from the recent(?)
> > languages discussion to be used in Bugzilla in the future?
>
> We decided that we don't have the manpower to split the team
> between a re-write and continuing maintenance of the current Bugzilla.

I work for March Hare Software who are the primary contributors to the
multi-platform open source CVSNT project as well as providing commercial
versions and support. For our commercial products we have supported and
integrated with Bugzilla for some time.  

We are currently working on a re-write of Bugzilla in C++ as a part of
the EVS project (www.evscm.org) which is designed as a platform for CM
systems rather than a version control tool.  At the moment this is all
happening closed source and behind doors though we are/will be releasing
"free" preview versions.  

It has not been decided what components of evscm will be "free", what
will be "open source" and what will be "commercially licensed" at the
end of the project.  If I evidence to support the notion that a number
of people in the community would help in the
development/testing/documenting of a C++ implementation of Bugzilla then
it'd help the argument that we should make it open source.  But while we
remain the only people working on it all options will be kept open.

The next preview release will be (hopefully) later this week and that'll
be the first release with the bugzilla engine in it.  That preview uses
the Bugzilla 2.18/2.20 data model with mysql though the intention is to
then switch to the 3.x data model and mysql/mssql/oracle.  Please
subscribe to the evs-support newsgroup (details at evscm.org) to get the
announcements and to contribute.

Note: whilst evs is multi platform - due to resource shortages we've had
to recently abandon all builds except the windows one, so this is a
windows-only effort until at least release 1, then we intend going back
to resurrect the unix/linux version.  However others outside of March
Hare have already started picking up the slack and build the previous
EVS preview for Debian.

Regards,


Arthur Barrett
Product Manager
March Hare Software





-
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: New language discussion?

Olav Vitters
On Tue, Oct 30, 2007 at 11:07:00AM +1100, Arthur Barrett wrote:

> We are currently working on a re-write of Bugzilla in C++ as a part of
> the EVS project (www.evscm.org) which is designed as a platform for CM
> systems rather than a version control tool.  At the moment this is all
> happening closed source and behind doors though we are/will be releasing
> "free" preview versions.  
>
> It has not been decided what components of evscm will be "free", what
> will be "open source" and what will be "commercially licensed" at the
> end of the project.  If I evidence to support the notion that a number
> of people in the community would help in the

Sorry.. I don't contribute to non-open source software (in my spare
time). Further, my C++ is non-existing and I have no intention to learn
it. So for me I don't think I'd ever contribute.

Won't C++ hurt where this can be installed upon? PHP seems easiest, then
in a distance (IMO) Perl, etc. C++ would require a compiler, which seems
even more restricted.

> development/testing/documenting of a C++ implementation of Bugzilla then
> it'd help the argument that we should make it open source.  But while we
> remain the only people working on it all options will be kept open.

Is the intention to stay compatible with Bugzilla?

> The next preview release will be (hopefully) later this week and that'll
> be the first release with the bugzilla engine in it.  That preview uses
> the Bugzilla 2.18/2.20 data model with mysql though the intention is to
> then switch to the 3.x data model and mysql/mssql/oracle.  Please
> subscribe to the evs-support newsgroup (details at evscm.org) to get the
> announcements and to contribute.
>
> Note: whilst evs is multi platform - due to resource shortages we've had
> to recently abandon all builds except the windows one, so this is a

Many Bugzilla devs use Linux exclusively AFAIK. So Windows only will
delay things.

> windows-only effort until at least release 1, then we intend going back
> to resurrect the unix/linux version.  However others outside of March
> Hare have already started picking up the slack and build the previous
> EVS preview for Debian.



--
Regards,
Olav
-
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: New language discussion?

Jochen Wiedmann
In reply to this post by Arthur Barrett
On 10/30/07, Arthur Barrett <[hidden email]> wrote:

> We are currently working on a re-write of Bugzilla in C++ as a part of
> the EVS project (www.evscm.org) which is designed as a platform for CM
> systems rather than a version control tool.

Of all the programming languages, my top priority of least usability
for a Bugzilla-like project would be: 1.) Assembler, 2.) C, 3.) C++

I am sure that choice of programming language was made due to the
programmers knowledge and not with regard to the suitability for a web
platform.

Jochen

--
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)
-
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: New language discussion?

Benton, Kevin
> > We are currently working on a re-write of Bugzilla in C++
> as a part of
> > the EVS project (www.evscm.org) which is designed as a
> platform for CM
> > systems rather than a version control tool.
>
> Of all the programming languages, my top priority of least usability
> for a Bugzilla-like project would be: 1.) Assembler, 2.) C, 3.) C++
>
> I am sure that choice of programming language was made due to the
> programmers knowledge and not with regard to the suitability for a web
> platform.

IMNSHO, the question of "do we move to a new language or keep moving
forward with what we have?" has been asked over and over.  The rub is
this: what does moving to a new language give us that we don't already
have and the corrolary, what is the return on investment if we move and
how will we be able to move faster because of the work done to move?
It's easy to argue that we like language x better than language y, but
that doesn't matter.  We have a working application in Perl today.  We
need to ask the hard questions in order to determine if the benefits
outweigh the risks, if the change will prove itself useful in a timely
manner, and if the change is made, at what point do we pull the plug on
changing if it hasn't happened "fast enough".

A much less preferred option is to encourage those that want to work on
the "new" language to do so on their own project.  This would further
split the resources to make Bugzilla into what it can be while it's
pulling resources away to a "new" project based on the old.  XEmacs and
Emacs have both had this issue in the past with gains and losses seen on
both sides.  In my view, I think both sides lost because development was
split and in some ways, has lost the benefit of the synergy between the
teams.  On the other hand, both sides won because each agreed to
disagree and go their own separate ways.  Users were given a choice on
which environment they preferred.  The drawback was that some wanted to
pick and choose feature sets from both but couldn't because the
development had diverged.  In my view, the result was a net loss.

As we all know, Bugzilla is implemented in Perl and the codebase is
getting better as we move to a more object-oriented model where
persistence is done at the proper layers.  There's a lot of work to be
done, but no matter what language is chosen, it's possible to wind up
with the same problems we have today if we don't change the standards by
which we code.  So, I suggest that we look at the real issue - how do we
design our code so that it doesn't look and feel like procedural
spaghetti?  Having SQL in the CGI, for example is a great example of why
you don't want to repeat yourself again (:-).  Moving the SQL into
modules that deal directly with the database (DAO) makes the most sense
to me because then, there is only one place to maintain with regard to
the back-end and it's easy to change out if needed.  This work is
already in-progress.  Another problem we've seen is the CGI will call
the same subroutine directly and indirectly a number of times to get the
same answer back each time.  This too is getting better, but it's got a
long way to go.

We're (AMD) actively working on a radical shift in the way that "custom"
fields are being done by providing a field scheme model of implementing
"custom" fields.  We prefer to call those "custom" fields "add-on"
fields rather than custom.  Once the code support them, then they truly
will be add-on fields.  While we're doing field schemes that allow
administrators to select what fields are available by product, we're
also developing workflow schemes in the same methodology so that each
product can have its own workflow.  There are many different workflow
needs within our company based on the type of work being done.  Some
processes have an extra documentation step, some have an extra
incorporation step, and there are many others.  Not all products need
the extra steps so workflow schemes will allow us to assign those
workflows on a per-product basis.

Frankly, our number one concern with contributing code back to the
community is the length of time it takes to go from contribution to
approval in combination with the risk that our change set(s) won't be
accepted by the community.  We're moving at the speed of business
requirements here and unfortunately, it's very challenging for us to
remain in sync with what the community is doing versus what our internal
needs are.  It's a lot of work for us to stay in sync with the tip and
do our own development with the risk that a patch we submit may not be
accepted by the community.  There are a number of things (like the
schemes discussed above) we need that really should be implemented
within Bugzilla core, but we need them before the community will be
ready to accept those changes (meaning more work for us to keep our
changes "up-to-date" while the community catches up with us).  Our
business requirements state that our field and workflow schemes must be
completed before the new year, yet, knowing that, there is no way we can
rely on the community to accept those changes into the trunk so we don't
have another issue with forking our code.  We've had internal
discussions that we'd be glad to contribute both code and test cases
(and Selenium tests to run those test cases) to prove out our
submissions, however, we've also seen resistance to our methods of
making changes because we need to package things in chunks that we feel
reviewers can review and approvers can approve.  That burns a lot of
time up because we can't insert forward-looking code in a patch moving
bugs.versions to bugs.version_id.  We're trying to get to a point where
all the _id fields are dealt with in a uniform fashion so that custom
fields become less custom and more add-on.

I won't begin to hide that we have an agenda as a corporate customer and
contributor.  Yes, we'd like to help when helping moves us in a
direction that makes sense for our company.  I'm certain that there are
other companies out there that would do the same.  The challenge is, how
do we contribute in a way that is meaningful for the community while it
doesn't hog-tie us.  AMD spends significant amount of money each year
for Bugzilla development.  AMD would love to see some ROI on that
development by seeing some of that code contributed back to the core so
that as Bugzilla features are added, incorporating those back into our
code base is less of a "how much effort will it take to incorporate
that?" to "are we ready to upgrade again?"

I could go on but I'll stop here for now.


---
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.


-
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: New language discussion?

Gervase Markham
Benton, Kevin wrote:
> As we all know, Bugzilla is implemented in Perl and the codebase is
> getting better as we move to a more object-oriented model where
> persistence is done at the proper layers.

Indeed. Several years, ago, we asked the same question - rewrite or
incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't happen; Myk
argued for incrementally fixing, and the code now is much better than it
was. It seems to me that the arguments now are even more in favour of
incremental improvement than they were then.

> There's a lot of work to be
> done, but no matter what language is chosen, it's possible to wind up
> with the same problems we have today if we don't change the standards by
> which we code.  So, I suggest that we look at the real issue - how do we
> design our code so that it doesn't look and feel like procedural
> spaghetti?  Having SQL in the CGI, for example is a great example of why
> you don't want to repeat yourself again (:-).  Moving the SQL into
> modules that deal directly with the database (DAO) makes the most sense
> to me because then, there is only one place to maintain with regard to
> the back-end and it's easy to change out if needed.

You see, five years ago, people weren't doing this - or it wasn't nearly
as well known as best practice. Bugzilla is improving all the time as
people's understanding of how to write web apps improves, and that can
only be a good thing. But we'll never be perfect, because perfect is
always changing.

> We're (AMD) actively working on a radical shift in the way that "custom"
> fields are being done by providing a field scheme model of implementing
> "custom" fields.  We prefer to call those "custom" fields "add-on"
> fields rather than custom.

How do they compare to the various other ways of implementing custom
fields that were proposed when we originally did them?

> Frankly, our number one concern with contributing code back to the
> community is the length of time it takes to go from contribution to
> approval in combination with the risk that our change set(s) won't be
> accepted by the community.

Contributing has concerns; forking has other concerns (like increased
maintenance). You have to do what is right for you and your business.
That's fair enough.

> however, we've also seen resistance to our methods of
> making changes because we need to package things in chunks that we feel
> reviewers can review and approvers can approve.

Do you really think this is unreasonable?

It's always the case that one guy working on his own with complete
freedom can work faster than when he's using a team process with checks
and balances. It's one of the downsides of collaboration which have to
be measured against the upsides of (hopefully) increased code quality
and more future-proof design, etc.

Gerv
-
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: New language discussion?

Jean-Marc Desperrier
In reply to this post by "Andrés G. Aragoneses"
Andrés G. Aragoneses wrote:
> Hey, but I proposed Mono. With that, we could write things in
> IronPython, IronRuby... and have good stuff from contributors like C#,
> all languages interacting together.

As well as javascript ( http://www.mono-project.com/JScript ) and perl !
(though PerlNet).


_______________________________________________
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=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: New language discussion?

Jean-Marc Desperrier
In reply to this post by Jochen Wiedmann
Benton, Kevin wrote:

> We're (AMD) actively working on a radical shift in the way that "custom"
> fields are being done by providing a field scheme model of implementing
> "custom" fields.  We prefer to call those "custom" fields "add-on"
> fields rather than custom.  Once the code support them, then they truly
> will be add-on fields.  While we're doing field schemes that allow
> administrators to select what fields are available by product, we're
> also developing workflow schemes in the same methodology so that each
> product can have its own workflow.  There are many different workflow
> needs within our company based on the type of work being done.  Some
> processes have an extra documentation step, some have an extra
> incorporation step, and there are many others.  Not all products need
> the extra steps so workflow schemes will allow us to assign those
> workflows on a per-product basis.

I think this is great work, and it's too bad it ends up behind closed
doors only because of the difficulty to integrate it.

I think you would render a great service to everybody by providing it as
a fork.

fork is an ugly word, but the truth is you already have that fork, and
in addition to being a fork, nobody can see it. So it would be a
positive move to make it a public fork instead of a private one.

Then, there would be a chance that someone else does the ugly work
needed to integrate it, or at least that bugzilla gets some of it's most
interesting/easy to integrate elements.

_______________________________________________
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: New language discussion?

"Andrés G. Aragoneses"
In reply to this post by Jean-Marc Desperrier
Jean-Marc Desperrier escribió:
> Andrés G. Aragoneses wrote:
>> Hey, but I proposed Mono. With that, we could write things in
>> IronPython, IronRuby... and have good stuff from contributors like C#,
>> all languages interacting together.
>
> As well as javascript ( http://www.mono-project.com/JScript ) and perl !
> (though PerlNet).

Interesting! Can you update the wiki with this info on the Mono section?

Regards,

        Andrés [ knocte ]

--

_______________________________________________
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=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: New language discussion?

John P. Fisher
In reply to this post by Gervase Markham
excuse me for butting in here, as a non-contributor to the public code
base. I have a bugzilla installation so modified and hacked that I gave
up on updates and just forked it. This discussion sounds very
professional and sensible, and illustrates, IMO, what happens with code
bases that become large and mature. You guys are all smarter than I, so
I won't pretend to any solution inside the main tree of bugzilla code.

I'd like some feedback, on my future plans for our bugzilla. We are a
small commercial software outfit ( linux - C ) with no IT department (
thank goodness). Our bug base has about 5000 bugs in the main product.
We are in the telephony-aerospace biz, so customers require separate
code trees sometimes, and years of support for any release. So we have
features like branches and cloned bugs and version-fixed-in to
accommodate. We don't use any of the whiteboard-time-tracking stuff, and
I have lost track of the current feature set ( since I can't use it anymore)

gab gab gab anyway, I just can't see going forward with perl for a
web-based app that needs custom fields and life-cycle changes. So I
looked around and PHP is very well supported, but Ruby has a far better
object orientation and database support, so it looks to me like a
re-write in Ruby would give the best results. In reading this thread, I
am a little puzzled that it wasn't considered- perhaps I just missed the
conversation?

thanks for any comment

John Fisher

Gervase Markham wrote:

> Benton, Kevin wrote:
>> As we all know, Bugzilla is implemented in Perl and the codebase is
>> getting better as we move to a more object-oriented model where
>> persistence is done at the proper layers.
>
> Indeed. Several years, ago, we asked the same question - rewrite or
> incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't happen; Myk
> argued for incrementally fixing, and the code now is much better than
> it was. It seems to me that the arguments now are even more in favour
> of incremental improvement than they were then.
>
>> There's a lot of work to be
>> done, but no matter what language is chosen, it's possible to wind up
>> with the same problems we have today
>
-
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: New language discussion?

Max Kanat-Alexander
In reply to this post by Arthur Barrett
On Tue, 30 Oct 2007 11:07:00 +1100 "Arthur Barrett"
<[hidden email]> wrote:
> We are currently working on a re-write of Bugzilla in C++ as a part of
> the EVS project

        I think we're all honored that you like Bugzilla enough to use
it as a base for your own project. However, I think a re-write,
particularly in C++ is an unwise move. Here's why:

        1. C++ is a much less flexible language than Perl, requiring
much more work to create a successful cross-platform application.

        2. C++ is rarely used for writing web applications nowadays.

        3. For the type of performance that Bugzilla users require,
the performance advantage is irrelevant, particularly with mod_perl
support in Bugzilla 3.0.

        4. Re-writing Bugzilla (particularly without consulting with us
or offering to contribute to Bugzilla itself) assumes that you know
just as much as we do, or more, about:

        * The history of bugs that people have encountered in Bugzilla.
        * The general needs of Bugzilla users.
        * The architecture and design of a bug-tracking system.

        5. You're going to experience the Second System Effect quite
intensely, particularly using C++, and particularly if you're basing
your efforts on the code base of older versions of Bugzilla.

        Please also keep in mind that "Bugzilla" is a trademark of the
Mozilla Foundation and that you can not use it in the name of your
product, or to advertise your product.

        I'm actually quite unaware what advantage you gain by
re-writing Bugzilla in C++. It would probably take less time for your
developers to become proficient in Perl than it would take to re-write
all of Bugzilla in a strongly-typed, compiled language.

        -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: Bugzilla Contribution Process (was RE: New language discussion?)

Benton, Kevin
In reply to this post by Gervase Markham
All,

I hope that this discussion helps make others aware of some of the
challenges that more than one business is facing with contributing code
(sponsored code) back to the community - and if possible, that we can
work together to find ways to see more sponsored code make it into the
community releases.  That *is* my goal in this topic.

> Benton, Kevin wrote:
> > As we all know, Bugzilla is implemented in Perl and the codebase is
> > getting better as we move to a more object-oriented model where
> > persistence is done at the proper layers.
>
> Indeed. Several years, ago, we asked the same question - rewrite or
> incrementally fix? The rewrite, Hixie's Bugzilla 3, didn't
> happen; Myk
> argued for incrementally fixing, and the code now is much
> better than it
> was. It seems to me that the arguments now are even more in favour of
> incremental improvement than they were then.

If you had asked us how we felt when evaluating this question against
2.20rc1, our answer would have been fork or re-write (it wound up being
fork at the time).  Knowing then what I know now, I may have made a
decision to switch tools.  Today, however, the code is *much* better
than it was and we're more likely to stick with what is already out
there.

> > There's a lot of work to be
> > done, but no matter what language is chosen, it's possible
> to wind up
> > with the same problems we have today if we don't change the
> standards by
> > which we code.  So, I suggest that we look at the real
> issue - how do we
> > design our code so that it doesn't look and feel like procedural
> > spaghetti?  Having SQL in the CGI, for example is a great
> example of why
> > you don't want to repeat yourself again (:-).  Moving the SQL into
> > modules that deal directly with the database (DAO) makes
> the most sense
> > to me because then, there is only one place to maintain
> with regard to
> > the back-end and it's easy to change out if needed.
>
> You see, five years ago, people weren't doing this - or it
> wasn't nearly
> as well known as best practice. Bugzilla is improving all the time as
> people's understanding of how to write web apps improves, and
> that can
> only be a good thing. But we'll never be perfect, because perfect is
> always changing.

We agree.  Best practices are getting better, though I don't know that
communicating those best practices is going as well as coding to them
is...  That may be because I haven't been looking for them in the right
places.  Max and others are doing a fantastic job of making the code
much more object oriented (not just having modules for the sake of
modules).  Hooks and the API are good things too...

> > We're (AMD) actively working on a radical shift in the way
> that "custom"
> > fields are being done by providing a field scheme model of
> implementing
> > "custom" fields.  We prefer to call those "custom" fields "add-on"
> > fields rather than custom.
>
> How do they compare to the various other ways of implementing custom
> fields that were proposed when we originally did them?

The "add-on" fields actually use a large part of the custom field code,
however, we're making sweeping changes so we utilize a small set of
routines to deal with field views and changes.  For example, we're
getting rid of is_(active|obsolete) and isobsolete, replacing each with
isactive, then updating the code so we don't have four different ways to
deal with whether or not a field or value is active or obsolete.  We're
also converting bugs columns to store ID's rather than values to enforce
referential integrity.  This makes it easier to maintain code because
all that's required afterward is to make sure that an insert or update
was successful.  Once we have a more unified way of dealing with fields
generically, then we can deal with field schemes.  Until then, we would
have far too many exceptions to deal with.

For those that don't know what field schemes are about, field schemes
determine what fields are displayed based on a bug's active product.
All values are stored in a bug regardless of field scheme, but this
allows product Foo to include all the default fields plus fields A and
B.  Product Bar doesn't care about field B, but cares about A and C, so
only A and C are displayed when Bar is the current product.  Field
schemes also set the list of available values on a per-scheme or
per-product basis depending on the scheme settings.  For example, field
schemes using "Bug Type" will share the same set of values regardless of
product, where field schemes using "First Rev Affected" will use a set
of values based on the product configuration (in the one-many and
many-many configurations).

Workflow schemes are similar to and build on field schemes.  Workflow
schemes affect more than just the available options of state changes.
Workflow schemes also specify when a field is required or not, when a
field gets cleared automatically, and who is allowed to make certain
changes.  So, when an approval must be made to release code, workflow
schemes allow for a list of individuals who can grant approval (as a
state, not a flag) before a bug can progress to the Incorporated state
(where the code is incorporated into a release).

For the purpose of searching, we've made some other improvements such as
adding a bug_values_cache table that stores a bug_id, and the values of
many-to-many relationships for each bug (such as the CC list members by
email and dependency relationships).  This makes it possible to display
columns of many-to-many relationship fields without expensive queries to
the database.  The downside is the very slight increase in time required
to create and update bugs where those fields are also involved.

We're also adding a description column to every table that doesn't
already have one for the purpose of improving the help system so it can
describe a table's values.  This provides guidance when users don't
understand when to use certain values versus others, especially when the
labels may not be clear enough.

> > Frankly, our number one concern with contributing code back to the
> > community is the length of time it takes to go from contribution to
> > approval in combination with the risk that our change
> set(s) won't be
> > accepted by the community.
>
> Contributing has concerns; forking has other concerns (like increased
> maintenance). You have to do what is right for you and your business.
> That's fair enough.
>
> > however, we've also seen resistance to our methods of
> > making changes because we need to package things in chunks
> that we feel
> > reviewers can review and approvers can approve.
>
> Do you really think this is unreasonable?

There are times when it seems reasonable, yet there are times when we
feel it's not.  There are times when we feel we just want to give back
but we don't have the resources to integrate.  There are other times
when a feature set is so invasive to the core of the community code and
so critical to our day-to-day development and operations that we're
willing to make the extra effort.  There are also times when we feel we
just can't wait for the community to review and approve what we're
doing.

> It's always the case that one guy working on his own with complete
> freedom can work faster than when he's using a team process
> with checks
> and balances. It's one of the downsides of collaboration
> which have to
> be measured against the upsides of (hopefully) increased code quality
> and more future-proof design, etc.

That's a given, and up to a point, there are times when it's worth the
effort.  The problem isn't just the size of the chunks, however.  It's
the extra effort that must be given to limit the scope of work in those
chunks.  The problem that corresponds with that, however, is do we wait
for the review / approval process to complete to move on to developing a
piece that builds on the chunk we just submitted for review, hoping that
it will be reviewed quickly and approved or, do we make the decision to
keep moving forward and backport any differences into our own code?  The
problem is that the review and approval process is a wildcard that we
have no control over.  Even though code may have completely passed our
own review and approval process, the community may inject its own
requirements that may or may not be compatible with our own.  That risk
is a real cost of doing business with open source communities and like
it or not, has a negative impact on schedules.

From our perspective, the challenge is deciding if/how to contribute and
when.  There are pieces we've added to Bugzilla that are intellectual
property that we will not contribute back to the community.  There are
other pieces that we've developed that we clearly want to see included,
yet will take significant effort because someone has to syncronize that
code with the current tip.  If the review takes long enough that someone
else's patch makes it into the tip before our review completes, then we
end up being asked to take the burden of merging the code again.
Granted, I would never ask the community to stop development just
because we want to contribute, but at the same time, our current review
process doesn't offer a way to protect contributors from excessive
amounts of merging due to lag between submission and review.  When we're
done with our field scheme and workflow scheme code, it's likely to be
thousands of lines each of implementation.  This is a prime example of
the risk versus reward situation.  With large patches, a lot of work
must be done to review, thus the likelihood of needing to merge
increases as well.  Are these features desired by the community?  There
is no question in my mind that in both cases, a resounding yes is
appropriate.  The problem on our end is that management is requiring
that we complete our work long before I think the review process can
complete from within the community.  Once we're "done" with our
implementation internally, managers want to see us continue to move
forward with the next series of changes as they come to us.  They don't
understand when we tell them we have to go back to update our code so
it'll work with the community when we've already moved beyond a feature
set.  It's an issue to explain that we're dealing with forward
compatibility with Bugzilla.

I hope that others don't get the idea that I'm complaining for the sake
of complaining about this.  I hope it'll help bring a bit more awareness
of some of the issues corporate contributors face when deciding do I
contribute or fork?  Unfortunately, I continue to get responses leading
me to believe that the answer often ends up being fork.  If there are
things that this community can do to help improve responsiveness by
helping corporate contributors what kind of things will help reviews get
done faster (such as submitting full sets of test cases and selenium
test code to go with the developed code), then I think you'll see more
sponsored contributions coming.  Otherwise, the risk of being stalled by
the review and approval process will remain high enough for many that
it's cheaper to fork than contribute and I think that's when we all
loose.

Kevin

---


Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.


-
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: Bugzilla Contribution Process (was RE: New language discussion?)

Max Kanat-Alexander
On Wed, 31 Oct 2007 11:46:41 -0700 "Benton, Kevin"
<[hidden email]> wrote:
> replacing
> each with isactive, then updating the code so we don't have four
> different ways to deal with whether or not a field or value is active
> or obsolete.

        The only reason Bugzilla currently works that way is that
isactive isn't used.

> field schemes [snip]

        I already have code that does this. It may even get into 3.2.

> For the purpose of searching, we've made some other improvements such
> as adding a bug_values_cache table that stores a bug_id, and the
> values of many-to-many relationships for each bug (such as the CC
> list members by email and dependency relationships).

        See, funny, because we're actually re-writing things to
eliminate those. :-

> We're also adding a description column to every table that doesn't
> already have one for the purpose of improving the help system so it
> can describe a table's values.

        The help system was already improved to allow for adding help
to any page. For us, we'd have to do this in a localizable way.

> [snip] There are also times when we
> feel we just can't wait for the community to review and approve what
> we're doing.

        And that's reasonable. That's one of the advantages of Open
Source code.

> There are other pieces that we've developed that we
> clearly want to see included, yet will take significant effort
> because someone has to syncronize that code with the current tip.
> [snip]

        In that case, I'd recommend hiring a contractor to help you out
with the process, somebody who's a core member of the Bugzilla team or
a proven Bugzilla contributor. You might think this is a subtle
self-advertisement, but it's not--there are many contractors, and I
really do think this is a great way to give back to the community and
also see your own goals realized.

> It's an issue to explain that we're dealing with forward
> compatibility with Bugzilla.

        I'd be happy to explain this to anybody who wants to talk about
it.

        I suspect that your managers don't understand the advantages of
open source? That is, *somebody else*, who *doesn't work at your
company*, is *also working on the code*. You get the work of many
people for free.

        The solid equation to look at, that any reasonable management
will accept, is how much code you're getting for free versus how much
work it takes you to synchronize with upstream. Given enough time,
upstream will always win, because there's more people working on it and
we're adding far more new features than one person possibly could.

> If there are things that this community can do to help improve
> responsiveness by helping corporate contributors what kind of things
> will help reviews get done faster (such as submitting full sets of
> test cases and selenium test code to go with the developed code),
> then I think you'll see more sponsored contributions coming.

        Unfortunately the problem isn't limited to corporate
contributions, or even large contributions. We simply need more
reviewers.

        Even with more reviewers, patches must be of a reviewable size.
I personally can edit down a patch to reasonable size at 2-3 hours
maximum. (Usually it takes far less time.) If you don't have 2-3 hours
to edit a patch, then you probably won't have time to revise the patch,
and as much as I'd like to be able to help, the solution to that problem
just logically doesn't lie with the Bugzilla Project.

        I often don't read or respond to very long posts, but I read
and responded to this one because the contribution process to Bugzilla
is extremely important to me. I have already worked to make it
easier and easier for new contributors to become known and contribute
their work to the Bugzilla Project. If anybody has some reasonable
ideas what can be done to further ease that process without relaxing
our code quality standards, do please let me know, either here or by
personal email.

        -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: New language discussion?

Aaron Trevena
In reply to this post by Max Kanat-Alexander
On 31/10/2007, Max Kanat-Alexander <[hidden email]> wrote:
> I think we're all honored that you like Bugzilla enough to use
> it as a base for your own project. However, I think a re-write,
> particularly in C++ is an unwise move. Here's why:

There are few things I agree with Max about when it comes to perl, but
he is spot on in what he says about porting to C++ (and much of it
applies to ruby or python).

>         4. Re-writing Bugzilla (particularly without consulting with us
> or offering to contribute to Bugzilla itself) assumes that you know
> just as much as we do, or more, about:
>
>         * The history of bugs that people have encountered in Bugzilla.
>         * The general needs of Bugzilla users.
>         * The architecture and design of a bug-tracking system.

I thought I knew bugzilla reasonably well after customising and
integrating it with an intranet in one job. Despite not liking or
agreeing with some of the design decisions I didn't have any problems
at all customising it to my needs, and this was a couple of years ago
and so without the benefit of recent refactoring, documentation or bug
fixes.

I thought I'd try porting it to a perl MVC framework, the first parts
were fairly simple, but Max's points about lack of domain knowledge
and the reasons behind many decisions were certainly true - if I
wanted it to be more than an interesting learning exersize it needed
to be useful to other people, and the bugzilla (and rt) developers
know more about that than me.

>         5. You're going to experience the Second System Effect quite
> intensely, particularly using C++, and particularly if you're basing
> your efforts on the code base of older versions of Bugzilla.

Even porting to an ORM and MVC application server I quickly found that
in remaining compatible I lost many benefits, and that if I wasn't
going to be fully compatible then I may as well spec out the project
and design from scratch, which is certainly more work than I really
wanted, particularly when there several perl bug / request tracking
systems that I can customise anyway.

>         I'm actually quite unaware what advantage you gain by
> re-writing Bugzilla in C++. It would probably take less time for your
> developers to become proficient in Perl than it would take to re-write
> all of Bugzilla in a strongly-typed, compiled language.

The same applies to pretty much any other language. I don't believe
you would get any noticable benefit in speed - in every web
application I've worked on perl has never been a bottleneck, query
optimisation, resource contention, and architecture of the database
schema, cluster and network all inevitable the bottlenecks in any such
system.

On the other hand, writing a first person shooter : C++ would probably
be my first choice

A.

--
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting
-
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: New language discussion?

Arthur Barrett
In reply to this post by "Andrés G. Aragoneses"
Hi All,

Thanks to all who have replied.  I'd like to address a couple of the
main Q's that everyone seems to be asking without replying to each post
separately.

1. Why C++?

It solves a particular business problem for us.  As a commercial
software vendor our interest is in what our customers can deploy easily
and (particularly for large customers) software that has as few
dependencies as possible.  We found this with our core open source CVSNT
as well - commercial customers do NOT want perl script triggers - they
want them in a DLL/.so.   If you've ever tried installing MySQL and Perl
on HPUX or Windows then you'd know why, or if you've ever dealt with
security audits...  We've had a lot of customers reject using our
Bugzilla integration because Bugzilla needs Perl (usually windows
customers) or the need to install MySQL (usually unix/linux customers
who want to keep an oracle only, or DB2 only shop - I know some progress
is being made in bugzilla towards database independance).

And yes - since CVSNT and EVS are both written in C++ we have lots of
C++ skills available to do this (and very few perl skills).

2. Why Windows as the first target.

Our customers when counted "by numbers" are split evenly across windows
and unix/linux however the biggest complaints that we have about
Bugzilla is from the windows customers.  I'd like to stress though that
CVSNT and EVS runs cross platform - it's just a project management
decision to kill the linux/unix builds until after release 1 to
concentrate resources.

3. Asking for help to write non-open source

This is/was NOT my intention.  What I am saying is that LOTS of our
(other) code is LGPL, and the bugzilla rewrite could be too IF I had
evidence to suggest that it would represent less work (ie: there are
people with time/skills clamouring to help but cannot/will not due to
the licnese).  Responses this far suggest that we are currently
following the best path in keeping development closed.

4. rewrite

I am not a fan of rewrites, and I'd only marginally call what we are
doing a rewrite.  Release 1 will not re-implement the full feature set
of bugzilla, but it will use the (latest) Bugzilla data model.  This
means that for people who want a bug tracking system that "can grow"
then they can start with ours that works "out of the box" and later
install the "full" Bugzilla on top.

Yes our next beta will use an old data model, but the intention is to
change that ASAP.  We'll most likely start with a VERY minor subset of
implemented functionality and let our customers decide which are the
"critical" missing features.

5. name

I'm not even sure if we have a name - the idea of EVS is it is a CM
system, rather than needing SCM+defect tracking+audit+build+etc etc,
it's just all in one.  I'm sure we'll market it as "data model
compatible with Bugzilla, but that doesn't infringe any trademark I
don't think.

6. if we did go open source...

Our main open source project is CVSNT, which was essentially a fork from
CVS.  One of the main things that drew people to CVSNT initially was
that the developers would accept almost any change and put it right into
the next build within a few days.  We still give out write access to our
repo very quickly... If we did go open source with this "rewrite", then
that would be the same.  I hate to see a company the size of AMD want to
contribute but not able to contribute due to the perception that the
open source management gets in the way.

7. bugzilla project

I personally think the bugzilla project is a great one - a true open
source success story.  I am hoping our work means more people adopt it
because our software is "an easy way to start" (see point 4 above).  As
I wrote earlier - we don't have much in the way of Perl expertise in
house, so contributing to a Perl based Bugzilla has never really been an
option for us.  On the up side -  by only supporting defect integration
to Bugzilla I know a lot of companies that have gone ahead with
Bugzilla...


Feel free to ask me any questions that you don't feel I've answered
adequately.

Regards,


Arthur Barrett

-
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: New language discussion?

Max Kanat-Alexander
On Thu, 1 Nov 2007 06:40:19 +1100 "Arthur Barrett"
<[hidden email]> wrote:
> It solves a particular business problem for us. [snip]

        Okay, this makes sense.

        For what it's worth, here's how I'd solve that problem and
still stay with Perl:

        1. Bugzilla could support SQLite, which would mean not having
to install MySQL.

        2. It's actually possible to compile perl apps to an .exe using
some applications. You could do this with every CGI. I have no idea if
it works with CGIs, but it couldn't hurt to try, I suppose. :-)

> I am not a fan of rewrites, and I'd only marginally call what we are
> doing a rewrite.  Release 1 will not re-implement the full feature set
> of bugzilla, but it will use the (latest) Bugzilla data model.  This
> means that for people who want a bug tracking system that "can grow"
> then they can start with ours that works "out of the box" and later
> install the "full" Bugzilla on top.

        Okay. So it's kind of like "mini-Bugzilla in a box". :-)

> I'm sure we'll market it as "data model
> compatible with Bugzilla, but that doesn't infringe any trademark I
> don't think.

        Yes, that is probably OK, although I'm not a trademark
authority for MoFo.

> Our main open source project is CVSNT, which was essentially a fork
> from CVS.  One of the main things that drew people to CVSNT initially
> was that the developers would accept almost any change and put it
> right into the next build within a few days.

        And the code hasn't gotten unmanageable? Perhaps CVS was
architected better than Bugzilla was architected some years ago.

> On the up side -  by only supporting defect
> integration to Bugzilla I know a lot of companies that have gone
> ahead with Bugzilla...

        Yeah, and we often point people at your software. :-) I know
that I'm certainly appreciative. :-)

        -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: New language discussion?

Arthur Barrett
In reply to this post by "Andrés G. Aragoneses"
Max,

> 1. Bugzilla could support SQLite, which would mean not having
> to install MySQL.

It's only single user though - which may work since Bugzilla is
stateless but could easily bite at 9a in the morning when everyone logs
in, or at 6p when everyone is finishing for the day - particularly when
integrated with CVSNT so checkin comments are going to the Bugzilla
db...  Its far more common though that "customers" request "will it work
with Oracle" though DB2 is also reasonably frequent...

>
> 2. It's actually possible to compile perl apps to an .exe using
> some applications. You could do this with every CGI. I have no idea if
> it works with CGIs, but it couldn't hurt to try, I suppose. :-)

I have seen this, but hadn't really connected the two.  I suspect that
since no one else has done it already it may be harder than it sounds -
and for now limiting the scope to a few functions and limited optios is
easier to deliver and test.  But it's an interesting option - thanks for
that suggestion.

>
> Okay. So it's kind of like "mini-Bugzilla in a box". :-)
>

Yes - though it has scope to grow based on demand - I guess I'd
eventually like to see 80% coverage of the top 80% used functions.

> And the code hasn't gotten unmanageable? Perhaps CVS was
> architected better than Bugzilla was architected some years ago.

We find that most peoples changes are fairly isolated - and they just
want "their change" added.  Giving write access to the repo means they
are more likely to stay up to date with the project later since their
change remains in there.  I am trying to encourage greater use of
"enable my feature with preference x".  Since 2.5.01 we've introduced
some very nice 3GL triggers that can do a lot more than the Perl ones
previously could - so that's a solution that's easily isolatable, but
usually peoples changes are in the core.

> Yeah, and we often point people at your software. :-) I know
> that I'm certainly appreciative. :-)

Always appreciated!

Regards,


Arthur Barrett
-
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: Bugzilla Contribution Process (was RE: New language discussion?)

Benton, Kevin
In reply to this post by Max Kanat-Alexander
> The only reason Bugzilla currently works that way is that
> isactive isn't used.

That's interesting.  Why have those fields then?

>
> > field schemes [snip]
>
> I already have code that does this. It may even get into 3.2.

This is one of the challenges of working with the open source community
in general.  With an in-house development team, we communicate to each
other on projects we're working on and nobody does anything "behind the
scenes" without communicating at least that it's being done to others
working on the project.  This is the first I've heard of anyone else
developing field schemes.  I haven't seen field schemes on a roadmap
indicating that work was even being considered.

> > For the purpose of searching, we've made some other
> improvements such
> > as adding a bug_values_cache table that stores a bug_id, and the
> > values of many-to-many relationships for each bug (such as the CC
> > list members by email and dependency relationships).
>
> See, funny, because we're actually re-writing things to
> eliminate those. :-

So are we for the purpose of general use, however, we need the
denormalization to keep large volume queries operating relatively
quickly.  Our expectation is to use triggers to update the
bug_values_cache table, though I know that doing it that way isn't
compatible with some of the databases Bugzilla supports currently (like
MySQL 4.1.x).  The speed decrease on the update end is worth the
dramatic speed increase on the search end.

> > We're also adding a description column to every table that doesn't
> > already have one for the purpose of improving the help system so it
> > can describe a table's values.
>
> The help system was already improved to allow for adding help
> to any page. For us, we'd have to do this in a localizable way.

The challenge from an administrative standpoint is anytime someone has
to touch a template in order to change help, that's seen as a code
change rather than a configuration change.  Maybe I'm out of date with
what is happening with the help system, but it's my understanding at
this point that changing help requires changing the template instead of
data in the database.  I hope I'm wrong. :-)

> > [snip] There are also times when we
> > feel we just can't wait for the community to review and approve what
> > we're doing.
>
> And that's reasonable. That's one of the advantages of Open
> Source code.

It's both an advantage and a disadvantage depending on perspective.  We
really want to contribute, but there is a real cost of contributing,
just like there's a cost to fork (loss of ability to easily incorporate
community updates).

> > There are other pieces that we've developed that we
> > clearly want to see included, yet will take significant effort
> > because someone has to syncronize that code with the current tip.
> > [snip]
>
> In that case, I'd recommend hiring a contractor to help you out
> with the process, somebody who's a core member of the Bugzilla team or
> a proven Bugzilla contributor. You might think this is a subtle
> self-advertisement, but it's not--there are many contractors, and I
> really do think this is a great way to give back to the community and
> also see your own goals realized.

I don't know how well that will fly with management - spend money to pay
a contractor to incorporate something we're giving away into the
community version...  Yes, I understand it has benefits, but I just
don't know if I can sell it.  It's a valid option to consider, however.
The question I will have to be able to answer in order to sell it is can
we justify the cost considering the cost of the fork versus remaining
much more in-sync...

> > It's an issue to explain that we're dealing with forward
> > compatibility with Bugzilla.
>
> I'd be happy to explain this to anybody who wants to talk about
> it.
>
> I suspect that your managers don't understand the advantages of
> open source? That is, *somebody else*, who *doesn't work at your
> company*, is *also working on the code*. You get the work of many
> people for free.

Max - I agree that we get "stuff" for free, but we also have to consider
the value we need versus the value we may get based on a time line we
have no way to drive.  Yes, open source is a great way to go when that
source meets basic needs.

> The solid equation to look at, that any reasonable management
> will accept, is how much code you're getting for free versus how much
> work it takes you to synchronize with upstream. Given enough time,
> upstream will always win, because there's more people working
> on it and
> we're adding far more new features than one person possibly could.

Yes, as long as upstream is going in the same direction as the needs of
the company, hence the reason for contributing back where appropriate or
forking if required (not preferred).

> > If there are things that this community can do to help improve
> > responsiveness by helping corporate contributors what kind of things
> > will help reviews get done faster (such as submitting full sets of
> > test cases and selenium test code to go with the developed code),
> > then I think you'll see more sponsored contributions coming.
>
> Unfortunately the problem isn't limited to corporate
> contributions, or even large contributions. We simply need more
> reviewers.

I agree with you with one addition - more *active* reviewers.  If I had
more time, I'd be doing more reviews myself.  When there's a feature I'm
interested in, I'm very likely to review.  I also do keep an eye on
documentation reviews.

> Even with more reviewers, patches must be of a reviewable size.
> I personally can edit down a patch to reasonable size at 2-3 hours
> maximum. (Usually it takes far less time.) If you don't have 2-3 hours
> to edit a patch, then you probably won't have time to revise
> the patch,
> and as much as I'd like to be able to help, the solution to
> that problem
> just logically doesn't lie with the Bugzilla Project.

I agree that having patches at a reviewable size is important to make
reviews go quickly.  From a purely business perspective, however, there
are times when justifying the extra time to get that code accepted is
difficult.  I understand, yes it does have benefits when accepted that
now the company doesn't have to maintain it any longer, however, at the
same time, there are no guarantees that a) it will be accepted, and b)
that the effort to make it acceptable is worth the risk to get it there.
This is especially true for large changes.

> I often don't read or respond to very long posts, but I read
> and responded to this one because the contribution process to Bugzilla
> is extremely important to me. I have already worked to make it
> easier and easier for new contributors to become known and contribute
> their work to the Bugzilla Project. If anybody has some reasonable
> ideas what can be done to further ease that process without relaxing
> our code quality standards, do please let me know, either here or by
> personal email.

Max - the work you've done to help Bugzilla move forward has been
greatly appreciated, not just by us here at AMD, but I'm sure by others
across many organizations.  The same is also appreciated of you on
Fedora.  Open source would loose out if you didn't participate.  Thanks
:-)

Kevin

---


Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO  80528
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.


-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
12