Hi, +1 for Django and Flask. Personally I prefer Django but both frameworks are promising.
Thanks, Dammina On Wed, Oct 25, 2017 at 5:50 PM, Gary <[email protected]> wrote: > 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 > -- Dammina Sahabandu Associate Tech Lead, AdroitLogic Committer, Apache Software Foundation AMIE (SL) Bsc Eng Hons (Moratuwa) +94716422775
