Re: Backwards development

Le 18. 11. 15 21:16, Denis Roy a écrit :
> Why does Mozilla do this backwards?  Wouldn't you want to improve the
> core project and have BMO (and everyone else) consume that?

As I understand it, several BMO extensions are very Mozilla-specific,
are based on some specific policies or have some hardcoded strings here
and there. This means that what matches Mozilla specific needs is not
necessarily what other Bugzilla maintainers would want for their
installation, which means extra work to implement new parameters or new
user preferences when they make sense. Also, hardcoded strings mean than
localizers couldn't translate them easily or at all, requiring extra
work to fix that. I guess some extensions also only work on Linux but
not on Windows, which upstream Bugzilla must also support. And finally,
BMO is currently based on Bugzilla 4.2 while current upstream version is
5.1 and so extra work would be required to port them from 4.2 to 5.1.

My understanding is that BMO maintainers do not want to waste their time
with these requirements and they prefer to customize their own
installation to spare several review cycles or endless discussions.


> Short story -- does the Bugzilla project want contributions, or is it
> relegated to being a code dump for Mozilla's bug tracker?

The Bugzilla project definitely wants contributions. One of the reasons
which causes review or implementation delays is that some of the
contributions are based on some older Bugzilla version, e.g. 4.2 or 4.4,
while the current master code is 5.1, and so the patch doesn't apply
cleanly. In some cases, it's trivial to fix conflicts and the reviewer
will very likely do it himself on checkin. In some other cases, the code
is different enough between 4.2 and 5.1 that the reviewer is not willing
to do the job himself, due to a lack of time or energy (some
contributions are not critical enough to waste hours fixing conflicts).
If the contributor has no interest in porting his patch to 5.1, then the
patch stays there for several months or years, till someone decides to
port it or rewrite it from scratch... or till the bug is finally closed
as worksforme or wontfix for some reason.

Another reason for the delays is that some contributors say that their
patches work, and do not see why they should waste their time fixing
them to meet our requirements. One example is a patch which duplicates
some existing code and is rejected because it would be better to
refactor the existing code to be able to reuse it in the patch, and the
contributor refuses to do this, probably due to a lack of time or interest.

When I started contributing 11 years ago, an informal policy was that
contributors had to fix their patches themselves, because it's their
contributions and it's a way to "become better to code" (or at least to
follow the guidelines). When I became an official reviewer 10 years ago,
I remember I once fixed the last few bits myself to avoid the
contributor to waste extra cycles, but I made him upset because the
final code was a bit different from his original contribution and he had
the feeling that I stole or heavily changed his contribution. I didn't
steal his contribution because he was listed as the original contributor
in the CVS commit message. But I admit I had to heavily refactor his
patch to make it pass our requirements. So my intention was to make
everybody to not waste their time (reviewing a huge patch also takes a
lot of time, and it's sometimes faster to fix it ourselves!). Since that
day, I stopped to do this. Now I let contributors waste cycles as it
seems some of them do not like to see someone else alter their patches,
even if the goal is to make development go faster. Oh, and one drawback
for a reviewer to heavily alter a patch himself is that he needs to find
another reviewer to review the new patch, and we all know how hard it is
to find another reviewer who is willing to do reviews these days.

<proposal>If the upstream Bugzilla team is really that small, then maybe
the requirement for them to ask for review should go away, so that they
are free to commit whatever code they want. But this would require an
hyperactive project leader to keep an eye on this. In fact, we did this
in the past already, when mkanat and I were both allowed to commit
patches without asking anyone for reviews, because we had a very good
understanding of the backend code and of the direction the project
wanted to go. We were terribly fast to implement new features and heavy
changes could be committed pretty quickly without having to wait for
months to get reviews.</proposal>


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+jYtjvyW6yDsg@public.gmane.org>