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.san...@oracle.com> wrote: > > On May 19, 2014, at 6:18 PM, Phil Race <philip.r...@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
Description: Message signed with OpenPGP using GPGMail
