[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of StringBuffer with StringBuilder within th
From:       Paul Sandoz <paul.sandoz () oracle ! com>
Date:       2014-06-16 16:51:04
Message-ID: 93462213-92CF-46A3-B465-7A52E4193775 () oracle ! com
[Download RAW message or body]

After some further reflection i have decided to not separate this out and some bits \
going to client and some bits going to dev, and have pushed all changes to dev. I \
realise this might cause some friction but believe it the right thing to do.

I remain unconvinced that the separate process for patches such as this scales and is \
a valuable use of our development time and resources. A merging process is surely \
fundamentally more efficient (and anyway has to be performed) over N developers \
having to use a slightly different process [*].

Call me human and flawed in my management of time :-( but higher priority things keep \
getting pushed to the top of my stack before getting around to following this \
separate process and i really don't want the code to bit rot. I suspect i am not \
unique in this regard.

Paul.

[*] Is it documented? I have never managed to obtain a definitive answer, nor an \
explicit white-list of Java package names (external yes, internal no).

On May 20, 2014, at 7:45 AM, Paul Sandoz <Paul.Sandoz@oracle.com> wrote:

> 
> On May 19, 2014, at 6:18 PM, Phil Race <philip.race@oracle.com> wrote:
> 
> > On 5/19/2014 12:50 AM, Alan Bateman wrote:
> > > On 19/05/2014 07:53, Paul Sandoz wrote:
> > > > If i don't have permission to push to the client repo (which might be likely) \
> > > > i will need to hand over the patch to yourself or Sergey to commit. And i \
> > > > presume this will have to be a separate issue.
> > > If you do decide to split this then it will require creating a second issue \
> > > JIRA to avoid running foul of jcheck when jdk/client eventually pushes to \
> > > jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it \
> > > doesn't seem to be very frequent (hg incoming suggests there is currently about \
> > > a month of changes backed up in jdk9/client but there may be issues to explain \
> > > this). 
> > > For this specific case then it doesn't seem worth it, it would be much less \
> > > effort to just push the lot to jdk9/dev. Clearly if there were substantive \
> > > changes then it would be important to push the changes to the forest where they \
> > > are most likely to get tested but it hardly seems worth it here. From what I \
> > > can tell then Phil or others sync up jdk9/client regularly and that might be \
> > > the most efficient way to get these changes into jdk9/client. 
> > The changes should go through client for the reasons I already gave.
> 
> IIUC these were the reasons you gave in a previous email on this thread:
> 
> "I would not push hotspot changes to client either. Also lots of files
> are being updated in client and doing it this way will minimise merges ..."
> 
> I don't find either very convincing.
> 
> 
> > No new permissions are needed but it will need a unique bug id.
> > 
> 
> Ok.
> 
> 
> > FWIW integrations are intended to be bi-weekly but holidays interfered this time.
> > 
> 
> Why does it take so long?
> 
> Paul.


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJTnyB5AAoJEAPxyzLE7ykSWG0P/3pSJjIeZ/rElLcJZke6tTI7
Pa1dpC6OT4o9oHIL52KrWWj6WL0ZTN+d2P8ua+fpLmlxE+fPPF6klyWlza6OwCWT
VgDvZ5913AzjU21o+9pW3zbolATe47iQOinO8hL1Ng/3BSEz3oNDWQcr2i4baFuq
Z48z2+TxqDME68gKLPRPIpQYA332htQ3SakJINaLwzdRGf7EHA2uusZ3/ts3EKFx
ZocSZnxd6vmVpaqWSJgobDjlSad+ImZKgtPlMkOQ1RzX3kco/DSM7xuQqOfaH/1n
FwzL3hpsbC2j8d+PqP8CfvYUDgft11fYHmF/C0gl8W4/zFB7Lw+HvVDAOS7zBEf2
WM4KgQPL5AAAvEELGIwAHlnRwluOgA7d9gScXKClt/7mqqp10vUtYp6dRMj/Mgr1
hUju3EjICgdSRTIARiPt441sHTAoL79bP+qCLX/npmBh6GHnoDniNshheVfV0ZPK
mEWzgHkzRnHXDSKLx3S4tvcR7Vve6tUtqhp02UTckvnUttH6lvxpl+DT5/hB28w4
U4FcxUEPuZenN8hIhK1+PsEJY6PulU7d9BE/H2gJfO4b8zGewXS0CkPx5LUqPWkz
ZN0Fm8Ptjvh1Xd+DxCov4YNVbaXrAtJchfay/kWBPwYjCCSALEJ9j731M7s2PpjD
uwmKtN2v7OvokjPZa0u4
=a5B5
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]