You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Branko Čibej <br...@apache.org> on 2015/03/26 12:28:19 UTC
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
> Author: dsetrakyan
> Date: Thu Mar 26 07:47:28 2015
> New Revision: 1669287
>
> URL: http://svn.apache.org/r1669287
Well, in my opinion, the source download should be first on the page,
not the binaries. Binaries are not official releases; the sources are.
We should be encouraging people to use the sources.
-- Brane
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Branko Čibej <br...@apache.org>.
On 26.03.2015 18:55, Valentin Kulichenko wrote:
> I think we should modify the build procedure of source package so that
> ignite.properties is augmented there as well. This way user will be able to
> build binary package from downloaded source zip.
>
> Actually it seems incorrect to ship source package with DEV version of
> ignite.properties, because it is based on specific revision.
I agree.
> On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <ds...@gridgain.com>
> wrote:
>
>> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
>>
>>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
>>>> Author: dsetrakyan
>>>> Date: Thu Mar 26 07:47:28 2015
>>>> New Revision: 1669287
>>>>
>>>> URL: http://svn.apache.org/r1669287
>>>
>>> Well, in my opinion, the source download should be first on the page,
>>> not the binaries. Binaries are not official releases; the sources are.
>>> We should be encouraging people to use the sources.
>>>
>> Brane,
>>
>> Our release build procedure which builds the binary, requires that you must
>> be under the GIT root. The reason is that it automatically grabs the
>> version from the GIT server in order to imprint it into the release. So the
>> build you are suggesting does not even work. User would still be able to
>> build the maven modules, but user cannot build the actual binary release,
>> hence the -P-release option.
>>
>> I don't mind having a separate discussion about how useful it is for our
>> users to build a complete binary from the source zip (and not from GIT),
>> but in the mean time, I cannot call it the recommended way, because it is
>> not. Do you mind if I update the text?
>>
>> D.
>>
>>
>>
>>> -- Brane
>>>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Valentin Kulichenko <va...@gmail.com>.
I think we should modify the build procedure of source package so that
ignite.properties is augmented there as well. This way user will be able to
build binary package from downloaded source zip.
Actually it seems incorrect to ship source package with DEV version of
ignite.properties, because it is based on specific revision.
--
Val
On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <ds...@gridgain.com>
wrote:
> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
>
> > On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
> > > Author: dsetrakyan
> > > Date: Thu Mar 26 07:47:28 2015
> > > New Revision: 1669287
> > >
> > > URL: http://svn.apache.org/r1669287
> >
> >
> > Well, in my opinion, the source download should be first on the page,
> > not the binaries. Binaries are not official releases; the sources are.
> > We should be encouraging people to use the sources.
> >
>
> Brane,
>
> Our release build procedure which builds the binary, requires that you must
> be under the GIT root. The reason is that it automatically grabs the
> version from the GIT server in order to imprint it into the release. So the
> build you are suggesting does not even work. User would still be able to
> build the maven modules, but user cannot build the actual binary release,
> hence the -P-release option.
>
> I don't mind having a separate discussion about how useful it is for our
> users to build a complete binary from the source zip (and not from GIT),
> but in the mean time, I cannot call it the recommended way, because it is
> not. Do you mind if I update the text?
>
> D.
>
>
>
> > -- Brane
> >
>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Valentin Kulichenko <va...@gmail.com>.
And by the way, the binary package which is currently on site, was built
from the exactly same source that on the vote. The only difference is that
we had to execute Maven command from Git root directory, not from unzipped
source package. This is fixed now.
--
Val
On Thu, Mar 26, 2015 at 4:21 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> I made a fix in sprint-2 - binary package can be built without Git now
> (revision will be 'n/a').
>
> --
> Val
>
> On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej <br...@apache.org> wrote:
>
>> If the user cannot build a complete release from source, then the source
>> release is not functional. It's as simple as that. The ASF releases
>> sources, not binaries. Binaries are never official releases.
>>
>> I'm really not interested in how other projects are doing it wrong; I'm
>> interested in Ignite doing it right. If that means we need to modify the
>> release process so that the source tarball is in a shape that allows
>> building a binary release (as opposed to a developer build), then that's
>> what we need to do.
>>
>> Two can play the second-guessing game by looking at what other projects
>> are doing; for example, I copied the disclaimer text straight off Flex's
>> web site. But that's unproductive: our goal should be to follow ASF
>> release policy, which states (http://www.apache.org/dev/release.html):
>>
>> Under no circumstances are unapproved builds a substitute for
>> releases. If this policy seems inconvenient, then release more
>> often. Proper release management is a key aspect of Apache software
>> development.
>>
>> The Apache Software Foundation produces open source software. All
>> releases are in the form of the source materials needed to make
>> changes to the software being released. In some cases,
>> binary/bytecode packages are also produced as a convenience to users
>> that might not have the appropriate tools to build a compiled
>> version of the source. In all such cases, the binary/bytecode
>> package must have the same version number as the source release and
>> may only add binary/bytecode files that are the result of compiling
>> that version of the source code release.
>>
>> Note the bit about "the result of compiling that version of the source
>> code release" and note that the 1.0.0-rc3 binary package contains
>> libraries that are not in the source package; that's another thing that
>> needs fixing for the next release.
>>
>> Also note the bit about "unapproved builds": Nobody voted on your binary
>> package, so it's quite inappropriate to *not* warn the user about the
>> convenience, unapproved nature of the binaries.
>>
>> -- Brane
>>
>> On 26.03.2015 18:29, Dmitriy Setrakyan wrote:
>> > Given that we cannot do a release build of the source code without
>> having
>> > GIT, I think keeping the text we have on our download page is very
>> > confusing to our users. I will go ahead and fix it for now, and I am
>> happy
>> > to have another discussion thread on whether to recommend binary or
>> source
>> > downloads.
>> >
>> > I also am looking at other projects, and I am seeing that they simply
>> > provide source and binary without actually imposing any recommendation
>> on
>> > the user. For example, take a look at Apache Kafka download page, which
>> is
>> > a popular incubating project within Apache:
>> >
>> > http://kafka.apache.org/downloads.html
>> >
>> > I would prefer that we take the same approach.
>> >
>> > D.
>> >
>> > On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <
>> dsetrakyan@gridgain.com>
>> > wrote:
>> >
>> >> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org>
>> wrote:
>> >>
>> >>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
>> >>>> Author: dsetrakyan
>> >>>> Date: Thu Mar 26 07:47:28 2015
>> >>>> New Revision: 1669287
>> >>>>
>> >>>> URL: http://svn.apache.org/r1669287
>> >>>
>> >>> Well, in my opinion, the source download should be first on the page,
>> >>> not the binaries. Binaries are not official releases; the sources are.
>> >>> We should be encouraging people to use the sources.
>> >>>
>> >> Brane,
>> >>
>> >> Our release build procedure which builds the binary, requires that you
>> >> must be under the GIT root. The reason is that it automatically grabs
>> the
>> >> version from the GIT server in order to imprint it into the release.
>> So the
>> >> build you are suggesting does not even work. User would still be able
>> to
>> >> build the maven modules, but user cannot build the actual binary
>> release,
>> >> hence the -P-release option.
>> >>
>> >> I don't mind having a separate discussion about how useful it is for
>> our
>> >> users to build a complete binary from the source zip (and not from
>> GIT),
>> >> but in the mean time, I cannot call it the recommended way, because it
>> is
>> >> not. Do you mind if I update the text?
>> >>
>> >> D.
>> >>
>> >>
>> >>
>> >>> -- Brane
>> >>>
>> >>
>>
>>
>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Branko Čibej <br...@apache.org>.
On 27.03.2015 00:21, Valentin Kulichenko wrote:
> I made a fix in sprint-2 - binary package can be built without Git now
> (revision will be 'n/a').
Nice.
Have you considered scripting the process of creating the source package
from Git so that you do get a valid revision and/or tag name from the
build? That would certainly help in tracking down issues raised by users.
-- Brane
On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej <br...@apache.org> wrote:
>> If the user cannot build a complete release from source, then the source
>> release is not functional. It's as simple as that. The ASF releases
>> sources, not binaries. Binaries are never official releases.
>>
>> I'm really not interested in how other projects are doing it wrong; I'm
>> interested in Ignite doing it right. If that means we need to modify the
>> release process so that the source tarball is in a shape that allows
>> building a binary release (as opposed to a developer build), then that's
>> what we need to do.
>>
>> Two can play the second-guessing game by looking at what other projects
>> are doing; for example, I copied the disclaimer text straight off Flex's
>> web site. But that's unproductive: our goal should be to follow ASF
>> release policy, which states (http://www.apache.org/dev/release.html):
>>
>> Under no circumstances are unapproved builds a substitute for
>> releases. If this policy seems inconvenient, then release more
>> often. Proper release management is a key aspect of Apache software
>> development.
>>
>> The Apache Software Foundation produces open source software. All
>> releases are in the form of the source materials needed to make
>> changes to the software being released. In some cases,
>> binary/bytecode packages are also produced as a convenience to users
>> that might not have the appropriate tools to build a compiled
>> version of the source. In all such cases, the binary/bytecode
>> package must have the same version number as the source release and
>> may only add binary/bytecode files that are the result of compiling
>> that version of the source code release.
>>
>> Note the bit about "the result of compiling that version of the source
>> code release" and note that the 1.0.0-rc3 binary package contains
>> libraries that are not in the source package; that's another thing that
>> needs fixing for the next release.
>>
>> Also note the bit about "unapproved builds": Nobody voted on your binary
>> package, so it's quite inappropriate to *not* warn the user about the
>> convenience, unapproved nature of the binaries.
>>
>> -- Brane
>>
>> On 26.03.2015 18:29, Dmitriy Setrakyan wrote:
>>> Given that we cannot do a release build of the source code without having
>>> GIT, I think keeping the text we have on our download page is very
>>> confusing to our users. I will go ahead and fix it for now, and I am
>> happy
>>> to have another discussion thread on whether to recommend binary or
>> source
>>> downloads.
>>>
>>> I also am looking at other projects, and I am seeing that they simply
>>> provide source and binary without actually imposing any recommendation on
>>> the user. For example, take a look at Apache Kafka download page, which
>> is
>>> a popular incubating project within Apache:
>>>
>>> http://kafka.apache.org/downloads.html
>>>
>>> I would prefer that we take the same approach.
>>>
>>> D.
>>>
>>> On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <
>> dsetrakyan@gridgain.com>
>>> wrote:
>>>
>>>> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
>>>>
>>>>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
>>>>>> Author: dsetrakyan
>>>>>> Date: Thu Mar 26 07:47:28 2015
>>>>>> New Revision: 1669287
>>>>>>
>>>>>> URL: http://svn.apache.org/r1669287
>>>>> Well, in my opinion, the source download should be first on the page,
>>>>> not the binaries. Binaries are not official releases; the sources are.
>>>>> We should be encouraging people to use the sources.
>>>>>
>>>> Brane,
>>>>
>>>> Our release build procedure which builds the binary, requires that you
>>>> must be under the GIT root. The reason is that it automatically grabs
>> the
>>>> version from the GIT server in order to imprint it into the release. So
>> the
>>>> build you are suggesting does not even work. User would still be able to
>>>> build the maven modules, but user cannot build the actual binary
>> release,
>>>> hence the -P-release option.
>>>>
>>>> I don't mind having a separate discussion about how useful it is for our
>>>> users to build a complete binary from the source zip (and not from GIT),
>>>> but in the mean time, I cannot call it the recommended way, because it
>> is
>>>> not. Do you mind if I update the text?
>>>>
>>>> D.
>>>>
>>>>
>>>>
>>>>> -- Brane
>>>>>
>>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Valentin Kulichenko <va...@gmail.com>.
I made a fix in sprint-2 - binary package can be built without Git now
(revision will be 'n/a').
--
Val
On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej <br...@apache.org> wrote:
> If the user cannot build a complete release from source, then the source
> release is not functional. It's as simple as that. The ASF releases
> sources, not binaries. Binaries are never official releases.
>
> I'm really not interested in how other projects are doing it wrong; I'm
> interested in Ignite doing it right. If that means we need to modify the
> release process so that the source tarball is in a shape that allows
> building a binary release (as opposed to a developer build), then that's
> what we need to do.
>
> Two can play the second-guessing game by looking at what other projects
> are doing; for example, I copied the disclaimer text straight off Flex's
> web site. But that's unproductive: our goal should be to follow ASF
> release policy, which states (http://www.apache.org/dev/release.html):
>
> Under no circumstances are unapproved builds a substitute for
> releases. If this policy seems inconvenient, then release more
> often. Proper release management is a key aspect of Apache software
> development.
>
> The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released. In some cases,
> binary/bytecode packages are also produced as a convenience to users
> that might not have the appropriate tools to build a compiled
> version of the source. In all such cases, the binary/bytecode
> package must have the same version number as the source release and
> may only add binary/bytecode files that are the result of compiling
> that version of the source code release.
>
> Note the bit about "the result of compiling that version of the source
> code release" and note that the 1.0.0-rc3 binary package contains
> libraries that are not in the source package; that's another thing that
> needs fixing for the next release.
>
> Also note the bit about "unapproved builds": Nobody voted on your binary
> package, so it's quite inappropriate to *not* warn the user about the
> convenience, unapproved nature of the binaries.
>
> -- Brane
>
> On 26.03.2015 18:29, Dmitriy Setrakyan wrote:
> > Given that we cannot do a release build of the source code without having
> > GIT, I think keeping the text we have on our download page is very
> > confusing to our users. I will go ahead and fix it for now, and I am
> happy
> > to have another discussion thread on whether to recommend binary or
> source
> > downloads.
> >
> > I also am looking at other projects, and I am seeing that they simply
> > provide source and binary without actually imposing any recommendation on
> > the user. For example, take a look at Apache Kafka download page, which
> is
> > a popular incubating project within Apache:
> >
> > http://kafka.apache.org/downloads.html
> >
> > I would prefer that we take the same approach.
> >
> > D.
> >
> > On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <
> dsetrakyan@gridgain.com>
> > wrote:
> >
> >> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
> >>
> >>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
> >>>> Author: dsetrakyan
> >>>> Date: Thu Mar 26 07:47:28 2015
> >>>> New Revision: 1669287
> >>>>
> >>>> URL: http://svn.apache.org/r1669287
> >>>
> >>> Well, in my opinion, the source download should be first on the page,
> >>> not the binaries. Binaries are not official releases; the sources are.
> >>> We should be encouraging people to use the sources.
> >>>
> >> Brane,
> >>
> >> Our release build procedure which builds the binary, requires that you
> >> must be under the GIT root. The reason is that it automatically grabs
> the
> >> version from the GIT server in order to imprint it into the release. So
> the
> >> build you are suggesting does not even work. User would still be able to
> >> build the maven modules, but user cannot build the actual binary
> release,
> >> hence the -P-release option.
> >>
> >> I don't mind having a separate discussion about how useful it is for our
> >> users to build a complete binary from the source zip (and not from GIT),
> >> but in the mean time, I cannot call it the recommended way, because it
> is
> >> not. Do you mind if I update the text?
> >>
> >> D.
> >>
> >>
> >>
> >>> -- Brane
> >>>
> >>
>
>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Branko Čibej <br...@apache.org>.
If the user cannot build a complete release from source, then the source
release is not functional. It's as simple as that. The ASF releases
sources, not binaries. Binaries are never official releases.
I'm really not interested in how other projects are doing it wrong; I'm
interested in Ignite doing it right. If that means we need to modify the
release process so that the source tarball is in a shape that allows
building a binary release (as opposed to a developer build), then that's
what we need to do.
Two can play the second-guessing game by looking at what other projects
are doing; for example, I copied the disclaimer text straight off Flex's
web site. But that's unproductive: our goal should be to follow ASF
release policy, which states (http://www.apache.org/dev/release.html):
Under no circumstances are unapproved builds a substitute for
releases. If this policy seems inconvenient, then release more
often. Proper release management is a key aspect of Apache software
development.
The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make
changes to the software being released. In some cases,
binary/bytecode packages are also produced as a convenience to users
that might not have the appropriate tools to build a compiled
version of the source. In all such cases, the binary/bytecode
package must have the same version number as the source release and
may only add binary/bytecode files that are the result of compiling
that version of the source code release.
Note the bit about "the result of compiling that version of the source
code release" and note that the 1.0.0-rc3 binary package contains
libraries that are not in the source package; that's another thing that
needs fixing for the next release.
Also note the bit about "unapproved builds": Nobody voted on your binary
package, so it's quite inappropriate to *not* warn the user about the
convenience, unapproved nature of the binaries.
-- Brane
On 26.03.2015 18:29, Dmitriy Setrakyan wrote:
> Given that we cannot do a release build of the source code without having
> GIT, I think keeping the text we have on our download page is very
> confusing to our users. I will go ahead and fix it for now, and I am happy
> to have another discussion thread on whether to recommend binary or source
> downloads.
>
> I also am looking at other projects, and I am seeing that they simply
> provide source and binary without actually imposing any recommendation on
> the user. For example, take a look at Apache Kafka download page, which is
> a popular incubating project within Apache:
>
> http://kafka.apache.org/downloads.html
>
> I would prefer that we take the same approach.
>
> D.
>
> On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <ds...@gridgain.com>
> wrote:
>
>> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
>>
>>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
>>>> Author: dsetrakyan
>>>> Date: Thu Mar 26 07:47:28 2015
>>>> New Revision: 1669287
>>>>
>>>> URL: http://svn.apache.org/r1669287
>>>
>>> Well, in my opinion, the source download should be first on the page,
>>> not the binaries. Binaries are not official releases; the sources are.
>>> We should be encouraging people to use the sources.
>>>
>> Brane,
>>
>> Our release build procedure which builds the binary, requires that you
>> must be under the GIT root. The reason is that it automatically grabs the
>> version from the GIT server in order to imprint it into the release. So the
>> build you are suggesting does not even work. User would still be able to
>> build the maven modules, but user cannot build the actual binary release,
>> hence the -P-release option.
>>
>> I don't mind having a separate discussion about how useful it is for our
>> users to build a complete binary from the source zip (and not from GIT),
>> but in the mean time, I cannot call it the recommended way, because it is
>> not. Do you mind if I update the text?
>>
>> D.
>>
>>
>>
>>> -- Brane
>>>
>>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Given that we cannot do a release build of the source code without having
GIT, I think keeping the text we have on our download page is very
confusing to our users. I will go ahead and fix it for now, and I am happy
to have another discussion thread on whether to recommend binary or source
downloads.
I also am looking at other projects, and I am seeing that they simply
provide source and binary without actually imposing any recommendation on
the user. For example, take a look at Apache Kafka download page, which is
a popular incubating project within Apache:
http://kafka.apache.org/downloads.html
I would prefer that we take the same approach.
D.
On Thu, Mar 26, 2015 at 7:19 AM, Dmitriy Setrakyan <ds...@gridgain.com>
wrote:
>
> On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
>
>> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
>> > Author: dsetrakyan
>> > Date: Thu Mar 26 07:47:28 2015
>> > New Revision: 1669287
>> >
>> > URL: http://svn.apache.org/r1669287
>>
>>
>> Well, in my opinion, the source download should be first on the page,
>> not the binaries. Binaries are not official releases; the sources are.
>> We should be encouraging people to use the sources.
>>
>
> Brane,
>
> Our release build procedure which builds the binary, requires that you
> must be under the GIT root. The reason is that it automatically grabs the
> version from the GIT server in order to imprint it into the release. So the
> build you are suggesting does not even work. User would still be able to
> build the maven modules, but user cannot build the actual binary release,
> hence the -P-release option.
>
> I don't mind having a separate discussion about how useful it is for our
> users to build a complete binary from the source zip (and not from GIT),
> but in the mean time, I cannot call it the recommended way, because it is
> not. Do you mind if I update the text?
>
> D.
>
>
>
>> -- Brane
>>
>
>
Re: svn commit: r1669287 - /incubator/ignite/site/trunk/download-mirrors.html
Posted by Dmitriy Setrakyan <ds...@gridgain.com>.
On Thu, Mar 26, 2015 at 4:28 AM, Branko Čibej <br...@apache.org> wrote:
> On 26.03.2015 08:47, dsetrakyan@apache.org wrote:
> > Author: dsetrakyan
> > Date: Thu Mar 26 07:47:28 2015
> > New Revision: 1669287
> >
> > URL: http://svn.apache.org/r1669287
>
>
> Well, in my opinion, the source download should be first on the page,
> not the binaries. Binaries are not official releases; the sources are.
> We should be encouraging people to use the sources.
>
Brane,
Our release build procedure which builds the binary, requires that you must
be under the GIT root. The reason is that it automatically grabs the
version from the GIT server in order to imprint it into the release. So the
build you are suggesting does not even work. User would still be able to
build the maven modules, but user cannot build the actual binary release,
hence the -P-release option.
I don't mind having a separate discussion about how useful it is for our
users to build a complete binary from the source zip (and not from GIT),
but in the mean time, I cannot call it the recommended way, because it is
not. Do you mind if I update the text?
D.
> -- Brane
>