Menu
▾
▴
pyblosxom-devel
|
From: Will Kahn-G. <wi...@bl...> - 2011-11-24 00:20:35
|
I updated the roundup package on bluesock (the server that hosts the Pyblosxom bug tracker) and inadvertently stomped on the fix I made to roundup. Then I started getting lots of error emails from roundup because it's "helpful". Took me about 30 minutes to figure out how I fixed it the last time and re-fix it. Irritating. That got me thinking. A while back, when we talked about switching to git and picking a host, I remember a lot of people said they already had github accounts. I picked gitorious because at the time is was close enough feature-wise and it was Free Software. I picked roundup because it seemed like a decent choice. At this point, I want to revisit those decisions. I'm thinking of moving things around in this way: 1. Move from gitorious to github. In doing this, we gain post-commit hooks some of which are wildly useful, an issue tracker, inline comments for pull requests, probably an order of magnitude more people who already have github accounts and who are used to drive-by-fixes, and probably some other github features I haven't yet discovered. 2. Move the Pyblosxom manual to ReadTheDocs. We're already using Sphinx. If we switch to github, then it's a post-commit hook to update it everytime something gets checked in. This would be really nice. 3. Ditch roundup and use the github issue tracker. After that we can see where things are at. Any thoughts on this? Is anyone against it? If not, I'm going to do this before releasing 1.5 since I want to update the urls everywhere. Hopefully before the end of this year. /will |
|
From: Tim G. <tg...@pr...> - 2011-11-24 03:13:38
|
On Nov 23, 2011 at 07:20 PM -0500, Will Kahn-Greene wrote: >Any thoughts on this? Is anyone against it? If not, I'm going to do this >before releasing 1.5 since I want to update the urls everywhere. >Hopefully before the end of this year. Makes sense to me. Github is nice. |
|
From: Wari W. <wa...@ho...> - 2011-11-24 04:13:44
|
<quote who="Will Kahn-Greene"> > 1. Move from gitorious to github. > 2. Move the Pyblosxom manual to ReadTheDocs. > 3. Ditch roundup and use the github issue tracker. > Any thoughts on this? Is anyone against it? If not, I'm going to do this > before releasing 1.5 since I want to update the urls everywhere. Wow, hey, I'm totally not against this. I use Gitorious on our private install in our company and it's a great product for that. Since we have Redmine as our bugtracker/documentation store, these two worked somewhat seemlessly and has been something that the company is accustomed to. Moving to Github is definitely a plus as you gain the all-in-one featureset of a bug tracker, repository, etc. And to top it all up, I love the edit-in- place-auto-fork-and-merge-request in less than a minute of kung-fu moves feature, etc. And the community around it, it makes Gitorious like a quiet boy sitting in the corner. I have no idea why Github is so popular. |
|
From: Dieter P. <di...@pl...> - 2011-11-24 08:17:23
|
On Thu, 24 Nov 2011 10:30:05 +0800 "Wari Wahab" <wa...@ho...> wrote: > And the community around it, it makes Gitorious like a quiet boy > sitting in the corner. I have no idea why Github is so popular. because it's a really good application, integrates well, is free and the people who run it are capable and very active in open source communities (ruby, git and more) personally I find it a pain to navigate in gitorious. I have the impression that what I'm looking for is usually not where I expect to find it. The last time this came up I was pro github, and I still am :) Dieter > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel |
|
From: <war...@gm...> - 2011-11-24 09:39:37
|
On 24 November 2011 AM 9:00:04 Dieter Plaetinck wrote: > personally I find it a pain to navigate in gitorious. I have the impression > that what I'm looking for is usually not where I expect to find it. Heh.. That was my first time trying to look for pyblosxom in Gitorious. Then again, was very new to this 'git' thing, and forks, and clones, etc. But quite at home with our install at the office. So github it is? +1 on that for me. |
|
From: Sebastian S. <Seb...@SS...> - 2011-12-02 06:36:23
|
On Wed, 23 Nov 2011 19:20:23 -0500 (EST), Will Kahn-Greene wrote: A bit lateish, but I have no strong opinions on gitorious vs github (I think keeping the repo at gitorious would be fine). But I am always for hosting things at existing infrastructure, relieving you from the burden of maintaining that. So using some bug tracker at github, assembla or whereever, sounds good to me. github or gitorious? ppff, it's just a different git@ URL ;-) Sebastian |
|
From: Dieter P. <di...@pl...> - 2011-12-02 08:11:49
Attachments:
signature.asc
|
On Thu, 01 Dec 2011 16:25:18 +0100 Sebastian Spaeth <Seb...@SS...> wrote: > github or gitorious? ppff, > it's just a different git@ URL ;-) > I know you meant that as a joke, but seriously, github and gitorious are quite different. personally i find gitorious very hard to navigate, their UI/menus aren't very well thought out. |
|
From: <Seb...@ss...> - 2011-12-03 19:56:31
|
I know both well... :-) what I implied is that the git repo is essentially the same. I hardly ever view the web ui of my githhub projects, and you can always mix with better infrastructure, ie bug trackers from assembla.com or whatnot. That having said, github is certainly cool. Sebastian >> github or gitorious? ppff, >> it's just a different git@ URL ;-) >> > >I know you meant that as a joke, but seriously, github and gitorious >are quite different. >personally i find gitorious very hard to navigate, their UI/menus >aren't very well thought out. |
|
From: seanh <sn...@gm...> - 2011-12-02 18:06:12
|
> 1. Move from gitorious to github. In doing this, we gain post-commit > hooks some of which are wildly useful, an issue tracker, inline comments > for pull requests, probably an order of magnitude more people who already > have github accounts and who are used to drive-by-fixes, and probably some > other github features I haven't yet discovered. Github can host the project website for you as well, and a wiki. The one disadvantage is that it's not open source whereas gitorious is. Hosting your git repo on github doesn't tie you down to anything as you can always move it somewhere else if you want to. But the more you come to depend on github's extra features like the issue tracker, the wiki, etc., the more you're becoming dependent on a proprietary platform. |
|
From: will kahn-g. <wi...@bl...> - 2011-12-02 18:23:16
|
On Fri 02 Dec 2011 01:05:57 PM EST, seanh wrote: >> 1. Move from gitorious to github. In doing this, we gain post-commit >> hooks some of which are wildly useful, an issue tracker, inline comments >> for pull requests, probably an order of magnitude more people who already >> have github accounts and who are used to drive-by-fixes, and probably some >> other github features I haven't yet discovered. > > Github can host the project website for you as well, and a wiki. > > The one disadvantage is that it's not open source whereas gitorious is. > Hosting your git repo on github doesn't tie you down to anything as you > can always move it somewhere else if you want to. But the more you come > to depend on github's extra features like the issue tracker, the wiki, > etc., the more you're becoming dependent on a proprietary platform. I dig what you're saying. I definitely don't want to repeat another SF situation--that sucked. I currently plan to use github for code, the issue tracker, and patch workflow. We can trivially move the code elsewhere. The patch workflow is transient, so if we move elsewhere we'll lose that and change workflows. That brings us to the issue tracker. I'm pretty ok with ditching issues in one system and moving to a new system. More often than not, issues that languish are either fixed, uninteresting, not fleshed out or in some state where ditching it isn't a big deal. I don't want this project to accrue task-debt. We either work on things we're interested in, or we don't. The set of issues we're interested in working on changes. If I had my druthers, I'd have our bug system auto-expire bugs that haven't been touched in a couple of months. Given that, switching to the github issue tracker is fine and doesn't lock us in. I'm game for hosting our own bug tracker, but I don't want to use Trac, Roundup or a non-Python-based tracker. That really limits the options. Essentially it means I should write my own bug tracker that meets my needs. I may do that at some point, but not any time soon. The website (currently at http://pyblosxom.bluesock.org/) will stay where it is and act as an anchor for the project allowing us to switch infrastructure without losing people. That's what I'm currently thinking. /will |
|
From: Dieter P. <di...@pl...> - 2011-12-02 18:38:06
|
On Fri, 02 Dec 2011 13:23:03 -0500 will kahn-greene <wi...@bl...> wrote: > Given that, switching to the github issue tracker is fine > and doesn't lock us in. GH issues doesn't lock us in? is that a typo or am i missing something? > I don't want to use Trac, Roundup what's wrong with roundup? |
|
From: will kahn-g. <wi...@bl...> - 2011-12-02 19:21:53
|
On Fri 02 Dec 2011 01:37:08 PM EST, Dieter Plaetinck wrote: > On Fri, 02 Dec 2011 13:23:03 -0500 > will kahn-greene <wi...@bl...> wrote: > >> Given that, switching to the github issue tracker is fine >> and doesn't lock us in. > > GH issues doesn't lock us in? is that a typo or am i missing something? You removed the context for that statement in your reply. It doesn't lock us in because I don't really care about leaving issues if we switch trackers. >> I don't want to use Trac, Roundup > > what's wrong with roundup? Pretty sure I've talked about this already, but I'm game for iterating through it again. Roundup doesn't have milestones by default. I've added mediocre milestone stuff based on the original round of milestone stuff that Jack at OpenHatch did. However, the urls for milestones are awful and generally I find the ui to be problematic. There are bugs in Roundup that irritate me. One of them is that the ExportCSV action doesn't check the querystring _before_ writing stuff to output. So when it hits a problem, it's already written stuff to output and thus you get back an HTTP 200 response with gibberish in it. The problem there is that Google bot and other search engines for some reason put bad stuff in the querystring and thus I get a ton of error emails. I tried to fix this in Roundup and write up a test case, but the Roundup code is really funky and totally alien to me and after spending a bunch of time on it, I just gave up. On top of that, I think the ui is clunky and it took me a day or two to figure out how to set it up. Ipso facto, I find Roundup more complex than I can wrap my head around, doesn't have features I want out of the box, and has bugs that affect me. /will |
Thanks for helping keep SourceForge clean.
X