Daniel, Sorry for the delay in the message appearing - it went via moderation.
My reply to the content is at the end. On Wed, 25 Oct 2017, at 11:39 AM, Daniel Brownridge wrote: > I used Bloodhound as our production issue management in a small > organisation a few years back. > > In many respects it worked very well but there where a few glitches that > became frustrating over time. > > I gravitated towards Bloodhound as at the time it appeared to be the > best thing open source could offer as an alternative to Jira which is > what I have encountered most frequently in use in businesses. > > I would support a move to python 3. In terms of changing the base I > think this is potentially a sensible idea. In terms of attracting > developers to the project Django would seem to be a very sensible > choice. This is partly coming from the fact it's what I have most > experience with but pragmatically the number of people familiar with > working on a Django project will vastly outweigh the number of people > who are familiar with the Trac code base. > > I'm sure there are a myriad of other potential options too, but, if it's > not Django then whatever does become the base of the project should > ideally have a lot of common ground to provide people an easy way into > to understanding the code. > > My assumption in making this point is that Bloodhound's ultimate goal is > to be the best open source bug/issue/task management tool it can be, not > to reinvent the wheel in other areas. > > To put it another way, and appreciate I might be a lone voice here, I > personally don't have much appetite to become skilled in trac, because > that doesn't take me much further, but as an opportunity to keep working > with a code base (i.e. Django etc) I know is transferable I'd be much > keener to contribute. > > Does this make sense to anyone? > > Thanks, > > Daniel > > ;On 25/10/17 08:13, Allan Swanepoel wrote: > > Gary, i completely agree with you > > wouldnt we end up recreating the wheel here then? > > https://github.com/Djacket/djacket ; gitLab; https://gitea.io/en-US/ > > just to name a few? > > > > > > On Wed, Oct 25, 2017 at 4:18 AM, Gary <[email protected]> wrote: > >> On Mon, 23 Oct 2017, at 08:33 PM, Allan Swanepoel wrote: > >>> As a massive outsider to this project, I joined the ML in the hope to > >>> learn more about the bloodhound project, only to be met with the > >>> possible archiving of it. > >>> > >>> Please don't get the wrong impression, I enjoy python and open source > >>> as much as i enjoy contributing to OSS. > >>> > >>> I would like to raise a few troublesome concerns I would have with > >>> this project (again, this is one person): > >>> 1) Trac - the foundation of BH is still on Py2 - with basically 2 yrs > >>> until py2 is declared EOL (2020) . > >>> 2) Trac Version - Trac is on version 1.2(stable), afaik, BH has only > >>> been tested on Trac 0.11 - 0.13 > >>> > >>> So, i guess my day 1 question would be how would you get Bloodhound to > >>> py3 in ~2yrs, especially if the platform its based on isnt there yet? > >> I think you make some very good points here. I would prefer to see > >> Bloodhound running on Python 3 and I am far from convinced that being > >> based on Trac will help us. > >> > >> Although it might point to a much larger effort, I would be interested > >> in opinions on whether the community (i.e. any part of the community > >> that wants to move forward with Bloodhound) would consider moving away > >> from Trac as the base for the project. > >> > >> Cheers, > >> Gary > > > > > > So, I probably should not jump on this to reply too quickly when it happens to be a message that agrees with my suspicions! There may be other points of view but it seemed likely that knowledge of Trac itself was a disincentive as something extra to learn. >From my point of view, the two obvious choices for web framework would be either Django or Flask. I believe they would have the advantage of being relatively easy to pick up, and would represent a much more transferable skill. As I think Daniel says, being based on either Django or Flask could attract those who are interested in gaining experience in these so that they get a transferable skill out of this. It may also be attractive to those who already have skills in these areas. We do need to consider the size of the task we are looking at though. Starting from scratch might be possible. We could look to adapt as much of the existing work as we can as well. Cheers, Gary
