openjdk build pages
Kelly O'Hair
kellyohair at gmail.com
Fri May 23 22:17:46 UTC 2014
jdk7u40-latest would be fine.
-kto
On May 23, 2014, at 3:11 PM, John Coomes wrote:
> Kelly O'Hair (kellyohair at gmail.com) wrote:
>>
>> 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.
>
> I would prefer to save the release name itself (e.g., "jdk7u40") for a
> branch name, not a tag. It's true we don't currently use named
> branches, but I (and others) would like to move to model where each
> release lives in a separate branch, instead of in a separate repo.
>
> Note that I'm not against adding tags for the "latest build". Just
> don't use the unadorned release name for it. Maybe "jdk7u40-latest"
> for the tag?
>
> -John
>
>>> 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