divmod-dev team mailing list archive

[Glyph <glyph@xxxxxxxxxxxxxxxxx>]

On Dec 29, 2012, at 11:55 AM, Florent <florent.xicluna@xxxxxxxxx> wrote:

> Hello,
> 
> Thank you for your prompt answer.
> 
> 2012/12/29 Glyph <glyph@xxxxxxxxxxxxxxxxx>
> 
> Different people have different priorities for their fixes, but PyFlakes is used as (for example) the commit hook on many projects, so introducing new types of spurious errors that need new workarounds is really bad, and of course introducing untested changes that may cause other errors to be missed in some cases is also bad.
> 
> 
> Regarding the test suite, I preserved all the existing test cases. And I merged the patches with their relevant test cases. It is not exhaustive, but at least there's no regression. And the tests are run for all Python versions https://travis-ci.org/florentx/pyflakes

Looks like it is failing on PyPy?  Good job setting up continuous integration though; as far as I know Pyflakes did not have a buildbot before.  So you may already be doing more maintenance than the current maintainers :).

> The contributions from the other repositories are essentially bug fixes, and they are published under the same license. I'm not a lawyer, but in general fixing bugs does not require any kind of explicit contributor agreement if the patch is only few lines.

I'm not talking about an explicit contributor agreement, I'm talking about the implicit contributor agreement of actually making a contribution, rather than making your own separate thing and distributing it elsewhere :).

If you have preserved history carefully though and cited the source of all modifications then it is easy to deal with this problem should it arise.

> You can try this unified version in a virtualenv with:
> 
>     pip install git+git://github.com/florentx/pyflakes.git#egg=pyflakes
> 
> and report any bug with existing hooks.
> 
> Since git encourages you to throw away history, I assume your fork (like all the other forks) has thrown away the record of who did what, and so it will be an impossible mess to sort out whose copyright is whose if a problem arises later.
> 
> I took care to preserve the history, thanks to git-bzr extension.
> This is the reason why I did not forked from the other GitHub repository from kevinw.

In that case I stand corrected, not to mention somewhat pleasantly surprised.  Bravo!  Thank you for dealing with this problem.

> I cloned the https://code.launchpad.net/~vcs-imports/pyflakes/main repository and added back the 3 changesets which were missing with their author names.

Uh... hm.  Is that up to date with the divmod.org repository?  How are you doing merges between them?

> If they can't even be convinced to do that much then it seems like an effort at collaboration is unlikely to succeed.
> 
> 
> What is bad is that there's no central repository to track the future of PyFlakes.
> Even on Launchpad, the code and the bug tracker are not under the same umbrella:
>  - the PyPI page links to https://launchpad.net/pyflakes where we find the bug tracker.

Is it possible to link to both places?

>  - but the code is at https://code.launchpad.net/divmod.org
>     (which is clearly tagged "Legacy" in the title)

OK, so, this was not a good choice of words on my part, and I guess I should have realized the implications.  I have changed it now.

To be clear, though, "legacy" has several meanings, and I meant to use the normal-english noun meaning, not the computer-jargon adjective meaning: <http://en.wiktionary.org/wiki/legacy>.

In case you are not a native english speaker, a "legacy" is something valuable that has been left to you, often by a relative who has died.  The title was therefore meant to evoke the idea that although Divmod (the company) has died, the valuable gift (legacy) that it gave to the community lives on.

> IMHO, the current state of the project does not encourage contributions. (code tagged as "Legacy", issue tracker not at the same place as the code).

This is fair, but I think that step 1 is to work with the current structure and step 2 is to improve the structure.  If nobody raises an objection I will add you to the divmod-dev group so you can do code reviews and help synchronize back and forth, since you clearly care about quality (automated testing etc) and have energy to invest in pyflakes.  What is your launchpad username?

> It "just works" for people running on Python 2. Not more.

Does anyone actually use python 3 though yet, really?

> I sent this to the list in order to give an hand for the code-review and the long-term maintenance of the project.

Great.

> If we keep the current status quo, it is much more likely that the development will continue and be published under a different name.

It is true that you are addressing a real problem, and the proliferation of a million pyflakes forks is definitely a bad thing.

-glyph