Combine localflavor apps again

[Jannis Leidel]

Hi all,

I'd like propose to combine all the django-localflavor-* packages - that were moved out of contrib a while ago - into a new "django-localflavor" package. None of the current maintainers would lose the commit bit. I'm ready to do the heavy lifting for that.

Ever since the localflavor apps were removed from contrib I've seen many stale ones, lingering on Github, only collecting issues and pull requests, without much guidance. We have been missing maintainers since the removal from contrib, even if some of the core developers helped out every once in a while. Recently we added a few more maintainers for each of those packages since they asked for it, which is great. But frankly I think that's not enough. Up until now only 7 of the 44 localflavor on github.com/django have been re-released on PyPI as separate packages. In other words, we have a success rate of handing over the maintainership of ~15%. I think that's because there is a lot of maintenance friction for each package.

With the split in packages we also broke the maintenance of translations of those localflavors, by removing those apps from the previously well established workflow using Transifex and left it to the maintainers to find a way. Especially for that kind of app a rather glaring mistake, IMO.

We also stopped being able to re-use code between localflavors, for example cryptographic code about ID validation, which in my opinion is a security liability that alone should be reason enough to have only one package.

There was also never a clear plan for releasing or deprecation of localflavor packages, which is the opposite to what we've been doing in the past with our release policy.

So what I propose to fix this is simple:

- combine the localflavor packages into one Python package again, call it django-localflavor
- give all the individual country maintainers also access to that package
- have a central documentation, e.g. django-localflavor.readthedocs.org
- update the Django docs to point to that package
- ask the maintainers of the 7 already released packages to point to the newly created django-localflavor

What do you think?

Jannis

[Aymeric Augustin]

2013/5/21 Jannis Leidel <lei...@gmail.com>

I'd like propose to combine all the django-localflavor-* packages - that were moved out of contrib a while ago - into a new "django-localflavor" package. None of the current maintainers would lose the commit bit. I'm ready to do the heavy lifting for that.

I'd love to see localflavor in a better shape, even though I don't have strong opinions on what should be done.

The situation would certainly be less dire if we had looked for maintainers. Did we say clearly that we wanted to hand over the repositories to local maintainers?

Merging the repositories again will require a non-negligible amount of work and a second migration for users who already started using django_localflavor_xx.

However, if you're convinced that's the right thing to do at this point, I don't oppose that move. It would help maintain best practices, especially wrt. backwards-compatibility and testing.

--
Aymeric.

[Łukasz Langa]

On 21 maj 2013, at 14:51, Jannis Leidel <lei...@gmail.com> wrote:

- combine the localflavor packages into one Python package again, call it django-localflavor
- give all the individual country maintainers also access to that package
- have a central documentation, e.g. django-localflavor.readthedocs.org
- update the Django docs to point to that package
- ask the maintainers of the 7 already released packages to point to the newly created django-localflavor

What do you think?

+1

This will make handling backwards compatibility easier, especially by having a central deprecation policy on outdated or invalid data in separate localflavors. Users have the right to know when compatibility might break and when a fix is going to get deployed. Such a combination will also enable users to use a flavor that lacks a formal maintainer.

Just $0.02 from the just-proclaimed django-localflavor-pl maintainer.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev

[Donald Stufft]

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>


This sounds ok to me.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Jacob Kaplan-Moss]

On Tue, May 21, 2013 at 7:51 AM, Jannis Leidel <lei...@gmail.com> wrote:
> What do you think?

I have no opinions either way, happy to help out if this is the
direction you want to go.

Jacob

[ptone]

On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote:

Hi all,

I'd like propose to combine all the django-localflavor-* packages - that were moved out of contrib a while ago - into a new "django-localflavor" package. None of the current maintainers would lose the commit bit. I'm ready to do the heavy lifting for that.

 

What do you think?

Clearly the current fragmentation has proven unworkable, so I think there is only upside in trying this approach.

I think there needs to be someone who will coordinate the version bumps and releases to PyPI  - perhaps just document that it will be released n times per year on dates a, b, c, d - and just roll whatever changes make it in by those dates? Maybe you are volunteering for that as well ;-)

so +1 from me.

-Preston

[Jannis Leidel]

Agreed, the maintenance policy would be along the lines of what Django does, but it wouldn't be hard-locked into Django's release cycle. In case there would be changes in Django that require a backwards-incompatible change localflavor ought to support both APIs (as long as the old API is in a maintained version of Django).

Jannis

[Jannis Leidel]

Oh, I am indeed volunteering to do the initial re-combination and act as release manager afterwards. I'm not a huge fan of forced time based releases, but I can't see another good indicator to do a release except "when needed". I'll know better once I have a better picture of the changes that were made to the localflavors in the recent months.

Jannis

[Trey Hunner]

On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote:

So what I propose to fix this is simple:

- combine the localflavor packages into one Python package again, call it django-localflavor
- give all the individual country maintainers also access to that package
- have a central documentation, e.g. django-localflavor.readthedocs.org
- update the Django docs to point to that package
- ask the maintainers of the 7 already released packages to point to the newly created django-localflavor 

I am also for this.

However, if the django-localflavor merge doesn't occur, at a minimum the django-localflavor-* ecosystem needs:

- A procedure for requesting access to maintain a django-localflavor-* variant

- A project for maintaining suggestions and guidelines for django-localflavor maintainers (e.g. use PyPI, add South rules, use tox)

- Relevant links to procedures and guidelines in every django-localflavor-* README file

I volunteer help merge changes for the django-localflavor-us variant if help is needed.

[Jannis Leidel]

On 24.05.2013, at 19:28, Trey Hunner <tr...@treyhunner.com> wrote:

> On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote:
> So what I propose to fix this is simple:
>
> - combine the localflavor packages into one Python package again, call it django-localflavor
> - give all the individual country maintainers also access to that package
> - have a central documentation, e.g. django-localflavor.readthedocs.org
> - update the Django docs to point to that package
> - ask the maintainers of the 7 already released packages to point to the newly created django-localflavor
>
> I am also for this.

Great to hear, as you're one of the people that successfully released one of the standalone apps to PyPI.

> However, if the django-localflavor merge doesn't occur, at a minimum the django-localflavor-* ecosystem needs:
>
> - A procedure for requesting access to maintain a django-localflavor-* variant
> - A project for maintaining suggestions and guidelines for django-localflavor maintainers (e.g. use PyPI, add South rules, use tox)
> - Relevant links to procedures and guidelines in every django-localflavor-* README file
>
> I volunteer help merge changes for the django-localflavor-us variant if help is needed.

Thanks, much appreciated, I've started the work on merging the apps again, and hope to have a ready version the coming week.

Jannis

[Horst Gutmann]

Same, of course, from me for localflavor-at. If there is anything I can do to help, please let me know :-)

Cheers,

Horst

 

Thanks, much appreciated, I've started the work on merging the apps again, and hope to have a ready version the coming week.

Jannis