openjdk build pages
Mario Torre
neugens.limasoftware at gmail.com
Fri May 23 23:08:09 UTC 2014
+1
Cheers,
Mario
Il 24/mag/2014 00:18 "Kelly O'Hair" <kellyohair at gmail.com> ha scritto:
> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20140524/a9695bea/attachment-0001.html>
More information about the web-discuss
mailing list