In what direction should Photologue be developed?

[Richard Barran]

The following is just some personal thoughts on how Photologue can evolve over the next few years - comments are welcome!

My personal thinking is that Photologue is a mature, stable project, that does the job that it is designed to do, and does not require any radical changes. There are some very interesting off-shoots of Photologue - including one that manages videos in addition to images. I think that these variations are better suited to forks; Photologue itself can stay pretty much as it feature-wise. As I see it, development of this project should focus on:
- bug fixes.
- compatibility with new versions of Django.
- adding secondary features (e.g. translations or extra template tags) that do not modify core functionality.

A lot has changed since Photologue was launched, and it is probably possible to write a  better gallery application - for example, much of the image management could be stripped out, and handled instead by ImageKit or easy-thumbnails. I think that such changes would be better suited to an entirely new project, and that in practice, Photologue is now in "maintenance mode".

Thoughts?

[Colin Powell]

Hi Richard,

Thanks for taking such an active role in keeping photologue updated. 

I too use photologue in a great many projects, and hadn't appreciated that it would likely not work with future Django releases. I second the need to provide bugfixes and compatibility fixes, and would be glad to help out.

Sad to see photologue age, but Django makes custom apps so easy to build that very few projects that deal explicitly with content tend to hang around very long. It's nearly always easier to "hack up" a quick photo gallery app rather than figure out how to fit photologue into a project.

That said, there may be some benefit to tracking the more robust and feature heavy forks actively and pulling in popular features so as to keep the core photologue project canonical.

The other distinct possibility is to pull a Rails and build a more modular photologue 3 leveraging projects like easy-thumbnail and django-filer. While there are other django gallery projects out there, a quick glance at http://www.djangopackages.com/grids/g/gallery/ shows that photologue is far and away the most mature and useful project, and it might be nice to keep the momentum going.

Just my two cents, but I would be happy to help maintain the project on Github.

- Colin

P.S. would you mind using the git-flow management method?

[Colin Powell]

Ugh, okay, well Photologue is used by lots of people, but it looks like the imagestore application one down from photologue is the future. Still would be interested in maintaining photologue with bugfixes and compatibility updates.

- Colin

[Richard Barran]

Hi Colin,
Thanks for your input & your offer of help.

There's 2 separate subjects here that I will try to answer separately:
1. maintaining the existing Photologue.
2. writing a better photo gallery application.

About subject 1: I'm using Photologue on several different projects ATM, and based on the stat of 25,000 downloads, I guess that a fair number of other people also have it deployed in their production sites.
For these, the rule of "if it ain't broke, don't fix" will apply: Photologue works, the users will be familiar with it, and in most cases a migration to using (for example) django-filer would require both data migration *and* user training - it's quite a bit of effort, for not much advantage (from the user's viewpoint). So my angle when I offered to help maintain Photologue was to keep the status quo.

About subject 2: There's always room to improve the application, some new libraries (e.g. easy-thumbnails) could help both simplify and improve the power of Photologue. I was dubious about finding people with the motivation to make big changes to the codebase, so I downplayed that aspect in my first email. But I have been known to be wrong... :-)
I had thought that big changes would be best handled in a totally separate project, but I like your suggestion of a "Photologue 3" that would allow for a clean break with the past, while still keeping the brand name. This could be handled as a new branch in the repository, that would never merge back to Master - but bug fixes to Master could still be cherry picked to "photologue3". Just a thought.

For the present, I will concentrate on maintaining Photologue, and advertise an open position for a new committer willing on work on big new features :-)
I will work on the Github repo to tidy up the README etc... and start a wiki page on what needs doing for a 2.4 release of Photologue that fixes known bugs and deprecated features.

- Richard

[cubells]

> Richard Barran <richar...@gmail.com>:

>
> Hi Colin,
> Thanks for your input & your offer of help.
>
> There's 2 separate subjects here that I will try to answer separately:
> 1. maintaining the existing Photologue.
> 2. writing a better photo gallery application.
>

I can help you too.

--

cubells

