As I've got less time hacking on stuff, or even just following mailing lists carefully, I'd like to have a way to look at issues to maybe find something to hack even after one or two months passed.
I didn't feel like it was needed in past, but I'd now like to have some kind of bug tracker, or issue management system.
From SBCL's experience, launchpad is pretty decent, and
comes with a pretty decent mailing list interface.
What are your thoughts on that matter?
-T.
* Tobias C Rittweiler [2010-08-21 07:56] writes:
As I've got less time hacking on stuff, or even just following mailing lists carefully, I'd like to have a way to look at issues to maybe find something to hack even after one or two months passed.
I didn't feel like it was needed in past, but I'd now like to have some kind of bug tracker, or issue management system.
From SBCL's experience, launchpad is pretty decent, and comes with a pretty decent mailing list interface.
What are your thoughts on that matter?
Trac also seems an option to consider; least that's available on cl.net. It seems to work to well for Clozure. They use SVN which has some synergies with Trac but I guess having a Wiki and bug tracker at the same place also a good thing.
Helmut
In article m2vd741ijk.fsf@common-lisp.net, Helmut Eller heller@common-lisp.net wrote:
- Tobias C Rittweiler [2010-08-21 07:56] writes:
As I've got less time hacking on stuff, or even just following mailing lists carefully, I'd like to have a way to look at issues to maybe find something to hack even after one or two months passed.
I didn't feel like it was needed in past, but I'd now like to have some kind of bug tracker, or issue management system.
From SBCL's experience, launchpad is pretty decent, and comes with a pretty decent mailing list interface.
What are your thoughts on that matter?
Trac also seems an option to consider; least that's available on cl.net. It seems to work to well for Clozure. They use SVN which has some synergies with Trac but I guess having a Wiki and bug tracker at the same place also a good thing.
My experience with Trac so far is that it tends to be noticably (euphemism for annoyingly) slow. Especially on c-l.net.
The suggestion about github etc. is what all the kool aid is about nowadays, I guess. I wouldn't mind that either, although I have no experience other than pulling from such sources. I did hear good words about it, FWIW.
Presumably you can use those with hg also, or similiar services will surely be found for hg elsewhere in case you disdain for git is really overwhelming.
To get this done, how shall we proceed?
-T.
* Tobias C Rittweiler [2010-08-23 20:36] writes:
My experience with Trac so far is that it tends to be noticably (euphemism for annoyingly) slow. Especially on c-l.net.
That's news to me. I don't quite see why a bug tracker could be slow. Sorting a table or a full text search don't seem demanding tasks. But then there's always room to make mistakes.
The suggestion about github etc. is what all the kool aid is about nowadays, I guess. I wouldn't mind that either, although I have no experience other than pulling from such sources. I did hear good words about it, FWIW.
github is certainly the one with the most Javascript.
Presumably you can use those with hg also, or similiar services will surely be found for hg elsewhere in case you disdain for git is really overwhelming.
To get this done, how shall we proceed?
I think the simplest would be to use Trac on cl.net without a new VCS. If you want something I will not stop you.
Helmut
On Tue, 24 Aug 2010 16:37:13 +0200, Helmut Eller heller@common-lisp.net wrote:
The suggestion about github etc. is what all the kool aid is about nowadays, I guess. I wouldn't mind that either, although I have no experience other than pulling from such sources. I did hear good words about it, FWIW.
github is certainly the one with the most Javascript.
Presumably you can use those with hg also, or similiar services will surely be found for hg elsewhere in case you disdain for git is really overwhelming.
To get this done, how shall we proceed?
Btw, apropos the mercurial preference, http://bitbucket.org/ is the hg analog to github.
I think the simplest would be to use Trac on cl.net without a new VCS. If you want something I will not stop you.
Helmut
On 8/23/10 10:36 PM, Tobias C Rittweiler wrote:
In articlem2vd741ijk.fsf@common-lisp.net, Helmut Ellerheller@common-lisp.net wrote:
[…]
What are your thoughts on that matter?
Trac also seems an option to consider; least that's available on cl.net. It seems to work to well for Clozure. They use SVN which has some synergies with Trac but I guess having a Wiki and bug tracker at the same place also a good thing.
My experience with Trac so far is that it tends to be noticably (euphemism for annoyingly) slow. Especially on c-l.net.
[…]
For [ABCL][1], Erik changed the default common-lisp.net configuration to use a FCGI connection between Apache httpd and a long-running Python process for the tracd. This has sped up Trac to acceptable levels. Presumably, he (we?) can share configuration details for interested parties.
[1]: http://trac.common-lisp.net/armedbear/wiki
The downside to Trac as possible on common-lisp.net is that only committers can add bug reports, provide comments, etc. as there are only notions of "users with a common-lisp.net uid" and "anonymous" for HTTP users. Something like Launchpad effectively subcontracts out the operational aspects of dealing with a large, untrusted, and varying user base.
In the hg v. git argument, I definitely prefer hg. It has consistent documentation and design, making much more sense than git ever did for me. When forced to use git for projects like ASDF even though I am a seasoned hg user for which DVC concepts are second nature, I am consistently frustrated at trying to figure out the corresponding commands in git.
Tobias C Rittweiler tcr@freebits.de writes:
As I've got less time hacking on stuff, or even just following mailing lists carefully, I'd like to have a way to look at issues to maybe find something to hack even after one or two months passed.
I didn't feel like it was needed in past, but I'd now like to have some kind of bug tracker, or issue management system.
From SBCL's experience, launchpad is pretty decent, and comes with a pretty decent mailing list interface.
What are your thoughts on that matter?
I like launchpad, though trac is OK too.
And while we're at it, maybe it's appropriate to consider transition to some more modern version control system.
Re all
github provides wiki + bug tracker + VCS. And you allow many developers to commit into single repository. May be this will be good solution? Because many big projects, like erlang, clojure, and many other, use github to host VCS
I personally like fork/pull request feature - this allows to anyone, who has no commit rights, to make some changes, and offer them to merge into mainstream.
Stas Boukarev at "Sun, 22 Aug 2010 01:32:56 +0400" wrote: SB> Tobias C Rittweiler tcr@freebits.de writes:
As I've got less time hacking on stuff, or even just following mailing lists carefully, I'd like to have a way to look at issues to maybe find something to hack even after one or two months passed.
I didn't feel like it was needed in past, but I'd now like to have some kind of bug tracker, or issue management system.
From SBCL's experience, launchpad is pretty decent, and comes with a pretty decent mailing list interface.
What are your thoughts on that matter?
SB> I like launchpad, though trac is OK too.
SB> And while we're at it, maybe it's appropriate to consider transition to SB> some more modern version control system.
* Stas Boukarev [2010-08-21 21:32] writes:
And while we're at it, maybe it's appropriate to consider transition to some more modern version control system.
Well, I think everybody can set up it's on repository with whatever VCS he likes that imports from CVS an make some scripts to commit back to CVS. That's probably less hassle than force everybody to switch to something else. That said, my favorite would be hg; git I don't like much because its UI is a disaster.
Helmut
On Sun, 22 Aug 2010 20:10:56 +0200 Helmut Eller heller@common-lisp.net wrote:
Well, I think everybody can set up it's on repository with whatever VCS he likes that imports from CVS an make some scripts to commit back to CVS. That's probably less hassle than force everybody to switch to something else.
I agree,
Matthew Mondor wrote:
On Sun, 22 Aug 2010 20:10:56 +0200 Helmut Eller heller@common-lisp.net wrote:
Well, I think everybody can set up it's on repository with whatever VCS he likes that imports from CVS an make some scripts to commit back to CVS. That's probably less hassle than force everybody to switch to something else.
I agree,
FWIW, Subversion was written because CVS has several well-known flaws which can result in a borked commit leaving the repository in a completely inconsistent state. SVN was designed to be a drop-in replacement with atomic commits to fix the fundamental issues in CVS.
Speaking from experience, newer tools including DVCSs *can* interact with CVS; but their users must give up most of the new features in doing so (including all the distributed features), and the conversion process is quite fragile and painful (largely due to CVS's lack of atomic commits). It is not a pleasant experience.
A switch to SVN means basically changing "cvs command" to "svn command". The newer tools with vastly superior history models do have different command sets.
IMNSHO, there were no justifiable reasons for using CVS in 2005, much less in 2010. The choice of VCS has ramifications to end-users and potential developers.
- Daniel
* dherring@tentpost.com [2010-08-23 15:54] writes:
FWIW, Subversion was written because CVS has several well-known flaws which can result in a borked commit leaving the repository in a completely inconsistent state. SVN was designed to be a drop-in replacement with atomic commits to fix the fundamental issues in CVS.
VCS debates... everybody has heard all the arguments already a dozen times and the result will be the same. Let's face it: it's a waste of time.
Speaking from experience, newer tools including DVCSs *can* interact with CVS; but their users must give up most of the new features in doing so (including all the distributed features), and the conversion process is quite fragile and painful (largely due to CVS's lack of atomic commits). It is not a pleasant experience.
I don't understand what you mean. The point of those DVCSs seems to be that you don't need a central server and that every clone/repository has all the history and therefore supports *all* features.
A switch to SVN means basically changing "cvs command" to "svn command". The newer tools with vastly superior history models do have different command sets.
IMNSHO, there were no justifiable reasons for using CVS in 2005, much less in 2010. The choice of VCS has ramifications to end-users and potential developers.
Well, Emacs switched from CVS to Bzr a while back. For someone like me who essentially only needs "cvs up" once in a while the switch was a net loss. What used to take 2 minutes and downloaded 5 MB with CVS takes now 20 minutes and 200 MB. My urge to update is no pretty much zero.
I doubt that it was an improvement for real Emacs developers either, as the main topic on the emacs-devel mailing list is now (since 6 month or so) in how many ways Bzr sucks. Good use of resources that is.
Helmut
Helmut Eller wrote:
- dherring@tentpost.com [2010-08-23 15:54] writes:
FWIW, Subversion was written because CVS has several well-known flaws which can result in a borked commit leaving the repository in a completely inconsistent state. SVN was designed to be a drop-in replacement with atomic commits to fix the fundamental issues in CVS.
VCS debates... everybody has heard all the arguments already a dozen times and the result will be the same. Let's face it: it's a waste of time.
...
Speaking from experience, newer tools including DVCSs *can* interact with CVS; but their users must give up most of the new features in doing so (including all the distributed features), and the conversion process is quite fragile and painful (largely due to CVS's lack of atomic commits). It is not a pleasant experience.
I don't understand what you mean. The point of those DVCSs seems to be that you don't need a central server and that every clone/repository has all the history and therefore supports *all* features.
Only true if each DVCS user has the same history. Since CVS is fundamentally broken, there are dozens of fuzz algorithms that try to extract a history. This is a nontrivial task, the conversion routines are not as well developed as other tools, etc. As a result, people intending to check back into CVS or SVN are advised to do their own conversions and not share with others.
I tried sharing converted repos. It was a massive maintenance drain, and eventually failed spectacularly. Everything needed a total rebuild once a year or so, each time the conversion tool changed substantially. Not fun at all. Lesson learned. Any conversion, even something saner like darcs to git, is fraught with terror.
A switch to SVN means basically changing "cvs command" to "svn command". The newer tools with vastly superior history models do have different command sets.
IMNSHO, there were no justifiable reasons for using CVS in 2005, much less in 2010. The choice of VCS has ramifications to end-users and potential developers.
Well, Emacs switched from CVS to Bzr a while back. For someone like me who essentially only needs "cvs up" once in a while the switch was a net loss. What used to take 2 minutes and downloaded 5 MB with CVS takes now 20 minutes and 200 MB. My urge to update is no pretty much zero.
I doubt that it was an improvement for real Emacs developers either, as the main topic on the emacs-devel mailing list is now (since 6 month or so) in how many ways Bzr sucks. Good use of resources that is.
At least we can agree that Bzr sucks. ;)
Seriously, I'm no SVN fanboy; but an upgrade from CVS to SVN causes minimal user-visible changes, while fixing some rather substantial bugs in CVS. It is like changing from rsh to ssh -- there are almost no downsides.
I only have CVS installed for a handful of projects. Sadly, they are all CL projects...
- Daniel
Daniel Herring wrote:
I tried sharing converted repos. It was a massive maintenance drain, and eventually failed spectacularly. Everything needed a total rebuild once a year or so, each time the conversion tool changed substantially. Not fun at all. Lesson learned. Any conversion, even something saner like darcs to git, is fraught with terror.
Note: conversions from SVN are generally better supported than from any other system.
- Daniel
On 8/23/10 1:52 PM, Helmut Eller wrote:
- dherring@tentpost.com [2010-08-23 15:54] writes:
IMNSHO, there were no justifiable reasons for using CVS in 2005, much less in 2010. The choice of VCS has ramifications to end-users and potential developers.
It would certainly be nice if there were One True VCS in 2010 instead of the multiplicity of VCSs now.
Well, Emacs switched from CVS to Bzr a while back. For someone like me who essentially only needs "cvs up" once in a while the switch was a net loss. What used to take 2 minutes and downloaded 5 MB with CVS takes now 20 minutes and 200 MB. My urge to update is no pretty much zero.
As a slime luser, I certainly like being able to cvs up and get slime in a few (tens?) of seconds. I don't have much experience with other VCSs, but I didn't particularly like how long it took to grab asdf2 via git.
Anyway, that's my micropayment on this subject.
Ray
Raymond Toy wrote:
On 8/23/10 1:52 PM, Helmut Eller wrote:
Well, Emacs switched from CVS to Bzr a while back. For someone like me who essentially only needs "cvs up" once in a while the switch was a net loss. What used to take 2 minutes and downloaded 5 MB with CVS takes now 20 minutes and 200 MB. My urge to update is no pretty much zero.
As a slime luser, I certainly like being able to cvs up and get slime in a few (tens?) of seconds. I don't have much experience with other VCSs, but I didn't particularly like how long it took to grab asdf2 via git.
Q: apples to apples? Did you compare an empty CVS checkout to an empty git clone, or did you compare a cvs up to a git clone?
It has been my experience that synchronizing large projects is generally faster with git since it just grabs a few patches instead of checking each file individually. Git is only somewhat slower when doing the initial clone. That said, http-backed git repos are generally a few times slower than repos using the native protocol.
- Daniel
On Tue, Aug 24, 2010 at 18:39, dherring@tentpost.com wrote:
It has been my experience that synchronizing large projects is generally faster with git since it just grabs a few patches instead of checking each file individually. Git is only somewhat slower when doing the initial clone. That said, http-backed git repos are generally a few times slower than repos using the native protocol.
I'll chime in with some data about the slime git mirror I've been keeping:
The (packed, compressed) repo size is 79MB right now, and a fresh clone fetches all of it (unless you use --reference on an existing clone, which speeds things up a /lot/). This means a fresh checkout can take a while on a slower line. Just yesterday, I had to wait more than just a few minutes for my 2MBit/s line to finish sucking down slime. However, I don't expect hg or bzr to perform much better (or worse) than this.
However, an update from one day to the next generally takes ~1 second, transferring just a couple dozen kilobytes on very few server round trips (could just be one, I don't know the git protocol by heart). Again, I don't expect any modern VCS like hg or bzr to perform much better or worse than this.
Speaking as a user, I'd be happy to have the authoritative slime development history available offline, with uniquely identifiable commits, so any of the saner VCSs is fine by me.
Cheers,
To corporate drones such as myself sitting behind a firewall it would be really usefull to have a VC with http access.
As long as it is not bazaar. We admittedly do not have the fastest connection to the outside world but I gave up after a checkout of the emacs repo literally had been running for several days without finishing.
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
On Wed, 2010-08-25 at 09:44 +0200, christian.lynbech@tieto.com wrote:
To corporate drones such as myself sitting behind a firewall it would be really usefull to have a VC with http access.
As long as it is not bazaar. We admittedly do not have the fastest connection to the outside world but I gave up after a checkout of the emacs repo literally had been running for several days without finishing.
With git you have two anonymous download protocols - one ad-hoc and very fast and one on top of HTTP(but usually not as efficient), with hg you have one on top of HTTP
OTOH, bzr is much too inefficient to be relevant and I think it's unfair to lay its sins on the other two
On Wed, Aug 25, 2010 at 11:43, Stelian Ionescu sionescu@cddr.org wrote:
With git you have two anonymous download protocols - one ad-hoc and very fast and one on top of HTTP(but usually not as efficient), with hg you have one on top of HTTP
One more thing: Given a sufficiently smart http server config (http://progit.org/2010/03/04/smart-http.html), you can get a reduced server roundtrip transport over http, too. Github implement this, and it's pretty cool.
Cheers,
In article m2mxse8qmn.fsf@common-lisp.net, Helmut Eller heller@common-lisp.net wrote:
- Stas Boukarev [2010-08-21 21:32] writes:
And while we're at it, maybe it's appropriate to consider transition to some more modern version control system.
Well, I think everybody can set up it's on repository with whatever VCS he likes that imports from CVS an make some scripts to commit back to CVS. That's probably less hassle than force everybody to switch to something else. That said, my favorite would be hg; git I don't like much because its UI is a disaster.
Helmut
In case you haven't looked at it recently, magit is a very decent Emacs mode for git. It improved a lot since some time ago. One might consider that sweeping the issue under the carpet, of course. :-)
-T.
-
Alex Ott -
Andreas Fuchs -
christian.lynbech＠tieto.com -
dherring＠tentpost.com -
Helmut Eller -
Mark Evenson -
Matthew Mondor -
Raymond Toy -
Samium Gromoff -
Stas Boukarev -
Stelian Ionescu -
Tobias C Rittweiler