Re: NEWS entries for pip

2017-05-02 Thread Donald Stufft

> On May 2, 2017, at 4:08 PM, Paul Moore  wrote:
> 
> On 2 May 2017 at 20:50, Donald Stufft  wrote:
>> It’s generally only a two step process if there isn’t an existing issue
>> you’re fixing. If you’re fixing an issue you can/should just use the issue’s
>> number instead of the PRs number. We can make it possible to do like
>> .feature and such too though if we think the random PR without an
>> issue case is big enough to warrant a special case.
> 
> Hmm, maybe. I tend to do all changes as PRs, not all of which come
> from an issue. But it's also true that it's not immediately obvious
> (to me) from the docs that it's OK to use the issue number rather than
> the PR number. I could try rewording the docs to that effect, but to
> do so will need the 2-step process as there's no issue for this :-)

Rewording the docs would be fine, and I think it would be a trivial fix since 
it’s just messing with development docs.

> 
> This originally came up for me because the discussion on
> https://github.com/pypa/pip/pull/4461 had got quite messy - I felt
> that it might be easier for me to offer to rework the OP's PR rather
> than keep asking for corrections - but having to ass the NEWS entry
> made me doing that more complex than I'd initially thought. NEWS
> management was making a pretty trivial change in the wording of an
> error into a bit of a nightmare, both for me and for the OP. I was
> *really * tempted to say drop the NEWS and I'll mark the change
> trivial - but that seemed wrong, given that the OP had taken the time
> to write a NEWS item.
> 
> I don't really have a good answer here. But this is my first
> experience with the new NEWS process - and it doesn't seem like an
> improvement over the old one, I'm afraid :-(
> 
> 


Would it be better if you could just name it no-issue-. in 
that case?


—
Donald Stufft





Re: NEWS entries for pip

2017-05-02 Thread Paul Moore
On 2 May 2017 at 20:50, Donald Stufft  wrote:
> It’s generally only a two step process if there isn’t an existing issue
> you’re fixing. If you’re fixing an issue you can/should just use the issue’s
> number instead of the PRs number. We can make it possible to do like
> .feature and such too though if we think the random PR without an
> issue case is big enough to warrant a special case.

Hmm, maybe. I tend to do all changes as PRs, not all of which come
from an issue. But it's also true that it's not immediately obvious
(to me) from the docs that it's OK to use the issue number rather than
the PR number. I could try rewording the docs to that effect, but to
do so will need the 2-step process as there's no issue for this :-)

This originally came up for me because the discussion on
https://github.com/pypa/pip/pull/4461 had got quite messy - I felt
that it might be easier for me to offer to rework the OP's PR rather
than keep asking for corrections - but having to ass the NEWS entry
made me doing that more complex than I'd initially thought. NEWS
management was making a pretty trivial change in the wording of an
error into a bit of a nightmare, both for me and for the OP. I was
*really * tempted to say drop the NEWS and I'll mark the change
trivial - but that seemed wrong, given that the OP had taken the time
to write a NEWS item.

I don't really have a good answer here. But this is my first
experience with the new NEWS process - and it doesn't seem like an
improvement over the old one, I'm afraid :-(

Paul


NEWS entries for pip

2017-05-02 Thread Paul Moore
One thing I've just noticed with the new NEWS process for pip is that
it's made the PR process a 2-step process - you have to first make the
change, then once you submit the PR you have a PR number that you can
use to add a NEWS entry as a second commit.

That's both clumsy from a workflow POV, and messy in the commit
history (as we'll presumably end up with a lot of "Add a NEWS entry"
commits).

Could we change the process to allow users who know the process to
include the NEWS entry as part of the first commit?

The current process makes it *very* tempting for me to mark small
changes as trivial just so that I don't have to do the second step,
which is bad :-(

Paul