web: vcubells.net
microblogging: identi.ca/cubells
xmpp: cub...@jabber.org

--

[Colin Powell]

Awesome to hear your interest in a possible version 3. And I'd also be happy to help with bugfixes as you start to layout what needs to happen to keep 2.4 relevant with Django updates.

Not to be overly ambitious, but I would love to see the following features in a PL3:

1.  DjCMS integration
   
2.  Robust uploaders (HTML5/bulk/zip/individual files)
   
3.  In-place editing of image descriptions/tags
   
4.  Bulk tag editor (for a gallery or arbitrary selection of images, i.e. tag)
   
5.  Leverage easy-thumbnail (but what about custom filters/watermarks?)
   
6.  Images & videos out of the box, with an extendable BaseMedia model for arbitrary media cataloging
   
7.  Mobile templates (uploaders?)
   
8.  Modular slideshow implementation so you can choose your jquery slider 
   
1. (or maybe we just have choose one...hello Nivo Slider or jquery.slider )
2. One way or another there should be a built-in slideshow tag/view
9. Choose/upload album cover
10. Download all images in a gallery or a search/tag query
11. Pingback support
12. Themeing support off stock templates? Maybe that's going overboard

Anyway, that's a start. I feel pretty comfortable with a great many of those tasks, and would love to start hacking away on the 2.4 codebase to see how much we can break and clean up. 

For development model, I suggest we start a release/3 branch and hack on it until it's stable and then make it master, with the release/2.4 partially frozen in time, with bugfixes and compatibility updates accepted. I would also like to put forward the use of the "git flow" model of development for proceeding on github. Google it if you've never used it, but it keeps things very sane when you have big changes in a codebase but still need to maintain older versions.

Let me know how you feel about this, and also when you start documentation on the github wiki.

Looking forward to a brave new world of 2.4 being Django 1.5 ready and a possible PL3!

- Colin

[Federico Maggi]

On Mon, Aug 6, 2012 at 7:28 AM, Colin Powell <colin....@gmail.com> wrote:
> DjCMS integration

may I propose django-mezzanine in its stead? It looks a very clean
and self-contained CMS app.

BTW, I did some initial refactoring of django-photologue (before this
thread started), and I added an ordering field through a model:

* https://github.com/phretor/django-photologue

Cheers,

-F

[Marcos Daniel Petry]

Hi folks

Like many, I also use the photologue in many projects and also did a fork with some improvements

It's the great idea of ​​the project evolve! Last year I tried to get in touch with justin, but no answer :(

I think everyone agrees that github is a much better place to evolve than GoogleCode, then I think we can do is:

• List all extra features implemented on forks and see which fits better in the maintenance release and it fits better in version 3
• Choose a base project on github and all those interested in evolve the project. make a fork from that project, so we will have a better idea of ​​who is creating new features and let make easier the merges through the pull-through requests

About a new feature that may we deploy: Instead of setting the mechanism of image manipulation, we could abstract this logic through plugins, this way, the user chooses what he thinks best.

My company has created a service called thumbor. It has has several nice features like facial recognition and cut and smart thumbnailing. The project won several contributions and is stable as well, is one of the features I've been thinking about developing

new features in my fork: https://github.com/petry/django-photologue/wiki/New-Features

So, what do you think?

[Richard Barran]

On 6 Aug 2012, at 16:13, Marcos Daniel Petry wrote:

Hi folks

Hi Marcos!

Like many, I also use the photologue in many projects and also did a fork with some improvements

I know - I forked it myself and added some more improvements :-)

It's the great idea of ​​the project evolve! Last year I tried to get in touch with justin, but no answer :(

