Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Bill Cole]

On 14 Apr 2017, at 22:40, Sidney Markowitz wrote:

I propose that we make a practice of 1) Create a Bugzilla issue for 
anything
we commit to source files or to any other files that are part of the 
build
process; 2) Include the text "bug " somewhere in the commit 
message.



Comments, votes?


+1

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Kevin A. McGrail]

On 4/15/2017 4:29 AM, Kevin Golding wrote:
Playing timezone bingo I'll assume I might be able to save you some 
work. I'll try to whizz through the patches I've sent KAM and send any 
I think are outstanding. 


Heh, yes.  I was also doing regression tests on the patch from Bill Cole 
on Ununto, Centos and RHEL.

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Kevin A. McGrail]

On 4/14/2017 11:25 PM, Sidney Markowitz wrote:

Kevin A. McGrail wrote on 15/04/17 3:06 PM:

Plus one here but will note Kevin Golding and I have already been syncing
trunk and 3.4. I can email you the remaining work tomorrow so we can sync.

I noticed what you have done. So far I'm about to be done with all the non
*.pm files and there are only 22 *.pm files with differences left to look at.
If you and Kevin Golding have anything that you are in the middle of that you
have not yet committed you should let me know because I may be able to get
through all the rest by tonight (still afternoon here).
I just sent you the files I was working on.  I had been testing the 
sa_install changes and some other bugs for Geo::IP so no worries. We'll 
get it in sync.


Regards,
KAM

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Sidney Markowitz]

Kevin Golding wrote on 15/04/17 8:51 PM:
> Apologies if any overlap

This looks good. I can see from the names of the attachments that most if not
all will be ones I have yet to look at, so the timing is good. I'll grab the
attachments and continue from there for the rest of tonight.

Thanks,

 Sidney

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Kevin Golding]

On Sat, 15 Apr 2017 04:25:47 +0100, Sidney Markowitz   
wrote:



Kevin A. McGrail wrote on 15/04/17 3:06 PM:
Plus one here but will note Kevin Golding and I have already been  
syncing
trunk and 3.4. I can email you the remaining work tomorrow so we can  
sync.


I noticed what you have done. So far I'm about to be done with all the  
non
*.pm files and there are only 22 *.pm files with differences left to  
look at.
If you and Kevin Golding have anything that you are in the middle of  
that you
have not yet committed you should let me know because I may be able to  
get

through all the rest by tonight (still afternoon here).


Apologies if any overlap, I was trying to handle things piece by piece  
because I didn't know the order they would be looked at and/or if they  
would all be included. (I think I missed a couple out because I recall KAM  
saying at least one had been surpassed by other changes.) I've just been  
checking against https://svn.apache.org/viewvc/spamassassin/branches/3.4/  
this morning and I'm speeding through to try and be helpful before I  
vanish for a little bit.


The bug and r named patches should be easiest to associate. The ones  
with filenames may be more cryptic. I know I sent explanations originally  
and if you want any details I can look back and forward the mails directly.

bug6608.patch
Description: Binary data


bug7198.patch
Description: Binary data


bug7215.patch
Description: Binary data


bug7225.patch
Description: Binary data


DKIM.pm.patch
Description: Binary data


DnsResolver.pm.patch
Description: Binary data


HeaderEval.pm.patch
Description: Binary data


Node.pm.patch
Description: Binary data


PerMsgStatus.pm.patch
Description: Binary data


r1707595.patch
Description: Binary data


r1694122.patch
Description: Binary data


txrep_pg.sql.patch
Description: Binary data

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Kevin Golding]

On Sat, 15 Apr 2017 04:25:47 +0100, Sidney Markowitz   
wrote:



Kevin A. McGrail wrote on 15/04/17 3:06 PM:
Plus one here but will note Kevin Golding and I have already been  
syncing
trunk and 3.4. I can email you the remaining work tomorrow so we can  
sync.


I noticed what you have done. So far I'm about to be done with all the  
non
*.pm files and there are only 22 *.pm files with differences left to  
look at.
If you and Kevin Golding have anything that you are in the middle of  
that you
have not yet committed you should let me know because I may be able to  
get

through all the rest by tonight (still afternoon here).


Playing timezone bingo I'll assume I might be able to save you some work.  
I'll try to whizz through the patches I've sent KAM and send any I think  
are outstanding.

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Sidney Markowitz]

