Moving Away From CVS: A Vote

[Max Kanat-Alexander]

        Okay, we've had this discussion before, but this time, we have to
actually do it. We've been on CVS for too long--we may be the only
remaining major Mozilla project still using CVS for primary development.
We're certainly the only major open source project that I know of and
interact with regularly that still uses CVS.

        The only reason that we haven't moved yet is that we have a conflict:

        * Bzr is known by the Bugzilla developers and is technically superior
to Hg in almost every way except scalability (and even that may be fixed
as of bzr 1.16).

        * Hg is supported by the Mozilla Corporation, has an extensive
infrastructure at Mozilla, and is already in use by Mozilla localizers.

        If you doubt that bzr is technically superior, here are a few points:

        * Compare the standard web interface to Hg (hgweb:
http://hg.mozilla.org/ ) to the standard web interface for bzr
(loggerhead: http://bzr.bugzilla.org/ ).

        * bzr has a *major* release nearly every month. (See the release notes:
http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html )
Mercurial's major releases are roughly 3 to 4 months apart (and there
were 9 months from 1.0 to 1.1).

        * bzr tracks directory renames as well as file renames, meaning that it
doesn't show hundreds of files being renamed if you rename a
directory--it only shows the directory name changing. (This also means
that bzr can show the existence of empty directories in its changeset
history, and Mercurial cannot.)

        * The commands used in bzr for a CVS-like workflow are *identical* to
the commands used in CVS, drastically lessening the learning curve for
users migrating from CVS.

        However, Hg is supported by the Mozilla Corporation and they already
have extensive infrastructure around it. Also, as Cedric has pointed out
in the past, localizers are already using Hg.

        To resolve the conflict, I am ***TAKING A VOTE***:

        * Respond to this email either publicly (if you want to make an
argument) or privately with your preference stated AT THE VERY TOP OF
THE EMAIL. Anybody who is currently contributing to the Bugzilla Project
or interacting with our CVS is eligible to vote. (If you are not a
current contributor, please state your interest when voting.)

        I will count all public and private votes, and we will move to
whichever VCS receives a simple majority (51%) of the received votes.
HOWEVER, if there is a clear consensus (75% or greater) among the
reviewers (and a significant number of reviewers vote--more than just 3
or 4), then there is a possibility we will just go with the reviewer
consensus, though the non-reviewer votes will also be taken into account.

        If you have any questions about the voting or about either VCS, feel
free to respond here publicly and I'd be happy to clarify.

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

[Max Kanat-Alexander]

        I am voting for bzr, because it would be difficult for me to accept the
more limited basic feature set and slightly awkward UI of Hg and hgweb,
after using bzr and loggerhead for a long time, and because we are
already using bzr for Bugzilla QA.

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

[Wurblzap]

bzr.

- I use bzr for bz de l10n
- bzr works really well on Win
- I'm told Hg is a pain on Win
- I've never used Hg

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

[Frédéric Buclin]

Le 05. 09. 09 00:28, Max Kanat-Alexander a écrit :
>     The only reason that we haven't moved yet is that we have a conflict:

You forgot quite a few other reasons:

* PatchReader (even with my patch applied) cannot display patches with
context=file.

* Neither Bonsai nor Tinderbox support bzr, AFAIK.


As a core developer, I cannot write nor review code without these tools.


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

[Max Kanat-Alexander]

On 09/04/2009 03:39 PM, Frédéric Buclin wrote:
> * Neither Bonsai nor Tinderbox support bzr, AFAIK.

        Bonsai doesn't need bzr support, because we have loggerhead, which does
pretty much everything thing that Bonsai does.

        We can make the tinderbox clients support bzr really easily, and I
think that's all that's really critical for us to move to bzr.

        As far as the PatchReader stuff goes, we don't have that for Hg either,
so I don't think we should hold up on that.

        In any case, do you have a vote for Hg vs. bzr?

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

[Frédéric Buclin]

Le 05. 09. 09 00:44, Max Kanat-Alexander a écrit :
>     Bonsai doesn't need bzr support, because we have loggerhead, which
> does pretty much everything thing that Bonsai does.

Except it doesn't display the bug ID + summary when hovering a commit
ID. This would need to be hacked to do that.


>     As far as the PatchReader stuff goes, we don't have that for Hg
> either, so I don't think we should hold up on that.

We definitely should. I *always* do reviews in context=file mode. Not
being able to do this anymore is a showstopper for me. I don't care we
don't have that for Hg either; we do have it for CVS, and that's all
which is important to me.


>     In any case, do you have a vote for Hg vs. bzr?

I have one, yes, but my issues mentioned above make my vote irrelevant
for now.

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

[Max Kanat-Alexander]

On 09/04/2009 03:54 PM, Frédéric Buclin wrote:
> Le 05. 09. 09 00:44, Max Kanat-Alexander a écrit :
> We definitely should. I *always* do reviews in context=file mode. Not
> being able to do this anymore is a showstopper for me. I don't care we
> don't have that for Hg either; we do have it for CVS, and that's all
> which is important to me.

        Okay. Well, let's assume that you resolve this (since you are totally
capable of doing so, being the module owner) before we move. What would
your vote be?

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

