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 <[email protected]> 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 <[email protected]> > Hello, > > Thank you for your prompt answer. > > 2012/12/29 Glyph <[email protected]> > > 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 >
-- Mailing list: https://launchpad.net/~divmod-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~divmod-dev More help : https://help.launchpad.net/ListHelp
