openjdk build pages
John Coomes
John.Coomes at oracle.com
Fri May 23 22:11:46 UTC 2014
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