I think that Justin is very busy man :-(

I think everyone agrees that github is a much better place to evolve than GoogleCode, then I think we can do is:

• List all extra features implemented on forks and see which fits better in the maintenance release and it fits better in version 3
• Choose a base project on github and all those interested in evolve the project. make a fork from that project, so we will have a better idea of ​​who is creating new features and let make easier the merges through the pull-through requests

Agreed about using Github, I have posted a mail "maintenance releases of django-photologue" with my suggestions on what to clone etc...

About a new feature that may we deploy: Instead of setting the mechanism of image manipulation, we could abstract this logic through plugins, this way, the user chooses what he thinks best.

Something for a 3.X branch? Maybe there's room for another thread to discuss this.

My company has created a service called thumbor. It has has several nice features like facial recognition and cut and smart thumbnailing. The project won several contributions and is stable as well, is one of the features I've been thinking about developing

new features in my fork: https://github.com/petry/django-photologue/wiki/New-Features

So, what do you think?

Features like class-based views are a "must-have" - Photologue will not work in Django 1.5 without them. Would you be willing to claim that ticket and work on it? :-)

- Richard

[Richard Barran]

On 6 Aug 2012, at 07:51, Federico Maggi wrote:

> On Mon, Aug 6, 2012 at 7:28 AM, Colin Powell <colin....@gmail.com> wrote:
>> DjCMS integration
>
> may I propose django-mezzanine in its stead? It looks a very clean
> and self-contained CMS app.

Personally, I like django-cms :-)
My point is that integration with a CMS application is a personal thing - each developer will have his favourite and there will be no clear consensus. Maybe it's something best left to third-party plugins and/or forks of Photologue.

> BTW, I did some initial refactoring of django-photologue (before this
> thread started), and I added an ordering field through a model:
>
> * https://github.com/phretor/django-photologue

Could be an interesting feature to add, even to the 2.X branch - do you want to open an "enhancement" ticket for it?

PS I noticed that you've refactored the README for Github - would you want to do the same thing for the new clone at https://github.com/jdriscoll/django-photologue? :-)

- Richard

[Federico Maggi]

On Tue, Aug 7, 2012 at 3:23 PM, Richard Barran <richar...@gmail.com> wrote:
> On 6 Aug 2012, at 07:51, Federico Maggi wrote:
>
>> On Mon, Aug 6, 2012 at 7:28 AM, Colin Powell <colin....@gmail.com> wrote:
>>> DjCMS integration
>>
>> may I propose django-mezzanine in its stead? It looks a very clean
>> and self-contained CMS app.
>
> Personally, I like django-cms :-)
> My point is that integration with a CMS application is a personal thing - each developer will have his favourite and there will be no clear consensus. Maybe it's something best left to third-party plugins and/or forks of Photologue.

I agree that django-photologue should remain just a photoblog app,
and nothing else. There are two paths that could be followed:

1) [photologue as a reusable app] - pretty much as it is now, with
the drawback of less people using it because the deployment takes some
effort (i.e., for me, easy deployment really means `pip install
django-photologue && django-admin.py start` - take a look at sentry,
for instance)

2) [photologue as a self-contained app with a "plugin" mechanism]
- what I see here is an all-in-one app that ships with many common
batteries that can be enabled/disabled easily. Maybe, django-logan
could be considered to ease the deployment and increase the "self
containedness".

>> BTW, I did some initial refactoring of django-photologue (before this
>> thread started), and I added an ordering field through a model:
>>
>> * https://github.com/phretor/django-photologue
>
> Could be an interesting feature to add, even to the 2.X branch - do you want to open an "enhancement" ticket for it?

I unfortunately don't have much time, but I can definitely open an
enhancement ticket with the patch code.

> PS I noticed that you've refactored the README for Github - would you want to do the same thing for the new clone at https://github.com/jdriscoll/django-photologue? :-)

Done!

-F

[Richard Barran]

On 6 Aug 2012, at 06:28, Colin Powell wrote:

Awesome to hear your interest in a possible version 3. And I'd also be happy to help with bugfixes as you start to layout what needs to happen to keep 2.4 relevant with Django updates.

Not to be overly ambitious, but I would love to see the following features in a PL3:

1.  DjCMS integration
   
2.  Robust uploaders (HTML5/bulk/zip/individual files)
   
3.  In-place editing of image descriptions/tags
   
4.  Bulk tag editor (for a gallery or arbitrary selection of images, i.e. tag)
   
5.  Leverage easy-thumbnail (but what about custom filters/watermarks?)
   
