You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary <ga...@physics.org> on 2017/12/13 01:13:36 UTC
[Proposal] Migrate platform from Trac to Django
Hi everyone,
I would like to propose that Apache Bloodhound should migrate away from
Trac as a base and instead use the Django web framework.
Some of the advantages we would gain from such a move include:
* Django supports Python 3 (as I understand it from version 2.0, Python
2 support is dropped)
* Django is popular enough that it should be considered a good
transferable skill for our contributors
* Similarly it may be that potential contributors with Django
experience may be attracted to this project
Other benefits we will have is that we will gain better control over the
basic data model rather than having to do any monkey patching or sql
translation.
My proposal as it is does not intend to go any further than settle the
question of our desire to change from Trac to Django but there are
decisions around some of the practicalities that are worth considering.
Given previous discussions, I suspect that we have enough support for
some kind of migration to Django as a base for the project. As far as I
am concerned there is nothing in previous discussions during the setup
of the Apache Bloodhound project that ties the community to Trac as a
base. Our only real commitment regarding our dealing with Trac was that
we would not encourage any kind of fork. Please do put me right if
anyone feels I am misrepresenting the situation of course.
There are still a range of ways that we could implement such a migration
to Django, from starting from scratch to attempting to match the
interfaces provided by Trac so as to limit changes to code that sits on
top of it.
The latter extreme does still feel a bit too much like forking Trac for
my liking so I think we need to be careful if something like that is
seen as best.
To start from scratch will leave us with plenty to do but I am hoping
that we will find ways to integrate other external projects to provide
features, either through Django apps and middleware or beyond.
Regardless of other decisions, the scope of the project should remain
broadly the same, so we would be aiming to have reasonable feature
parity including, amongst other stuff:
* Multi tracker support (multi-product)
* Integrated wiki
* Fast search plugin
* SCM integration
We will obviously also need to ensure that we can migrate from a
bloodhound based on Trac to any new version.
I look forward to hearing thoughts around this.
Cheers,
Gary
Re: [Proposal] Migrate platform from Trac to Django
Posted by Sathishkumar Duraisamy <be...@gmail.com>.
+1 on the proposal !!
On Fri, Dec 15, 2017 at 6:56 AM, Hongjie Tian <ti...@gmail.com>
wrote:
> +1 on that proposal. I've done a lot of work in Django so will be happy to
> help.
>
> 2017-12-14 20:37 GMT+08:00 Jason Morgan <ja...@pavegen.co.uk>:
>
> > +1 on that proposal. I've done a lot of work in Django so will be happy
> to
> > help
> >
> > On 13 December 2017 at 01:13, Gary <ga...@physics.org> wrote:
> >
> > > Hi everyone,
> > >
> > > I would like to propose that Apache Bloodhound should migrate away from
> > > Trac as a base and instead use the Django web framework.
> > >
> > > Some of the advantages we would gain from such a move include:
> > >
> > > * Django supports Python 3 (as I understand it from version 2.0,
> Python
> > > 2 support is dropped)
> > > * Django is popular enough that it should be considered a good
> > > transferable skill for our contributors
> > > * Similarly it may be that potential contributors with Django
> > > experience may be attracted to this project
> > >
> > > Other benefits we will have is that we will gain better control over
> the
> > > basic data model rather than having to do any monkey patching or sql
> > > translation.
> > >
> > > My proposal as it is does not intend to go any further than settle the
> > > question of our desire to change from Trac to Django but there are
> > > decisions around some of the practicalities that are worth considering.
> > >
> > > Given previous discussions, I suspect that we have enough support for
> > > some kind of migration to Django as a base for the project. As far as I
> > > am concerned there is nothing in previous discussions during the setup
> > > of the Apache Bloodhound project that ties the community to Trac as a
> > > base. Our only real commitment regarding our dealing with Trac was that
> > > we would not encourage any kind of fork. Please do put me right if
> > > anyone feels I am misrepresenting the situation of course.
> > >
> > > There are still a range of ways that we could implement such a
> migration
> > > to Django, from starting from scratch to attempting to match the
> > > interfaces provided by Trac so as to limit changes to code that sits on
> > > top of it.
> > >
> > > The latter extreme does still feel a bit too much like forking Trac for
> > > my liking so I think we need to be careful if something like that is
> > > seen as best.
> > >
> > > To start from scratch will leave us with plenty to do but I am hoping
> > > that we will find ways to integrate other external projects to provide
> > > features, either through Django apps and middleware or beyond.
> > >
> > > Regardless of other decisions, the scope of the project should remain
> > > broadly the same, so we would be aiming to have reasonable feature
> > > parity including, amongst other stuff:
> > >
> > > * Multi tracker support (multi-product)
> > > * Integrated wiki
> > > * Fast search plugin
> > > * SCM integration
> > >
> > > We will obviously also need to ensure that we can migrate from a
> > > bloodhound based on Trac to any new version.
> > >
> > > I look forward to hearing thoughts around this.
> > >
> > > Cheers,
> > > Gary
> > >
> >
> >
> >
> > --
> >
> > ------------------------------
> > <http://www.pavegen.com>
> >
> > *Jason Morgan*
> > Principal Engineer
> >
> > t: +44 1223 781555
> > m: +44 (0) 7877 662290
> > ddi: +44 1223 781556
> >
> > *Engineering*
> > Pavegen Systems Ltd
> > Future Business Centre
> > Kings Hedges Road
> > Cambridge, CB4 2HY
> >
> > *Head Office*
> > 5-15 Cromer St
> > London, WC1H 8LS
> >
> > t: +44 (0) 2033 977 279
> > pavegen.com <http://www.pavegen.com>
> > #thenextstep16 <http://www.pavegen.com/livestream>
> >
> > <http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen>
> > <https://www.linkedin.com/company/pavegen-system-ltd->
> > ------------------------------
> >
> > The content of this email and any attachments are confidential and may
> > contain privileged information. If you are not the addressee it may be
> > unlawful for you to read, copy, distribute, disclose or otherwise use the
> > information contained herein.
> >
> > Company Registered no: 06980029 | Company VAT no: 996499723
> >
>
--
Regards,
Sathishkumar D
Re: [Proposal] Migrate platform from Trac to Django
Posted by Hongjie Tian <ti...@gmail.com>.
+1 on that proposal. I've done a lot of work in Django so will be happy to
help.
2017-12-14 20:37 GMT+08:00 Jason Morgan <ja...@pavegen.co.uk>:
> +1 on that proposal. I've done a lot of work in Django so will be happy to
> help
>
> On 13 December 2017 at 01:13, Gary <ga...@physics.org> wrote:
>
> > Hi everyone,
> >
> > I would like to propose that Apache Bloodhound should migrate away from
> > Trac as a base and instead use the Django web framework.
> >
> > Some of the advantages we would gain from such a move include:
> >
> > * Django supports Python 3 (as I understand it from version 2.0, Python
> > 2 support is dropped)
> > * Django is popular enough that it should be considered a good
> > transferable skill for our contributors
> > * Similarly it may be that potential contributors with Django
> > experience may be attracted to this project
> >
> > Other benefits we will have is that we will gain better control over the
> > basic data model rather than having to do any monkey patching or sql
> > translation.
> >
> > My proposal as it is does not intend to go any further than settle the
> > question of our desire to change from Trac to Django but there are
> > decisions around some of the practicalities that are worth considering.
> >
> > Given previous discussions, I suspect that we have enough support for
> > some kind of migration to Django as a base for the project. As far as I
> > am concerned there is nothing in previous discussions during the setup
> > of the Apache Bloodhound project that ties the community to Trac as a
> > base. Our only real commitment regarding our dealing with Trac was that
> > we would not encourage any kind of fork. Please do put me right if
> > anyone feels I am misrepresenting the situation of course.
> >
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> >
> > The latter extreme does still feel a bit too much like forking Trac for
> > my liking so I think we need to be careful if something like that is
> > seen as best.
> >
> > To start from scratch will leave us with plenty to do but I am hoping
> > that we will find ways to integrate other external projects to provide
> > features, either through Django apps and middleware or beyond.
> >
> > Regardless of other decisions, the scope of the project should remain
> > broadly the same, so we would be aiming to have reasonable feature
> > parity including, amongst other stuff:
> >
> > * Multi tracker support (multi-product)
> > * Integrated wiki
> > * Fast search plugin
> > * SCM integration
> >
> > We will obviously also need to ensure that we can migrate from a
> > bloodhound based on Trac to any new version.
> >
> > I look forward to hearing thoughts around this.
> >
> > Cheers,
> > Gary
> >
>
>
>
> --
>
> ------------------------------
> <http://www.pavegen.com>
>
> *Jason Morgan*
> Principal Engineer
>
> t: +44 1223 781555
> m: +44 (0) 7877 662290
> ddi: +44 1223 781556
>
> *Engineering*
> Pavegen Systems Ltd
> Future Business Centre
> Kings Hedges Road
> Cambridge, CB4 2HY
>
> *Head Office*
> 5-15 Cromer St
> London, WC1H 8LS
>
> t: +44 (0) 2033 977 279
> pavegen.com <http://www.pavegen.com>
> #thenextstep16 <http://www.pavegen.com/livestream>
>
> <http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen>
> <https://www.linkedin.com/company/pavegen-system-ltd->
> ------------------------------
>
> The content of this email and any attachments are confidential and may
> contain privileged information. If you are not the addressee it may be
> unlawful for you to read, copy, distribute, disclose or otherwise use the
> information contained herein.
>
> Company Registered no: 06980029 | Company VAT no: 996499723
>
Re: [Proposal] Migrate platform from Trac to Django
Posted by Jason Morgan <ja...@pavegen.co.uk>.
+1 on that proposal. I've done a lot of work in Django so will be happy to
help
On 13 December 2017 at 01:13, Gary <ga...@physics.org> wrote:
> Hi everyone,
>
> I would like to propose that Apache Bloodhound should migrate away from
> Trac as a base and instead use the Django web framework.
>
> Some of the advantages we would gain from such a move include:
>
> * Django supports Python 3 (as I understand it from version 2.0, Python
> 2 support is dropped)
> * Django is popular enough that it should be considered a good
> transferable skill for our contributors
> * Similarly it may be that potential contributors with Django
> experience may be attracted to this project
>
> Other benefits we will have is that we will gain better control over the
> basic data model rather than having to do any monkey patching or sql
> translation.
>
> My proposal as it is does not intend to go any further than settle the
> question of our desire to change from Trac to Django but there are
> decisions around some of the practicalities that are worth considering.
>
> Given previous discussions, I suspect that we have enough support for
> some kind of migration to Django as a base for the project. As far as I
> am concerned there is nothing in previous discussions during the setup
> of the Apache Bloodhound project that ties the community to Trac as a
> base. Our only real commitment regarding our dealing with Trac was that
> we would not encourage any kind of fork. Please do put me right if
> anyone feels I am misrepresenting the situation of course.
>
> There are still a range of ways that we could implement such a migration
> to Django, from starting from scratch to attempting to match the
> interfaces provided by Trac so as to limit changes to code that sits on
> top of it.
>
> The latter extreme does still feel a bit too much like forking Trac for
> my liking so I think we need to be careful if something like that is
> seen as best.
>
> To start from scratch will leave us with plenty to do but I am hoping
> that we will find ways to integrate other external projects to provide
> features, either through Django apps and middleware or beyond.
>
> Regardless of other decisions, the scope of the project should remain
> broadly the same, so we would be aiming to have reasonable feature
> parity including, amongst other stuff:
>
> * Multi tracker support (multi-product)
> * Integrated wiki
> * Fast search plugin
> * SCM integration
>
> We will obviously also need to ensure that we can migrate from a
> bloodhound based on Trac to any new version.
>
> I look forward to hearing thoughts around this.
>
> Cheers,
> Gary
>
--
------------------------------
<http://www.pavegen.com>
*Jason Morgan*
Principal Engineer
t: +44 1223 781555
m: +44 (0) 7877 662290
ddi: +44 1223 781556
*Engineering*
Pavegen Systems Ltd
Future Business Centre
Kings Hedges Road
Cambridge, CB4 2HY
*Head Office*
5-15 Cromer St
London, WC1H 8LS
t: +44 (0) 2033 977 279
pavegen.com <http://www.pavegen.com>
#thenextstep16 <http://www.pavegen.com/livestream>
<http://www.twitter.com/pavegen> <http://www.facebook.com/pavegen>
<https://www.linkedin.com/company/pavegen-system-ltd->
------------------------------
The content of this email and any attachments are confidential and may
contain privileged information. If you are not the addressee it may be
unlawful for you to read, copy, distribute, disclose or otherwise use the
information contained herein.
Company Registered no: 06980029 | Company VAT no: 996499723
Re: [Proposal] Migrate platform from Trac to Django
Posted by Gary <ga...@physics.org>.
I meant to reply to this earlier but various things got in the way... I
think I was going to start with: Ah, now that is interesting.
Thank you for pointing that out, Daniel. The hybid approach could work
though I am still interested in working toward a clean model as a
starting point. Regardless, it does look like we would be able to make
use of the information you point out to simplify work towards an initial
migration.
One interesting problem I expect we will have to deal with is deferring
migration of parts of the model that we are not initially looking to
support. Even if we decide to support the full model from Bloodhound
from the start, including the plugins we install by default, we can't
really be expected to be able to deal with all trac-hacks that users may
have installed. It may be possible to introduce additional plugins to
deal with particularly important trac-hack plugins that re-migrate data
from the original model. Anyway, I'm looking forward to seeing how this
will work!
Cheers,
Gary
On Mon, 18 Dec 2017, at 10:45 AM, Daniel Brownridge wrote:
> Hi Gary,
>
> Another plus one on this!
>
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> One point to note about Django is it's really good for transitioning
> from existing datamodels.
>
> See https://docs.djangoproject.com/en/2.0/howto/legacy-databases/
>
> What can work well is having a hybrid situation of existing code +
> Django looking at same database tables while bringing things up to par
> with the existing functionality. This is kind of like a double heart
> bypass approach. Auto-generate models from existing tables. Models are
> 'unmanaged' in first instance. Then build rest of Django (views, forms
> etc.) around the models. Then excise old Bloodhound / Trac code when
> things are up to scratch. The make models managed plus migrations. Then
> data model can evolve independently from that point forward. Nice point
> is it give an opportunity to keep existing data.
>
> May be more hassle than it's worth but just thought I'd throw it in the
> mix.
>
> Thanks,
>
> Daniel
>
> On 13/12/17 01:13, Gary wrote:
> > Hi everyone,
> >
> > I would like to propose that Apache Bloodhound should migrate away from
> > Trac as a base and instead use the Django web framework.
> >
> > Some of the advantages we would gain from such a move include:
> >
> > * Django supports Python 3 (as I understand it from version 2.0, Python
> > 2 support is dropped)
> > * Django is popular enough that it should be considered a good
> > transferable skill for our contributors
> > * Similarly it may be that potential contributors with Django
> > experience may be attracted to this project
> >
> > Other benefits we will have is that we will gain better control over the
> > basic data model rather than having to do any monkey patching or sql
> > translation.
> >
> > My proposal as it is does not intend to go any further than settle the
> > question of our desire to change from Trac to Django but there are
> > decisions around some of the practicalities that are worth considering.
> >
> > Given previous discussions, I suspect that we have enough support for
> > some kind of migration to Django as a base for the project. As far as I
> > am concerned there is nothing in previous discussions during the setup
> > of the Apache Bloodhound project that ties the community to Trac as a
> > base. Our only real commitment regarding our dealing with Trac was that
> > we would not encourage any kind of fork. Please do put me right if
> > anyone feels I am misrepresenting the situation of course.
> >
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> >
> > The latter extreme does still feel a bit too much like forking Trac for
> > my liking so I think we need to be careful if something like that is
> > seen as best.
> >
> > To start from scratch will leave us with plenty to do but I am hoping
> > that we will find ways to integrate other external projects to provide
> > features, either through Django apps and middleware or beyond.
> >
> > Regardless of other decisions, the scope of the project should remain
> > broadly the same, so we would be aiming to have reasonable feature
> > parity including, amongst other stuff:
> >
> > * Multi tracker support (multi-product)
> > * Integrated wiki
> > * Fast search plugin
> > * SCM integration
> >
> > We will obviously also need to ensure that we can migrate from a
> > bloodhound based on Trac to any new version.
> >
> > I look forward to hearing thoughts around this.
> >
> > Cheers,
> > Gary
>
>
Re: [Proposal] Migrate platform from Trac to Django
Posted by Daniel Brownridge <da...@gmail.com>.
Hi Gary,
Another plus one on this!
> There are still a range of ways that we could implement such a migration
> to Django, from starting from scratch to attempting to match the
> interfaces provided by Trac so as to limit changes to code that sits on
> top of it.
One point to note about Django is it's really good for transitioning
from existing datamodels.
See https://docs.djangoproject.com/en/2.0/howto/legacy-databases/
What can work well is having a hybrid situation of existing code +
Django looking at same database tables while bringing things up to par
with the existing functionality. This is kind of like a double heart
bypass approach. Auto-generate models from existing tables. Models are
'unmanaged' in first instance. Then build rest of Django (views, forms
etc.) around the models. Then excise old Bloodhound / Trac code when
things are up to scratch. The make models managed plus migrations. Then
data model can evolve independently from that point forward. Nice point
is it give an opportunity to keep existing data.
May be more hassle than it's worth but just thought I'd throw it in the mix.
Thanks,
Daniel
On 13/12/17 01:13, Gary wrote:
> Hi everyone,
>
> I would like to propose that Apache Bloodhound should migrate away from
> Trac as a base and instead use the Django web framework.
>
> Some of the advantages we would gain from such a move include:
>
> * Django supports Python 3 (as I understand it from version 2.0, Python
> 2 support is dropped)
> * Django is popular enough that it should be considered a good
> transferable skill for our contributors
> * Similarly it may be that potential contributors with Django
> experience may be attracted to this project
>
> Other benefits we will have is that we will gain better control over the
> basic data model rather than having to do any monkey patching or sql
> translation.
>
> My proposal as it is does not intend to go any further than settle the
> question of our desire to change from Trac to Django but there are
> decisions around some of the practicalities that are worth considering.
>
> Given previous discussions, I suspect that we have enough support for
> some kind of migration to Django as a base for the project. As far as I
> am concerned there is nothing in previous discussions during the setup
> of the Apache Bloodhound project that ties the community to Trac as a
> base. Our only real commitment regarding our dealing with Trac was that
> we would not encourage any kind of fork. Please do put me right if
> anyone feels I am misrepresenting the situation of course.
>
> There are still a range of ways that we could implement such a migration
> to Django, from starting from scratch to attempting to match the
> interfaces provided by Trac so as to limit changes to code that sits on
> top of it.
>
> The latter extreme does still feel a bit too much like forking Trac for
> my liking so I think we need to be careful if something like that is
> seen as best.
>
> To start from scratch will leave us with plenty to do but I am hoping
> that we will find ways to integrate other external projects to provide
> features, either through Django apps and middleware or beyond.
>
> Regardless of other decisions, the scope of the project should remain
> broadly the same, so we would be aiming to have reasonable feature
> parity including, amongst other stuff:
>
> * Multi tracker support (multi-product)
> * Integrated wiki
> * Fast search plugin
> * SCM integration
>
> We will obviously also need to ensure that we can migrate from a
> bloodhound based on Trac to any new version.
>
> I look forward to hearing thoughts around this.
>
> Cheers,
> Gary
Re: [Proposal] Migrate platform from Trac to Django
Posted by Olemis Lang <ol...@gmail.com>.
On Tue, Dec 12, 2017 at 8:13 PM, Gary <ga...@physics.org> wrote:
[...]
>
> I would like to propose that Apache Bloodhound should migrate away from
> Trac as a base and instead use the Django web framework.
>
> [...]
>
> My proposal as it is does not intend to go any further than settle the
> question of our desire to change from Trac to Django but there are
> decisions around some of the practicalities that are worth considering.
>
> [...]
>
> There are still a range of ways that we could implement such a migration
> to Django,
In my opinion this should be the first thing we should do if there is
consensus on migrating to Django . Bloodhound v0.9 (or whatever other
version number is chosen) architecture proposal plus milestones .
[...]
>
> Regardless of other decisions, the scope of the project should remain
> broadly the same, so we would be aiming to have reasonable feature
> parity including, amongst other stuff:
>
> * Multi tracker support (multi-product)
> * Integrated wiki
> * Fast search plugin
> * SCM integration
>
> We will obviously also need to ensure that we can migrate from a
> bloodhound based on Trac to any new version.
>
>
>
> [...]
+1
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Brython committer
http://brython.info
http://github.com/brython-dev/brython
SciPy Latin America - Ambassador
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Proposal] Migrate platform from Trac to Django
Posted by John Chambers <ch...@apache.org>.
It's a +1 for this proposal from me.
I like the idea of a set of modules that can be run independently or
together within the Django framework.
Hopefully there will be more interest in taking part in the project as a
result of this proposal.
I am looking forward to the discussions / working towards a release based
on Django.
Cheers,
John.
On 13 December 2017 at 07:07, Dammina Sahabandu <dm...@gmail.com>
wrote:
> Hi Gary,
>
> Thank you very much for pushing this effort. I agree with almost all the
> facts that you have pointed out. I hope to get back with some more ideas
> after doing some thorough research on the facts that you have already
> noted.
>
> Thanks,
> Dammina
>
> On Wed, Dec 13, 2017 at 6:43 AM, Gary <ga...@physics.org> wrote:
>
> > Hi everyone,
> >
> > I would like to propose that Apache Bloodhound should migrate away from
> > Trac as a base and instead use the Django web framework.
> >
> > Some of the advantages we would gain from such a move include:
> >
> > * Django supports Python 3 (as I understand it from version 2.0, Python
> > 2 support is dropped)
> > * Django is popular enough that it should be considered a good
> > transferable skill for our contributors
> > * Similarly it may be that potential contributors with Django
> > experience may be attracted to this project
> >
> > Other benefits we will have is that we will gain better control over the
> > basic data model rather than having to do any monkey patching or sql
> > translation.
> >
> > My proposal as it is does not intend to go any further than settle the
> > question of our desire to change from Trac to Django but there are
> > decisions around some of the practicalities that are worth considering.
> >
> > Given previous discussions, I suspect that we have enough support for
> > some kind of migration to Django as a base for the project. As far as I
> > am concerned there is nothing in previous discussions during the setup
> > of the Apache Bloodhound project that ties the community to Trac as a
> > base. Our only real commitment regarding our dealing with Trac was that
> > we would not encourage any kind of fork. Please do put me right if
> > anyone feels I am misrepresenting the situation of course.
> >
> > There are still a range of ways that we could implement such a migration
> > to Django, from starting from scratch to attempting to match the
> > interfaces provided by Trac so as to limit changes to code that sits on
> > top of it.
> >
> > The latter extreme does still feel a bit too much like forking Trac for
> > my liking so I think we need to be careful if something like that is
> > seen as best.
> >
> > To start from scratch will leave us with plenty to do but I am hoping
> > that we will find ways to integrate other external projects to provide
> > features, either through Django apps and middleware or beyond.
> >
> > Regardless of other decisions, the scope of the project should remain
> > broadly the same, so we would be aiming to have reasonable feature
> > parity including, amongst other stuff:
> >
> > * Multi tracker support (multi-product)
> > * Integrated wiki
> > * Fast search plugin
> > * SCM integration
> >
> > We will obviously also need to ensure that we can migrate from a
> > bloodhound based on Trac to any new version.
> >
> > I look forward to hearing thoughts around this.
> >
> > Cheers,
> > Gary
> >
>
>
>
> --
> Dammina Sahabandu
> PMC & Committer, Apache Software Foundation
> AMIE (SL)
> Bsc Eng Hons (Moratuwa)
> +94716422775
>
Re: [Proposal] Migrate platform from Trac to Django
Posted by Dammina Sahabandu <dm...@gmail.com>.
Hi Gary,
Thank you very much for pushing this effort. I agree with almost all the
facts that you have pointed out. I hope to get back with some more ideas
after doing some thorough research on the facts that you have already noted.
Thanks,
Dammina
On Wed, Dec 13, 2017 at 6:43 AM, Gary <ga...@physics.org> wrote:
> Hi everyone,
>
> I would like to propose that Apache Bloodhound should migrate away from
> Trac as a base and instead use the Django web framework.
>
> Some of the advantages we would gain from such a move include:
>
> * Django supports Python 3 (as I understand it from version 2.0, Python
> 2 support is dropped)
> * Django is popular enough that it should be considered a good
> transferable skill for our contributors
> * Similarly it may be that potential contributors with Django
> experience may be attracted to this project
>
> Other benefits we will have is that we will gain better control over the
> basic data model rather than having to do any monkey patching or sql
> translation.
>
> My proposal as it is does not intend to go any further than settle the
> question of our desire to change from Trac to Django but there are
> decisions around some of the practicalities that are worth considering.
>
> Given previous discussions, I suspect that we have enough support for
> some kind of migration to Django as a base for the project. As far as I
> am concerned there is nothing in previous discussions during the setup
> of the Apache Bloodhound project that ties the community to Trac as a
> base. Our only real commitment regarding our dealing with Trac was that
> we would not encourage any kind of fork. Please do put me right if
> anyone feels I am misrepresenting the situation of course.
>
> There are still a range of ways that we could implement such a migration
> to Django, from starting from scratch to attempting to match the
> interfaces provided by Trac so as to limit changes to code that sits on
> top of it.
>
> The latter extreme does still feel a bit too much like forking Trac for
> my liking so I think we need to be careful if something like that is
> seen as best.
>
> To start from scratch will leave us with plenty to do but I am hoping
> that we will find ways to integrate other external projects to provide
> features, either through Django apps and middleware or beyond.
>
> Regardless of other decisions, the scope of the project should remain
> broadly the same, so we would be aiming to have reasonable feature
> parity including, amongst other stuff:
>
> * Multi tracker support (multi-product)
> * Integrated wiki
> * Fast search plugin
> * SCM integration
>
> We will obviously also need to ensure that we can migrate from a
> bloodhound based on Trac to any new version.
>
> I look forward to hearing thoughts around this.
>
> Cheers,
> Gary
>
--
Dammina Sahabandu
PMC & Committer, Apache Software Foundation
AMIE (SL)
Bsc Eng Hons (Moratuwa)
+94716422775