Kevin A. McGrail wrote on 15/04/17 3:06 PM:
> Plus one here but will note Kevin Golding and I have already been syncing
> trunk and 3.4. I can email you the remaining work tomorrow so we can sync.

I noticed what you have done. So far I'm about to be done with all the non
*.pm files and there are only 22 *.pm files with differences left to look at.
If you and Kevin Golding have anything that you are in the middle of that you
have not yet committed you should let me know because I may be able to get
through all the rest by tonight (still afternoon here).

 Sidney

Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Kevin A. McGrail]

Plus one here but will note Kevin Golding and I have already been syncing trunk 
and 3.4.  I can email you the remaining work tomorrow so we can sync.
Regards,
KAM

On April 14, 2017 10:40:41 PM EDT, Sidney Markowitz  wrote:
>My task this weekend has been tracking down mismatches between trunk
>and
>branch 3.4 to make sure that anything that has been committed to trunk
>and is
>or should be targeted for the 3.4.2 release has been committed to the
>branch.
>
>In doing that I'm encountering a number of commits to trunk that do not
>refer
>back to a Bugzilla issue. Usually it is a simple and obvious patch for
>an
>issue that clearly ought to be done, and probably didn't seem worth the
>extra
>steps of creating an issue in Bugzilla for it. Maybe some of them were
>a
>result of the committer not including the bug number in the commit
>message - I
>would not be able to tell if that's the case without a search in
>Bugzilla in
>which I guess the keywords to look for.
>
>I propose that we make a practice of 1) Create a Bugzilla issue for
>anything
>we commit to source files or to any other files that are part of the
>build
>process; 2) Include the text "bug " somewhere in the commit
>message.
>
>The benefits of doing this include 1) Makes it easier to track what has
>to be
>ported from trunk to branch before a release; 2) Makes it possible to
>look up
>the reasons and discussions related to a commit, and to find other
>commits
>that are related to the same issue even when at the time of the first
>commit
>it was not anticipated that there would be anything more to be
>committed.
>
>We already have in our guidelines to include "bug " in the commit
>message
>
>https://wiki.apache.org/spamassassin/UsingBugzilla#Committing_Fixes_For_Bugs
>
>I would like to see if there is consensus on adding to our guidelines
>that we
>always create a Bugzilla issue for something that will be committed
>into our
>source or related files.
>
>It also seems like a good idea to create a CommitterGuidelines page on
>the
>wiki. I had some difficulty finding the guideline for svn commit
>messages
>where it is hiding under UsingBugzilla.
>
>Comments, votes?
>
> Sidney

PROPOSAL: Be stricter about creating Bugzilla issue before committing

[Sidney Markowitz]

My task this weekend has been tracking down mismatches between trunk and
branch 3.4 to make sure that anything that has been committed to trunk and is
or should be targeted for the 3.4.2 release has been committed to the branch.

In doing that I'm encountering a number of commits to trunk that do not refer
back to a Bugzilla issue. Usually it is a simple and obvious patch for an
issue that clearly ought to be done, and probably didn't seem worth the extra
steps of creating an issue in Bugzilla for it. Maybe some of them were a
result of the committer not including the bug number in the commit message - I
would not be able to tell if that's the case without a search in Bugzilla in
which I guess the keywords to look for.

I propose that we make a practice of 1) Create a Bugzilla issue for anything
we commit to source files or to any other files that are part of the build
process; 2) Include the text "bug " somewhere in the commit message.

The benefits of doing this include 1) Makes it easier to track what has to be
ported from trunk to branch before a release; 2) Makes it possible to look up
the reasons and discussions related to a commit, and to find other commits
that are related to the same issue even when at the time of the first commit
it was not anticipated that there would be anything more to be committed.

We already have in our guidelines to include "bug " in the commit message

https://wiki.apache.org/spamassassin/UsingBugzilla#Committing_Fixes_For_Bugs

I would like to see if there is consensus on adding to our guidelines that we
always create a Bugzilla issue for something that will be committed into our
source or related files.

It also seems like a good idea to create a CommitterGuidelines page on the
wiki. I had some difficulty finding the guideline for svn commit messages
where it is hiding under UsingBugzilla.

Comments, votes?

 Sidney