From: Jim B. <jam...@gm...> - 2008-02-03 21:17:47
|
I'd much prefer Trac too. www.edgewall.org lists a number of providers that provide free hosting of open source projects. Any thoughts on WebFaction.com? - Jim -- Jim Baker jb...@zy... On Feb 3, 2008, at 1:56 PM, Nicholas Riley <nj...@ui...> wrote: > In article > <c6f...@ma...>, > "Alexandru Popescu ?" <the...@gm...> wrote: > >> I pretty much dislike everything related to SF (except maybe the >> package distribution), so >> migrating away from it will always have my +1 (even if I am not >> involved at this moment with the tracker). > > Certainly SourceForge's hideous bug tracker has been an impediment > to my > contribution on other projects in the past. Roundup is pretty ugly, > but > reasonably functional. Unfortunately Google Code still doesn't > support > import, and given protecting a bug tracking system from spammers is a > big job, it's probably better we don't try to run our own Trac > instance > or similar. > > Even SourceForge's downloads are still annoying since they've switched > to automatic mirror selection - it downloads automatically to your > local > machine, so I have to stop it, copy the URL and paste it into the > machine I actually wanted to install on. > -- > Nicholas Riley <nj...@ui...> > > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Charlie G. <cha...@gm...> - 2008-02-03 21:39:29
|
It sounded like Nicholas was actually saying running trac would be a bad idea since we'd have to protect it from spammers. What makes you prefer it to roundup? Charlie On Feb 3, 2008 1:17 PM, Jim Baker <jam...@gm...> wrote: > I'd much prefer Trac too. www.edgewall.org lists a number of providers > that provide free hosting of open source projects. Any thoughts on > WebFaction.com? > > - Jim > > -- > Jim Baker > jb...@zy... > > > On Feb 3, 2008, at 1:56 PM, Nicholas Riley <nj...@ui...> wrote: > > > In article > > <c6f...@ma...>, > > "Alexandru Popescu ?" <the...@gm...> wrote: > > > >> I pretty much dislike everything related to SF (except maybe the > >> package distribution), so > >> migrating away from it will always have my +1 (even if I am not > >> involved at this moment with the tracker). > > > > Certainly SourceForge's hideous bug tracker has been an impediment > > to my > > contribution on other projects in the past. Roundup is pretty ugly, > > but > > reasonably functional. Unfortunately Google Code still doesn't > > support > > import, and given protecting a bug tracking system from spammers is a > > big job, it's probably better we don't try to run our own Trac > > instance > > or similar. > > > > Even SourceForge's downloads are still annoying since they've switched > > to automatic mirror selection - it downloads automatically to your > > local > > machine, so I have to stop it, copy the URL and paste it into the > > machine I actually wanted to install on. > > -- > > Nicholas Riley <nj...@ui...> > > > > > > --- > > ---------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
From: Nicholas R. <nj...@ui...> - 2008-02-03 21:48:04
|
In article <96c...@ma...>, "Charlie Groves" <cha...@gm...> wrote: > It sounded like Nicholas was actually saying running trac would be a > bad idea since we'd have to protect it from spammers. What makes you > prefer it to roundup? I could have been clearer, but there are at least two issues with running Trac: 1) sysadmin/maintenance overhead - somewhat mitigated if we get WebFaction or another provider to run the machine for us 2) managing ticket spam Good things about Trac vs. Roundup include the wiki syntax/Subversion integration, wonderful usability and very active development. I've just seen enough spam-related issues with the Django Trac that I'm a bit concerned. However, (a) Jython is a lower-traffic project and (b) we could require everyone filing a ticket create a Trac account, which should pretty much eliminate the problem. The latter is no different from the status quo with SourceForge, in any case. I run a bunch of Trac sites myself and am quite happy with the software; they're closed-membership so I've never had to deal with spam. -- Nicholas Riley <nj...@ui...> |
From: Frank W. <fwi...@gm...> - 2008-02-03 22:40:14
|
On Feb 3, 2008 4:17 PM, Jim Baker <jam...@gm...> wrote: > I'd much prefer Trac too. www.edgewall.org lists a number of providers > that provide free hosting of open source projects. Any thoughts on > WebFaction.com? My reasons for suggesting Python's roundup are: 1. Python has an existing migration tool that we can use (probably with a few modifications for our needs) 2. Python has an existing admin/support structure -- though we would want to find some volunteers from the Jython side to help, but we wouldn't need to be "on our own" 3. It would be nice to have tighter bonds with the CPython folks But of course if there is an overwhelming desire to go with trac and 1. and 2. can be addressed then I can be persuaded. 3. is just a nice-to-have that we can achieve in other ways. -Frank |
From: Nicholas R. <nj...@ui...> - 2008-02-03 23:06:43
|
In article <4da...@ma...>, "Frank Wierzbicki" <fwi...@gm...> wrote: > 1. Python has an existing migration tool that we can use (probably > with a few modifications for our needs) Trac has <http://trac.edgewall.org/browser/trunk/contrib/sourceforge2trac.py> which looks quite hackable if it doesn't do what we want. If someone with SourceForge admin access can send me an XML dump of the Jython bug database I can import it into Trac. > 2. Python has an existing admin/support structure -- though we would > want to find some volunteers from the Jython side to help, but we > wouldn't need to be "on our own" This is certainly the major potential blocker. I am certainly willing to volunteer to help out with administration, if we can find a host such as WebFaction to handle the hardware side of things. Perhaps Jim Baker could contact them about potentially hosting Jython? > 3. It would be nice to have tighter bonds with the CPython folks > > But of course if there is an overwhelming desire to go with trac and > 1. and 2. can be addressed then I can be persuaded. 3. is just a > nice-to-have that we can achieve in other ways. Certainly I agree on 3. Maybe the mailing lists can be moved to @python.org? -- Nicholas Riley <nj...@ui...> |
From: Alan K. <jyt...@xh...> - 2008-02-04 19:08:45
|
[Nicholas] > Maybe the mailing lists can be moved to @python.org? That would be great; the SF list interface is slow, unreliable and frustrating. Searching is painful; even when you get good results from search engines such as Google, SF sometimes fails to present the original indexed email, either because they've changed the URL resolution algorithm, or they fail to thread message ids together correctly. Dedicated list facilities like Nabble and Google Groups are good way to get around these problems. But it would be fantastic if we could have a definitive archive of jython lists posted on mail.jython.org, perhaps managed by the same infrastructure as mail.python.org. Regards, Alan. |
From: Charlie G. <cha...@gm...> - 2008-02-03 23:33:48
|
On Feb 3, 2008 1:47 PM, Nicholas Riley <nj...@ui...> wrote: > In article > <96c...@ma...>, > "Charlie Groves" <cha...@gm...> wrote: > > > It sounded like Nicholas was actually saying running trac would be a > > bad idea since we'd have to protect it from spammers. What makes you > > prefer it to roundup? > > I could have been clearer, but there are at least two issues with > running Trac: > > 1) sysadmin/maintenance overhead - somewhat mitigated if we get > WebFaction or another provider to run the machine for us I don't really like either of those ends though. On the running a dedicated Jython issue tracker machine end, I don't think we're a big enough project to merit someone's time doing all that maintenance. On the hosting provider end, we end up in the same boat that we're currently in with Sourceforge: the SS Inability to Customize or Fix Things. Admittedly the need for that would decrease away from sourceforge, but pitching in a little to use Python's existing infrastructure seems like a nice middle road. > 2) managing ticket spam > > Good things about Trac vs. Roundup include the wiki syntax/Subversion > integration, wonderful usability and very active development. > > I've just seen enough spam-related issues with the Django Trac that I'm > a bit concerned. However, (a) Jython is a lower-traffic project and (b) > we could require everyone filing a ticket create a Trac account, which > should pretty much eliminate the problem. The latter is no different > from the status quo with SourceForge, in any case. > > I run a bunch of Trac sites myself and am quite happy with the software; > they're closed-membership so I've never had to deal with spam. We actually allow anonymous bug postings now, but I haven't gotten a lot of good out of it. In almost every case I've asked for follow-up from the poster to track down what's going wrong, and I haven't gotten a response. Charlie |
From: Frank W. <fwi...@gm...> - 2008-02-03 23:41:45
|
On Feb 3, 2008 6:33 PM, Charlie Groves <cha...@gm...> wrote: > > 1) sysadmin/maintenance overhead - somewhat mitigated if we get > > WebFaction or another provider to run the machine for us > > I don't really like either of those ends though. On the running a > dedicated Jython issue tracker machine end, I don't think we're a big > enough project to merit someone's time doing all that maintenance. On > the hosting provider end, we end up in the same boat that we're > currently in with Sourceforge: the SS Inability to Customize or Fix > Things. Admittedly the need for that would decrease away from > sourceforge, but pitching in a little to use Python's existing > infrastructure seems like a nice middle road. yeah, #1 is the big one -- having a well-tuned group like Python.org is the biggest plus for this. I do think we are a bit too small to run our own infrastructure. I really want to piggy-back on Python wherever possible. -Frank |
From: Nicholas R. <nj...@ui...> - 2008-02-04 00:29:44
|
In article <96c...@ma...>, "Charlie Groves" <cha...@gm...> wrote: > I don't really like either of those ends though. On the running a > dedicated Jython issue tracker machine end, I don't think we're a big > enough project to merit someone's time doing all that maintenance. On > the hosting provider end, we end up in the same boat that we're > currently in with Sourceforge: the SS Inability to Customize or Fix > Things. Admittedly the need for that would decrease away from > sourceforge, but pitching in a little to use Python's existing > infrastructure seems like a nice middle road. I don't think there'd be much admin time involved (certainly, the Trac instances I run have required essentially none after initial setup) and certainly no dedicated machine (at best Jython would get a VPS, at worst a shared setup such as SourceForge offers now). Either way, it's not a big commitment. I do believe Trac would be better from a usability/features standpoint. I am willing to volunteer some time to set it up initially. Some things that annoy me about Roundup: 1. If you go to http://bugs.python.org/ and aren't logged in, there is no obvious "create issue" button 2. Searching does not show you excerpts of matching text, just bug titles 3. Roundup uses nonstandard/confusing terminology such as "activity", "nosy list" and "actor" instead of "last modified", "cc" and "modified by". I couldn't even figure out what the big "Change Note:" box means on the issue edit page even looking in the Roundup user guide; by process of elimination I guess it is the message you are posting. 4. The interface just looks rough and unfinished. For example, compare the "advanced" search of Roundup: <http://bugs.python.org/issue?@template=search&status=1> with that of Trac: <http://trac.edgewall.org/query> or just look at the size of URL each one generates for a trivial query. Even Roundup would be a huge improvement over what Jython uses now, of course. > We actually allow anonymous bug postings now, but I haven't gotten a > lot of good out of it. In almost every case I've asked for follow-up > from the poster to track down what's going wrong, and I haven't gotten > a response. Guess I got confused by the SF interface. Good to know that removing the anonymous option is unlikely to hurt, though; it means my concerns about spam are unfounded. -- Nicholas Riley <nj...@ui...> |
From: Frank W. <fwi...@gm...> - 2008-02-04 02:27:21
|
Hmmm. Well, I'd like to make a choice in a few days if that's possible. At least everyone agrees that we need to get away from SF. It looks like we have two choices: 1. Run our own instance of Trac in some kind of hosted environment like WebFaction.com. 2. Get an instance of Roundup from Python.org And it looks like the main advantage of Trac is that it has a nicer interface, and the main advantage of Roundup is that we take less administrative burden. I have to say I'm a little nervous about an independent entity like WebFaction.com. The PSF is not going to suddenly go away, and they (I'm sure) have nice backup and recovery strategies specific to the roundup software. So I still lean that way. -Frank |
From: Charlie G. <cha...@gm...> - 2008-02-04 03:58:11
|
On Feb 3, 2008 4:29 PM, Nicholas Riley <nj...@ui...> wrote: > I do believe Trac would be better from a usability/features standpoint. > I am willing to volunteer some time to set it up initially. Some things > that annoy me about Roundup: > > 1. If you go to http://bugs.python.org/ and aren't logged in, there is > no obvious "create issue" button Seems like it wouldn't be hugely difficult to fix this, and that would have the benefit of helping python.org. > 2. Searching does not show you excerpts of matching text, just bug titles Same as 1. > 3. Roundup uses nonstandard/confusing terminology such as "activity", > "nosy list" and "actor" instead of "last modified", "cc" and "modified > by". I couldn't even figure out what the big "Change Note:" box means > on the issue edit page even looking in the Roundup user guide; by > process of elimination I guess it is the message you are posting. No argument. > 4. The interface just looks rough and unfinished. For example, compare > the "advanced" search of Roundup: > > <http://bugs.python.org/issue?@template=search&status=1> > > with that of Trac: > > <http://trac.edgewall.org/query> > > or just look at the size of URL each one generates for a trivial query. No argument here either, though I will say it took me a bit to figure out that the pull down allows you to add queries to trac and that I'm proposing we eliminate 3 of the fields for Roundup, so it'll shrink that page a bit. In general it seems like these issues could be fixed(except for the oddball naming, which we should probably keep so we're the same as CPython) with a little work on Roundup. I doubt that would be more work than setting up and maintaining our own Trac instance. It also looks like the PSF considered Trac back when they selected Roundup: http://mail.python.org/pipermail/python-dev/2006-October/069139.html The reasons given for not selecting Trac were "customization or UI problems", so it's hard to say exactly what the problems were and if they've been fixed in the meantime. It'd probably be worth finding out what they were though. Charlie |
From: Jim B. <jb...@zy...> - 2008-02-04 05:06:45
|
FWIW, Roundup is actually externally hosted by Upfront Systems, a South African provider focusing on Zope/Plone: http://www.upfrontsystems.co.za/news/we-host-official-python-issue-tracker-on-roundup It would be interesting to examine more of the selection process with Trac vs Roundup, however as a Django user, I find Trac invaluable in terms of its transparency in tracking Django bugs and corresponding changesets. I do believe that trackers have significant value for people who are not necessarily involved in specific bug fixes, but want to follow what's going on. (That would be me with respect to Django, I really want to see it as a system that just runs on Jython as-is, assuming some backend support.) Trac also seems to be very transparent to Google searches, with a greater likelihood of my finding the right page. (But that of course could be just my searches.) And I have great admiration for how the Django project has effectively used Trac, especially in scaling up for their world-wide sprints. I'd be happy to contact WebFaction and other possible providers and see what they can do for us. - Jim On Feb 3, 2008 8:58 PM, Charlie Groves <cha...@gm...> wrote: > On Feb 3, 2008 4:29 PM, Nicholas Riley <nj...@ui...> wrote: > > I do believe Trac would be better from a usability/features standpoint. > > I am willing to volunteer some time to set it up initially. Some things > > that annoy me about Roundup: > > > > 1. If you go to http://bugs.python.org/ and aren't logged in, there is > > no obvious "create issue" button > > Seems like it wouldn't be hugely difficult to fix this, and that would > have the benefit of helping python.org. > > > 2. Searching does not show you excerpts of matching text, just bug > titles > > Same as 1. > > > 3. Roundup uses nonstandard/confusing terminology such as "activity", > > "nosy list" and "actor" instead of "last modified", "cc" and "modified > > by". I couldn't even figure out what the big "Change Note:" box means > > on the issue edit page even looking in the Roundup user guide; by > > process of elimination I guess it is the message you are posting. > > No argument. > > > 4. The interface just looks rough and unfinished. For example, compare > > the "advanced" search of Roundup: > > > > <http://bugs.python.org/issue?@template=search&status=1> > > > > with that of Trac: > > > > <http://trac.edgewall.org/query> > > > > or just look at the size of URL each one generates for a trivial query. > > No argument here either, though I will say it took me a bit to figure > out that the pull down allows you to add queries to trac and that I'm > proposing we eliminate 3 of the fields for Roundup, so it'll shrink > that page a bit. > > In general it seems like these issues could be fixed(except for the > oddball naming, which we should probably keep so we're the same as > CPython) with a little work on Roundup. I doubt that would be more > work than setting up and maintaining our own Trac instance. > > It also looks like the PSF considered Trac back when they selected > Roundup: > http://mail.python.org/pipermail/python-dev/2006-October/069139.html > The reasons given for not selecting Trac were "customization or UI > problems", so it's hard to say exactly what the problems were and if > they've been fixed in the meantime. It'd probably be worth finding > out what they were though. > > Charlie > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- Jim Baker jb...@zy... |
From: Charlie G. <cha...@gm...> - 2008-02-04 19:37:28
|
On Feb 3, 2008 9:06 PM, Jim Baker <jb...@zy...> wrote: > FWIW, Roundup is actually externally hosted by Upfront Systems, a South > African provider focusing on Zope/Plone: > http://www.upfrontsystems.co.za/news/we-host-official-python-issue-tracker-on-roundup It's not so much who's doing the hosting as that we'd share the responsibility of keeping it in order with CPython rather than going it alone. > It would be interesting to examine more of the selection process with Trac > vs Roundup, however as a Django user, I find Trac invaluable in terms of its > transparency in tracking Django bugs and corresponding changesets. I do > believe that trackers have significant value for people who are not > necessarily involved in specific bug fixes, but want to follow what's going > on. (That would be me with respect to Django, I really want to see it as a > system that just runs on Jython as-is, assuming some backend support.) Trac > also seems to be very transparent to Google searches, with a greater > likelihood of my finding the right page. (But that of course could be just > my searches.) And I have great admiration for how the Django project has > effectively used Trac, especially in scaling up for their world-wide > sprints. Is this transparency not available with roundup? I've gotten Roundup to link to other issues and subversion revisions(admittedly in an external viewer, but I prefer Fisheye to Trac for that anyway) pretty easily in the past, so that integration isn't a problem. You can subscribe to get email notifications when an issue changes from roundup too. What else does Trac provide? Charlie |
From: Philip J. <pj...@gr...> - 2008-02-04 22:18:17
|
On Feb 3, 2008, at 3:33 PM, Charlie Groves wrote: > On Feb 3, 2008 1:47 PM, Nicholas Riley <nj...@ui...> wrote: >> In article >> <96c...@ma...>, >> "Charlie Groves" <cha...@gm...> wrote: > >> 2) managing ticket spam >> >> Good things about Trac vs. Roundup include the wiki syntax/Subversion >> integration, wonderful usability and very active development. >> >> I've just seen enough spam-related issues with the Django Trac >> that I'm >> a bit concerned. However, (a) Jython is a lower-traffic project >> and (b) >> we could require everyone filing a ticket create a Trac account, >> which >> should pretty much eliminate the problem. The latter is no different >> from the status quo with SourceForge, in any case. >> >> I run a bunch of Trac sites myself and am quite happy with the >> software; >> they're closed-membership so I've never had to deal with spam. > > We actually allow anonymous bug postings now, but I haven't gotten a > lot of good out of it. In almost every case I've asked for follow-up > from the poster to track down what's going wrong, and I haven't gotten > a response. I am pretty much -1 on trac. I've had a lot of experience with it, and I think trac's tickets system are its most lacking component. Trac's default setup is to allow anonymous ticket postings, hence the spam concerns. What most projects end up doing to avoid the spam is adding a guest user (with its password on the front page of the wiki) that has the ticket creation permission. This foils spammers and still allows anyone to post tickets. A better alternative would be to require anyone that wants to create a ticket to sign up for an account, but unfortunately Trac doesn't provide that feature out of the box. There's now a trac plugin that allows users to register for an account (we use it on http:// trac.pylonshq.com ) -- but my big problem with it is it does not require a valid email address. Many times in other open source projects I've had to deal with tickets that are blocked by further feedback from the originator. Without a registered email address, my requests for followups are more likely to be ignored by the originator. Then the ticket becomes useless and a waste of my time. Another couple things I don't like about trac tickets: o lack of dependency ordering (ticket #5 blocks #10) o the version field is a dropdown, not a select field o though I know they're working on this, a common criticism is that it can be slow on heavier environments -- Philip Jenvey |
From: Frank W. <fwi...@gm...> - 2008-02-05 12:31:26
|
So maybe a better question than which is better for us, Trac or Roundup is: Who is willing to volunteer to support Trac and who is willing to volunteer for Roundup. Volunteers should commit to a significant time, say six months. -Frank |
From: Raghuram D. <dra...@gm...> - 2008-02-05 19:36:19
|
On Feb 5, 2008 7:31 AM, Frank Wierzbicki <fwi...@gm...> wrote: > So maybe a better question than which is better for us, Trac or > Roundup is: Who is willing to volunteer to support Trac and who is > willing to volunteer for Roundup. Volunteers should commit to a > significant time, say six months. I am guessing that roundup maintainance wouldn't involve lot of effort as we will be using python's infrastructure. If that is the case, I will volunteer. For the record, my only prior experience with roundup is as a user of cpython's tracker and I do think it is holding up nicely with heavy use. |