Discussion:
A small procedural request
(too old to reply)
Julian Elischer
2018-02-21 04:01:33 UTC
Permalink
Hi,  I have a very small request to those committing into head.

If you commit a fix, then if it is possible to easily do so, can you
give the revision number in which the regression was introduced?

like "this was  broken in r329xxx"

this allows people who are looking for specific problems to say "Ok
that bug was introduced after the snapshot I'm working on and can't be
my issue".

(we are not always working on the very tip).


thanks

Julian
Tomoaki AOKI
2018-02-21 11:14:05 UTC
Permalink
Hi.

+1. But have one suggestion for format.
Something like

Broken by: rXXXXXXX
Broken by: Unknown (Bugfix but the revision introduced it is unknown)

and optionally

Broken by: No (To emphasize it's NOT a bugfix.)

would be better for scripts already handling "MFC after: " or
"X-MFC-With: " etc. to support this.

If put on the top with "MFC rXXXXXX: Comments", it can be

FIX rXXXXXX: Comments

or for multiple revisions,

FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals
FIX rXXXXXX-rYYYYYY: Comments for massive continuous range

would be better.

Regards.


On Wed, 21 Feb 2018 12:01:33 +0800
Hi,$B".(B I have a very small request to those committing into head.
If you commit a fix, then if it is possible to easily do so, can you
give the revision number in which the regression was introduced?
like "this was$B".(B broken in r329xxx"
this allows people who are looking for specific problems to say "Ok
that bug was introduced after the snapshot I'm working on and can't be
my issue".
(we are not always working on the very tip).
thanks
Julian
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
--
Tomoaki AOKI <***@dec.sakura.ne.jp>
Julian Elischer
2018-02-21 14:22:08 UTC
Permalink
Post by Tomoaki AOKI
Hi.
+1. But have one suggestion for format.
Something like
Broken by: rXXXXXXX
Broken by: Unknown (Bugfix but the revision introduced it is unknown)
and optionally
Broken by: No (To emphasize it's NOT a bugfix.)
I think that is probably too much, but the        Broken by:  would be
good.
Post by Tomoaki AOKI
would be better for scripts already handling "MFC after: " or
"X-MFC-With: " etc. to support this.
If put on the top with "MFC rXXXXXX: Comments", it can be
FIX rXXXXXX: Comments
possibly..
that Would allow some sort of collection of the data to  suggest good
places to
retrospectively base your head following (but not too closely) branches.
but may be more work that people are willing to do..
For myself, just a hint of where the bug was introduced would help a lot.
further more if you have a branch/product based at some point in time,
this would help
you to know when a patch needs to be cherry picked back to your code.
Post by Tomoaki AOKI
or for multiple revisions,
FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals
FIX rXXXXXX-rYYYYYY: Comments for massive continuous range
would be better.
Regards.
On Wed, 21 Feb 2018 12:01:33 +0800
Hi,〓 I have a very small request to those committing into head.
If you commit a fix, then if it is possible to easily do so, can you
give the revision number in which the regression was introduced?
like "this was〓 broken in r329xxx"
this allows people who are looking for specific problems to say "Ok
that bug was introduced after the snapshot I'm working on and can't be
my issue".
(we are not always working on the very tip).
thanks
Julian
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
Tomoaki AOKI
2018-02-22 12:39:20 UTC
Permalink
On Wed, 21 Feb 2018 22:22:08 +0800
Post by Tomoaki AOKI
Hi.
+1. But have one suggestion for format.
Something like
Broken by: rXXXXXXX
Broken by: Unknown (Bugfix but the revision introduced it is unknown)
and optionally
Broken by: No (To emphasize it's NOT a bugfix.)
I think that is probably too much, but the$B".".".".".".".(B Broken by:$B".(B would be
good.
Maybe not all committers would add this info.
But examples should be useful for who wants to write. ;-)
Post by Tomoaki AOKI
would be better for scripts already handling "MFC after: " or
"X-MFC-With: " etc. to support this.
If put on the top with "MFC rXXXXXX: Comments", it can be
FIX rXXXXXX: Comments
possibly..
that Would allow some sort of collection of the data to$B".(B suggest good
places to
retrospectively base your head following (but not too closely) branches.
but may be more work that people are willing to do..
I guess so, too. It's useful, but not a creative work.
I think less is better than nothing.
For myself, just a hint of where the bug was introduced would help a lot.
further more if you have a branch/product based at some point in time,
this would help
you to know when a patch needs to be cherry picked back to your code.
Yes. I 100% agree.
BTW, "X-MFC-With: " is sometimes used for the same purpose, but not
always. (Used for bugfixes for new feature, and related new features.)
Post by Tomoaki AOKI
or for multiple revisions,
FIX rXXXXXX rYYYYYY rZZZZZZ: Comments for multiple individuals
FIX rXXXXXX-rYYYYYY: Comments for massive continuous range
would be better.
Regards.
On Wed, 21 Feb 2018 12:01:33 +0800
Hi,$B".(B I have a very small request to those committing into head.
If you commit a fix, then if it is possible to easily do so, can you
give the revision number in which the regression was introduced?
like "this was$B".(B broken in r329xxx"
this allows people who are looking for specific problems to say "Ok
that bug was introduced after the snapshot I'm working on and can't be
my issue".
(we are not always working on the very tip).
thanks
Julian
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
--
Tomoaki AOKI <***@dec.sakura.ne.jp>
Continue reading on narkive:
Loading...