6.  Images & videos out of the box, with an extendable BaseMedia model for arbitrary media cataloging
   
7.  Mobile templates (uploaders?)
   
8.  Modular slideshow implementation so you can choose your jquery slider 
   
1. (or maybe we just have choose one...hello Nivo Slider or jquery.slider )
2. One way or another there should be a built-in slideshow tag/view
9. Choose/upload album cover
10. Download all images in a gallery or a search/tag query
11. Pingback support
12. Themeing support off stock templates? Maybe that's going overboard

Anyway, that's a start. I feel pretty comfortable with a great many of those tasks, and would love to start hacking away on the 2.4 codebase to see how much we can break and clean up. 

There's an open position for "official maintainer of the django-photologue 3.X branch" ;-)

For development model, I suggest we start a release/3 branch and hack on it until it's stable and then make it master, with the release/2.4 partially frozen in time, with bugfixes and compatibility updates accepted. I would also like to put forward the use of the "git flow" model of development for proceeding on github. Google it if you've never used it, but it keeps things very sane when you have big changes in a codebase but still need to maintain older versions.

I can see how this would be useful for the 3.X project, for example. I think that git flow is well suited to large projects with several developers working in parallel, and many new features in the pipeline that have to be tested before release.

For the 2.X series, I think (hope?) that after an initial mad rush, we will settle down to maybe 10 or so commits per year. For this low level of activity, it's better to keep things as simple as possible. Also, I don't want potential contributors to spend a lot of time working out how the project is organised.

So I'd be more inclined to go with a pretty basic setup:

- use just a master branch. Fixes/small changes are written in other repos, with a pull request to bring them in.

- every now and then a new release is made by tagging the last commit, preparing a .tar.gz, and putting it on Pypi.

- if there are any serious bugs/security weaknesses found then we have to start a branch for that release, and make another .tar.gz.

Thoughts?

[Marcos Daniel Petry]

2012/8/7 Richard Barran <richar...@gmail.com>

On 6 Aug 2012, at 16:13, Marcos Daniel Petry wrote:

Hi folks

Hi Marcos!

Like many, I also use the photologue in many projects and also did a fork with some improvements

I know - I forked it myself and added some more improvements :-)

wow, just saw now that there were some forks of my project :) 

It's the great idea of ​​the project evolve! Last year I tried to get in touch with justin, but no answer :(

I think that Justin is very busy man :-(

I think everyone agrees that github is a much better place to evolve than GoogleCode, then I think we can do is:

• List all extra features implemented on forks and see which fits better in the maintenance release and it fits better in version 3
• Choose a base project on github and all those interested in evolve the project. make a fork from that project, so we will have a better idea of ​​who is creating new features and let make easier the merges through the pull-through requests

Agreed about using Github, I have posted a mail "maintenance releases of django-photologue" with my suggestions on what to clone etc...

I just answered that thread 

About a new feature that may we deploy: Instead of setting the mechanism of image manipulation, we could abstract this logic through plugins, this way, the user chooses what he thinks best.

Something for a 3.X branch? Maybe there's room for another thread to discuss this.

or discuss new features of the project directly on github and classify the tasks are for the new version or maintenance 

My company has created a service called thumbor. It has has several nice features like facial recognition and cut and smart thumbnailing. The project won several contributions and is stable as well, is one of the features I've been thinking about developing

new features in my fork: https://github.com/petry/django-photologue/wiki/New-Features

So, what do you think?

Features like class-based views are a "must-have" - Photologue will not work in Django 1.5 without them. Would you be willing to claim that ticket and work on it? :-)

I had made this change in my repository last year, but I believe that lack a better test coverage, I must start working on it in coming days.

I also saw that I sent a bug using django 1.5, should I check it soon

- Richard

--
You received this message because you are subscribed to the Google Groups "Django Photologue" group.

To post to this group, send email to django-p...@googlegroups.com.
To unsubscribe from this group, send email to django-photolo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-photologue?hl=en.

--
Marcos Daniel Petry
http://petry.cc