Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jul 2014 11:48:05 -0500
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        John Baldwin <jhb@freebsd.org>, src-committers@freebsd.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org
Subject:   Re: Phabric IDs / URLs in commits
Message-ID:  <53C01545.8030708@FreeBSD.org>
In-Reply-To: <53C01512.3070506@FreeBSD.org>
References:  <201407111616.s6BGGQFW060195@svn.freebsd.org> <201407111238.23391.jhb@freebsd.org> <53C01512.3070506@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--lAvfPnI6xBCaKculwrHw0iTLbat5RBNN3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 7/11/2014 11:47 AM, Bryan Drewery wrote:
> On 7/11/2014 11:38 AM, John Baldwin wrote:
>> On Friday, July 11, 2014 12:16:26 pm John Baldwin wrote:
>>> Author: jhb
>>> Date: Fri Jul 11 16:16:26 2014
>>> New Revision: 268531
>>> URL: http://svnweb.freebsd.org/changeset/base/268531
>>>
>>> Log:
>>>   Fix some edge cases with rewinddir():
>>>   - In the unionfs case, opendir() and fdopendir() read the directory=
's full
>>>     contents and cache it.  This cache is not refreshed when rewinddi=
r() is
>>>     called, so rewinddir() will not notice updates to a directory.  F=
ix this
>>>     by splitting the code to fetch a directory's contents out of
>>>     __opendir_common() into a new _filldir() function and call this f=
rom
>>>     rewinddir() when operating on a unionfs directory.
>>>   - If rewinddir() is called on a directory opened with fdopendir() b=
efore
>>>     any directory entries are fetched, rewinddir() will not adjust th=
e seek
>>>     location of the backing file descriptor.  If the file descriptor =
passed
>>>     to fdopendir() had a non-zero offset, the rewinddir() will not re=
wind to
>>>     the beginning.  Fix this by always seeking back to 0 in rewinddir=
().
>>>     This means the dd_rewind hack can also be removed.
>>>  =20
>>>   While here, add missing locking to rewinddir().
>>>  =20
>>>   CR:   	    	https://phabric.freebsd.org/D312
>>>   Reviewed by:	jilles
>>>   MFC after:	1 week
>>
>> Just picking my own commit here as a sample case.
>>
>> I think we should be annotating commits with phabricator code reviews =
in some=20
>> way when a change has gone through that review.  It is very useful to =
get back
>> to the review details from the commit log message in svnweb, etc.
>>
>> I can see a number of different ways to do this, but I do think it wou=
ld be
>> nice to pick a consistent way to do it.
>>
>> Things to consider:
>>
>> 1) The tag ("CR:" is what I used above).  I don't care, just pick one.=
  I
>>    chose CR since Warner used it previously.  Whatever we decide, we s=
hould
>>    add it to the template.
>>
>> 2) ID vs full URL.  For PRs we just list the bug ID and not the full U=
RL
>>    (same for Coverity).  I would be fine with that so long as someone =
hacks
>>    up svnweb to convert the IDs into links (the way it handles PR bug
>>    numbers).  OTOH, if you use the full URL you get that for free in s=
vnweb,
>>    and you also get it in mail clients, etc.  It helps that the URL is=
n't but
>>    so long.
>>
>> This is more of a pie-in-the-sky, but it would be _really_ nice if arc=
anist=20
>> were hacked up to support our local commit template and would auto pop=
ulate=20
>> the 'Reviewed by' and 'CR' (or whatever it ends up being called) field=
s so one=20
>> could use 'arc commit'.
>>
>> So what do folks prefer for 1) and 2)?
>>
>=20
> FYI Ports has been using the convention: "Phabric\tDXXX"
>=20

'Phabric:\tDXXX' with : of course.

--=20
Regards,
Bryan Drewery


--lAvfPnI6xBCaKculwrHw0iTLbat5RBNN3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTwBVFAAoJEDXXcbtuRpfPRhwH/3Zgo57uSEUESbLHntQL5g2D
xqKCR4MpCfOC5Vwf5RnzIfo2mTD+aHZ9eE5iTzRiy3Sg0MfIdqFyTwAwotrEFbei
k0D/gQGV39v9s5f7rwL+pOY90Vv/zdx+HYSZaEttP/bMlmheZHnzn/n1EL553Cyc
CjMJnS74QuGBTe+7tKeKH2abIP/WfNrwgl9/0XDZ5WLizT4YcfLf3fHE7c0BzUBt
uIQYg7kyDVInUDBduNJXjcn0g/bXPwX7vA11g5toNHE3+GDhyLkTri4dR5ChfssO
3f79J3l/CkGoVl61f0RuKNbTNLp6z99sNmV5PuHai662LM/JGdOIKWrN4MFgABE=
=LOBz
-----END PGP SIGNATURE-----

--lAvfPnI6xBCaKculwrHw0iTLbat5RBNN3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53C01545.8030708>