Automating the maintenance of the ChangeLog file

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Florian Weimer-5
* Joseph Myers:

> On Wed, 28 Nov 2018, Florian Weimer wrote:
>
>> Does our Patchwork instance support this?  Are there Gnus/mutt
>
> I thought that the main requirement for patchwork to remove committed
> patches automatically was that the git-patch-id of the committed change
> was the same as that of the patch posting.  The patch-id does not depend
> on the commit message, only on the diffs (but this does require that the
> posted diffs be the same as the committed ones - in particular, committing
> changes to the ChangeLog file that aren't included in the diffs prevents
> such automatic removal at present).

Interesting.  But given that Patchwork is a wasteland today and only a
subset of posted patches will be ever committed (each revision counts as
a new patch, after all), I don't think the auto-closing of posted
patches is a substantial factor in reducing the number of stale patches
in Patchwork.

I'm coming to this from a completely different angle.  I want a way for
contributors and reviewers to have a *reliable* to determine what the
patch will look like in the repository.  That includes both the diff
*and* the commit message.

Patchwork could be a tool in this context.  If it is able to close
approximate the commit, then we could give contributors a list of
formatting rules, and they can double-check on Patchwork if they got it
right.

On the other hand, maybe an approach based on pull requests is the
future, where all this is much more tightly integrated.  But I don't
know if we (as in GNU) have hosting for that available.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Jeff Law
On 11/29/18 6:45 AM, Florian Weimer wrote:
>
> On the other hand, maybe an approach based on pull requests is the
> future, where all this is much more tightly integrated.  But I don't
> know if we (as in GNU) have hosting for that available.
That's certainly where I want to go...

jeff
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Joseph Myers
In reply to this post by Florian Weimer-5
On Thu, 29 Nov 2018, Florian Weimer wrote:

> I'm coming to this from a completely different angle.  I want a way for
> contributors and reviewers to have a *reliable* to determine what the
> patch will look like in the repository.  That includes both the diff
> *and* the commit message.

I think that should be the "git am" convention (subject header gives
summary line for the patch after removing any [PATCH ...] tag, body of
email is rest of commit message up to a "---" line or the patch itself).  
(And that convention should be appropriate for emails generated by any
pull request / patch review system as well.)

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Szabolcs Nagy-2
On 29/11/18 14:04, Joseph Myers wrote:

> On Thu, 29 Nov 2018, Florian Weimer wrote:
>> I'm coming to this from a completely different angle.  I want a way for
>> contributors and reviewers to have a *reliable* to determine what the
>> patch will look like in the repository.  That includes both the diff
>> *and* the commit message.
>
> I think that should be the "git am" convention (subject header gives
> summary line for the patch after removing any [PATCH ...] tag, body of
> email is rest of commit message up to a "---" line or the patch itself).  
> (And that convention should be appropriate for emails generated by any
> pull request / patch review system as well.)

i'd also allow the "git am" convention text to be an attachment
(and additional text to go into the mail body) for unreliable
email systems that only preserve whitespace in attachments.
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Siddhesh Poyarekar-8
In reply to this post by Jeff Law
On 29/11/18 7:24 PM, Jeff Law wrote:
> On 11/29/18 6:45 AM, Florian Weimer wrote:
>>
>> On the other hand, maybe an approach based on pull requests is the
>> future, where all this is much more tightly integrated.  But I don't
>> know if we (as in GNU) have hosting for that available.
> That's certainly where I want to go...

IIRC we discussed phabricator, gerrit and gitlab in that context
earlier.  I'm now seeing patchwork as this first step to make sure that
nothing in our workflow gets in its way.  If we succeed in that, it
means that we can move up to something more tightly integrated later.

If we cannot make patchwork happy, we can rest assured that we cannot
make any PR based tools happy.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Zack Weinberg-2
On Thu, Nov 29, 2018 at 10:03 AM Siddhesh Poyarekar <[hidden email]> wrote:
>
> If we cannot make patchwork happy, we can rest assured that we cannot
> make any PR based tools happy.

Is that right, though?  In a PR-based workflow, the primary artifact
is a VCS branch and its meta-revision history (i.e. first we had this
series of commits, then they got rebased and now we have this other
one, etc) and the review discussion (which may still be email-based,
and indeed I hope it will be) is hanging off of that.  It seems to me
that that would inherently make it easier for a patch tracker to
monitor the status of all proposed changes, since it can directly
monitor events in the VCS rather than trying to reconstruct them from
emails that may be ambiguous.

zw
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Florian Weimer-5
* Zack Weinberg:

> On Thu, Nov 29, 2018 at 10:03 AM Siddhesh Poyarekar <[hidden email]> wrote:
>>
>> If we cannot make patchwork happy, we can rest assured that we cannot
>> make any PR based tools happy.
>
> Is that right, though?  In a PR-based workflow, the primary artifact
> is a VCS branch and its meta-revision history (i.e. first we had this
> series of commits, then they got rebased and now we have this other
> one, etc) and the review discussion (which may still be email-based,
> and indeed I hope it will be) is hanging off of that.  It seems to me
> that that would inherently make it easier for a patch tracker to
> monitor the status of all proposed changes, since it can directly
> monitor events in the VCS rather than trying to reconstruct them from
> emails that may be ambiguous.

I think technically it's easier because the PR tool is the single source
of truth, whereas Patchwork lives just on the side.

On the other hand, if we cannot get people to use Patchwork, I don't
think they will be too happy with using the PR tool (which would be
mandatory because it's the single source of truth).

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Automating the maintenance of the ChangeLog file

Siddhesh Poyarekar-8
In reply to this post by Zack Weinberg-2
On 29/11/18 9:21 PM, Zack Weinberg wrote:

> On Thu, Nov 29, 2018 at 10:03 AM Siddhesh Poyarekar <[hidden email]> wrote:
>>
>> If we cannot make patchwork happy, we can rest assured that we cannot
>> make any PR based tools happy.
>
> Is that right, though?  In a PR-based workflow, the primary artifact
> is a VCS branch and its meta-revision history (i.e. first we had this
> series of commits, then they got rebased and now we have this other
> one, etc) and the review discussion (which may still be email-based,
> and indeed I hope it will be) is hanging off of that.  It seems to me
> that that would inherently make it easier for a patch tracker to
> monitor the status of all proposed changes, since it can directly
> monitor events in the VCS rather than trying to reconstruct them from
> emails that may be ambiguous.

I should clarify that I'm not promoting patchwork as the end result of
our efforts.  The only point I'm making is that we don't necessarily
need to choose a PR-based workflow now to make our patches compatible
with them; patchwork can do that for us.

Choice of patch review tools is going to take another Cauldron at least,
if not two.  Patchwork exists today because one day I hosted it on my
personal host some years ago and a bunch of us liked it at the time.
The result was that not a lot of people (including me) used it and it
bit rotted.  We need to make sure that that doesn't happen again.

Siddhesh
12