divmod-dev team mailing list archive

[Glyph <glyph@xxxxxxxxxxxxxxxxx>]

Yes, I'm aware of this deficiency in both bzr (which can't export a subtree to a different repo) and launchpad (which can't point at another launchpad project for its code, or associate a repository with a project group; see <https://launchpad.net/divmod>) :-\.  It's very unfortunate.

To be fair, <https://launchpad.net/pyflakes> clearly points at <https://launchpad.net/divmod.org>.

Rummaging around I could not find an official bug report referencing this behavior, so please "affects me too" this: <https://bugs.launchpad.net/launchpad/+bug/1094606>.  I could have sworn I've reported it before...

-g

On Dec 29, 2012, at 12:08 PM, Florent <florent.xicluna@xxxxxxxxx> wrote:

> Funny enough, even Launchpad website says:
> "Launchpad does not know where Pyflakes hosts its code."
> 
> The first line on this page: https://code.launchpad.net/pyflakes
> 
> -- 
> Florent
> 
> 
> 2012/12/29 Florent <florent.xicluna@xxxxxxxxx>
> 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
> 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.
> 
> 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.
> 
> 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.
> 
>  
> 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.
>  - but the code is at https://code.launchpad.net/divmod.org
>     (which is clearly tagged "Legacy" in the title)
> 
> 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).
> It "just works" for people running on Python 2. Not more.
> 
> I sent this to the list in order to give an hand for the code-review and the long-term maintenance of the project.
> If we keep the current status quo, it is much more likely that the development will continue and be published under a different name.
> 
> Best regards,
> 
> -- 
> Florent Xicluna
>