Draft Repository Management

[Dalibor Topic]

On 7/29/11 10:33 PM, Erik Trimble wrote:
> On 7/29/2011 9:29 AM, Jim Holmlund wrote:
>>
>>
>> On 7/29/2011 1:46 AM, Seán Coffey wrote:
>>> Poonam,
>>>
>>> 7u repos are best viewed from http://hg.openjdk.java.net/
>>>
>>> I've often wondered why the mercurial webserver doesn't show a sub-forest type view when using the link you've mentioned.  e.g http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ is the forest I'm using.
>> As I read the doc
>>     http://openjdk.java.net/projects/jdk7u/repos.html
>>
>> jdk7u/jdk7u is the master and people should not be pushing to it.  Erik said that the integration repo(s) to which we should push have not yet been created.  It isn't clear to me if we will have just one integration repo, or maybe different ones for core, client, hotspot, etc.)
>>
>> - jjh
>>
> 
> As far as I understand, jdk7u/jdk7u is analogous to the old jdk7/jdk7 forest, and is the RE master which only the Gatekeepers should be pushing to.
> 
> There also will only be one forest (jdk7u/jdk7u-dev) for everyone to push fixes to (i.e just one Integration forest). There are a couple of reasons:

Correct. Things are a bit more complicated on the closed side (aren't they always?), since we have two further repositories there, in addition to the closedjdk jdk7u-dev.
But as far as OpenJDK goes, jdk7u-dev is the place to push fixes to.
 
>     (a) the number of fixes is expected to be significantly lower than the active development branch (jdk8)
>     (b) we'd like to have developers test a bit more themselves before pushing into the Integration repository; that is, since fixes to 7u are lower-risk (i.e. we should be doing almost exclusively bugfixing, with the exception of Hotspot)
>     (c) builds should be further apart than with jdk8, which allows for more time to QA the -dev repository and find any issues
> 
> All this adds up to making it simpler to have just a single development forest repository, rather than individual group forests. It also means we can dedicate more QA testing hardware to that single forest, rather than spread our resources over multiple forests.
> 
> Also, as we implement the Build Improvement project, full JDK forest builds will become *significantly* faster, which will allow us to build and test the entire jdk7u-dev forest frequently - ideally, every push from every developer to jdk7u-dev will require a full JDK build&test, but that's the goal; we'll see if that happens.

All very good points - thanks, Erik.

cheers,
dalibor topic

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment