Message8796

I see. I'm not privy to how pull requests are handled on that side. I was
under the impression that Bitbucket could detect __only__ the changes
between the head of https://bitbucket.org/jython/jython and the head of
whatever branch I sent a pull request for, as I took care that said branch
is always isolated to the feature/issue at hand. The bookmarks are there
for me to keep track of different heads in one repo, but they are all their
own feature "branches" per se.

~/santoso

On Mon, Jun 23, 2014 at 8:40 AM, Jim Baker <report@bugs.jython.org> wrote:

>
> Jim Baker added the comment:
>
> That would be easier to work with on my end, but just marginally so. It's
> up to you -  a missing committed file is rare and easy to spot with any
> level of testing. However, it should mean we could merge in the changesets
> of the PRs, and bitbucket should be able to detect this and mark the PR as
> merged. Should. I have seen bitbucket in fact not do this. But after all,
> https://bitbucket.org/jython/jython is a mirror, so that it even sort of
> works is perhaps the real thing we should appreciate! ;)
>
> The lack of any CI on PRs is a bigger issue; that we are running PRs on
> bitbucket means it requires more integration work.
>
> I think we need to revisit this whole process post 2.7.0, possibly using
> github and travis CI to frontend hg.python.org/jython, given that it's
> just a final push anyway and we are not using any of the branch support at
> hg.python.org other than for 2.7 vs 2.5 - it's just too heavyweight/error
> prone. Even better workflows as seen in OpenStack would be fantastic.
>
> CPython is looking at a completely revamped workflow, but it's very early
> in the planning process: https://mail.python.org/pipermail/core-workflow/
>
> _______________________________________
> Jython tracker <report@bugs.jython.org>
> <http://bugs.jython.org/issue2146>
> _______________________________________
>