You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2012/12/05 10:43:54 UTC
[RELEASE, IMPORTANT]: What is a release - my lesson learned at ApacheCon
EU 2012
Hi,
In the thread regarding our planned release for further languages - thread
subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about
what we want/should release and what kind of binary packages should be made
available and on which location.
Thus, I just want to share what I had learned in the discussions with Apache
members at the ApacheCon EU 2012 regarding releases made by an ASF project. The
discussion was more or less about all paragraphs in section "What Is A Release?"
found at [1]:
<my lesson learned>
A release - in nomenclature of ASF - is more or less the publication of the open
source material of an ASF project.
A binary packages which are produced on the basis of a certain release are only
for the convenience to the users. These binary packages do not belong to the
released material.
</my lesson learned>
My conclusions for our AOO project releases are:
- An AOO release consists of the source package which we are creating based on a
certain revision of our source code repository.
- We are producing certain binary packages based on the same source code
repository revision which we had tested in advanced.
- We are providing the produced binary packages as convenience to our users
together this the publication of our release.
[1] http://www.apache.org/dev/release.html#releases
Best regards, Oliver.
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at
ApacheCon EU 2012
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Dec 5, 2012 at 2:57 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Dec 5, 2012 at 1:03 PM, Rob Weir <ra...@gmail.com> wrote:
>> On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
>>> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
>>> <my lesson learned>
>>> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
>>> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
>>> </my lesson learned>
>>
>>
>>
>> If you ask 5 Apache Members on this you will get 5 interpretations. I
>> know. I've seen many conflicting interpretations on the Incubator
>> general list.
>>
>>
>>>
>>> My conclusions for our AOO project releases are:
>>> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
>>> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
>>> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>>>
>>
>> But from this you cannot conclude that a project may publish binaries
>> with lesser degree of review and approval than we do for a release.
>
> What I took from this, as we have all seen and supposedly understand
> the ASF release guidelines and what they mean, is the appropriate
> place(s) to house our binaries, beta or not. Right now our production
> releases of these are NOT in our ASF "dist" area, nor should they be I
> guess.
OOPS! on this one...I missed the binaries in the "files" section- of
"dist". So, yes they're in the "dist" but we don't actually distribute
them from there!
>
> But, you are correct, we absolutely should NOT publish binaries
> without undergoing scrutiny. The binaries are, for the most part, our
> deliverable and the product that is used.
>
>
>> Remember our Notice obligations stem from the use of 3rd party open
>> source. This is more than just an ASF policy question. Ditto for
>> proper license file.
>>
>> Also, Remember, our binaries are the source files for some consumers,
>> those who repackage, e.g. WinPenPack. So proper review of the IP is
>> essential.
>>
>> I'd recommend simply producing a RC and having a 72 hour vote. This
>> won't kill anyone. I don't see what we're so scared of. We review blog
>> posts for 72 hours before publishing. Is it really such a bad thing to
>> have a review and approval of binaries before publishing?
>>
>> -Rob
>>
>>
>>> [1] http://www.apache.org/dev/release.html#releases
>>>
>>>
>>> Best regards, Oliver.
>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> “How wrong is it for a woman to expect the man to build the world
> she wants, rather than to create it herself?”
>
> -- Anais Nin
--
----------------------------------------------------------------------------------------
MzK
“How wrong is it for a woman to expect the man to build the world
she wants, rather than to create it herself?”
-- Anais Nin
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at
ApacheCon EU 2012
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Dec 5, 2012 at 3:41 PM, Rob Weir <ro...@apache.org> wrote:
> On Wed, Dec 5, 2012 at 5:57 PM, Kay Schenk <ka...@gmail.com> wrote:
>> On Wed, Dec 5, 2012 at 1:03 PM, Rob Weir <ra...@gmail.com> wrote:
>>> On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann
>>> <or...@googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
>>>> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
>>>> <my lesson learned>
>>>> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
>>>> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
>>>> </my lesson learned>
>>>
>>>
>>>
>>> If you ask 5 Apache Members on this you will get 5 interpretations. I
>>> know. I've seen many conflicting interpretations on the Incubator
>>> general list.
>>>
>>>
>>>>
>>>> My conclusions for our AOO project releases are:
>>>> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
>>>> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
>>>> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>>>>
>>>
>>> But from this you cannot conclude that a project may publish binaries
>>> with lesser degree of review and approval than we do for a release.
>>
>> What I took from this, as we have all seen and supposedly understand
>> the ASF release guidelines and what they mean, is the appropriate
>> place(s) to house our binaries, beta or not. Right now our production
>> releases of these are NOT in our ASF "dist" area, nor should they be I
>> guess.
>>
>
> I'm not sure what you mean by a "production release". If you mean the
> final, tested, approved and published binaries, they should go onto
> the 'dist' directory. That's where other Apache projects put their
> binaries, if they have them. Poke around on
> http://www.apache.org/dist/ and you will see dozens of examples of
> this.
>
> Ours are there as well:
> http://www.apache.org/dist/incubator/ooo/files/stable/3.4.1/
yes, I just corrected this in a new post. Sorry...I missed them.
>
> The main concern with our binary releases was that once you include
> all the language and platform variations they were too large for most
> of the mirror operators to deal with. We still need to fix that
> version * language * platform * architecture combinatorial explosion
> problem...
yes, see comments on newly submitted INFRA-5607 --
https://issues.apache.org/jira/browse/INFRA-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510903#comment-13510903
I think it might help the storage problem is we didn't include the
binaries on "dist" and only on SourceForge, but this is a topic for a
separate discussion.
>
>> But, you are correct, we absolutely should NOT publish binaries
>> without undergoing scrutiny. The binaries are, for the most part, our
>> deliverable and the product that is used.
>>
>
> Maybe that is a good way to think of it. We vote on a "release" that
> is the source tarball. It undergoes the normal checks for RAT scans,
> NOTICE and LICENSE reviews, etc. But we also vote on "publication" of
> binaries. The binaries undergo QA and a subset of the release
> reviews. For example, binaries have a LICENSE but they don't need
> RAT scans. The "source release" and "binaries publication" votes can
> be held at the same time, even in the same ballot.
>
> Further, if we need to extend a release to publish new binaries, and
> with no source changes, then that only requires approval of the
> binaries, since the source has not changed.
>
> However, adding a new language, where the language strings have been
> be changed, is a source change. So it requires approval as a release
> and publication of binaries.
>
> But if we want to publish binaries for a partial translation, say 80%,
> where the translation is identical to what was already included in a
> prior source release, then that only requires approval of the
> publication of the binaries. But these would need to go out to
> SourceForge, not people.apache.org.
>
> The thing to remember is a translation is not guaranteed to be free of
> novel functional defects. The strings interact in odd ways. If you
> recall, the Finnish translation was at 100% for 3.4.0, but we had to
> pull it from the release because of functional errors called by
> malformed strings.
I confess I don't have a very deep understanding of what's involved
with this other than my limited experience on our Pootle setup. My
feeling is that allowing for even "provisional" access to end users
with some things not translated, regardless of where it lives,
wouldn't be wise. But OK, on your analysis here.
>
> It is probably a good idea to keep in mind principles, rather than
> trying to get too legalistic about the policies. We should be asking
> ourselves:
>
> 1) How can we stay out of Infra jail by avoiding sending excessive
> traffic to Apache servers?
yes...see my alternate suggestion.
>
> 2) How can we reinforce our brand reputation by ensuring that only
> QA'ed code is released to the public?
>
> 3) How can we ensure that items released in the name of the project
> have consensus of the PMC and are given ample opportunity for
> discussion?
>
> 4) How can we ensure that our published packages, both source and
> binaries, conform to the license, an of the open source libraries we
> use?
>
> 5) How can we ensure that our published packages, both source and
> binaries, have their license restrictions (both Apache and 3rd
> parties) well-documented, so users and downstream consumers and
> repackagers are able to determine their obligations.
>
>
> Regards,
>
> -Rob
>
>>
>>> Remember our Notice obligations stem from the use of 3rd party open
>>> source. This is more than just an ASF policy question. Ditto for
>>> proper license file.
>>>
>>> Also, Remember, our binaries are the source files for some consumers,
>>> those who repackage, e.g. WinPenPack. So proper review of the IP is
>>> essential.
>>>
>>> I'd recommend simply producing a RC and having a 72 hour vote. This
>>> won't kill anyone. I don't see what we're so scared of. We review blog
>>> posts for 72 hours before publishing. Is it really such a bad thing to
>>> have a review and approval of binaries before publishing?
>>>
>>> -Rob
>>>
>>>
>>>> [1] http://www.apache.org/dev/release.html#releases
>>>>
>>>>
>>>> Best regards, Oliver.
>>
>>
>>
>> --
>> ----------------------------------------------------------------------------------------
>> MzK
>>
>> “How wrong is it for a woman to expect the man to build the world
>> she wants, rather than to create it herself?”
>>
>> -- Anais Nin
--
----------------------------------------------------------------------------------------
MzK
“How wrong is it for a woman to expect the man to build the world
she wants, rather than to create it herself?”
-- Anais Nin
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at
ApacheCon EU 2012
Posted by Rob Weir <ro...@apache.org>.
On Wed, Dec 5, 2012 at 5:57 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Dec 5, 2012 at 1:03 PM, Rob Weir <ra...@gmail.com> wrote:
>> On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
>>> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
>>> <my lesson learned>
>>> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
>>> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
>>> </my lesson learned>
>>
>>
>>
>> If you ask 5 Apache Members on this you will get 5 interpretations. I
>> know. I've seen many conflicting interpretations on the Incubator
>> general list.
>>
>>
>>>
>>> My conclusions for our AOO project releases are:
>>> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
>>> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
>>> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>>>
>>
>> But from this you cannot conclude that a project may publish binaries
>> with lesser degree of review and approval than we do for a release.
>
> What I took from this, as we have all seen and supposedly understand
> the ASF release guidelines and what they mean, is the appropriate
> place(s) to house our binaries, beta or not. Right now our production
> releases of these are NOT in our ASF "dist" area, nor should they be I
> guess.
>
I'm not sure what you mean by a "production release". If you mean the
final, tested, approved and published binaries, they should go onto
the 'dist' directory. That's where other Apache projects put their
binaries, if they have them. Poke around on
http://www.apache.org/dist/ and you will see dozens of examples of
this.
Ours are there as well:
http://www.apache.org/dist/incubator/ooo/files/stable/3.4.1/
The main concern with our binary releases was that once you include
all the language and platform variations they were too large for most
of the mirror operators to deal with. We still need to fix that
version * language * platform * architecture combinatorial explosion
problem...
> But, you are correct, we absolutely should NOT publish binaries
> without undergoing scrutiny. The binaries are, for the most part, our
> deliverable and the product that is used.
>
Maybe that is a good way to think of it. We vote on a "release" that
is the source tarball. It undergoes the normal checks for RAT scans,
NOTICE and LICENSE reviews, etc. But we also vote on "publication" of
binaries. The binaries undergo QA and a subset of the release
reviews. For example, binaries have a LICENSE but they don't need
RAT scans. The "source release" and "binaries publication" votes can
be held at the same time, even in the same ballot.
Further, if we need to extend a release to publish new binaries, and
with no source changes, then that only requires approval of the
binaries, since the source has not changed.
However, adding a new language, where the language strings have been
be changed, is a source change. So it requires approval as a release
and publication of binaries.
But if we want to publish binaries for a partial translation, say 80%,
where the translation is identical to what was already included in a
prior source release, then that only requires approval of the
publication of the binaries. But these would need to go out to
SourceForge, not people.apache.org.
The thing to remember is a translation is not guaranteed to be free of
novel functional defects. The strings interact in odd ways. If you
recall, the Finnish translation was at 100% for 3.4.0, but we had to
pull it from the release because of functional errors called by
malformed strings.
It is probably a good idea to keep in mind principles, rather than
trying to get too legalistic about the policies. We should be asking
ourselves:
1) How can we stay out of Infra jail by avoiding sending excessive
traffic to Apache servers?
2) How can we reinforce our brand reputation by ensuring that only
QA'ed code is released to the public?
3) How can we ensure that items released in the name of the project
have consensus of the PMC and are given ample opportunity for
discussion?
4) How can we ensure that our published packages, both source and
binaries, conform to the license, an of the open source libraries we
use?
5) How can we ensure that our published packages, both source and
binaries, have their license restrictions (both Apache and 3rd
parties) well-documented, so users and downstream consumers and
repackagers are able to determine their obligations.
Regards,
-Rob
>
>> Remember our Notice obligations stem from the use of 3rd party open
>> source. This is more than just an ASF policy question. Ditto for
>> proper license file.
>>
>> Also, Remember, our binaries are the source files for some consumers,
>> those who repackage, e.g. WinPenPack. So proper review of the IP is
>> essential.
>>
>> I'd recommend simply producing a RC and having a 72 hour vote. This
>> won't kill anyone. I don't see what we're so scared of. We review blog
>> posts for 72 hours before publishing. Is it really such a bad thing to
>> have a review and approval of binaries before publishing?
>>
>> -Rob
>>
>>
>>> [1] http://www.apache.org/dev/release.html#releases
>>>
>>>
>>> Best regards, Oliver.
>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> “How wrong is it for a woman to expect the man to build the world
> she wants, rather than to create it herself?”
>
> -- Anais Nin
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at
ApacheCon EU 2012
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Dec 5, 2012 at 1:03 PM, Rob Weir <ra...@gmail.com> wrote:
> On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
>
>> Hi,
>>
>> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
>> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
>> <my lesson learned>
>> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
>> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
>> </my lesson learned>
>
>
>
> If you ask 5 Apache Members on this you will get 5 interpretations. I
> know. I've seen many conflicting interpretations on the Incubator
> general list.
>
>
>>
>> My conclusions for our AOO project releases are:
>> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
>> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
>> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>>
>
> But from this you cannot conclude that a project may publish binaries
> with lesser degree of review and approval than we do for a release.
What I took from this, as we have all seen and supposedly understand
the ASF release guidelines and what they mean, is the appropriate
place(s) to house our binaries, beta or not. Right now our production
releases of these are NOT in our ASF "dist" area, nor should they be I
guess.
But, you are correct, we absolutely should NOT publish binaries
without undergoing scrutiny. The binaries are, for the most part, our
deliverable and the product that is used.
> Remember our Notice obligations stem from the use of 3rd party open
> source. This is more than just an ASF policy question. Ditto for
> proper license file.
>
> Also, Remember, our binaries are the source files for some consumers,
> those who repackage, e.g. WinPenPack. So proper review of the IP is
> essential.
>
> I'd recommend simply producing a RC and having a 72 hour vote. This
> won't kill anyone. I don't see what we're so scared of. We review blog
> posts for 72 hours before publishing. Is it really such a bad thing to
> have a review and approval of binaries before publishing?
>
> -Rob
>
>
>> [1] http://www.apache.org/dev/release.html#releases
>>
>>
>> Best regards, Oliver.
--
----------------------------------------------------------------------------------------
MzK
“How wrong is it for a woman to expect the man to build the world
she wants, rather than to create it herself?”
-- Anais Nin
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at
ApacheCon EU 2012
Posted by Rob Weir <ra...@gmail.com>.
On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
> <my lesson learned>
> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
> </my lesson learned>
If you ask 5 Apache Members on this you will get 5 interpretations. I
know. I've seen many conflicting interpretations on the Incubator
general list.
>
> My conclusions for our AOO project releases are:
> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>
But from this you cannot conclude that a project may publish binaries
with lesser degree of review and approval than we do for a release.
Remember our Notice obligations stem from the use of 3rd party open
source. This is more than just an ASF policy question. Ditto for
proper license file.
Also, Remember, our binaries are the source files for some consumers,
those who repackage, e.g. WinPenPack. So proper review of the IP is
essential.
I'd recommend simply producing a RC and having a 72 hour vote. This
won't kill anyone. I don't see what we're so scared of. We review blog
posts for 72 hours before publishing. Is it really such a bad thing to
have a review and approval of binaries before publishing?
-Rob
> [1] http://www.apache.org/dev/release.html#releases
>
>
> Best regards, Oliver.
Re: [RELEASE, IMPORTANT]: What is a release - my lesson learned at ApacheCon EU 2012
Posted by Dave Fisher <da...@comcast.net>.
Oliver-Ranier,
You have written an excellent summary.
These "releases" both official source releases and user convenience binaries are distinct and voted. These should not be confused with the following:
(1) current svn source trunk.
(2) binaries built for QA, l10n, or other purposes especially release candidates.
As long as we do not distribute these unofficial internal purpose artifacts to our release channels and do not promote these to the general public as releases we are doing our best.
Rob mentions edge cases where an internal to the project build gets out. For this case it might make sense to discuss with infra on IRC if a people account is a concern of theirs and how they would prefer to mitigate that risk.
Regards,
Dave
Sent from my iPhone
On Dec 5, 2012, at 1:43 AM, Oliver-Rainer Wittmann <or...@googlemail.com> wrote:
> Hi,
>
> In the thread regarding our planned release for further languages - thread subject "[RELEASE]: new languages for AOO 3.4.1" - a discussion took place about what we want/should release and what kind of binary packages should be made available and on which location.
> Thus, I just want to share what I had learned in the discussions with Apache members at the ApacheCon EU 2012 regarding releases made by an ASF project. The discussion was more or less about all paragraphs in section "What Is A Release?" found at [1]:
> <my lesson learned>
> A release - in nomenclature of ASF - is more or less the publication of the open source material of an ASF project.
> A binary packages which are produced on the basis of a certain release are only for the convenience to the users. These binary packages do not belong to the released material.
> </my lesson learned>
>
> My conclusions for our AOO project releases are:
> - An AOO release consists of the source package which we are creating based on a certain revision of our source code repository.
> - We are producing certain binary packages based on the same source code repository revision which we had tested in advanced.
> - We are providing the produced binary packages as convenience to our users together this the publication of our release.
>
> [1] http://www.apache.org/dev/release.html#releases
>
>
> Best regards, Oliver.