openjdk build pages
Kelly O'Hair
kellyohair at gmail.com
Fri May 23 16:07:36 UTC 2014
On May 23, 2014, at 1:59 AM, dalibor topic wrote:
> The problem with moving tags is that what you get when you clone a repository with a tag depends on when you cloned it.
That's always true when you request a clone without a tag, you never know what you will get.
With a jdk7u40 tag, if it was released, it's stable, but if it isn't you get the latest jdk7u40, which should be a stable release.
I don't see a problem with that.
-kto
>
> 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
More information about the web-discuss
mailing list