[Guy Pyrzak]

I don't know anything about patchreader library, but could someone write the equiv for either Hg or bzr?

Hg vs Bzr is kinda hard for me since I've never used Hg and I've been using BZR for my "real" job more or less every day... so I'm kinda bias.

-Guy

2009/9/4 Frédéric Buclin <lpsolit@...>

Le 05. 09. 09 00:44, Max Kanat-Alexander a écrit :

>     Bonsai doesn't need bzr support, because we have loggerhead, which
> does pretty much everything thing that Bonsai does.

Except it doesn't display the bug ID + summary when hovering a commit
ID. This would need to be hacked to do that.

>     As far as the PatchReader stuff goes, we don't have that for Hg
> either, so I don't think we should hold up on that.

We definitely should. I *always* do reviews in context=file mode. Not
being able to do this anymore is a showstopper for me. I don't care we
don't have that for Hg either; we do have it for CVS, and that's all
which is important to me.

>     In any case, do you have a vote for Hg vs. bzr?

I have one, yes, but my issues mentioned above make my vote irrelevant
for now.

LpSolit

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

[Frédéric Buclin]

Le 05. 09. 09 00:58, Max Kanat-Alexander a écrit :
> What would your vote be?

bzr. I already use it for Selenium, and used it with ES.

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

[Cédric Corazza]

The embryo of l10n how-to for Bugzilla didn't bring us new locales
AFAIK, and I guess the current localizers are tech savvy enough to
switch from VCS tool. Thus, the rationale to stick with Mercurial seems
to be weaker in that context.
Though it will be yet another tool to play with, the mentioned benefits
seem this switch is worthwhile.
So, I would vote to switch to Bazaar.
I would like to have some other localizers' opinion though.
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
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@...>

[David Miller]

I also personally prefer Bzr over Hg.  We're using it already for bmo's
local hacks, and to me the command set just seems more friendly than Hg.
 The scalability/performance issues that Mozilla ran into don't really
affect us because our codebase isn't as huge as theirs.

If we end up going with this, I'll see to it that we get "real" support
for it on Mozilla's infrastructure (rather than the "nothing more than a
bare repo" that we have for bmo currently, that shares a server with one
of the staging boxes).

Max Kanat-Alexander wrote on 9/4/09 6:28 PM:

>     Okay, we've had this discussion before, but this time, we have to
> actually do it. We've been on CVS for too long--we may be the only
> remaining major Mozilla project still using CVS for primary development.
> We're certainly the only major open source project that I know of and
> interact with regularly that still uses CVS.
>
>     The only reason that we haven't moved yet is that we have a conflict:
>
>     * Bzr is known by the Bugzilla developers and is technically
> superior to Hg in almost every way except scalability (and even that may
> be fixed as of bzr 1.16).
>
>     * Hg is supported by the Mozilla Corporation, has an extensive
> infrastructure at Mozilla, and is already in use by Mozilla localizers.
>
>     If you doubt that bzr is technically superior, here are a few points:
>
>     * Compare the standard web interface to Hg (hgweb:
> http://hg.mozilla.org/ ) to the standard web interface for bzr
> (loggerhead: http://bzr.bugzilla.org/ ).
>
>     * bzr has a *major* release nearly every month. (See the release
> notes: http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html )
> Mercurial's major releases are roughly 3 to 4 months apart (and there
> were 9 months from 1.0 to 1.1).
>
>     * bzr tracks directory renames as well as file renames, meaning that
> it doesn't show hundreds of files being renamed if you rename a
> directory--it only shows the directory name changing. (This also means
> that bzr can show the existence of empty directories in its changeset
> history, and Mercurial cannot.)
>
>     * The commands used in bzr for a CVS-like workflow are *identical*
> to the commands used in CVS, drastically lessening the learning curve
> for users migrating from CVS.
>
>     However, Hg is supported by the Mozilla Corporation and they already
> have extensive infrastructure around it. Also, as Cedric has pointed out
> in the past, localizers are already using Hg.
>
>     To resolve the conflict, I am ***TAKING A VOTE***:
>
>     * Respond to this email either publicly (if you want to make an
> argument) or privately with your preference stated AT THE VERY TOP OF
> THE EMAIL. Anybody who is currently contributing to the Bugzilla Project
> or interacting with our CVS is eligible to vote. (If you are not a
> current contributor, please state your interest when voting.)
>
>     I will count all public and private votes, and we will move to
> whichever VCS receives a simple majority (51%) of the received votes.
> HOWEVER, if there is a clear consensus (75% or greater) among the
> reviewers (and a significant number of reviewers vote--more than just 3
> or 4), then there is a possibility we will just go with the reviewer
> consensus, though the non-reviewer votes will also be taken into account.
>
>     If you have any questions about the voting or about either VCS, feel
> free to respond here publicly and I'd be happy to clarify.
>
>     -Max

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[bill barry]

Max Kanat-Alexander wrote:
> Anybody who is currently contributing to the Bugzilla Project or
> interacting with our CVS is eligible to vote. (If you are not a
> current contributor, please state your interest when voting.)

Not a contributor currently so my vote doesn't really count but I would
vote Mercurial.

There is significant fear that bazaar will break compatibility in
upgrades (it has already done so before). As someone who only rarely
updates Bugzilla and even far more rarely updates underlying system
infrastructure (at that level bureaucracy is simply to much in the way)
what guarantees do I have that "bzr up" will continue to work a year
from now the next time I update Bugzilla?

Any other reasons I have for wanting Mercurial are not things this
community should care about (I have infrastructure and tooling support
built up for Mercurial but not Bzr; I am active in the Mercurial dev
community; etc.).

Your FUD about Bzr being superior is BS:

* Comparing the interface is merely subjective. I very much like the Hg
interface better for one.
* Bzr has a new release every month because it finds major deficiencies
every month. It also doesn't have minor releases and every single
release has had breaking changes. In a corporate environment there is no
reasonable suggestion for bzr to remain in any state of stability if you
are interacting with repositories in external environments.
* While this is true, it is also pointless. I have yet to see any reason
why you might need to track empty directories which couldn't be
accomplished by tracking an empty file in a directory.
* The mercurial commands are not significantly different than CVS or SVN.

As far as superiority: last I checked over 90% of the commits to Bzr
were from 2 or 3 people employed by Canonical. There literally was not a
developer community.

Regardless, all I really want is for our benevolent dictator for the
time being to decide and make the move (and to see a testopia repository
that keeps up to date with the changes as they happen).
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

On 09/05/2009 03:43 PM, Bill Barry wrote:
> There is significant fear that bazaar will break compatibility in
> upgrades (it has already done so before).

        The fear is unfounded. Bazaar has never actually *broken compatibility*
in its upgrades--at least not that I recall since 1.0. However, if
administrators of bzr servers choose to convert their repositories to a
format that older versions of Bazaar don't support, then it's true that
older versions of Bazaar can no longer access those repositories.

        There would probably be a decision made when we switch to bzr what
repository format we were going to use, and then we'd stick with it
until such a time as all reasonably available versions of bzr supported
a newer repository format (most likely several years). Also, it's
looking like the 2a format may indeed be the last word in formats--we'll
see. At the least, the packs format is good enough for what we do with
Bugzilla, so we may not ever have to change.

> * Bzr has a new release every month because it finds major deficiencies
> every month.

        Not really. Read the release notes and see.

 > It also doesn't have minor releases

        Not true, it's had some minor releases. See the release notes. There
was a 1.6.1, as an example.

> * The mercurial commands are not significantly different than CVS or SVN.

        Except that last time I checked, Mercurial lacks built-in support for
bound branches--the fundamental CVS/SVN workflow (that you commit back
to the branch you checked out from with a "commit" command).

> As far as superiority: last I checked over 90% of the commits to Bzr
> were from 2 or 3 people employed by Canonical. There literally was not a
> developer community.

        Here's the current list of top contributors to bzr:

        https://launchpad.net/bazaar/+topcontributors

        (Looking at the "Bazaar Branches" section will limit it to just code
contributors.)

> see a testopia repository
> that keeps up to date with the changes as they happen).

        That would depend more upon somebody committing development resources
