On Wed, Dec 5, 2012 at 3:41 PM, Rob Weir <robw...@apache.org> wrote: > On Wed, Dec 5, 2012 at 5:57 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >> On Wed, Dec 5, 2012 at 1:03 PM, Rob Weir <rabas...@gmail.com> wrote: >>> On Dec 5, 2012, at 4:44 AM, Oliver-Rainer Wittmann >>> <orwittm...@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
