openjdk build pages

Fri May 23 08:59:31 UTC 2014

The problem with moving tags is that what you get when you clone a 
repository with a tag depends on when you cloned it.

On 23.05.2014 01:41, Kelly O'Hair wrote:
> Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update.
> You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag.
>
> So jdk7u40 becomes "the latest", and ultimately, the "final" one.
>
> -kto
>
> On May 21, 2014, at 7:08 PM, David Holmes wrote:
>
>> On 22/05/2014 11:47 AM, Martin Buchholz wrote:
>>> Another way to look at it is that "jdk7u40" is a tag that will gather
>>> far more interest than the build-specific tags "jdk7u40-b62" currently
>>> available, which are likely mostly of interest to Oracle release
>>> engineering.
>>
>> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think.
>>
>> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes.
>>
>> David
>> ------
>>
>>>
>>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz <martinrb at google.com
>>> <mailto:martinrb at google.com>> wrote:
>>>
>>>     A slight tangent, but maybe y'all could expand the URLs that allow
>>>     you to download an entire repo to make this particular way of
>>>     grabbing bundles more convenient:
>>>
>>>     1. In addition to the various labels like "jdk7u40-b62" that include
>>>     a build number, when jdk7u40 is finally released, simply add a tag
>>>     "jdk7u40" that is the true final released jdk7u40.  It would point
>>>     to the same revision as the last build, presumably jdk7u40-b62".
>>>       This allows you to download via URL, e.g.
>>>
>>>     http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip
>>>     <https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>
>>>
>>>     2.  (some hg hacking required) Expand the per-repo URLs to download
>>>     all the repos with one URL, e.g.
>>>
>>>     http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip <https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>
>>>
>>>
>>>     On Wed, May 21, 2014 at 4:44 PM, Omair Majid <omajid at redhat.com
>>>     <mailto:omajid at redhat.com>> wrote:
>>>
>>>         * dalibor topic <dalibor.topic at oracle.com
>>>         <mailto:dalibor.topic at oracle.com>> [2014-05-21 05:15]:
>>>          > Actually, I think that for 7u60 (and 7u80) we need to move in
>>>         the other
>>>          > direction, and not publish separate source bundles from the
>>>         source code
>>>          > that's already in the Project's Mercurial repositories.
>>>
>>>         I encourage you to think again. The source code system used by
>>>         OpenJDK
>>>         (hg trees) is not straight-forward to work with for packagers,
>>>         and needs
>>>         non-standard tools, like the trees extension, to fetch complete and
>>>         consistent things.
>>>
>>>         Source bundles are really easy to work with as a packager. You
>>>         know you
>>>         got something consistent that works and don't have to mess
>>>         around with
>>>         source code control systems checking out various repositories
>>>         and tags
>>>         to find the 'right' source.
>>>
>>>          > Beside being potentially error prone,
>>>
>>>         I am not sure I understand. Surely you can write a script that
>>>         grabs the
>>>         right tags from the right forests to create a tarball. I could
>>>         do it, if
>>>         I knew exactly which forests and tags contain the right stuff
>>>         (and could
>>>         upload it somewhere on openjdk.java.net
>>>         <http://openjdk.java.net>). In fact, I have something
>>>         generic already written [1]. Feel free to use it.
>>>
>>>          > and update releases that we can't work on as part of OpenJDK
>>>         (like
>>>          > 7u55),
>>>
>>>         I am not sure I follow. If you can commit the source to the
>>>         repository
>>>         and tag it, why can't you create a source bundle for those tags?
>>>
>>>          > The added complexity provides little benefit, and the
>>>         simplest way to remove
>>>          > the complexity is to remove the issue causing it, and educate
>>>         users to use
>>>          > the source ... directly from the respective source repository.
>>>
>>>         I respectfully disagree with your solution. If not providing source
>>>         bundles causes confusion, wouldn't the right fix be to provide
>>>         source
>>>         bundles?
>>>
>>>         As for benefit, just today I saw people asking on #openjdk about
>>>         where
>>>         to get source bundles. And they complained that using source
>>>         control to
>>>         get a release bundles is too hard (and shouldn't be necessary).
>>>
>>>         Also, if you think users have problems distinguishing 7u60 from
>>>         7u55,
>>>         can you imagine the problems they will have trying to find the
>>>         real/final tag for 7u55 in the repos? And how some tags do not
>>>         exist in
>>>         some repos at some points in time? [2].
>>>
>>>         Thanks,
>>>         Omair
>>>
>>>         [1]
>>>         http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh
>>>         [2]
>>>         http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html
>>>         --
>>>         PGP Key: 66484681 (http://pgp.mit.edu/)
>>>         Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>>>
>>>
>>>
>

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

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