to Testopia than a VCS switch, although switching to a DVCS would
certainly have some advantages. I agree it would be nice, though. :-)

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

[bill barry]

Max Kanat-Alexander wrote:

> On 09/05/2009 03:43 PM, Bill Barry wrote:
>> There is significant fear that bazaar will break compatibility in
>> upgrades (it has already done so before).
>
>     The fear is unfounded. Bazaar has never actually *broken
> compatibility* in its upgrades--at least not that I recall since 1.0.
> However, if administrators of bzr servers choose to convert their
> repositories to a format that older versions of Bazaar don't support,
> then it's true that older versions of Bazaar can no longer access
> those repositories.

I seem to recall some dirstate problem that we had to change how our
server was working because we couldn't push to it. A new version came
out about a week after we started evaluating bazaar and we decided to
upgrade and found that we couldn't push to it. I think it was 1.13 or
something like that. We gave up pretty quickly after that.

>
>     There would probably be a decision made when we switch to bzr what
> repository format we were going to use, and then we'd stick with it
> until such a time as all reasonably available versions of bzr
> supported a newer repository format (most likely several years). Also,
> it's looking like the 2a format may indeed be the last word in
> formats--we'll see. At the least, the packs format is good enough for
> what we do with Bugzilla, so we may not ever have to change.
>
>> * Bzr has a new release every month because it finds major deficiencies
>> every month.
>
>     Not really. Read the release notes and see.

Every release (and there has been almost 1 a month for the past 2 years)
seems to fix at least a dozen bugs. How exactly does there happen to be
a new bug fixed every other day on average? How do that many bugs get in
the code in the first place? The only ways I can think of are either
poor coding or hastily done work (which then gets fixed in some
subsequent release; as paid developers on a project from a company with
an agenda).

Wasn't it you that wrote the post about sucking less every release?
 
>
> > It also doesn't have minor releases
>
>     Not true, it's had some minor releases. See the release notes.
> There was a 1.6.1, as an example.
I am sorry, I was wrong there.
>
>> * The mercurial commands are not significantly different than CVS or
>> SVN.
>
>     Except that last time I checked, Mercurial lacks built-in support
> for bound branches--the fundamental CVS/SVN workflow (that you commit
> back to the branch you checked out from with a "commit" command).
No it doesn't have bound branches; I'll give you that too. I don't think
it would be that difficult to write as an extension. I did write an
auto-push extension which would function just like bound mode in all
cases except for when pushing would first require a merge, but the
repository shouldn't be deciding when to merge. That should be a user
decision (in Mercurial you may instead want to rebase for instance).

My bound mode extension can be found here:
https://bitbucket.org/Bill_Barry/boundmode/

In bound mode the centralized workflow would be:
setup:
1. hg clone path
2. hg bind path

daily use:
3. hg pull --update
4. do work
5. hg ci

if ci fails to push (push may be aborted if there already exists a head
on the central which you don't have)
3. hg pull --update
4. do work
5. hg ci (fails to push)

6. hg pull --rebase
7. hg push

or

6. hg pull
7. hg merge
8. hg ci

or

6. hg fetch
7. hg push

or

6. hg push --force

or any number of other options. The point being that Mercurial shouldn't
do any magic like automatic merges (which is why fetch is in an
extension and not in the core by default). But there isn't anything that
says I couldn't write an extension that does this just like Bazaar does
(and in fact it would be a fairly simple extension come to think of it;
simply a push/pull/merge/commit loop until it succeeds).

>
>> As far as superiority: last I checked over 90% of the commits to Bzr
>> were from 2 or 3 people employed by Canonical. There literally was not a
>> developer community.
>
>     Here's the current list of top contributors to bzr:
>
>     https://launchpad.net/bazaar/+topcontributors
>
>     (Looking at the "Bazaar Branches" section will limit it to just
> code contributors.)

That has changed considerably since we last looked at it over in the
Mercurial list:
http://www.selenic.com/pipermail/mercurial/2009-January/023261.html

>
>> see a testopia repository
>> that keeps up to date with the changes as they happen).
>
>     That would depend more upon somebody committing development
> resources to Testopia than a VCS switch, although switching to a DVCS
> would certainly have some advantages. I agree it would be nice,
> though. :-)
It will be much easier to maintain a fork than it currently is to
maintain a single giant patch. I pity what Greg has to go through each
time he attempts to upgrade Testopia. That is a lot of work (which
wouldn't be nearly so difficult if it was easier to keep up with the
changes). His latest news was a bit unsettling as far as the future for
Testopia goes.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Max Kanat-Alexander]

On 09/05/2009 10:01 PM, Bill Barry wrote:
> I seem to recall some dirstate problem that we had to change how our
> server was working because we couldn't push to it. A new version came
> out about a week after we started evaluating bazaar and we decided to
> upgrade and found that we couldn't push to it. I think it was 1.13 or
> something like that. We gave up pretty quickly after that.

        Hmm. It's possible there was a problem with dirstate that I never ran
into. At this point most repos are in the packs format (same as git
uses) and it seems to be working totally fine.

> Every release (and there has been almost 1 a month for the past 2 years)
> seems to fix at least a dozen bugs. How exactly does there happen to be
> a new bug fixed every other day on average?

        I'd say that probably a lot of what's showing up there is just issues
found in Release Candidates. Not sure, though. I haven't encountered a
serious issue in bzr in a while.

> Wasn't it you that wrote the post about sucking less every release?

        Hahaha, it was. :-)

> No it doesn't have bound branches; I'll give you that too. I don't think
> it would be that difficult to write as an extension. [snip]

        Fair enough. I think bound branches is how we'd recommend users check
out Bugzilla code, though, so that they could do "bzr up" and it would
"just work" pretty nicely.

        As a result of having bound branches, bzr also has "lightweight
checkouts", which are just a copy of the working tree without the entire
history, and a pointer back to the main repo for operations that require
the history. Of course, I've never used lightweight checkouts, and I
don't know anybody who does. :-)

> My bound mode extension can be found here:
> https://bitbucket.org/Bill_Barry/boundmode/

        Cool. I will look into that if we go with Hg (though the way the voting
is going bzr seems pretty likely).

> It will be much easier to maintain a fork than it currently is to
> maintain a single giant patch. I pity what Greg has to go through each
> time he attempts to upgrade Testopia. That is a lot of work (which
> wouldn't be nearly so difficult if it was easier to keep up with the
> changes).

        Yeah, I wouldn't want to maintain Testopia without bzr, myself, if I
were a maintainer. Of course, I think the "Testopia For Bugzilla 3.4"
may not involve a patch to Bugzilla at all. We'll see. :-)

 > His latest news was a bit unsettling as far as the future for
> Testopia goes.

        Yeah, agreed, but it's possible we'll see some community member come
and pick it up.

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

[Charlie Powell-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Although I don't have much experience with either Hg or Bzr, it appears to me that bzr has more support backing its development and use; Hg just has Mozilla corp.  In addition, pending what you said about the commands for bzr being almost exact in comparison to cvs, I'd have to vote for bzr. 

That said however, I am neither an active contributor nor a user of either bzr or hg, so this vote can count for half :p




----- Original Message -----
From: "Max Kanat-Alexander" <mkanat@...>
To: developers@...
Sent: Sunday, September 6, 2009 4:45:58 AM GMT -05:00 US/Canada Eastern
Subject: Re: Moving Away From CVS: A Vote

On 09/05/2009 10:01 PM, Bill Barry wrote:
> I seem to recall some dirstate problem that we had to change how our
> server was working because we couldn't push to it. A new version came
> out about a week after we started evaluating bazaar and we decided to
> upgrade and found that we couldn't push to it. I think it was 1.13 or
> something like that. We gave up pretty quickly after that.

        Hmm. It's possible there was a problem with dirstate that I never ran
into. At this point most repos are in the packs format (same as git
uses) and it seems to be working totally fine.

> Every release (and there has been almost 1 a month for the past 2 years)
> seems to fix at least a dozen bugs. How exactly does there happen to be
> a new bug fixed every other day on average?

        I'd say that probably a lot of what's showing up there is just issues
found in Release Candidates. Not sure, though. I haven't encountered a
serious issue in bzr in a while.

> Wasn't it you that wrote the post about sucking less every release?

        Hahaha, it was. :-)

> No it doesn't have bound branches; I'll give you that too. I don't think
> it would be that difficult to write as an extension. [snip]

        Fair enough. I think bound branches is how we'd recommend users check
out Bugzilla code, though, so that they could do "bzr up" and it would
"just work" pretty nicely.

        As a result of having bound branches, bzr also has "lightweight
checkouts", which are just a copy of the working tree without the entire
history, and a pointer back to the main repo for operations that require
the history. Of course, I've never used lightweight checkouts, and I
don't know anybody who does. :-)

> My bound mode extension can be found here:
> https://bitbucket.org/Bill_Barry/boundmode/

        Cool. I will look into that if we go with Hg (though the way the voting
is going bzr seems pretty likely).

> It will be much easier to maintain a fork than it currently is to
> maintain a single giant patch. I pity what Greg has to go through each
> time he attempts to upgrade Testopia. That is a lot of work (which
> wouldn't be nearly so difficult if it was easier to keep up with the
> changes).

        Yeah, I wouldn't want to maintain Testopia without bzr, myself, if I
were a maintainer. Of course, I think the "Testopia For Bugzilla 3.4"
may not involve a patch to Bugzilla at all. We'll see. :-)

 > His latest news was a bit unsettling as far as the future for
> Testopia goes.

        Yeah, agreed, but it's possible we'll see some community member come
and pick it up.

        -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=powellc@...>

[Gervase Markham]

On 07/09/09 07:33, Charlie Powell wrote:
> Although I don't have much experience with either Hg or Bzr, it
> appears to me that bzr has more support backing its development and
> use; Hg just has Mozilla corp.

I'm not sure what you mean by that. Mercurial (Hg) is not a Mozilla
Project project, but an independent project, used by many free and open
source projects, as listed at the bottom of this page:
http://en.wikipedia.org/wiki/Mercurial_%28software%29

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
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@...>

[Gervase Markham]

Current vote: undecided.

On 04/09/09 23:28, Max Kanat-Alexander wrote:
> If you doubt that bzr is technically superior, here are a few points:
>
> * Compare the standard web interface to Hg (hgweb:
> http://hg.mozilla.org/ ) to the standard web interface for bzr
> (loggerhead: http://bzr.bugzilla.org/ ).

Here's a test for function I've needed from the 3 major Mozilla SCMs
recently: can it give me an XML or RSS feed of all changes in the entire
repository (or, perhaps, a separate feed for each branch) from a
particular date, say, six months ago?

> * bzr has a *major* release nearly every month. (See the release notes:
> http://doc.bazaar-vcs.org/bzr.1.17/en/release-notes/NEWS.html )
> Mercurial's major releases are roughly 3 to 4 months apart (and there
> were 9 months from 1.0 to 1.1).

I really don't think release frequency is a good metric of software quality.

> However, Hg is supported by the Mozilla Corporation and they already
> have extensive infrastructure around it.

I personally use an abstraction library (Patch Maker -
http://www.gerv.net/software/patch-maker/) to work with multiple SCMs,
so in one sense it doesn't matter too much. And I've certainly found Hg
difficult to use. But my one big concern would be the level of support
we would get from Mozilla IT if we asked them to support Yet Another SCM
system. If justdave is telling us he can guarantee that Mozilla IT will
properly support bzr, then I'll abstain. Otherwise, I vote for Hg.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
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@...>

[Anjali Sharma-2]

Hi

 

I installed Bugzilla on windows. Now i want to customize the existing template of it according to my requirement. Please let me know how can i do it asap.

 

Thanks

Anjali Sharma

On Mon, Sep 7, 2009 at 3:19 PM, Gervase Markham <gerv@...> wrote:

On 07/09/09 07:33, Charlie Powell wrote:

Although I don't have much experience with either Hg or Bzr, it
appears to me that bzr has more support backing its development and
use; Hg just has Mozilla corp.

I'm not sure what you mean by that. Mercurial (Hg) is not a Mozilla Project project, but an independent project, used by many free and open source projects, as listed at the bottom of this page:
http://en.wikipedia.org/wiki/Mercurial_%28software%29

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla@...
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=sharmaanjali70@...>

[Frédéric Buclin]

Le 07. 09. 09 11:56, Anjali Sharma a écrit :
> I installed Bugzilla on windows. Now i want to customize the existing
> template of it according to my requirement. Please let me know how can i do
> it asap.

You are completely out of topic, and this is not the right place to ask
for help, see http://www.bugzilla.org/support/.

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