You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2012/05/28 20:10:02 UTC
[PROPOSAL] Starting the graduation process
I'd like to start the graduation process, with the aim of being a TLP
in time for the 3.4.1 release.
The IPMC has a "Guide to Successful Graduation" page with a lot of
detail and advice: http://incubator.apache.org/guides/graduation.html
The calendar here is especially useful:
http://incubator.apache.org/guides/graduation.html#toplevel
It shows 4 steps:
1) a vote on ooo-dev (a community vote) on whether we want to graduate now
2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
3) an IPMC vote on whether or not to recommend the podling for graduation
4) a vote by the ASF Board on a resolution creating the new TLP
This thread is just a proposal. It is not the actual vote called for
in #1 above. But I'd like to gauge current sentiment. Are we all +1
for going ahead? If not, please list what pre-graduation tasks you
believe need to be done first.
Thanks!
-Rob
Re: [PROPOSAL] Starting the graduation process
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, May 29, 2012 at 3:45 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, May 29, 2012 at 6:29 PM, Kay Schenk <ka...@gmail.com> wrote:
> > On Mon, May 28, 2012 at 11:10 AM, Rob Weir <ro...@apache.org> wrote:
> >
> >> I'd like to start the graduation process, with the aim of being a TLP
> >> in time for the 3.4.1 release.
> >>
> >> The IPMC has a "Guide to Successful Graduation" page with a lot of
> >> detail and advice: http://incubator.apache.org/guides/graduation.html
> >>
> >> The calendar here is especially useful:
> >> http://incubator.apache.org/guides/graduation.html#toplevel
> >>
> >> It shows 4 steps:
> >>
> >> 1) a vote on ooo-dev (a community vote) on whether we want to graduate
> now
> >>
> >> 2) a discussion on ooo-dev leading to the draft of a charter for the new
> >> TLP
> >>
> >> 3) an IPMC vote on whether or not to recommend the podling for
> graduation
> >>
> >> 4) a vote by the ASF Board on a resolution creating the new TLP
> >>
> >> This thread is just a proposal. It is not the actual vote called for
> >> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> >> for going ahead? If not, please list what pre-graduation tasks you
> >> believe need to be done first.
> >>
> >> Thanks!
> >>
> >> -Rob
> >>
> >
> > There is a LOT to go through here. I was OK up until the "Prepare a
> > Charter" and then I'm confused. I see the minutes of board actions but
> not
> > actual charters(?) OK, I may have missed the essence...I'll move on.
> >
>
> I think Charter == Board Resolution.
>
> So we need something according to this template:
>
>
> https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt
>
> So the actual work for "Prepare a Charter" is to fill in the blanks in
> that template, including project name, description and scope,
> determining the initial PMC members and the PMC Chair. The calendar
> suggested a week to figure these items out. It might take us longer.
>
oh --OK...I saw these in the minutes referenced in the guide, but, well, it
didn't register with me I guess.
>
> > I think it's fine to "start the graduation process" at this time though
> I'm
> > not sure we'll make the 3.4.1 timeline proposal of July 31, 2012. (There
> > seems to be a lot to do with this.)
> >
>
> It is just a goal. If we don't make that date then the downside is:
>
> 1) We need to go thorugh the extra IPMC vote on the release and wait
> for three IPMC votes
>
> 2) We cannot issue an official press release
>
> 3) The release has "incubating" in the name
>
> This isn't horrible, but if we can avoid it, then this is good as
> well. But getting this done before we all leave for summer holidays
> seems like a good idea.
>
I understand what you're saying. Interesting points I hadn't thought of. I
was just concerned about some of the "machinations" this might involve.
> > Pedro has brought up some points. The only thing I've seen that might be
> an
> > issue for us is the use of Apache mirrors, as we're currently using
> > SourceForge for distributions also.
> >
>
> Remember, we have permission to use SourceForge, and we're also using
> the Apache mirrors, for the source distribution. So I think we're OK
> here.
>
OK, my apologies...I looked up the thread on this (again)...
http://markmail.org/message/quwkdctro7dpzyly
and it seems to imply we CAN keeping using SF if we choose.
(maybe it's time to document this somewhere...I'll see what I can do about
this.)
>
>
> -Rob
>
> >
> > --
> >
> ----------------------------------------------------------------------------------------
> > MzK
> >
> > "The reports of my death are greatly exaggerated."
> > -- Mark Twain
>
--
----------------------------------------------------------------------------------------
MzK
"The reports of my death are greatly exaggerated."
-- Mark Twain
Re: [PROPOSAL] Starting the graduation process
Posted by Shane Curcuru <as...@shanecurcuru.org>.
On 2012-05-29 6:45 PM, Rob Weir wrote:
> On Tue, May 29, 2012 at 6:29 PM, Kay Schenk<ka...@gmail.com> wrote:
>> On Mon, May 28, 2012 at 11:10 AM, Rob Weir<ro...@apache.org> wrote:
...
>> There is a LOT to go through here. I was OK up until the "Prepare a
>> Charter" and then I'm confused. I see the minutes of board actions but not
>> actual charters(?) OK, I may have missed the essence...I'll move on.
>>
>
> I think Charter == Board Resolution.
>
> So we need something according to this template:
>
> https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt
...
The template is simple, and comes after the graduation vote. But read
the third to last para thereof.
It would be instructive to search "apache project bylaws" to see
examples. While I'm pretty sure there are some projects that have never
actually written down bylaws (they really should), with a project the
size of AOO it would be useful to have at least a sketch of how the
project plans to govern itself written down.
- Shane
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 6:29 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Mon, May 28, 2012 at 11:10 AM, Rob Weir <ro...@apache.org> wrote:
>
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>>
>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>
>> The calendar here is especially useful:
>> http://incubator.apache.org/guides/graduation.html#toplevel
>>
>> It shows 4 steps:
>>
>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>
>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>> TLP
>>
>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>
>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>
>> This thread is just a proposal. It is not the actual vote called for
>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> for going ahead? If not, please list what pre-graduation tasks you
>> believe need to be done first.
>>
>> Thanks!
>>
>> -Rob
>>
>
> There is a LOT to go through here. I was OK up until the "Prepare a
> Charter" and then I'm confused. I see the minutes of board actions but not
> actual charters(?) OK, I may have missed the essence...I'll move on.
>
I think Charter == Board Resolution.
So we need something according to this template:
https://svn.apache.org/repos/private/committers/board/templates/podling-tlp-resolution.txt
So the actual work for "Prepare a Charter" is to fill in the blanks in
that template, including project name, description and scope,
determining the initial PMC members and the PMC Chair. The calendar
suggested a week to figure these items out. It might take us longer.
> I think it's fine to "start the graduation process" at this time though I'm
> not sure we'll make the 3.4.1 timeline proposal of July 31, 2012. (There
> seems to be a lot to do with this.)
>
It is just a goal. If we don't make that date then the downside is:
1) We need to go thorugh the extra IPMC vote on the release and wait
for three IPMC votes
2) We cannot issue an official press release
3) The release has "incubating" in the name
This isn't horrible, but if we can avoid it, then this is good as
well. But getting this done before we all leave for summer holidays
seems like a good idea.
> Pedro has brought up some points. The only thing I've seen that might be an
> issue for us is the use of Apache mirrors, as we're currently using
> SourceForge for distributions also.
>
Remember, we have permission to use SourceForge, and we're also using
the Apache mirrors, for the source distribution. So I think we're OK
here.
-Rob
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "The reports of my death are greatly exaggerated."
> -- Mark Twain
Re: [PROPOSAL] Starting the graduation process
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, May 28, 2012 at 11:10 AM, Rob Weir <ro...@apache.org> wrote:
> I'd like to start the graduation process, with the aim of being a TLP
> in time for the 3.4.1 release.
>
> The IPMC has a "Guide to Successful Graduation" page with a lot of
> detail and advice: http://incubator.apache.org/guides/graduation.html
>
> The calendar here is especially useful:
> http://incubator.apache.org/guides/graduation.html#toplevel
>
> It shows 4 steps:
>
> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>
> 2) a discussion on ooo-dev leading to the draft of a charter for the new
> TLP
>
> 3) an IPMC vote on whether or not to recommend the podling for graduation
>
> 4) a vote by the ASF Board on a resolution creating the new TLP
>
> This thread is just a proposal. It is not the actual vote called for
> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> for going ahead? If not, please list what pre-graduation tasks you
> believe need to be done first.
>
> Thanks!
>
> -Rob
>
There is a LOT to go through here. I was OK up until the "Prepare a
Charter" and then I'm confused. I see the minutes of board actions but not
actual charters(?) OK, I may have missed the essence...I'll move on.
I think it's fine to "start the graduation process" at this time though I'm
not sure we'll make the 3.4.1 timeline proposal of July 31, 2012. (There
seems to be a lot to do with this.)
Pedro has brought up some points. The only thing I've seen that might be an
issue for us is the use of Apache mirrors, as we're currently using
SourceForge for distributions also.
--
----------------------------------------------------------------------------------------
MzK
"The reports of my death are greatly exaggerated."
-- Mark Twain
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 28/5/12, Rob Weir <ro...@apache.org> ha scritto:
> But just to be clear, if it is found out, after
> investigation, that what we're doing is within
> Apache policies, will you still oppose this?
>
If it were declared by legal to be OK, of course
I wouldn't oppose. It is not really in my
agenda to have things done my way.
> In other words, to you is this a policy question? Or
> do you have your
> own motivations/desires that are independent of policy for
> moving
> these components?
>
> I ask this for one simple reason: If you feel strongly
> about this,
> and are motivated to do the work yourself, I would not
> object to you
> moving the tarballs. This would be true
> even if the policy question
> did not exist.
>
I think it is a matter of setting the new URL in
ooo.lst so yes, I would think I could do it myself.
I am somewhat busy right now though.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 4:48 PM, Pedro Giffuni <pf...@apache.org> wrote:
> On 05/28/12 15:42, Rob Weir wrote:
>>
>>
>>> I won't spend any more energy on the issue but feel free to
>>> do all the consultations you want, and don't take the second
>>> alternative as a threat.
>>>
>> How should I take it then?
>
>
> It's something that has to be sorted out, and in lack of a
> specific response my suggestion to just move them
> outside the SVN tree is pretty reasonable.
>
> If the issue is not solved adequately then I would feel
> little motivation in what I do in the PPMC, but that's
> really my issue and not the end of the world for this
> project. Thankfully this project is very mature and
> doesn't depend on one person.
>
But just to be clear, if it is found out, after investigation, that
what we're doing is within Apache policies, will you still oppose
this?
In other words, to you is this a policy question? Or do you have your
own motivations/desires that are independent of policy for moving
these components?
I ask this for one simple reason: If you feel strongly about this,
and are motivated to do the work yourself, I would not object to you
moving the tarballs. This would be true even if the policy question
did not exist.
-Rob
> Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
On 05/28/12 15:42, Rob Weir wrote:
>
>> I won't spend any more energy on the issue but feel free to
>> do all the consultations you want, and don't take the second
>> alternative as a threat.
>>
> How should I take it then?
It's something that has to be sorted out, and in lack of a
specific response my suggestion to just move them
outside the SVN tree is pretty reasonable.
If the issue is not solved adequately then I would feel
little motivation in what I do in the PPMC, but that's
really my issue and not the end of the world for this
project. Thankfully this project is very mature and
doesn't depend on one person.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Tsutomu Uchino <ha...@gmail.com>.
2012/5/29 Rob Weir <ro...@apache.org>:
> On Mon, May 28, 2012 at 11:18 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
>> 2012/5/29 Rob Weir <ro...@apache.org>:
>>> On Mon, May 28, 2012 at 10:44 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
>>>> Hi, Rob
>>>>
>>>> 2012/5/29 Rob Weir <ro...@apache.org>:
>>>> ...
>>>>>
>>>>> You could be in error. I hope you acknowledge that as a possibility.
>>>>> I could be in error s well. So what either one of us believes is not
>>>>> really the point, is it? Thus the suggestion to clarify the policy.
>>>>>
>>>>>> Category-B tarballs are there in an attempt to work around the
>>>>>> fact that we are only supposed to be using binaries.
>>>>>>
>>>>>
>>>>> The restriction concerning category-b binaries is a restriction on releases.
>>>>>
>>>>>> No other Apache project is carrying sources and patches to
>>>>>> MPL'd tarballs in the repositories and, other than the
>>>>>> configure option, we are giving them basically the same
>>>>>> treatment as Category-A.
>>>>>>
>>>>>
>>>>> We're not including category-b source in releases. If we learned
>>>>> anything in the last year I'd hope we learned that this was an
>>>>> important distinction.
>>>>>
>>>> Release includes some JavaScript source having MPL header from moz module
>>>> in openoffice.org/basis3.4/program/defaults and greprefs directories.
>>>>
>>>
>>> The distinction between source and binary breaks down with interpreted
>>> languages like Javascript. In such cases the distinction would be
>>> between what we include in our released source tarballs versus what we
>>> include in our released binary install sets. We may include
>>> category-b in our binary packages, even if they are in Javascript,
>>> though we may not include the same in our source packages.
>>>
>> Thanks to make it clear. In category-b section has the following
>> paragraph. I thought "ASF product" includes binary release.
>> But if it is not, I have no more concern among these files.
>>>"Note that works written in a scripting language without a binary form cannot be included in any ASF product under one of these licenses (see Transition and Exceptions)."
>>
>
> That text was in an old draft of the 3rd party licensing policy. It
> is not in the current policy. If you scroll to the top of the page
> you referenced, you should see that stated, as well as a link to the
> "official policy".
>
> -Ro
>
>> Thanks,
>> -- Tsutomu
I wonder I have not noticed about it at starting to read it from top
today. Thanks.
- Tsutomu
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 11:18 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
> 2012/5/29 Rob Weir <ro...@apache.org>:
>> On Mon, May 28, 2012 at 10:44 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
>>> Hi, Rob
>>>
>>> 2012/5/29 Rob Weir <ro...@apache.org>:
>>> ...
>>>>
>>>> You could be in error. I hope you acknowledge that as a possibility.
>>>> I could be in error s well. So what either one of us believes is not
>>>> really the point, is it? Thus the suggestion to clarify the policy.
>>>>
>>>>> Category-B tarballs are there in an attempt to work around the
>>>>> fact that we are only supposed to be using binaries.
>>>>>
>>>>
>>>> The restriction concerning category-b binaries is a restriction on releases.
>>>>
>>>>> No other Apache project is carrying sources and patches to
>>>>> MPL'd tarballs in the repositories and, other than the
>>>>> configure option, we are giving them basically the same
>>>>> treatment as Category-A.
>>>>>
>>>>
>>>> We're not including category-b source in releases. If we learned
>>>> anything in the last year I'd hope we learned that this was an
>>>> important distinction.
>>>>
>>> Release includes some JavaScript source having MPL header from moz module
>>> in openoffice.org/basis3.4/program/defaults and greprefs directories.
>>>
>>
>> The distinction between source and binary breaks down with interpreted
>> languages like Javascript. In such cases the distinction would be
>> between what we include in our released source tarballs versus what we
>> include in our released binary install sets. We may include
>> category-b in our binary packages, even if they are in Javascript,
>> though we may not include the same in our source packages.
>>
> Thanks to make it clear. In category-b section has the following
> paragraph. I thought "ASF product" includes binary release.
> But if it is not, I have no more concern among these files.
>>"Note that works written in a scripting language without a binary form cannot be included in any ASF product under one of these licenses (see Transition and Exceptions)."
>
That text was in an old draft of the 3rd party licensing policy. It
is not in the current policy. If you scroll to the top of the page
you referenced, you should see that stated, as well as a link to the
"official policy".
-Ro
> Thanks,
> -- Tsutomu
Re: [PROPOSAL] Starting the graduation process
Posted by Tsutomu Uchino <ha...@gmail.com>.
2012/5/29 Rob Weir <ro...@apache.org>:
> On Mon, May 28, 2012 at 10:44 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
>> Hi, Rob
>>
>> 2012/5/29 Rob Weir <ro...@apache.org>:
>> ...
>>>
>>> You could be in error. I hope you acknowledge that as a possibility.
>>> I could be in error s well. So what either one of us believes is not
>>> really the point, is it? Thus the suggestion to clarify the policy.
>>>
>>>> Category-B tarballs are there in an attempt to work around the
>>>> fact that we are only supposed to be using binaries.
>>>>
>>>
>>> The restriction concerning category-b binaries is a restriction on releases.
>>>
>>>> No other Apache project is carrying sources and patches to
>>>> MPL'd tarballs in the repositories and, other than the
>>>> configure option, we are giving them basically the same
>>>> treatment as Category-A.
>>>>
>>>
>>> We're not including category-b source in releases. If we learned
>>> anything in the last year I'd hope we learned that this was an
>>> important distinction.
>>>
>> Release includes some JavaScript source having MPL header from moz module
>> in openoffice.org/basis3.4/program/defaults and greprefs directories.
>>
>
> The distinction between source and binary breaks down with interpreted
> languages like Javascript. In such cases the distinction would be
> between what we include in our released source tarballs versus what we
> include in our released binary install sets. We may include
> category-b in our binary packages, even if they are in Javascript,
> though we may not include the same in our source packages.
>
Thanks to make it clear. In category-b section has the following
paragraph. I thought "ASF product" includes binary release.
But if it is not, I have no more concern among these files.
>"Note that works written in a scripting language without a binary form cannot be included in any ASF product under one of these licenses (see Transition and Exceptions)."
Thanks,
-- Tsutomu
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 10:44 PM, Tsutomu Uchino <ha...@gmail.com> wrote:
> Hi, Rob
>
> 2012/5/29 Rob Weir <ro...@apache.org>:
> ...
>>
>> You could be in error. I hope you acknowledge that as a possibility.
>> I could be in error s well. So what either one of us believes is not
>> really the point, is it? Thus the suggestion to clarify the policy.
>>
>>> Category-B tarballs are there in an attempt to work around the
>>> fact that we are only supposed to be using binaries.
>>>
>>
>> The restriction concerning category-b binaries is a restriction on releases.
>>
>>> No other Apache project is carrying sources and patches to
>>> MPL'd tarballs in the repositories and, other than the
>>> configure option, we are giving them basically the same
>>> treatment as Category-A.
>>>
>>
>> We're not including category-b source in releases. If we learned
>> anything in the last year I'd hope we learned that this was an
>> important distinction.
>>
> Release includes some JavaScript source having MPL header from moz module
> in openoffice.org/basis3.4/program/defaults and greprefs directories.
>
The distinction between source and binary breaks down with interpreted
languages like Javascript. In such cases the distinction would be
between what we include in our released source tarballs versus what we
include in our released binary install sets. We may include
category-b in our binary packages, even if they are in Javascript,
though we may not include the same in our source packages.
>>> I won't spend any more energy on the issue but feel free to
>>> do all the consultations you want, and don't take the second
>>> alternative as a threat.
>>>
>>
>> How should I take it then?
>>
>>> Pedro.
>
> -- Tsutomu
Re: [PROPOSAL] Starting the graduation process
Posted by Tsutomu Uchino <ha...@gmail.com>.
Hi, Rob
2012/5/29 Rob Weir <ro...@apache.org>:
...
>
> You could be in error. I hope you acknowledge that as a possibility.
> I could be in error s well. So what either one of us believes is not
> really the point, is it? Thus the suggestion to clarify the policy.
>
>> Category-B tarballs are there in an attempt to work around the
>> fact that we are only supposed to be using binaries.
>>
>
> The restriction concerning category-b binaries is a restriction on releases.
>
>> No other Apache project is carrying sources and patches to
>> MPL'd tarballs in the repositories and, other than the
>> configure option, we are giving them basically the same
>> treatment as Category-A.
>>
>
> We're not including category-b source in releases. If we learned
> anything in the last year I'd hope we learned that this was an
> important distinction.
>
Release includes some JavaScript source having MPL header from moz module
in openoffice.org/basis3.4/program/defaults and greprefs directories.
>> I won't spend any more energy on the issue but feel free to
>> do all the consultations you want, and don't take the second
>> alternative as a threat.
>>
>
> How should I take it then?
>
>> Pedro.
-- Tsutomu
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 4:34 PM, Pedro Giffuni <pf...@apache.org> wrote:
> On 05/28/12 15:00, Rob Weir wrote:
>>
>>
>> ...
>>
>>
>> Yes the situation was specifically postponed as a graduation
>> issue, I am not going through that discussion again.
>>
>> I made a concrete proposal with two alternatives:
>>
>> - They are moved to a friendly ftp/http site.
>> - I step down from the PPMC to avoid the community
>> the pain of a -1 vote.
>>
>> Since this is a policy question, I assume a third option would be to
>> clarify the policy? That might make sense as the first step in any
>> case.
>
>
> We already went through that and it's pretty clear to me. Those
You could be in error. I hope you acknowledge that as a possibility.
I could be in error s well. So what either one of us believes is not
really the point, is it? Thus the suggestion to clarify the policy.
> Category-B tarballs are there in an attempt to work around the
> fact that we are only supposed to be using binaries.
>
The restriction concerning category-b binaries is a restriction on releases.
> No other Apache project is carrying sources and patches to
> MPL'd tarballs in the repositories and, other than the
> configure option, we are giving them basically the same
> treatment as Category-A.
>
We're not including category-b source in releases. If we learned
anything in the last year I'd hope we learned that this was an
important distinction.
> I won't spend any more energy on the issue but feel free to
> do all the consultations you want, and don't take the second
> alternative as a threat.
>
How should I take it then?
> Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
On 05/28/12 15:00, Rob Weir wrote:
>
> ...
>
> Yes the situation was specifically postponed as a graduation
> issue, I am not going through that discussion again.
>
> I made a concrete proposal with two alternatives:
>
> - They are moved to a friendly ftp/http site.
> - I step down from the PPMC to avoid the community
> the pain of a -1 vote.
>
> Since this is a policy question, I assume a third option would be to
> clarify the policy? That might make sense as the first step in any
> case.
We already went through that and it's pretty clear to me. Those
Category-B tarballs are there in an attempt to work around the
fact that we are only supposed to be using binaries.
No other Apache project is carrying sources and patches to
MPL'd tarballs in the repositories and, other than the
configure option, we are giving them basically the same
treatment as Category-A.
I won't spend any more energy on the issue but feel free to
do all the consultations you want, and don't take the second
alternative as a threat.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 3:50 PM, Pedro Giffuni <pf...@apache.org> wrote:
> On 05/28/12 14:25, Rob Weir wrote:
>>
>> On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>
>>> Hi Rob;
>>>
>>>
>>> On 05/28/12 13:10, Rob Weir wrote:
>>>>
>>>> I'd like to start the graduation process, with the aim of being a TLP
>>>> in time for the 3.4.1 release.
>>>>
>>>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>>>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>>>
>>>> The calendar here is especially useful:
>>>> http://incubator.apache.org/guides/graduation.html#toplevel
>>>>
>>>> It shows 4 steps:
>>>>
>>>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate
>>>> now
>>>>
>>>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>>>> TLP
>>>>
>>>> 3) an IPMC vote on whether or not to recommend the podling for
>>>> graduation
>>>>
>>>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>>>
>>>> This thread is just a proposal. It is not the actual vote called for
>>>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>>>> for going ahead? If not, please list what pre-graduation tasks you
>>>> believe need to be done first.
>>>>
>>>> Thanks!
>>>>
>>>> -Rob
>>>
>>>
>>> A reminder of a small, but IMHO significant, technical issue:
>>>
>>> We do have to take the category-B tarballs out of the tree
>>> before graduation.
>>>
>> Do we? If I recall, there were multiple views on this and no
>> consensus. But you are welcome to make a concrete proposal.
>
>
> Yes the situation was specifically postponed as a graduation
> issue, I am not going through that discussion again.
>
> I made a concrete proposal with two alternatives:
>
> - They are moved to a friendly ftp/http site.
> - I step down from the PPMC to avoid the community
> the pain of a -1 vote.
>
Since this is a policy question, I assume a third option would be to
clarify the policy? That might make sense as the first step in any
case.
> Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 6:01 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On May 29, 2012, at 11:51 AM, Rob Weir wrote:
>
>> On Tue, May 29, 2012 at 2:29 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>> Hi Drew;
>>>
>>> --- Mar 29/5/12, drew <dr...@baseanswers.com> ha scritto:
>>>
>>> <snip>
>>>
>>>>>>>>>
>>>>>>> Yes the situation was specifically postponed as a graduation
>>>>>>> issue, I am not going through that discussion again.
>>>>>>>
>>>>>>> I made a concrete proposal with two alternatives:
>>>>>>>
>>>>>>> - They are moved to a friendly ftp/http site.
>>>>>>> - I step down from the PPMC to avoid the community
>>>>>>> the pain of a -1 vote.
>>>>>>
>>> ...
>>>>
>>>> Could be - it was just the way Pedro phrased his comment I
>>>> thought perhaps his thinking was being influenced by the
>>>> earlier remarks.
>>>>
>>>
>>> The idea that we have remaining issues with Category-B
>>> tarballs in the tree has been around since before the
>>> release, and one of our mentors (Ross I recall) did
>>> acknowledge my point of view.
>>>
>>
>> Again, I don't see an issue here. But if you feel strongly about this
>> you are welcome to copy the ext_sources over to Apache Extras and do a
>> trivial update of the build script. Whatever makes you happy. But
>> I'd find it odd if any substantial issue of policy could really be
>> addressed by simply changing a URL. To me that sounds like worshiping
>> some formalism rather than actually understanding the policy and its
>> intentions.
>
> There are issues with these embedded convenience packages.
>
> (1) Some are Category B. An issue to some more than others.
>
> (2) Some are patched versions of existing open-source packages. We should attempt to push these upstream. The COINMP patch looks trivial. We may need to have special builds, but we should be avoiding and removing.
>
> (3) Some are specific versions of open-source packages. We should try to get official distributions and use a version at Apache Extras as a known version.
>
> (4) Some are versions of Apache open-source packages. We should use the appropriate release or archive from the project.
>
>
> ext_sources dave$ ls -1
> 0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz
> 067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz
> 0b49ede71c21c0599b0cc19b353a6cb3-README_apache-commons.txt
> 128cfc86ed5953e57fe0f5ae98b62c2e-libtextcat-2.2.tar.gz
> 17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip
> 1756c4fa6c616ae15973c104cd8cb256-Adobe-Core35_AFMs-314.tar.gz
> 18f577b374d60b3c760a3a3350407632-STLport-4.5.tar.gz
> 1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz
> 220035f111ea045a51e290906025e8b5-libpng-1.5.1.tar.gz
> 24be19595acad0a2cae931af77a0148a-LICENSE_source-9.0.0.7-bj.html
> 284e768eeda0e2898b0d5bf7e26a016e-raptor-1.4.18.tar.gz
> 2ae988b339daec234019a7066f96733e-commons-lang-2.3-src.tar.gz
> 2b5f1ca58d6ef30f18f1415b65bed81c-CoinMP-1.6.0.tgz
> 2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
> 2f6ecca935948f7db92d925d88d0d078-icu4c-4_0_1-src.tgz
> 35efabc239af896dfb79be7ebdd6e6b9-gentiumbasic-fonts-1.10.zip
> 377a60170e5185eb63d3ed2fae98e621-README_silgraphite-2.3.1.txt
> 3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
> 3c219630e4302863a9a83d0efde889db-commons-logging-1.1.1-src.tar.gz
> 48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt
> 48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
> 48d8169acc35f97e05d8dcdfd45be7f2-lucene-2.3.2.tar.gz
> 61f59e4110781cbe66b46449eadac231-croscorefonts-1.21.0.tar.gz
> 63ddc5116488985e820075e65fbe6aa4-openssl-0.9.8o.tar.gz
> 666a5d56098a9debf998510e304c8095-apr-util-1.4.1.tar.gz
> 68dd2e8253d9a7930e9fd50e2d7220d0-hunspell-1.2.9.tar.gz
> 7376930b0d3f3d77a685d94c4a3acda8-STLport-4.5-0119.tar.gz
> 7740a8ec23878a2f50120e1faa2730f2-libxml2-2.7.6.tar.gz
> 7e4e73c21f031d5a4c93c128baf7fd75-apache-tomcat-5.5.35-src.tar.gz
> 97262fe54dddaf583eaaee3497a426e1-apr-1.4.5.tar.gz
> 980143f96b3f6ce45d2e4947da21a5e9-stax-src-1.2.0.zip
> 99d94103662a8d0b571e247a77432ac5-rhino1_7R3.zip
> a169ab152209200a7bad29a275cb0333-seamonkey-1.1.14.source.tar.gz
> a2c10c04f396a9ce72894beb18b4e1f9-jpeg-8c.tar.gz
> a7983f859eafb2677d7ff386a023bc40-xsltml_2.1.2.zip
> ada24d37d8d638b3d8a9985e80bc2978-source-9.0.0.7-bj.zip
> af3c3acf618de6108d65fcdc92b492e1-commons-codec-1.3-src.tar.gz
> b92261a5679276c400555004937af965-nss-3.12.6-with-nspr-4.8.4.tar.gz
> bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
> c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz
> c735eab2d659a96e5a594c9e8541ad63-zlib-1.2.5.tar.gz
> ca66e26082cab8bb817185a116db809b-redland-1.0.8.tar.gz
> cf8a6967f7de535ae257fa411c98eb88-mdds_0.3.0.tar.bz2
> d35724900f6a4105550293686688bbb3-silgraphite-2.3.1.tar.gz
> e61d0364a30146aaa3001296f853b2b9-libxslt-1.1.26.tar.gz
> e81c2f0953aa60f8062c05a4673f2be0-Python-2.6.1.tar.bz2
> ea570af93c284aa9e5621cd563f54f4d-bsh-2.0b1-src.tar.gz
> ea91f2fb4212a21d708aced277e6e85a-vigra1.4.0.tar.gz
> ecb2e37e45c9933e2a963cabe03670ab-curl-7.19.7.tar.gz
> ee8b492592568805593f81f8cdf2a04c-expat-2.0.1.tar.gz
> f872f4ac066433d8ff92f5e316b36ff9-dejavu-fonts-ttf-2.33.zip
> fca8706f2c4619e2fa3f8f42f8fc1e9d-rasqal-0.9.16.tar.gz
> fcc6df1160753d0b8c835d17fdeeb0a7-boost_1_39_0.tar.gz
> fdb27bfe2dbe2e7b57ae194d9bf36bab-SampleICC-1.3.2.tar.gz
>
> Do we seriously need to carry our own version of Python 2.6.1? Aren't the Adobe Base 35 AFMs good for all. There must be a common location.
>
I'll assert that we need to maintain these exact files for as long as
we maintain the 3.4.x release stream. Think of 3.4.1, security
patches, etc. But there is certainly room for improvement in a 3.5 or
4.0 stream. And as I said before, if anyone thinks that merely
relocating these dependencies to a non-Apache server solves anything,
then great.
The real question is whether anyone really thinks that it is necessary
that we either break our 3.4.x stream, or that we wait for a major
update with AOO 3.5 before we can graduate?
> Regards,
> Dave
>
>
>>
>>> I did offer to step down then but I don't mean to make
>>> a big issue out of this. If I step down it will be
>>> communicated in the private list exclusively. I would
>>> still be a committer and nothing would really change
>>> for me.
>>>
>>> What I feel is disappointing is the lack of
>>> acknowledgement that there *is* an issue. Category-B
>>> software can be included in releases in binary form
>>> but it should be otherwise actively discouraged, and in
>>> general unsupported: it should not be included in the
>>> buildbots and using it should be, in general terms, a
>>> PITA.
>>>
>>> IMHO this project benefited greatly from the Category-X
>>> replacement and in general I would like the project to
>>> head in a direction that will lead to greater license
>>> and code simplification but the current situation where
>>> we work-around the policy issues instead of solving them
>>> is (again IMO) unacceptable.
>>>
>>> Pedro.
>
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Dave;
--- Mar 29/5/12, Dave Fisher <da...@comcast.net> ha scritto:
...
>
> There are issues with these embedded convenience packages.
>
> (1) Some are Category B. An issue to some more than others.
>
> (2) Some are patched versions of existing open-source
> packages. We should attempt to push these upstream. The
> COINMP patch looks trivial. We may need to have special
> builds, but we should be avoiding and removing.
>
> (3) Some are specific versions of open-source packages. We
> should try to get official distributions and use a version
> at Apache Extras as a known version.
>
> (4) Some are versions of Apache open-source packages. We
> should use the appropriate release or archive from the
> project.
>
>
> ext_sources dave$ ls -1
> 0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz
> 067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz
> 0b49ede71c21c0599b0cc19b353a6cb3-README_apache-commons.txt
> 128cfc86ed5953e57fe0f5ae98b62c2e-libtextcat-2.2.tar.gz
> 17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip
> 1756c4fa6c616ae15973c104cd8cb256-Adobe-Core35_AFMs-314.tar.gz
> 18f577b374d60b3c760a3a3350407632-STLport-4.5.tar.gz
> 1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz
> 220035f111ea045a51e290906025e8b5-libpng-1.5.1.tar.gz
> 24be19595acad0a2cae931af77a0148a-LICENSE_source-9.0.0.7-bj.html
> 284e768eeda0e2898b0d5bf7e26a016e-raptor-1.4.18.tar.gz
> 2ae988b339daec234019a7066f96733e-commons-lang-2.3-src.tar.gz
> 2b5f1ca58d6ef30f18f1415b65bed81c-CoinMP-1.6.0.tgz
> 2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
> 2f6ecca935948f7db92d925d88d0d078-icu4c-4_0_1-src.tgz
> 35efabc239af896dfb79be7ebdd6e6b9-gentiumbasic-fonts-1.10.zip
> 377a60170e5185eb63d3ed2fae98e621-README_silgraphite-2.3.1.txt
> 3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
> 3c219630e4302863a9a83d0efde889db-commons-logging-1.1.1-src.tar.gz
> 48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt
> 48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
> 48d8169acc35f97e05d8dcdfd45be7f2-lucene-2.3.2.tar.gz
> 61f59e4110781cbe66b46449eadac231-croscorefonts-1.21.0.tar.gz
> 63ddc5116488985e820075e65fbe6aa4-openssl-0.9.8o.tar.gz
> 666a5d56098a9debf998510e304c8095-apr-util-1.4.1.tar.gz
> 68dd2e8253d9a7930e9fd50e2d7220d0-hunspell-1.2.9.tar.gz
> 7376930b0d3f3d77a685d94c4a3acda8-STLport-4.5-0119.tar.gz
> 7740a8ec23878a2f50120e1faa2730f2-libxml2-2.7.6.tar.gz
> 7e4e73c21f031d5a4c93c128baf7fd75-apache-tomcat-5.5.35-src.tar.gz
> 97262fe54dddaf583eaaee3497a426e1-apr-1.4.5.tar.gz
> 980143f96b3f6ce45d2e4947da21a5e9-stax-src-1.2.0.zip
> 99d94103662a8d0b571e247a77432ac5-rhino1_7R3.zip
> a169ab152209200a7bad29a275cb0333-seamonkey-1.1.14.source.tar.gz
> a2c10c04f396a9ce72894beb18b4e1f9-jpeg-8c.tar.gz
> a7983f859eafb2677d7ff386a023bc40-xsltml_2.1.2.zip
> ada24d37d8d638b3d8a9985e80bc2978-source-9.0.0.7-bj.zip
> af3c3acf618de6108d65fcdc92b492e1-commons-codec-1.3-src.tar.gz
> b92261a5679276c400555004937af965-nss-3.12.6-with-nspr-4.8.4.tar.gz
> bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
> c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz
> c735eab2d659a96e5a594c9e8541ad63-zlib-1.2.5.tar.gz
> ca66e26082cab8bb817185a116db809b-redland-1.0.8.tar.gz
> cf8a6967f7de535ae257fa411c98eb88-mdds_0.3.0.tar.bz2
> d35724900f6a4105550293686688bbb3-silgraphite-2.3.1.tar.gz
> e61d0364a30146aaa3001296f853b2b9-libxslt-1.1.26.tar.gz
> e81c2f0953aa60f8062c05a4673f2be0-Python-2.6.1.tar.bz2
> ea570af93c284aa9e5621cd563f54f4d-bsh-2.0b1-src.tar.gz
> ea91f2fb4212a21d708aced277e6e85a-vigra1.4.0.tar.gz
> ecb2e37e45c9933e2a963cabe03670ab-curl-7.19.7.tar.gz
> ee8b492592568805593f81f8cdf2a04c-expat-2.0.1.tar.gz
> f872f4ac066433d8ff92f5e316b36ff9-dejavu-fonts-ttf-2.33.zip
> fca8706f2c4619e2fa3f8f42f8fc1e9d-rasqal-0.9.16.tar.gz
> fcc6df1160753d0b8c835d17fdeeb0a7-boost_1_39_0.tar.gz
> fdb27bfe2dbe2e7b57ae194d9bf36bab-SampleICC-1.3.2.tar.gz
>
> Do we seriously need to carry our own version of Python
> 2.6.1? Aren't the Adobe Base 35 AFMs good for all. There
> must be a common location.
>
FreeBSD and most linux distributions have been moving
towards using prepackaged versions of this stuff when
possible. I have been updating some of these packages
attempting not to break the API but I am far from over.
The main reason why we don't just use prepackaged stuff
for everything and throw stuff like python 2.6.1 away
is that it is not practical for windows (which is
the major platform). Our python is severely patched
for other palforms and those patches have taken a lot
of time to update even for a minor version update.
The problem with Category B is that according to
Apache Policies we shouldn't be carrying the sources
but instead we should carry links to the sources in
the NOTICE file. For 3.4 we didn't comply
(embarrassingly the COIN-OR guys noted this!).
The idea is that we should be using unmodified binaries
so carrying fonts and java bytecode would be OK, but
carrying tarballs with sources was not really intended.
In the case of NSS and Seamonkey, our versions are
way too outdated: I think the Seamonkey version we
carry is not even available online anymore and
there are known security risks.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Dave Fisher <da...@comcast.net>.
On May 29, 2012, at 11:51 AM, Rob Weir wrote:
> On Tue, May 29, 2012 at 2:29 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> Hi Drew;
>>
>> --- Mar 29/5/12, drew <dr...@baseanswers.com> ha scritto:
>>
>> <snip>
>>
>>>>>>>>
>>>>>> Yes the situation was specifically postponed as a graduation
>>>>>> issue, I am not going through that discussion again.
>>>>>>
>>>>>> I made a concrete proposal with two alternatives:
>>>>>>
>>>>>> - They are moved to a friendly ftp/http site.
>>>>>> - I step down from the PPMC to avoid the community
>>>>>> the pain of a -1 vote.
>>>>>
>> ...
>>>
>>> Could be - it was just the way Pedro phrased his comment I
>>> thought perhaps his thinking was being influenced by the
>>> earlier remarks.
>>>
>>
>> The idea that we have remaining issues with Category-B
>> tarballs in the tree has been around since before the
>> release, and one of our mentors (Ross I recall) did
>> acknowledge my point of view.
>>
>
> Again, I don't see an issue here. But if you feel strongly about this
> you are welcome to copy the ext_sources over to Apache Extras and do a
> trivial update of the build script. Whatever makes you happy. But
> I'd find it odd if any substantial issue of policy could really be
> addressed by simply changing a URL. To me that sounds like worshiping
> some formalism rather than actually understanding the policy and its
> intentions.
There are issues with these embedded convenience packages.
(1) Some are Category B. An issue to some more than others.
(2) Some are patched versions of existing open-source packages. We should attempt to push these upstream. The COINMP patch looks trivial. We may need to have special builds, but we should be avoiding and removing.
(3) Some are specific versions of open-source packages. We should try to get official distributions and use a version at Apache Extras as a known version.
(4) Some are versions of Apache open-source packages. We should use the appropriate release or archive from the project.
ext_sources dave$ ls -1
0168229624cfac409e766913506961a8-ucpp-1.3.2.tar.gz
067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz
0b49ede71c21c0599b0cc19b353a6cb3-README_apache-commons.txt
128cfc86ed5953e57fe0f5ae98b62c2e-libtextcat-2.2.tar.gz
17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip
1756c4fa6c616ae15973c104cd8cb256-Adobe-Core35_AFMs-314.tar.gz
18f577b374d60b3c760a3a3350407632-STLport-4.5.tar.gz
1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz
220035f111ea045a51e290906025e8b5-libpng-1.5.1.tar.gz
24be19595acad0a2cae931af77a0148a-LICENSE_source-9.0.0.7-bj.html
284e768eeda0e2898b0d5bf7e26a016e-raptor-1.4.18.tar.gz
2ae988b339daec234019a7066f96733e-commons-lang-2.3-src.tar.gz
2b5f1ca58d6ef30f18f1415b65bed81c-CoinMP-1.6.0.tgz
2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
2f6ecca935948f7db92d925d88d0d078-icu4c-4_0_1-src.tgz
35efabc239af896dfb79be7ebdd6e6b9-gentiumbasic-fonts-1.10.zip
377a60170e5185eb63d3ed2fae98e621-README_silgraphite-2.3.1.txt
3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
3c219630e4302863a9a83d0efde889db-commons-logging-1.1.1-src.tar.gz
48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt
48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
48d8169acc35f97e05d8dcdfd45be7f2-lucene-2.3.2.tar.gz
61f59e4110781cbe66b46449eadac231-croscorefonts-1.21.0.tar.gz
63ddc5116488985e820075e65fbe6aa4-openssl-0.9.8o.tar.gz
666a5d56098a9debf998510e304c8095-apr-util-1.4.1.tar.gz
68dd2e8253d9a7930e9fd50e2d7220d0-hunspell-1.2.9.tar.gz
7376930b0d3f3d77a685d94c4a3acda8-STLport-4.5-0119.tar.gz
7740a8ec23878a2f50120e1faa2730f2-libxml2-2.7.6.tar.gz
7e4e73c21f031d5a4c93c128baf7fd75-apache-tomcat-5.5.35-src.tar.gz
97262fe54dddaf583eaaee3497a426e1-apr-1.4.5.tar.gz
980143f96b3f6ce45d2e4947da21a5e9-stax-src-1.2.0.zip
99d94103662a8d0b571e247a77432ac5-rhino1_7R3.zip
a169ab152209200a7bad29a275cb0333-seamonkey-1.1.14.source.tar.gz
a2c10c04f396a9ce72894beb18b4e1f9-jpeg-8c.tar.gz
a7983f859eafb2677d7ff386a023bc40-xsltml_2.1.2.zip
ada24d37d8d638b3d8a9985e80bc2978-source-9.0.0.7-bj.zip
af3c3acf618de6108d65fcdc92b492e1-commons-codec-1.3-src.tar.gz
b92261a5679276c400555004937af965-nss-3.12.6-with-nspr-4.8.4.tar.gz
bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz
c735eab2d659a96e5a594c9e8541ad63-zlib-1.2.5.tar.gz
ca66e26082cab8bb817185a116db809b-redland-1.0.8.tar.gz
cf8a6967f7de535ae257fa411c98eb88-mdds_0.3.0.tar.bz2
d35724900f6a4105550293686688bbb3-silgraphite-2.3.1.tar.gz
e61d0364a30146aaa3001296f853b2b9-libxslt-1.1.26.tar.gz
e81c2f0953aa60f8062c05a4673f2be0-Python-2.6.1.tar.bz2
ea570af93c284aa9e5621cd563f54f4d-bsh-2.0b1-src.tar.gz
ea91f2fb4212a21d708aced277e6e85a-vigra1.4.0.tar.gz
ecb2e37e45c9933e2a963cabe03670ab-curl-7.19.7.tar.gz
ee8b492592568805593f81f8cdf2a04c-expat-2.0.1.tar.gz
f872f4ac066433d8ff92f5e316b36ff9-dejavu-fonts-ttf-2.33.zip
fca8706f2c4619e2fa3f8f42f8fc1e9d-rasqal-0.9.16.tar.gz
fcc6df1160753d0b8c835d17fdeeb0a7-boost_1_39_0.tar.gz
fdb27bfe2dbe2e7b57ae194d9bf36bab-SampleICC-1.3.2.tar.gz
Do we seriously need to carry our own version of Python 2.6.1? Aren't the Adobe Base 35 AFMs good for all. There must be a common location.
Regards,
Dave
>
>> I did offer to step down then but I don't mean to make
>> a big issue out of this. If I step down it will be
>> communicated in the private list exclusively. I would
>> still be a committer and nothing would really change
>> for me.
>>
>> What I feel is disappointing is the lack of
>> acknowledgement that there *is* an issue. Category-B
>> software can be included in releases in binary form
>> but it should be otherwise actively discouraged, and in
>> general unsupported: it should not be included in the
>> buildbots and using it should be, in general terms, a
>> PITA.
>>
>> IMHO this project benefited greatly from the Category-X
>> replacement and in general I would like the project to
>> head in a direction that will lead to greater license
>> and code simplification but the current situation where
>> we work-around the policy issues instead of solving them
>> is (again IMO) unacceptable.
>>
>> Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 2:29 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Drew;
>
> --- Mar 29/5/12, drew <dr...@baseanswers.com> ha scritto:
>
> <snip>
>
>> > >> >>
>>> >> Yes the situation was specifically postponed as a graduation
>>> >> issue, I am not going through that discussion again.
>>> >>
>>> >> I made a concrete proposal with two alternatives:
>>> >>
>>> >> - They are moved to a friendly ftp/http site.
>>> >> - I step down from the PPMC to avoid the community
>>> >> the pain of a -1 vote.
>>> >
> ...
>>
>> Could be - it was just the way Pedro phrased his comment I
>> thought perhaps his thinking was being influenced by the
>> earlier remarks.
>>
>
> The idea that we have remaining issues with Category-B
> tarballs in the tree has been around since before the
> release, and one of our mentors (Ross I recall) did
> acknowledge my point of view.
>
Again, I don't see an issue here. But if you feel strongly about this
you are welcome to copy the ext_sources over to Apache Extras and do a
trivial update of the build script. Whatever makes you happy. But
I'd find it odd if any substantial issue of policy could really be
addressed by simply changing a URL. To me that sounds like worshiping
some formalism rather than actually understanding the policy and its
intentions.
> I did offer to step down then but I don't mean to make
> a big issue out of this. If I step down it will be
> communicated in the private list exclusively. I would
> still be a committer and nothing would really change
> for me.
>
> What I feel is disappointing is the lack of
> acknowledgement that there *is* an issue. Category-B
> software can be included in releases in binary form
> but it should be otherwise actively discouraged, and in
> general unsupported: it should not be included in the
> buildbots and using it should be, in general terms, a
> PITA.
>
> IMHO this project benefited greatly from the Category-X
> replacement and in general I would like the project to
> head in a direction that will lead to greater license
> and code simplification but the current situation where
> we work-around the policy issues instead of solving them
> is (again IMO) unacceptable.
>
> Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Andre Fischer <af...@a-w-f.de>.
On 01.06.2012 14:03, Rob Weir wrote:
> On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer<af...@a-w-f.de> wrote:
>> On 31.05.2012 18:12, Rob Weir wrote:
>>>
>>> On Thu, May 31, 2012 at 11:19 AM, Andre Fischer<af...@a-w-f.de> wrote:
>>>>
>>>> On 31.05.2012 14:51, Rob Weir wrote:
>>>>>
>>>>>
>>>>> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>>>>
>>>>
>>>>
>>>> [...]
>>>>
>>>>
>>>>> So instead of a an axe, let's try a scalpel. The ext_sources tree was
>>>>> branched along with the rest of the the AOO 3.4 tree. So you should
>>>>> be able to safely work on the branch, defining the external
>>>>> dependencies there. This could be done without touching the trunk and
>>>>> without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
>>>>> can bring those changes to the trunk.
>>>>>
>>>>> Does that make sense? We don't break our release distributions until
>>>>> we have a working replacement in the form of 3.4.1. If that means we
>>>>> delay graduation until 3.4.1, then so be it.
>>>>
>>>>
>>>>
>>>> You are talking about a new branch, right, not the 3.4.1 branch?
>>>>
>>>
>>> I thought the 3.4.1 branch would be appropriate. Move the category-b
>>> tarballs to Apache Extras, and make the build fetch from there instead
>>> of from SVN. That way the trunk's copy of these dependencies doesn't
>>> disappear yet. Then when we release 3.4.1, we have a release that is
>>> not dependent on the SVN copies, and we can safely remove them then.
>>
>>
>> My understanding is that we have to make sure that the files referenced by
>> the (source) release do not go away. That did not work so well for the 3.4
>> release because they where referenced on trunk. If the 3.4.1 release
>> references the files on the branch then that should be safe(r).
>> Trunk is where the main part of development takes place.
>>
>
> In an ideal world, yes. We would never break the AOO 3.4.0 release
> source package. But one compromise could be to first relocate the
> cat-b tarballs for 3.4.1 release. And once that release is made, then
> do the changes that would break the 3.4.0 source package.
>
> If we do this then we ensure that the latest source distribution can
> always build.
Maybe you are right. May resistance against such changes in 3.4.1 comes
from the rules we had at Sun/Oracle: only fix severe bugs and not
introduce new regressions.
Anyway, I am working on the changes to fetch_tarballs.sh:
- The conversion to a Perl script is already done (it is already notably
faster on Windows when no packages have to be downloaded)
- I can specify multiple download sites for each file. The majority of
tar balls can be downloaded from their original servers.
- Fallback download server will be Apache Extras.
I hope that the work will be finished by Monday.
-Andre
>
>>
>>>
>>> The problem we have now is that even though we branched after the 3.4
>>> release, the build script is still fetching from the trunk copy of the
>>> dependencies. So we need to fix this is a somewhat backwards way.
>>
>>
>> For the 3.4 release we have to restore the tar-balls that where deleted
>> since the release. That does of course not mean that the newer versions
>> have to be removed as well. Due to different version numbers and MD5 sums
>> they have different names and can coexist.
>>
>> -Andre
>>
>>
>>>
>>> Or am I missing something?
>>>
>>> -Rob
>>>
>>>> -Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer <af...@a-w-f.de> wrote:
> On 31.05.2012 18:12, Rob Weir wrote:
>>
>> On Thu, May 31, 2012 at 11:19 AM, Andre Fischer<af...@a-w-f.de> wrote:
>>>
>>> On 31.05.2012 14:51, Rob Weir wrote:
>>>>
>>>>
>>>> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>>>
>>>
>>>
>>> [...]
>>>
>>>
>>>> So instead of a an axe, let's try a scalpel. The ext_sources tree was
>>>> branched along with the rest of the the AOO 3.4 tree. So you should
>>>> be able to safely work on the branch, defining the external
>>>> dependencies there. This could be done without touching the trunk and
>>>> without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
>>>> can bring those changes to the trunk.
>>>>
>>>> Does that make sense? We don't break our release distributions until
>>>> we have a working replacement in the form of 3.4.1. If that means we
>>>> delay graduation until 3.4.1, then so be it.
>>>
>>>
>>>
>>> You are talking about a new branch, right, not the 3.4.1 branch?
>>>
>>
>> I thought the 3.4.1 branch would be appropriate. Move the category-b
>> tarballs to Apache Extras, and make the build fetch from there instead
>> of from SVN. That way the trunk's copy of these dependencies doesn't
>> disappear yet. Then when we release 3.4.1, we have a release that is
>> not dependent on the SVN copies, and we can safely remove them then.
>
>
> My understanding is that we have to make sure that the files referenced by
> the (source) release do not go away. That did not work so well for the 3.4
> release because they where referenced on trunk. If the 3.4.1 release
> references the files on the branch then that should be safe(r).
> Trunk is where the main part of development takes place.
>
In an ideal world, yes. We would never break the AOO 3.4.0 release
source package. But one compromise could be to first relocate the
cat-b tarballs for 3.4.1 release. And once that release is made, then
do the changes that would break the 3.4.0 source package.
If we do this then we ensure that the latest source distribution can
always build.
>
>>
>> The problem we have now is that even though we branched after the 3.4
>> release, the build script is still fetching from the trunk copy of the
>> dependencies. So we need to fix this is a somewhat backwards way.
>
>
> For the 3.4 release we have to restore the tar-balls that where deleted
> since the release. That does of course not mean that the newer versions
> have to be removed as well. Due to different version numbers and MD5 sums
> they have different names and can coexist.
>
> -Andre
>
>
>>
>> Or am I missing something?
>>
>> -Rob
>>
>>> -Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Andre Fischer <af...@a-w-f.de>.
On 31.05.2012 18:12, Rob Weir wrote:
> On Thu, May 31, 2012 at 11:19 AM, Andre Fischer<af...@a-w-f.de> wrote:
>> On 31.05.2012 14:51, Rob Weir wrote:
>>>
>>> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>>
>>
>> [...]
>>
>>
>>> So instead of a an axe, let's try a scalpel. The ext_sources tree was
>>> branched along with the rest of the the AOO 3.4 tree. So you should
>>> be able to safely work on the branch, defining the external
>>> dependencies there. This could be done without touching the trunk and
>>> without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
>>> can bring those changes to the trunk.
>>>
>>> Does that make sense? We don't break our release distributions until
>>> we have a working replacement in the form of 3.4.1. If that means we
>>> delay graduation until 3.4.1, then so be it.
>>
>>
>> You are talking about a new branch, right, not the 3.4.1 branch?
>>
>
> I thought the 3.4.1 branch would be appropriate. Move the category-b
> tarballs to Apache Extras, and make the build fetch from there instead
> of from SVN. That way the trunk's copy of these dependencies doesn't
> disappear yet. Then when we release 3.4.1, we have a release that is
> not dependent on the SVN copies, and we can safely remove them then.
My understanding is that we have to make sure that the files referenced
by the (source) release do not go away. That did not work so well for
the 3.4 release because they where referenced on trunk. If the 3.4.1
release references the files on the branch then that should be safe(r).
Trunk is where the main part of development takes place.
>
> The problem we have now is that even though we branched after the 3.4
> release, the build script is still fetching from the trunk copy of the
> dependencies. So we need to fix this is a somewhat backwards way.
For the 3.4 release we have to restore the tar-balls that where deleted
since the release. That does of course not mean that the newer versions
have to be removed as well. Due to different version numbers and MD5
sums they have different names and can coexist.
-Andre
>
> Or am I missing something?
>
> -Rob
>
>> -Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 31, 2012 at 11:19 AM, Andre Fischer <af...@a-w-f.de> wrote:
> On 31.05.2012 14:51, Rob Weir wrote:
>>
>> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>
>>>
>>>
>>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>
>
> [...]
>
>
>> So instead of a an axe, let's try a scalpel. The ext_sources tree was
>> branched along with the rest of the the AOO 3.4 tree. So you should
>> be able to safely work on the branch, defining the external
>> dependencies there. This could be done without touching the trunk and
>> without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
>> can bring those changes to the trunk.
>>
>> Does that make sense? We don't break our release distributions until
>> we have a working replacement in the form of 3.4.1. If that means we
>> delay graduation until 3.4.1, then so be it.
>
>
> You are talking about a new branch, right, not the 3.4.1 branch?
>
I thought the 3.4.1 branch would be appropriate. Move the category-b
tarballs to Apache Extras, and make the build fetch from there instead
of from SVN. That way the trunk's copy of these dependencies doesn't
disappear yet. Then when we release 3.4.1, we have a release that is
not dependent on the SVN copies, and we can safely remove them then.
The problem we have now is that even though we branched after the 3.4
release, the build script is still fetching from the trunk copy of the
dependencies. So we need to fix this is a somewhat backwards way.
Or am I missing something?
-Rob
> -Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Andre Fischer <af...@a-w-f.de>.
On 31.05.2012 14:51, Rob Weir wrote:
> On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>
>>
>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
[...]
> So instead of a an axe, let's try a scalpel. The ext_sources tree was
> branched along with the rest of the the AOO 3.4 tree. So you should
> be able to safely work on the branch, defining the external
> dependencies there. This could be done without touching the trunk and
> without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
> can bring those changes to the trunk.
>
> Does that make sense? We don't break our release distributions until
> we have a working replacement in the form of 3.4.1. If that means we
> delay graduation until 3.4.1, then so be it.
You are talking about a new branch, right, not the 3.4.1 branch?
-Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> --- Mer 30/5/12, Rob Weir <ro...@apache.org> ha scritto:
>
>> >
>> > So *NOW* you are admitting that those tarballs are
>> part
>> > of the Release??
>> >
>>
>> Not at all. But they are referenced from build
>> files. I hope this distinction is clear.
>
> No. If they are just referenced then we don't depend
> on having them there: we just have to replace the
> reference. A nice text file mentioning where to find
> them (ooo-exttas @ Apache Extras) *is* a reference.
>
>
>> Again, go back to the licensing page and the principles
>> stated there. This is not a crusade to eradicate
>> category-b code from the face of the earth.
>
> I didn'r say I am eradicating anything (yet), they just can't
> be in SVN.
>
> This is about making it clear to downstream
>> consumers what
>> the dependencies are, what obligations those dependencies
>> bring, and
>> to require an explicit, informed decision for the downstream
>> developer
>> to enable the use of category-b binaries. We
>> are doing all of that.
>>
>> > We don't have permission from legal@ to ship
>> Category-B
>> > sources .. that must be fixed .. with axe.
>> >
>>
>> Put the axe away, Pedro. As you know,
>> category-b code is not
>> included in the release. We already went through the
>> audit on that.
>>
>
> There was no audit. Mr RAT never examined those and we
> discussed this was a temporary situation.
>
>> In case it is not clear, I'll veto any attempt by you to
>> break the 3.4 source distributions.
>>
>
> You mean source distribution (tarballs) don't build on
> their own and depend on what we carry in SVN? Sounds
> like something is wrong.
>
> Well ... those files are not required by default for
> the build, they are only optionally used and we did it
> on purpose so as long as we make a small adjustment in
> the buildbots I don't see what you can veto about it.
>
> And while you are so brave about vetoing hypothetical
> issues ... I already axed a couple of tarballs from the
> old Apache commons and Lucene. Have fun putting them
> back :-P.
>
Just to be clear, I am not objecting to you relocating the category-b
tarballs. I'm objecting to doing this in a way that breaks the AOO
3.4.0 release.
Remember, we have had many downloads of the AOO 3.4 source
distribution. Not the least of the users is the LibreOffice project,
which has already declared that they are rebasing on that release. Do
we really want to break them?
So instead of a an axe, let's try a scalpel. The ext_sources tree was
branched along with the rest of the the AOO 3.4 tree. So you should
be able to safely work on the branch, defining the external
dependencies there. This could be done without touching the trunk and
without breaking the 3.4.0 release. Then, after 3.4.1 is released, we
can bring those changes to the trunk.
Does that make sense? We don't break our release distributions until
we have a working replacement in the form of 3.4.1. If that means we
delay graduation until 3.4.1, then so be it.
-Rob
> Pedro.
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Joe Schaefer <jo...@yahoo.com>.
Ack. To avoid complications we could do the
svn promotion as a 2-stage copy + delete, where
the delete happens post 3.4.1 release.
>________________________________
> From: Rob Weir <ro...@apache.org>
>To: ooo-dev@incubator.apache.org
>Sent: Saturday, June 2, 2012 9:55 AM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
>On Sat, Jun 2, 2012 at 9:41 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> FWIW, part of migrating to a TLP involves relocating
>> your svn tree to top-level, thereby breaking any links
>> to svn urls in 3.4.0's source tarball. No we do not
>> support redirects for svn.a.o, and I doubt Subversion
>> does either.
>>
>
>The build doesn't use svn to retrieve the tarballs. They are stored
>in svn, but they are copied down via http, using wget. So we could
>probably solve this via a redirect. But it would be good to avoid
>that additional complexity if possible.
>
>> I trust 3.4.1 will therefore address this issue properly
>> going forward.
>>
>>
>>
>>
>>>________________________________
>>> From: Rob Weir <ro...@apache.org>
>>>To: ooo-dev@incubator.apache.org
>>>Sent: Saturday, June 2, 2012 9:37 AM
>>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>>
>>>On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>>> Hi Ross;
>>>>
>>>> I don't think it's "my turn" since my issues remain unresolved.
>>>>
>>>
>>>I think Ross's idea was to stop batting this back and forth at a high
>>>level, and instead focus on a specific file. So get into the details
>>>rather than talking about generalities.
>>>
>>>So if you had to pick a single tarball that best makes your case for
>>>it being a violation of policy, what would it be? Which one best
>>>illustrates your concern?
>>>
>>>Then we can talk about the details of that file.
>>>
>>>-Rob
>>>
>>>> However let me recap:
>>>>
>>>> 1) I think just having patches that can or cannot be applied
>>>> to category-B licensed code is OK as long as it is not the
>>>> default.
>>>>
>>>> 2) I don't think we are allowed to distribute source tarballs
>>>> in subversion. The argument in the legal FAQ would seem
>>>> not to be specific enough:
>>>> http://www.apache.org/legal/resolved.html#category-b
>>>>
>>>> " Software under the following licenses may be included in binary form
>>>> within an Apache
>>>> product if the inclusion is appropriately labeled"
>>>>
>>>> Redistribution of Category B in small quantities is also permitted but
>>>> both clarifications clearly imply including source code the size and
>>>> complexity of Mozilla Seamonkey is prohibited.
>>>>
>>>> The draft on which the policy was based is very clear:
>>>> http://www.apache.org/legal/3party.html#criteriaandcategories
>>>>
>>>> "Although the source must not be included in Apache products, the NOTICE
>>>> file, which is required to be included in each ASF distribution,*must point
>>>> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
>>>> the included binary*(more on that in the forthcoming "Receiving and
>>>> Releasing Contributions" document)."
>>>>
>>>> I don't think anyone is arguing here that the principle has changed and
>>>> that we can include Category-B software
>>>>
>>>> 3) EPL and other licenses state that we must point to the source code
>>>> used to generate the binary and this has already been pointed out by
>>>> external developers like the COIN-OR guys.
>>>>
>>>> We are currently carrying outdated versions of Seamonkey
>>>> and saxon in SVN and we are unable to point to the sources due
>>>> to 2 reasons:
>>>>
>>>> 1) The specific source code is not available upstream anymore.
>>>>
>>>> 2) If the code is enabled (which is the default in the buildbots),
>>>> the specific source code is patched during the build.
>>>> I sustain that by keeping these sources in our SVN tree
>>>> we are for all purposes forking the code and to some extent
>>>> becoming the new upstream maintainers. Even if the original
>>>> code is available upstream I still don't see a good reason
>>>> to carry that code under version control.
>>>>
>>>> 4) I can't find a precedent among any other Apache Project
>>>> where the ASF distributes Category-B sources in SVN, so I
>>>> think hosting them would require a specific approval by
>>>> legal@.
>>>>
>>>> My understanding is that there is work being done to have
>>>> these issues solved on Monday.
>>>>
>>>> Pedro.
>>>>
>>>>
>>>>
>>>> On 06/01/12 18:09, Ross Gardler wrote:
>>>>>
>>>>> Just bringing this item back to the top. Nobody has linked to a policy
>>>>> that allows this or disallows it yet. However, Pedro has indicated he
>>>>> doesn't object to this specific case.
>>>>>
>>>>> Can we consider this one done? If so that is good progress (thank you
>>>>> Jurgen for making consensus possible on one specific case).
>>>>>
>>>>> Lets move onto the next one. Pedro raised a concern about a specific
>>>>> case and, if I'm following right there isn't consenus on that one (I
>>>>> wouldn't be surprised if I'm not following right since I'm tired of
>>>>> reading the arguments that go round in circles and stopped as soon as
>>>>> it descended again into non-specific cases).
>>>>>
>>>>> Can we have an equally detailed and clear description about the case
>>>>> Pedro highlights? We only need the facts about the problem being
>>>>> solved and the current solution, not the arguments for/against. Pedro,
>>>>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>>>>> can be up next (sorry to sound like a school teacher, please think of
>>>>> me as a conductor not a school teacher - I'm not trying to patronise,
>>>>> it's just it's very late here and I still have a client deliverable
>>>>> that AOO has stood in the way of for the last two days).
>>>>>
>>>>> Once we have the facts laid out nice and cleanly lets seek pointers to
>>>>> policy that allows or disallows the solution in place. If pointers are
>>>>> not possible lets take the specific case to the IPMC for
>>>>> clarification.
>>>>>
>>>>> Ross
>>>>>
>>>>
>>>
>>>
>>>
>
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Sat, Jun 2, 2012 at 9:41 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> FWIW, part of migrating to a TLP involves relocating
> your svn tree to top-level, thereby breaking any links
> to svn urls in 3.4.0's source tarball. No we do not
> support redirects for svn.a.o, and I doubt Subversion
> does either.
>
The build doesn't use svn to retrieve the tarballs. They are stored
in svn, but they are copied down via http, using wget. So we could
probably solve this via a redirect. But it would be good to avoid
that additional complexity if possible.
> I trust 3.4.1 will therefore address this issue properly
> going forward.
>
>
>
>
>>________________________________
>> From: Rob Weir <ro...@apache.org>
>>To: ooo-dev@incubator.apache.org
>>Sent: Saturday, June 2, 2012 9:37 AM
>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>
>>On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>> Hi Ross;
>>>
>>> I don't think it's "my turn" since my issues remain unresolved.
>>>
>>
>>I think Ross's idea was to stop batting this back and forth at a high
>>level, and instead focus on a specific file. So get into the details
>>rather than talking about generalities.
>>
>>So if you had to pick a single tarball that best makes your case for
>>it being a violation of policy, what would it be? Which one best
>>illustrates your concern?
>>
>>Then we can talk about the details of that file.
>>
>>-Rob
>>
>>> However let me recap:
>>>
>>> 1) I think just having patches that can or cannot be applied
>>> to category-B licensed code is OK as long as it is not the
>>> default.
>>>
>>> 2) I don't think we are allowed to distribute source tarballs
>>> in subversion. The argument in the legal FAQ would seem
>>> not to be specific enough:
>>> http://www.apache.org/legal/resolved.html#category-b
>>>
>>> " Software under the following licenses may be included in binary form
>>> within an Apache
>>> product if the inclusion is appropriately labeled"
>>>
>>> Redistribution of Category B in small quantities is also permitted but
>>> both clarifications clearly imply including source code the size and
>>> complexity of Mozilla Seamonkey is prohibited.
>>>
>>> The draft on which the policy was based is very clear:
>>> http://www.apache.org/legal/3party.html#criteriaandcategories
>>>
>>> "Although the source must not be included in Apache products, the NOTICE
>>> file, which is required to be included in each ASF distribution,*must point
>>> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
>>> the included binary*(more on that in the forthcoming "Receiving and
>>> Releasing Contributions" document)."
>>>
>>> I don't think anyone is arguing here that the principle has changed and
>>> that we can include Category-B software
>>>
>>> 3) EPL and other licenses state that we must point to the source code
>>> used to generate the binary and this has already been pointed out by
>>> external developers like the COIN-OR guys.
>>>
>>> We are currently carrying outdated versions of Seamonkey
>>> and saxon in SVN and we are unable to point to the sources due
>>> to 2 reasons:
>>>
>>> 1) The specific source code is not available upstream anymore.
>>>
>>> 2) If the code is enabled (which is the default in the buildbots),
>>> the specific source code is patched during the build.
>>> I sustain that by keeping these sources in our SVN tree
>>> we are for all purposes forking the code and to some extent
>>> becoming the new upstream maintainers. Even if the original
>>> code is available upstream I still don't see a good reason
>>> to carry that code under version control.
>>>
>>> 4) I can't find a precedent among any other Apache Project
>>> where the ASF distributes Category-B sources in SVN, so I
>>> think hosting them would require a specific approval by
>>> legal@.
>>>
>>> My understanding is that there is work being done to have
>>> these issues solved on Monday.
>>>
>>> Pedro.
>>>
>>>
>>>
>>> On 06/01/12 18:09, Ross Gardler wrote:
>>>>
>>>> Just bringing this item back to the top. Nobody has linked to a policy
>>>> that allows this or disallows it yet. However, Pedro has indicated he
>>>> doesn't object to this specific case.
>>>>
>>>> Can we consider this one done? If so that is good progress (thank you
>>>> Jurgen for making consensus possible on one specific case).
>>>>
>>>> Lets move onto the next one. Pedro raised a concern about a specific
>>>> case and, if I'm following right there isn't consenus on that one (I
>>>> wouldn't be surprised if I'm not following right since I'm tired of
>>>> reading the arguments that go round in circles and stopped as soon as
>>>> it descended again into non-specific cases).
>>>>
>>>> Can we have an equally detailed and clear description about the case
>>>> Pedro highlights? We only need the facts about the problem being
>>>> solved and the current solution, not the arguments for/against. Pedro,
>>>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>>>> can be up next (sorry to sound like a school teacher, please think of
>>>> me as a conductor not a school teacher - I'm not trying to patronise,
>>>> it's just it's very late here and I still have a client deliverable
>>>> that AOO has stood in the way of for the last two days).
>>>>
>>>> Once we have the facts laid out nice and cleanly lets seek pointers to
>>>> policy that allows or disallows the solution in place. If pointers are
>>>> not possible lets take the specific case to the IPMC for
>>>> clarification.
>>>>
>>>> Ross
>>>>
>>>
>>
>>
>>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Joe Schaefer <jo...@yahoo.com>.
Furthermore addressing this issue from a legal perspective
misses the point- the org will certainly permit you to
distribute Category-B sources for things that only are useful
when compiled on the target host. The point is that
you should be distributing dependencies from either the
mirrors using a deps (source) tarball, or you should fetch them
from their non-apache original locations. Longstanding
infra policy is that *only* our mirror system is appropriate
for distributing source releases and their dependencies.
Distribution of "tarballs" in support of a release
directly from svn.a.o violates infra policy just
as much as distribution from any other apache.org website
would be. I'm not sure we've written this down anywhere
but it is certainly well-understood as infra policy for
as long as I have worked here as a contractor.
HTH
>________________________________
> From: Joe Schaefer <jo...@yahoo.com>
>To: "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>
>Sent: Saturday, June 2, 2012 9:41 AM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
>FWIW, part of migrating to a TLP involves relocating
>your svn tree to top-level, thereby breaking any links
>to svn urls in 3.4.0's source tarball. No we do not
>support redirects for svn.a.o, and I doubt Subversion
>does either.
>
>I trust 3.4.1 will therefore address this issue properly
>going forward.
>
>
>
>
>>________________________________
>> From: Rob Weir <ro...@apache.org>
>>To: ooo-dev@incubator.apache.org
>>Sent: Saturday, June 2, 2012 9:37 AM
>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>
>>On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>> Hi Ross;
>>>
>>> I don't think it's "my turn" since my issues remain unresolved.
>>>
>>
>>I think Ross's idea was to stop batting this back and forth at a high
>>level, and instead focus on a specific file. So get into the details
>>rather than talking about generalities.
>>
>>So if you had to pick a single tarball that best makes your case for
>>it being a violation of policy, what would it be? Which one best
>>illustrates your concern?
>>
>>Then we can talk about the details of that file.
>>
>>-Rob
>>
>>> However let me recap:
>>>
>>> 1) I think just having patches that can or cannot be applied
>>> to category-B licensed code is OK as long as it is not the
>>> default.
>>>
>>> 2) I don't think we are allowed to distribute source tarballs
>>> in subversion. The argument in the legal FAQ would seem
>>> not to be specific enough:
>>> http://www.apache.org/legal/resolved.html#category-b
>>>
>>> " Software under the following licenses may be included in binary form
>>> within an Apache
>>> product if the inclusion is appropriately labeled"
>>>
>>> Redistribution of Category B in small quantities is also permitted but
>>> both clarifications clearly imply including source code the size and
>>> complexity of Mozilla Seamonkey is prohibited.
>>>
>>> The draft on which the policy was based is very clear:
>>> http://www.apache.org/legal/3party.html#criteriaandcategories
>>>
>>> "Although the source must not be included in Apache products, the NOTICE
>>> file, which is required to be included in each ASF distribution,*must point
>>> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
>>> the included binary*(more on that in the forthcoming "Receiving and
>>> Releasing Contributions" document)."
>>>
>>> I don't think anyone is arguing here that the principle has changed and
>>> that we can include Category-B software
>>>
>>> 3) EPL and other licenses state that we must point to the source code
>>> used to generate the binary and this has already been pointed out by
>>> external developers like the COIN-OR guys.
>>>
>>> We are currently carrying outdated versions of Seamonkey
>>> and saxon in SVN and we are unable to point to the sources due
>>> to 2 reasons:
>>>
>>> 1) The specific source code is not available upstream anymore.
>>>
>>> 2) If the code is enabled (which is the default in the buildbots),
>>> the specific source code is patched during the build.
>>> I sustain that by keeping these sources in our SVN tree
>>> we are for all purposes forking the code and to some extent
>>> becoming the new upstream maintainers. Even if the original
>>> code is available upstream I still don't see a good reason
>>> to carry that code under version control.
>>>
>>> 4) I can't find a precedent among any other Apache Project
>>> where the ASF distributes Category-B sources in SVN, so I
>>> think hosting them would require a specific approval by
>>> legal@.
>>>
>>> My understanding is that there is work being done to have
>>> these issues solved on Monday.
>>>
>>> Pedro.
>>>
>>>
>>>
>>> On 06/01/12 18:09, Ross Gardler wrote:
>>>>
>>>> Just bringing this item back to the top. Nobody has linked to a policy
>>>> that allows this or disallows it yet. However, Pedro has indicated he
>>>> doesn't object to this specific case.
>>>>
>>>> Can we consider this one done? If so that is good progress (thank you
>>>> Jurgen for making consensus possible on one specific case).
>>>>
>>>> Lets move onto the next one. Pedro raised a concern about a specific
>>>> case and, if I'm following right there isn't consenus on that one (I
>>>> wouldn't be surprised if I'm not following right since I'm tired of
>>>> reading the arguments that go round in circles and stopped as soon as
>>>> it descended again into non-specific cases).
>>>>
>>>> Can we have an equally detailed and clear description about the case
>>>> Pedro highlights? We only need the facts about the problem being
>>>> solved and the current solution, not the arguments for/against. Pedro,
>>>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>>>> can be up next (sorry to sound like a school teacher, please think of
>>>> me as a conductor not a school teacher - I'm not trying to patronise,
>>>> it's just it's very late here and I still have a client deliverable
>>>> that AOO has stood in the way of for the last two days).
>>>>
>>>> Once we have the facts laid out nice and cleanly lets seek pointers to
>>>> policy that allows or disallows the solution in place. If pointers are
>>>> not possible lets take the specific case to the IPMC for
>>>> clarification.
>>>>
>>>> Ross
>>>>
>>>
>>
>>
>>
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Joe Schaefer <jo...@yahoo.com>.
FWIW, part of migrating to a TLP involves relocating
your svn tree to top-level, thereby breaking any links
to svn urls in 3.4.0's source tarball. No we do not
support redirects for svn.a.o, and I doubt Subversion
does either.
I trust 3.4.1 will therefore address this issue properly
going forward.
>________________________________
> From: Rob Weir <ro...@apache.org>
>To: ooo-dev@incubator.apache.org
>Sent: Saturday, June 2, 2012 9:37 AM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
>On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> Hi Ross;
>>
>> I don't think it's "my turn" since my issues remain unresolved.
>>
>
>I think Ross's idea was to stop batting this back and forth at a high
>level, and instead focus on a specific file. So get into the details
>rather than talking about generalities.
>
>So if you had to pick a single tarball that best makes your case for
>it being a violation of policy, what would it be? Which one best
>illustrates your concern?
>
>Then we can talk about the details of that file.
>
>-Rob
>
>> However let me recap:
>>
>> 1) I think just having patches that can or cannot be applied
>> to category-B licensed code is OK as long as it is not the
>> default.
>>
>> 2) I don't think we are allowed to distribute source tarballs
>> in subversion. The argument in the legal FAQ would seem
>> not to be specific enough:
>> http://www.apache.org/legal/resolved.html#category-b
>>
>> " Software under the following licenses may be included in binary form
>> within an Apache
>> product if the inclusion is appropriately labeled"
>>
>> Redistribution of Category B in small quantities is also permitted but
>> both clarifications clearly imply including source code the size and
>> complexity of Mozilla Seamonkey is prohibited.
>>
>> The draft on which the policy was based is very clear:
>> http://www.apache.org/legal/3party.html#criteriaandcategories
>>
>> "Although the source must not be included in Apache products, the NOTICE
>> file, which is required to be included in each ASF distribution,*must point
>> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
>> the included binary*(more on that in the forthcoming "Receiving and
>> Releasing Contributions" document)."
>>
>> I don't think anyone is arguing here that the principle has changed and
>> that we can include Category-B software
>>
>> 3) EPL and other licenses state that we must point to the source code
>> used to generate the binary and this has already been pointed out by
>> external developers like the COIN-OR guys.
>>
>> We are currently carrying outdated versions of Seamonkey
>> and saxon in SVN and we are unable to point to the sources due
>> to 2 reasons:
>>
>> 1) The specific source code is not available upstream anymore.
>>
>> 2) If the code is enabled (which is the default in the buildbots),
>> the specific source code is patched during the build.
>> I sustain that by keeping these sources in our SVN tree
>> we are for all purposes forking the code and to some extent
>> becoming the new upstream maintainers. Even if the original
>> code is available upstream I still don't see a good reason
>> to carry that code under version control.
>>
>> 4) I can't find a precedent among any other Apache Project
>> where the ASF distributes Category-B sources in SVN, so I
>> think hosting them would require a specific approval by
>> legal@.
>>
>> My understanding is that there is work being done to have
>> these issues solved on Monday.
>>
>> Pedro.
>>
>>
>>
>> On 06/01/12 18:09, Ross Gardler wrote:
>>>
>>> Just bringing this item back to the top. Nobody has linked to a policy
>>> that allows this or disallows it yet. However, Pedro has indicated he
>>> doesn't object to this specific case.
>>>
>>> Can we consider this one done? If so that is good progress (thank you
>>> Jurgen for making consensus possible on one specific case).
>>>
>>> Lets move onto the next one. Pedro raised a concern about a specific
>>> case and, if I'm following right there isn't consenus on that one (I
>>> wouldn't be surprised if I'm not following right since I'm tired of
>>> reading the arguments that go round in circles and stopped as soon as
>>> it descended again into non-specific cases).
>>>
>>> Can we have an equally detailed and clear description about the case
>>> Pedro highlights? We only need the facts about the problem being
>>> solved and the current solution, not the arguments for/against. Pedro,
>>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>>> can be up next (sorry to sound like a school teacher, please think of
>>> me as a conductor not a school teacher - I'm not trying to patronise,
>>> it's just it's very late here and I still have a client deliverable
>>> that AOO has stood in the way of for the last two days).
>>>
>>> Once we have the facts laid out nice and cleanly lets seek pointers to
>>> policy that allows or disallows the solution in place. If pointers are
>>> not possible lets take the specific case to the IPMC for
>>> clarification.
>>>
>>> Ross
>>>
>>
>
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 1, 2012 at 9:08 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Ross;
>
> I don't think it's "my turn" since my issues remain unresolved.
>
I think Ross's idea was to stop batting this back and forth at a high
level, and instead focus on a specific file. So get into the details
rather than talking about generalities.
So if you had to pick a single tarball that best makes your case for
it being a violation of policy, what would it be? Which one best
illustrates your concern?
Then we can talk about the details of that file.
-Rob
> However let me recap:
>
> 1) I think just having patches that can or cannot be applied
> to category-B licensed code is OK as long as it is not the
> default.
>
> 2) I don't think we are allowed to distribute source tarballs
> in subversion. The argument in the legal FAQ would seem
> not to be specific enough:
> http://www.apache.org/legal/resolved.html#category-b
>
> " Software under the following licenses may be included in binary form
> within an Apache
> product if the inclusion is appropriately labeled"
>
> Redistribution of Category B in small quantities is also permitted but
> both clarifications clearly imply including source code the size and
> complexity of Mozilla Seamonkey is prohibited.
>
> The draft on which the policy was based is very clear:
> http://www.apache.org/legal/3party.html#criteriaandcategories
>
> "Although the source must not be included in Apache products, the NOTICE
> file, which is required to be included in each ASF distribution,*must point
> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
> the included binary*(more on that in the forthcoming "Receiving and
> Releasing Contributions" document)."
>
> I don't think anyone is arguing here that the principle has changed and
> that we can include Category-B software
>
> 3) EPL and other licenses state that we must point to the source code
> used to generate the binary and this has already been pointed out by
> external developers like the COIN-OR guys.
>
> We are currently carrying outdated versions of Seamonkey
> and saxon in SVN and we are unable to point to the sources due
> to 2 reasons:
>
> 1) The specific source code is not available upstream anymore.
>
> 2) If the code is enabled (which is the default in the buildbots),
> the specific source code is patched during the build.
> I sustain that by keeping these sources in our SVN tree
> we are for all purposes forking the code and to some extent
> becoming the new upstream maintainers. Even if the original
> code is available upstream I still don't see a good reason
> to carry that code under version control.
>
> 4) I can't find a precedent among any other Apache Project
> where the ASF distributes Category-B sources in SVN, so I
> think hosting them would require a specific approval by
> legal@.
>
> My understanding is that there is work being done to have
> these issues solved on Monday.
>
> Pedro.
>
>
>
> On 06/01/12 18:09, Ross Gardler wrote:
>>
>> Just bringing this item back to the top. Nobody has linked to a policy
>> that allows this or disallows it yet. However, Pedro has indicated he
>> doesn't object to this specific case.
>>
>> Can we consider this one done? If so that is good progress (thank you
>> Jurgen for making consensus possible on one specific case).
>>
>> Lets move onto the next one. Pedro raised a concern about a specific
>> case and, if I'm following right there isn't consenus on that one (I
>> wouldn't be surprised if I'm not following right since I'm tired of
>> reading the arguments that go round in circles and stopped as soon as
>> it descended again into non-specific cases).
>>
>> Can we have an equally detailed and clear description about the case
>> Pedro highlights? We only need the facts about the problem being
>> solved and the current solution, not the arguments for/against. Pedro,
>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>> can be up next (sorry to sound like a school teacher, please think of
>> me as a conductor not a school teacher - I'm not trying to patronise,
>> it's just it's very late here and I still have a client deliverable
>> that AOO has stood in the way of for the last two days).
>>
>> Once we have the facts laid out nice and cleanly lets seek pointers to
>> policy that allows or disallows the solution in place. If pointers are
>> not possible lets take the specific case to the IPMC for
>> clarification.
>>
>> Ross
>>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Sab 2/6/12, Rob Weir <ro...@apache.org> ha scritto:
...
>
> Pedro, your logic violates every principle of
> interpretation. If something was in a draft
> and then was removed from the draft, that
> suggests that there was not consensus for it to
> remain.
I think the issue is strictly policy related.
The "approved policy" is not a Bible, and even
the Bible requires to be put into context.
AOO is not a special case in the ASF where we
interpret things we can or cannot do. I would
prefer if someone qualified (from the IPMC
perhaps) would explain to us if the policy has
changed and we are now fine with including
the sources of SeaMonkey and maintain patches
for them in SVN.
This said, I think the discussion is losing
relevance in light of the developments. I would
think the discussion has shifted from
"SHOULD we remove Cat-B tarballs from SVN" to
"HOW will we remove Cat-B tarballs from SVN".
I think this is a positive advance for the
project.
Pedro.
You cannot use its removal as evidence that it is applicable.
>
> Please stick to the text of the approved policy.
>
> -Rob
>
> > http://www.apache.org/legal/3party.html#criteriaandcategories
> >
> > /"Even optional works must adhere to this policy if
> they are included as
> > part of the Apache product."/
> >
> > So even when Category B tarballs appear to be
> optional,
> > in practice they are part of the product and we
> shouldn't
> > be distributing source code.
> >
> > cheers,
> >
> > Pedro.
> >
> >
> > On 06/01/12 20:08, Pedro Giffuni wrote:
> >>
> >> Hi Ross;
> >>
> >> I don't think it's "my turn" since my issues remain
> unresolved.
> >>
> >> However let me recap:
> >>
> >> 1) I think just having patches that can or cannot
> be applied
> >> to category-B licensed code is OK as long as it is
> not the
> >> default.
> >>
> >> 2) I don't think we are allowed to distribute
> source tarballs
> >> in subversion. The argument in the legal FAQ would
> seem
> >> not to be specific enough:
> >> http://www.apache.org/legal/resolved.html#category-b
> >>
> >> " Software under the following licenses may be
> included in binary form
> >> within an Apache
> >> product if the inclusion is appropriately labeled"
> >>
> >> Redistribution of Category B in small quantities is
> also permitted but
> >> both clarifications clearly imply including source
> code the size and
> >> complexity of Mozilla Seamonkey is prohibited.
> >>
> >> The draft on which the policy was based is very
> clear:
> >> http://www.apache.org/legal/3party.html#criteriaandcategories
> >>
> >> "Although the source must not be included in Apache
> products, the NOTICE
> >> file, which is required to be included in each ASF
> distribution,*must point
> >> to thesource <http://www.apache.org/legal/3party.html#define-source>form
> of
> >> the included binary*(more on that in the
> forthcoming "Receiving and
> >> Releasing Contributions" document)."
> >>
> >> I don't think anyone is arguing here that the
> principle has changed and
> >> that we can include Category-B software
> >>
> >> 3) EPL and other licenses state that we must point
> to the source code
> >> used to generate the binary and this has already
> been pointed out by
> >> external developers like the COIN-OR guys.
> >>
> >> We are currently carrying outdated versions of
> Seamonkey
> >> and saxon in SVN and we are unable to point to the
> sources due
> >> to 2 reasons:
> >>
> >> 1) The specific source code is not available
> upstream anymore.
> >>
> >> 2) If the code is enabled (which is the default in
> the buildbots),
> >> the specific source code is patched during the
> build.
> >> I sustain that by keeping these sources in our SVN
> tree
> >> we are for all purposes forking the code and to
> some extent
> >> becoming the new upstream maintainers. Even if the
> original
> >> code is available upstream I still don't see a good
> reason
> >> to carry that code under version control.
> >>
> >> 4) I can't find a precedent among any other Apache
> Project
> >> where the ASF distributes Category-B sources in
> SVN, so I
> >> think hosting them would require a specific
> approval by
> >> legal@.
> >>
> >> My understanding is that there is work being done
> to have
> >> these issues solved on Monday.
> >>
> >> Pedro.
> >>
> >>
> >> On 06/01/12 18:09, Ross Gardler wrote:
> >>>
> >>> Just bringing this item back to the top. Nobody
> has linked to a policy
> >>> that allows this or disallows it yet. However,
> Pedro has indicated he
> >>> doesn't object to this specific case.
> >>>
> >>> Can we consider this one done? If so that is
> good progress (thank you
> >>> Jurgen for making consensus possible on one
> specific case).
> >>>
> >>> Lets move onto the next one. Pedro raised a
> concern about a specific
> >>> case and, if I'm following right there isn't
> consenus on that one (I
> >>> wouldn't be surprised if I'm not following
> right since I'm tired of
> >>> reading the arguments that go round in circles
> and stopped as soon as
> >>> it descended again into non-specific cases).
> >>>
> >>> Can we have an equally detailed and clear
> description about the case
> >>> Pedro highlights? We only need the facts about
> the problem being
> >>> solved and the current solution, not the
> arguments for/against. Pedro,
> >>> I suggest it's your turn since Jurgen started
> the ball rolling, Rob
> >>> can be up next (sorry to sound like a school
> teacher, please think of
> >>> me as a conductor not a school teacher - I'm
> not trying to patronise,
> >>> it's just it's very late here and I still have
> a client deliverable
> >>> that AOO has stood in the way of for the last
> two days).
> >>>
> >>> Once we have the facts laid out nice and
> cleanly lets seek pointers to
> >>> policy that allows or disallows the solution in
> place. If pointers are
> >>> not possible lets take the specific case to the
> IPMC for
> >>> clarification.
> >>>
> >>> Ross
> >>>
> >>
> >
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 1, 2012 at 9:23 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Sorry to highlight something more here...
>
> The draft (which I insist is clearer that the resolved FAQ)
> says, under License Categories:
>
Pedro, your logic violates every principle of interpretation. If
something was in a draft and then was removed from the draft, that
suggests that there was not consensus for it to remain. You cannot
use its removal as evidence that it is applicable.
Please stick to the text of the approved policy.
-Rob
> http://www.apache.org/legal/3party.html#criteriaandcategories
>
> /"Even optional works must adhere to this policy if they are included as
> part of the Apache product."/
>
> So even when Category B tarballs appear to be optional,
> in practice they are part of the product and we shouldn't
> be distributing source code.
>
> cheers,
>
> Pedro.
>
>
> On 06/01/12 20:08, Pedro Giffuni wrote:
>>
>> Hi Ross;
>>
>> I don't think it's "my turn" since my issues remain unresolved.
>>
>> However let me recap:
>>
>> 1) I think just having patches that can or cannot be applied
>> to category-B licensed code is OK as long as it is not the
>> default.
>>
>> 2) I don't think we are allowed to distribute source tarballs
>> in subversion. The argument in the legal FAQ would seem
>> not to be specific enough:
>> http://www.apache.org/legal/resolved.html#category-b
>>
>> " Software under the following licenses may be included in binary form
>> within an Apache
>> product if the inclusion is appropriately labeled"
>>
>> Redistribution of Category B in small quantities is also permitted but
>> both clarifications clearly imply including source code the size and
>> complexity of Mozilla Seamonkey is prohibited.
>>
>> The draft on which the policy was based is very clear:
>> http://www.apache.org/legal/3party.html#criteriaandcategories
>>
>> "Although the source must not be included in Apache products, the NOTICE
>> file, which is required to be included in each ASF distribution,*must point
>> to thesource <http://www.apache.org/legal/3party.html#define-source>form of
>> the included binary*(more on that in the forthcoming "Receiving and
>> Releasing Contributions" document)."
>>
>> I don't think anyone is arguing here that the principle has changed and
>> that we can include Category-B software
>>
>> 3) EPL and other licenses state that we must point to the source code
>> used to generate the binary and this has already been pointed out by
>> external developers like the COIN-OR guys.
>>
>> We are currently carrying outdated versions of Seamonkey
>> and saxon in SVN and we are unable to point to the sources due
>> to 2 reasons:
>>
>> 1) The specific source code is not available upstream anymore.
>>
>> 2) If the code is enabled (which is the default in the buildbots),
>> the specific source code is patched during the build.
>> I sustain that by keeping these sources in our SVN tree
>> we are for all purposes forking the code and to some extent
>> becoming the new upstream maintainers. Even if the original
>> code is available upstream I still don't see a good reason
>> to carry that code under version control.
>>
>> 4) I can't find a precedent among any other Apache Project
>> where the ASF distributes Category-B sources in SVN, so I
>> think hosting them would require a specific approval by
>> legal@.
>>
>> My understanding is that there is work being done to have
>> these issues solved on Monday.
>>
>> Pedro.
>>
>>
>> On 06/01/12 18:09, Ross Gardler wrote:
>>>
>>> Just bringing this item back to the top. Nobody has linked to a policy
>>> that allows this or disallows it yet. However, Pedro has indicated he
>>> doesn't object to this specific case.
>>>
>>> Can we consider this one done? If so that is good progress (thank you
>>> Jurgen for making consensus possible on one specific case).
>>>
>>> Lets move onto the next one. Pedro raised a concern about a specific
>>> case and, if I'm following right there isn't consenus on that one (I
>>> wouldn't be surprised if I'm not following right since I'm tired of
>>> reading the arguments that go round in circles and stopped as soon as
>>> it descended again into non-specific cases).
>>>
>>> Can we have an equally detailed and clear description about the case
>>> Pedro highlights? We only need the facts about the problem being
>>> solved and the current solution, not the arguments for/against. Pedro,
>>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>>> can be up next (sorry to sound like a school teacher, please think of
>>> me as a conductor not a school teacher - I'm not trying to patronise,
>>> it's just it's very late here and I still have a client deliverable
>>> that AOO has stood in the way of for the last two days).
>>>
>>> Once we have the facts laid out nice and cleanly lets seek pointers to
>>> policy that allows or disallows the solution in place. If pointers are
>>> not possible lets take the specific case to the IPMC for
>>> clarification.
>>>
>>> Ross
>>>
>>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Sorry to highlight something more here...
The draft (which I insist is clearer that the resolved FAQ)
says, under License Categories:
http://www.apache.org/legal/3party.html#criteriaandcategories
/"Even optional works must adhere to this policy if they are included as
part of the Apache product."/
So even when Category B tarballs appear to be optional,
in practice they are part of the product and we shouldn't
be distributing source code.
cheers,
Pedro.
On 06/01/12 20:08, Pedro Giffuni wrote:
> Hi Ross;
>
> I don't think it's "my turn" since my issues remain unresolved.
>
> However let me recap:
>
> 1) I think just having patches that can or cannot be applied
> to category-B licensed code is OK as long as it is not the
> default.
>
> 2) I don't think we are allowed to distribute source tarballs
> in subversion. The argument in the legal FAQ would seem
> not to be specific enough:
> http://www.apache.org/legal/resolved.html#category-b
>
> " Software under the following licenses may be included in binary form
> within an Apache
> product if the inclusion is appropriately labeled"
>
> Redistribution of Category B in small quantities is also permitted but
> both clarifications clearly imply including source code the size and
> complexity of Mozilla Seamonkey is prohibited.
>
> The draft on which the policy was based is very clear:
> http://www.apache.org/legal/3party.html#criteriaandcategories
>
> "Although the source must not be included in Apache products, the
> NOTICE file, which is required to be included in each ASF
> distribution,*must point to thesource
> <http://www.apache.org/legal/3party.html#define-source>form of the
> included binary*(more on that in the forthcoming "Receiving and
> Releasing Contributions" document)."
>
> I don't think anyone is arguing here that the principle has changed and
> that we can include Category-B software
>
> 3) EPL and other licenses state that we must point to the source code
> used to generate the binary and this has already been pointed out by
> external developers like the COIN-OR guys.
>
> We are currently carrying outdated versions of Seamonkey
> and saxon in SVN and we are unable to point to the sources due
> to 2 reasons:
>
> 1) The specific source code is not available upstream anymore.
>
> 2) If the code is enabled (which is the default in the buildbots),
> the specific source code is patched during the build.
> I sustain that by keeping these sources in our SVN tree
> we are for all purposes forking the code and to some extent
> becoming the new upstream maintainers. Even if the original
> code is available upstream I still don't see a good reason
> to carry that code under version control.
>
> 4) I can't find a precedent among any other Apache Project
> where the ASF distributes Category-B sources in SVN, so I
> think hosting them would require a specific approval by
> legal@.
>
> My understanding is that there is work being done to have
> these issues solved on Monday.
>
> Pedro.
>
>
> On 06/01/12 18:09, Ross Gardler wrote:
>> Just bringing this item back to the top. Nobody has linked to a policy
>> that allows this or disallows it yet. However, Pedro has indicated he
>> doesn't object to this specific case.
>>
>> Can we consider this one done? If so that is good progress (thank you
>> Jurgen for making consensus possible on one specific case).
>>
>> Lets move onto the next one. Pedro raised a concern about a specific
>> case and, if I'm following right there isn't consenus on that one (I
>> wouldn't be surprised if I'm not following right since I'm tired of
>> reading the arguments that go round in circles and stopped as soon as
>> it descended again into non-specific cases).
>>
>> Can we have an equally detailed and clear description about the case
>> Pedro highlights? We only need the facts about the problem being
>> solved and the current solution, not the arguments for/against. Pedro,
>> I suggest it's your turn since Jurgen started the ball rolling, Rob
>> can be up next (sorry to sound like a school teacher, please think of
>> me as a conductor not a school teacher - I'm not trying to patronise,
>> it's just it's very late here and I still have a client deliverable
>> that AOO has stood in the way of for the last two days).
>>
>> Once we have the facts laid out nice and cleanly lets seek pointers to
>> policy that allows or disallows the solution in place. If pointers are
>> not possible lets take the specific case to the IPMC for
>> clarification.
>>
>> Ross
>>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Ross;
I don't think it's "my turn" since my issues remain unresolved.
However let me recap:
1) I think just having patches that can or cannot be applied
to category-B licensed code is OK as long as it is not the
default.
2) I don't think we are allowed to distribute source tarballs
in subversion. The argument in the legal FAQ would seem
not to be specific enough:
http://www.apache.org/legal/resolved.html#category-b
" Software under the following licenses may be included in binary form
within an Apache
product if the inclusion is appropriately labeled"
Redistribution of Category B in small quantities is also permitted but
both clarifications clearly imply including source code the size and
complexity of Mozilla Seamonkey is prohibited.
The draft on which the policy was based is very clear:
http://www.apache.org/legal/3party.html#criteriaandcategories
"Although the source must not be included in Apache products, the NOTICE
file, which is required to be included in each ASF distribution,*must
point to thesource
<http://www.apache.org/legal/3party.html#define-source>form of the
included binary*(more on that in the forthcoming "Receiving and
Releasing Contributions" document)."
I don't think anyone is arguing here that the principle has changed and
that we can include Category-B software
3) EPL and other licenses state that we must point to the source code
used to generate the binary and this has already been pointed out by
external developers like the COIN-OR guys.
We are currently carrying outdated versions of Seamonkey
and saxon in SVN and we are unable to point to the sources due
to 2 reasons:
1) The specific source code is not available upstream anymore.
2) If the code is enabled (which is the default in the buildbots),
the specific source code is patched during the build.
I sustain that by keeping these sources in our SVN tree
we are for all purposes forking the code and to some extent
becoming the new upstream maintainers. Even if the original
code is available upstream I still don't see a good reason
to carry that code under version control.
4) I can't find a precedent among any other Apache Project
where the ASF distributes Category-B sources in SVN, so I
think hosting them would require a specific approval by
legal@.
My understanding is that there is work being done to have
these issues solved on Monday.
Pedro.
On 06/01/12 18:09, Ross Gardler wrote:
> Just bringing this item back to the top. Nobody has linked to a policy
> that allows this or disallows it yet. However, Pedro has indicated he
> doesn't object to this specific case.
>
> Can we consider this one done? If so that is good progress (thank you
> Jurgen for making consensus possible on one specific case).
>
> Lets move onto the next one. Pedro raised a concern about a specific
> case and, if I'm following right there isn't consenus on that one (I
> wouldn't be surprised if I'm not following right since I'm tired of
> reading the arguments that go round in circles and stopped as soon as
> it descended again into non-specific cases).
>
> Can we have an equally detailed and clear description about the case
> Pedro highlights? We only need the facts about the problem being
> solved and the current solution, not the arguments for/against. Pedro,
> I suggest it's your turn since Jurgen started the ball rolling, Rob
> can be up next (sorry to sound like a school teacher, please think of
> me as a conductor not a school teacher - I'm not trying to patronise,
> it's just it's very late here and I still have a client deliverable
> that AOO has stood in the way of for the last two days).
>
> Once we have the facts laid out nice and cleanly lets seek pointers to
> policy that allows or disallows the solution in place. If pointers are
> not possible lets take the specific case to the IPMC for
> clarification.
>
> Ross
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Ross Gardler <rg...@opendirective.com>.
Just bringing this item back to the top. Nobody has linked to a policy
that allows this or disallows it yet. However, Pedro has indicated he
doesn't object to this specific case.
Can we consider this one done? If so that is good progress (thank you
Jurgen for making consensus possible on one specific case).
Lets move onto the next one. Pedro raised a concern about a specific
case and, if I'm following right there isn't consenus on that one (I
wouldn't be surprised if I'm not following right since I'm tired of
reading the arguments that go round in circles and stopped as soon as
it descended again into non-specific cases).
Can we have an equally detailed and clear description about the case
Pedro highlights? We only need the facts about the problem being
solved and the current solution, not the arguments for/against. Pedro,
I suggest it's your turn since Jurgen started the ball rolling, Rob
can be up next (sorry to sound like a school teacher, please think of
me as a conductor not a school teacher - I'm not trying to patronise,
it's just it's very late here and I still have a client deliverable
that AOO has stood in the way of for the last two days).
Once we have the facts laid out nice and cleanly lets seek pointers to
policy that allows or disallows the solution in place. If pointers are
not possible lets take the specific case to the IPMC for
clarification.
Ross
On 1 June 2012 11:09, Jürgen Schmidt <jo...@googlemail.com> wrote:
> Hi,
>
> sorry for top posting but I followed Ross advice and will give a
> concrete example.
>
> Hunspell -> MPL + LGPL
>
> - we use currently version 1.2.9 and compile the source in our build env
> on demand when the correct configure switch is used
>
> - we apply 4 or in case of mingw 5 patch files (depends on the mechanism
> that is used in our build env generally for this kind of things)
>
> 3 of these patch files contains minor changes used/necessary for our
> build env.
>
> For example hunspell-solaris.patch:
> ###
> --- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx 2010-02-27
> 23:42:05.000000000 +0000
> +++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx 2010-02-27
> 23:43:02.000000000 +0000
> @@ -10,6 +10,9 @@
> #include "hunspell.hxx"
> #include "csutil.hxx"
>
> +// switch off iconv support for tests (fixing Solaris problems)
> +#undef HAVE_ICONV
> +
> #ifndef HUNSPELL_EXTRA
> #define suggest_auto suggest
> #endif
> ###
>
> One patch apply a back port patch for an important issue that is fixed
> in a newer version. Don't ask me why we haven't upgraded the version
> already. But that is as I mentioned before on our plan.
>
> hunspell-stackmash.patch
> ###
> --- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
> 10:25:06.000000000 +0000
> +++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
> 10:25:38.000000000 +0000
> @@ -1665,7 +1665,7 @@
> if (!q2) return 0; // bad XML input
> if (check_xml_par(q, "type=", "analyze")) {
> int n = 0, s = 0;
> - if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
> analyze(slst, cw);
> + if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
> analyze(slst, cw);
> if (n == 0) return 0;
> // convert the result to <code><a>ana1</a><a>ana2</a></code> format
> for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
> @@ -1686,13 +1686,13 @@
> (*slst)[0] = r;
> return 1;
> } else if (check_xml_par(q, "type=", "stem")) {
> - if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
> stem(slst, cw);
> + if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
> stem(slst, cw);
> } else if (check_xml_par(q, "type=", "generate")) {
> - int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
> + int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
> if (n == 0) return 0;
> char * q3 = strstr(q2 + 1, "<word");
> if (q3) {
> - if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
> + if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
> return generate(slst, cw, cw2);
> }
> } else {
> ###
>
> This fix is fixed upstream in version 1.2.11, see
> http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9
>
>
> That means with our further ongoing improvements in this area we get rid
> of this patch and have only minor patches for our build env.
>
> Building these libs on demand in our build env is for convenience.
> Otherwise we would have to put them somewhere else, have to duplicate
> the build env or would need to build them with our build env and use the
> binary libraries from there. That would mean a further huge burden to
> make the development for AOO more complicate.
>
> I hope this helps
>
> Juergen
>
>
> On 6/1/12 11:07 AM, Ross Gardler wrote:
>> On 1 June 2012 09:50, Jürgen Schmidt <jo...@googlemail.com> wrote:
>>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>>> Sent from my mobile device, please forgive errors and brevity.
>>>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>>>>>
>>
>> ...
>>
>>>>> I admit this is very clear. I don't expect such development to be
>>>>> a requirement for graduation but the transitory situation of a source
>>>>> release that depends on carrying category-B tarballs in SVN now is
>>>>> not really acceptable.
>>>>
>>>> I do expect this to be sorted out before graduation.
>>>
>>> it is addressed already
>>>
>>>> That might be as simple as getting clarity on the policy, it might be more
>>>> than that. However, as a mentor I am uncertain about the practice adopted
>>>> here and as such will not encourage the IPMC to vote for graduation until
>>>> someone in the PPMC gets clarity.
>>>
>>> what do you expect?
>>
>> Someone needs to take out all the rhetoric and abstract concepts. Pick
>> any one of the cat-b cases and describe *exactly* how it is addressed
>> in that case and *exactly* how this conforms to documented ASF
>> policies.
>>
>> Once we have clarity on the first case we can ask whether any of the
>> other cases are different and then examine those.
>>
>>> Should we remove all this dependencies and make AOO more or less
>>> unusable or better uninteresting for real usage?
>>
>> I am making no comment on what the technical solution is.
>>
>> I want to see consensus. Consensus cannot be gained by shouting at one
>> another about vague examples. I want concrete examples on a case by
>> case basis until nobody is objecting or until the issues can be
>> clearly communicated to either the IPMC or legal@ so that a
>> clarification of ASF policy can be made.
>>
>>> Anyway I think we tried everything to address this and we still work on
>>> improvements step by step. If that is not enough for graduation I would
>>> feel very unsatisfied.
>>
>> It is, and always has been, a condition of graduation that the IP
>> situation in the project conforms to ASF policies. There is a question
>> about these tarballs and it must be resolved before graduation.
>>
>> Ross
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Ross Gardler <rg...@opendirective.com>.
On 1 June 2012 11:09, Jürgen Schmidt <jo...@googlemail.com> wrote:
> I hope this helps
It certainly does - thank you for taking the time to do this. I'm not
going to comment as I am not clear on ASF policy in this case.
I will leave it a few days to hear from people who wish to either:
a) point at a written ASF policy that clearly permits this
or
b) point at a written ASF policy that clearly disallows this
(I guess there might be a need for correction of any errors Juergen
might have made, but lets be sure to stay to *facts* about this
specific case rather than conjecture or situations in other cases)
If consensus around either a) or b) is not formed then we need to seek
the input of the IPMC (remember legal@ delegated to the IPMC). If the
IPMC cannot give clarity then we go to legal@.
If we repeat this process x times (once for each case that is notably
different from this one) we'll have the clarity we need to bring
consensus and thus plan for graduation.
Once again, thank you Jeurgen.
Ross
>
> Juergen
>
>
> On 6/1/12 11:07 AM, Ross Gardler wrote:
>> On 1 June 2012 09:50, Jürgen Schmidt <jo...@googlemail.com> wrote:
>>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>>> Sent from my mobile device, please forgive errors and brevity.
>>>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>>>>>
>>
>> ...
>>
>>>>> I admit this is very clear. I don't expect such development to be
>>>>> a requirement for graduation but the transitory situation of a source
>>>>> release that depends on carrying category-B tarballs in SVN now is
>>>>> not really acceptable.
>>>>
>>>> I do expect this to be sorted out before graduation.
>>>
>>> it is addressed already
>>>
>>>> That might be as simple as getting clarity on the policy, it might be more
>>>> than that. However, as a mentor I am uncertain about the practice adopted
>>>> here and as such will not encourage the IPMC to vote for graduation until
>>>> someone in the PPMC gets clarity.
>>>
>>> what do you expect?
>>
>> Someone needs to take out all the rhetoric and abstract concepts. Pick
>> any one of the cat-b cases and describe *exactly* how it is addressed
>> in that case and *exactly* how this conforms to documented ASF
>> policies.
>>
>> Once we have clarity on the first case we can ask whether any of the
>> other cases are different and then examine those.
>>
>>> Should we remove all this dependencies and make AOO more or less
>>> unusable or better uninteresting for real usage?
>>
>> I am making no comment on what the technical solution is.
>>
>> I want to see consensus. Consensus cannot be gained by shouting at one
>> another about vague examples. I want concrete examples on a case by
>> case basis until nobody is objecting or until the issues can be
>> clearly communicated to either the IPMC or legal@ so that a
>> clarification of ASF policy can be made.
>>
>>> Anyway I think we tried everything to address this and we still work on
>>> improvements step by step. If that is not enough for graduation I would
>>> feel very unsatisfied.
>>
>> It is, and always has been, a condition of graduation that the IP
>> situation in the project conforms to ASF policies. There is a question
>> about these tarballs and it must be resolved before graduation.
>>
>> Ross
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Jürguen;
On 06/01/12 05:09, Jürgen Schmidt wrote:
> Hi,
>
> sorry for top posting but I followed Ross advice and will give a
> concrete example.
>
> Hunspell -> MPL + LGPL
Hunspell illustrates a case that I would consider unsupported but
valid for redistribution.
My opinion on the MPL+ patches is as follows.
-I don't see a problem patching the MPL sources for two reasons:
1) We don't do this by default, the patches are only there for
convenience to external packagers. It must be made clear they
are unsupported though.
2) The patches are under ALv2.
I do think it would be consistent with (1) to disable category-B in the
buildbots: The category-B dependencies as they are right now
(built from source and patched) are unsupported. We can officially
support them only if we use binaries (I am thinking of Java bytecode
and fonts).
I would like now to point out another case that points out a
real issue:
We are using Seamonkey version 1.1.14 and we are patching it.
Version 1.1.14 is unsupported upstream and the Mozilla Foundation
doesn't carry it anymore. For all purposes it seems like we have forked
this package and can be considered "upstream".
We are not allowed to distribute MPL code at all, and even if we just
mirror it for convenience to our users, like in this case, we will always
be exposed to becoming the mainstream distributors of forked code.
Pedro.
> - we use currently version 1.2.9 and compile the source in our build env
> on demand when the correct configure switch is used
>
> - we apply 4 or in case of mingw 5 patch files (depends on the mechanism
> that is used in our build env generally for this kind of things)
>
> 3 of these patch files contains minor changes used/necessary for our
> build env.
>
> For example hunspell-solaris.patch:
> ###
> --- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx 2010-02-27
> 23:42:05.000000000 +0000
> +++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx 2010-02-27
> 23:43:02.000000000 +0000
> @@ -10,6 +10,9 @@
> #include "hunspell.hxx"
> #include "csutil.hxx"
>
> +// switch off iconv support for tests (fixing Solaris problems)
> +#undef HAVE_ICONV
> +
> #ifndef HUNSPELL_EXTRA
> #define suggest_auto suggest
> #endif
> ###
>
> One patch apply a back port patch for an important issue that is fixed
> in a newer version. Don't ask me why we haven't upgraded the version
> already. But that is as I mentioned before on our plan.
>
> hunspell-stackmash.patch
> ###
> --- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
> 10:25:06.000000000 +0000
> +++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
> 10:25:38.000000000 +0000
> @@ -1665,7 +1665,7 @@
> if (!q2) return 0; // bad XML input
> if (check_xml_par(q, "type=", "analyze")) {
> int n = 0, s = 0;
> - if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
> analyze(slst, cw);
> + if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
> analyze(slst, cw);
> if (n == 0) return 0;
> // convert the result to<code><a>ana1</a><a>ana2</a></code> format
> for (int i = 0; i< n; i++) s+= strlen((*slst)[i]);
> @@ -1686,13 +1686,13 @@
> (*slst)[0] = r;
> return 1;
> } else if (check_xml_par(q, "type=", "stem")) {
> - if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
> stem(slst, cw);
> + if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
> stem(slst, cw);
> } else if (check_xml_par(q, "type=", "generate")) {
> - int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
> + int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
> if (n == 0) return 0;
> char * q3 = strstr(q2 + 1, "<word");
> if (q3) {
> - if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
> + if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
> return generate(slst, cw, cw2);
> }
> } else {
> ###
>
> This fix is fixed upstream in version 1.2.11, see
> http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9
>
>
> That means with our further ongoing improvements in this area we get rid
> of this patch and have only minor patches for our build env.
>
> Building these libs on demand in our build env is for convenience.
> Otherwise we would have to put them somewhere else, have to duplicate
> the build env or would need to build them with our build env and use the
> binary libraries from there. That would mean a further huge burden to
> make the development for AOO more complicate.
>
> I hope this helps
>
> Juergen
>
>
> On 6/1/12 11:07 AM, Ross Gardler wrote:
>> On 1 June 2012 09:50, Jürgen Schmidt<jo...@googlemail.com> wrote:
>>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>>> Sent from my mobile device, please forgive errors and brevity.
>>>> On May 31, 2012 5:26 PM, "Pedro Giffuni"<pf...@apache.org> wrote:
>> ...
>>
>>>>> I admit this is very clear. I don't expect such development to be
>>>>> a requirement for graduation but the transitory situation of a source
>>>>> release that depends on carrying category-B tarballs in SVN now is
>>>>> not really acceptable.
>>>> I do expect this to be sorted out before graduation.
>>> it is addressed already
>>>
>>>> That might be as simple as getting clarity on the policy, it might be more
>>>> than that. However, as a mentor I am uncertain about the practice adopted
>>>> here and as such will not encourage the IPMC to vote for graduation until
>>>> someone in the PPMC gets clarity.
>>> what do you expect?
>> Someone needs to take out all the rhetoric and abstract concepts. Pick
>> any one of the cat-b cases and describe *exactly* how it is addressed
>> in that case and *exactly* how this conforms to documented ASF
>> policies.
>>
>> Once we have clarity on the first case we can ask whether any of the
>> other cases are different and then examine those.
>>
>>> Should we remove all this dependencies and make AOO more or less
>>> unusable or better uninteresting for real usage?
>> I am making no comment on what the technical solution is.
>>
>> I want to see consensus. Consensus cannot be gained by shouting at one
>> another about vague examples. I want concrete examples on a case by
>> case basis until nobody is objecting or until the issues can be
>> clearly communicated to either the IPMC or legal@ so that a
>> clarification of ASF policy can be made.
>>
>>> Anyway I think we tried everything to address this and we still work on
>>> improvements step by step. If that is not enough for graduation I would
>>> feel very unsatisfied.
>> It is, and always has been, a condition of graduation that the IP
>> situation in the project conforms to ASF policies. There is a question
>> about these tarballs and it must be resolved before graduation.
>>
>> Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Hi,
sorry for top posting but I followed Ross advice and will give a
concrete example.
Hunspell -> MPL + LGPL
- we use currently version 1.2.9 and compile the source in our build env
on demand when the correct configure switch is used
- we apply 4 or in case of mingw 5 patch files (depends on the mechanism
that is used in our build env generally for this kind of things)
3 of these patch files contains minor changes used/necessary for our
build env.
For example hunspell-solaris.patch:
###
--- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx 2010-02-27
23:42:05.000000000 +0000
+++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx 2010-02-27
23:43:02.000000000 +0000
@@ -10,6 +10,9 @@
#include "hunspell.hxx"
#include "csutil.hxx"
+// switch off iconv support for tests (fixing Solaris problems)
+#undef HAVE_ICONV
+
#ifndef HUNSPELL_EXTRA
#define suggest_auto suggest
#endif
###
One patch apply a back port patch for an important issue that is fixed
in a newer version. Don't ask me why we haven't upgraded the version
already. But that is as I mentioned before on our plan.
hunspell-stackmash.patch
###
--- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
10:25:06.000000000 +0000
+++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
10:25:38.000000000 +0000
@@ -1665,7 +1665,7 @@
if (!q2) return 0; // bad XML input
if (check_xml_par(q, "type=", "analyze")) {
int n = 0, s = 0;
- if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
analyze(slst, cw);
+ if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
analyze(slst, cw);
if (n == 0) return 0;
// convert the result to <code><a>ana1</a><a>ana2</a></code> format
for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
@@ -1686,13 +1686,13 @@
(*slst)[0] = r;
return 1;
} else if (check_xml_par(q, "type=", "stem")) {
- if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
stem(slst, cw);
+ if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
stem(slst, cw);
} else if (check_xml_par(q, "type=", "generate")) {
- int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
+ int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
if (n == 0) return 0;
char * q3 = strstr(q2 + 1, "<word");
if (q3) {
- if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
+ if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
return generate(slst, cw, cw2);
}
} else {
###
This fix is fixed upstream in version 1.2.11, see
http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9
That means with our further ongoing improvements in this area we get rid
of this patch and have only minor patches for our build env.
Building these libs on demand in our build env is for convenience.
Otherwise we would have to put them somewhere else, have to duplicate
the build env or would need to build them with our build env and use the
binary libraries from there. That would mean a further huge burden to
make the development for AOO more complicate.
I hope this helps
Juergen
On 6/1/12 11:07 AM, Ross Gardler wrote:
> On 1 June 2012 09:50, Jürgen Schmidt <jo...@googlemail.com> wrote:
>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>> Sent from my mobile device, please forgive errors and brevity.
>>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>>>>
>
> ...
>
>>>> I admit this is very clear. I don't expect such development to be
>>>> a requirement for graduation but the transitory situation of a source
>>>> release that depends on carrying category-B tarballs in SVN now is
>>>> not really acceptable.
>>>
>>> I do expect this to be sorted out before graduation.
>>
>> it is addressed already
>>
>>> That might be as simple as getting clarity on the policy, it might be more
>>> than that. However, as a mentor I am uncertain about the practice adopted
>>> here and as such will not encourage the IPMC to vote for graduation until
>>> someone in the PPMC gets clarity.
>>
>> what do you expect?
>
> Someone needs to take out all the rhetoric and abstract concepts. Pick
> any one of the cat-b cases and describe *exactly* how it is addressed
> in that case and *exactly* how this conforms to documented ASF
> policies.
>
> Once we have clarity on the first case we can ask whether any of the
> other cases are different and then examine those.
>
>> Should we remove all this dependencies and make AOO more or less
>> unusable or better uninteresting for real usage?
>
> I am making no comment on what the technical solution is.
>
> I want to see consensus. Consensus cannot be gained by shouting at one
> another about vague examples. I want concrete examples on a case by
> case basis until nobody is objecting or until the issues can be
> clearly communicated to either the IPMC or legal@ so that a
> clarification of ASF policy can be made.
>
>> Anyway I think we tried everything to address this and we still work on
>> improvements step by step. If that is not enough for graduation I would
>> feel very unsatisfied.
>
> It is, and always has been, a condition of graduation that the IP
> situation in the project conforms to ASF policies. There is a question
> about these tarballs and it must be resolved before graduation.
>
> Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Ross Gardler <rg...@opendirective.com>.
On 1 June 2012 09:50, Jürgen Schmidt <jo...@googlemail.com> wrote:
> On 6/1/12 9:47 AM, Ross Gardler wrote:
>> Sent from my mobile device, please forgive errors and brevity.
>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>>>
...
>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now is
>>> not really acceptable.
>>
>> I do expect this to be sorted out before graduation.
>
> it is addressed already
>
>> That might be as simple as getting clarity on the policy, it might be more
>> than that. However, as a mentor I am uncertain about the practice adopted
>> here and as such will not encourage the IPMC to vote for graduation until
>> someone in the PPMC gets clarity.
>
> what do you expect?
Someone needs to take out all the rhetoric and abstract concepts. Pick
any one of the cat-b cases and describe *exactly* how it is addressed
in that case and *exactly* how this conforms to documented ASF
policies.
Once we have clarity on the first case we can ask whether any of the
other cases are different and then examine those.
> Should we remove all this dependencies and make AOO more or less
> unusable or better uninteresting for real usage?
I am making no comment on what the technical solution is.
I want to see consensus. Consensus cannot be gained by shouting at one
another about vague examples. I want concrete examples on a case by
case basis until nobody is objecting or until the issues can be
clearly communicated to either the IPMC or legal@ so that a
clarification of ASF policy can be made.
> Anyway I think we tried everything to address this and we still work on
> improvements step by step. If that is not enough for graduation I would
> feel very unsatisfied.
It is, and always has been, a condition of graduation that the IP
situation in the project conforms to ASF policies. There is a question
about these tarballs and it must be resolved before graduation.
Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 6/1/12 9:47 AM, Ross Gardler wrote:
> Sent from my mobile device, please forgive errors and brevity.
> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>>
>> Hi Jürgen;
>>
>> Let me clarify some issues too ...
>>
>> On 05/31/12 10:39, Jürgen Schmidt wrote:
>>>
>>> ...
>>>
>
> ...
>
>>
>>> 6. we agreed to upstream changes to external libs where possible and
>>> necessary. And we agreed to improve the workflow to use the tar-balls
>>> from their original source where possible over time and where we can
>>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>>
>> Yes. Most of them are just uninteresting upstream.
>
> This is the part that really bothers me. There is a world of difference
> between providing unmodified cat-b sources and providing modified cat-b
> sources. The ASF only releases software under the ALv2. If any of these
> cat-b sources have modifications they cannot, IMHO, be managed by the ASF
> unless specific approval for an exception to policy is sought.
>
with my statement above I didn't differentiate between cat-a or cat-b
etc. The general approach is
- that we try to upstream patches where possible.
- we often apply patches to make the source compilable in our build env.
The reason why this is necessary is much more complex.
> If there are no modifications the position is much less clear, but still
> needs examination.
>
>> I admit this is very clear. I don't expect such development to be
>> a requirement for graduation but the transitory situation of a source
>> release that depends on carrying category-B tarballs in SVN now is
>> not really acceptable.
>
> I do expect this to be sorted out before graduation.
it is addressed already
>
> That might be as simple as getting clarity on the policy, it might be more
> than that. However, as a mentor I am uncertain about the practice adopted
> here and as such will not encourage the IPMC to vote for graduation until
> someone in the PPMC gets clarity.
what do you expect?
Should we remove all this dependencies and make AOO more or less
unusable or better uninteresting for real usage?
Mmm, maybe a good idea. We would get rid of the binary releases because
nobody would be interested in them. But who would build and provide
binaries? Do you think we could attract any new developer to work on AOO
in this case?
Anyway I think we tried everything to address this and we still work on
improvements step by step. If that is not enough for graduation I would
feel very unsatisfied. We can't perform magic and we think more
practical according the Apache rules/policies as we understand them.
Juergen
>
> As a mentor I'm not going to do it. I've been asked to stop doing stuff for
> the community and let it manage its own afairs, and I'm happy to do so.
>
> Ross
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Ross Gardler <rg...@opendirective.com>.
Sent from my mobile device, please forgive errors and brevity.
On May 31, 2012 5:26 PM, "Pedro Giffuni" <pf...@apache.org> wrote:
>
> Hi Jürgen;
>
> Let me clarify some issues too ...
>
> On 05/31/12 10:39, Jürgen Schmidt wrote:
>>
>> ...
>>
...
>
>> 6. we agreed to upstream changes to external libs where possible and
>> necessary. And we agreed to improve the workflow to use the tar-balls
>> from their original source where possible over time and where we can
>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>
> Yes. Most of them are just uninteresting upstream.
This is the part that really bothers me. There is a world of difference
between providing unmodified cat-b sources and providing modified cat-b
sources. The ASF only releases software under the ALv2. If any of these
cat-b sources have modifications they cannot, IMHO, be managed by the ASF
unless specific approval for an exception to policy is sought.
If there are no modifications the position is much less clear, but still
needs examination.
> I admit this is very clear. I don't expect such development to be
> a requirement for graduation but the transitory situation of a source
> release that depends on carrying category-B tarballs in SVN now is
> not really acceptable.
I do expect this to be sorted out before graduation.
That might be as simple as getting clarity on the policy, it might be more
than that. However, as a mentor I am uncertain about the practice adopted
here and as such will not encourage the IPMC to vote for graduation until
someone in the PPMC gets clarity.
As a mentor I'm not going to do it. I've been asked to stop doing stuff for
the community and let it manage its own afairs, and I'm happy to do so.
Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Dave Fisher <da...@comcast.net>.
+1 from me.
On vacation a few more days...
Sent from my iPhone
On Jun 18, 2012, at 12:25 PM, "Dennis E. Hamilton" <de...@acm.org> wrote:
> +1
>
> sounds like a plan
>
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, June 18, 2012 07:59
> To: ooo-dev@incubator.apache.org; pfg@apache.org
> Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
> On Mon, Jun 18, 2012 at 10:49 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>
>> --- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
>>
>>>>
>>>> Andre did a nice job but the category B tarballs are
>>>> still in SVN so I dont consider the issue has been
>>>> solved.
>>>>
>>>
>>> Do you have any proposal for how that could addressed
>>> without breaking the released AOO 3.4.0 source
>>> distribution?
>>>
>>
>> Hasn't changed.
>>
>> Axe and add a note to the src distribution to let
>> people know where to find the (already optional)
>> tarballs.
>>
>
> This would also be cleared up after 3.4.1 is released, since that
> would not depend on the legacy location for the tarballs. It is
> easier to break 3.4.0 once a 3.4.1 is out.
>
> It is fine with me if we delay graduation until after 3.4.1 is
> released. This also avoids having graduation trigger a disruptive set
> of naming changes to the release and the website at the same time
> we're trying to get out a release.
>
>> Pedro.
>>
>>
>
RE: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1
sounds like a plan
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Monday, June 18, 2012 07:59
To: ooo-dev@incubator.apache.org; pfg@apache.org
Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
On Mon, Jun 18, 2012 at 10:49 AM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> --- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
>
>> >
>> > Andre did a nice job but the category B tarballs are
>> > still in SVN so I dont consider the issue has been
>> > solved.
>> >
>>
>> Do you have any proposal for how that could addressed
>> without breaking the released AOO 3.4.0 source
>> distribution?
>>
>
> Hasn't changed.
>
> Axe and add a note to the src distribution to let
> people know where to find the (already optional)
> tarballs.
>
This would also be cleared up after 3.4.1 is released, since that
would not depend on the legacy location for the tarballs. It is
easier to break 3.4.0 once a 3.4.1 is out.
It is fine with me if we delay graduation until after 3.4.1 is
released. This also avoids having graduation trigger a disruptive set
of naming changes to the release and the website at the same time
we're trying to get out a release.
> Pedro.
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Jun 18, 2012 at 7:58 AM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Jun 18, 2012 at 10:49 AM, Pedro Giffuni <pf...@apache.org> wrote:
> >
> >
> > --- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
> >
> >> >
> >> > Andre did a nice job but the category B tarballs are
> >> > still in SVN so I dont consider the issue has been
> >> > solved.
> >> >
> >>
> >> Do you have any proposal for how that could addressed
> >> without breaking the released AOO 3.4.0 source
> >> distribution?
> >>
> >
> > Hasn't changed.
> >
> > Axe and add a note to the src distribution to let
> > people know where to find the (already optional)
> > tarballs.
> >
>
> This would also be cleared up after 3.4.1 is released, since that
> would not depend on the legacy location for the tarballs. It is
> easier to break 3.4.0 once a 3.4.1 is out.
>
> It is fine with me if we delay graduation until after 3.4.1 is
> released. This also avoids having graduation trigger a disruptive set
> of naming changes to the release and the website at the same time
> we're trying to get out a release.
>
I think this is wise... +1!
>
> > Pedro.
> >
> >
>
--
----------------------------------------------------------------------------------------
MzK
"Known commonly as the jackass, this long-eared little creature
is respected throughout the southwest—roundly cursed
yet respected—and here he is usually referred to by his
Spanish name, burro. Because of his extraordinary bray,
he is sometimes ironically called the "Arizona Nightingale."
-- "Arizona, the Grand Canyon State: A State Guide",
By Federal Writers' Project
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jun 18, 2012 at 10:49 AM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> --- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
>
>> >
>> > Andre did a nice job but the category B tarballs are
>> > still in SVN so I dont consider the issue has been
>> > solved.
>> >
>>
>> Do you have any proposal for how that could addressed
>> without breaking the released AOO 3.4.0 source
>> distribution?
>>
>
> Hasn't changed.
>
> Axe and add a note to the src distribution to let
> people know where to find the (already optional)
> tarballs.
>
This would also be cleared up after 3.4.1 is released, since that
would not depend on the legacy location for the tarballs. It is
easier to break 3.4.0 once a 3.4.1 is out.
It is fine with me if we delay graduation until after 3.4.1 is
released. This also avoids having graduation trigger a disruptive set
of naming changes to the release and the website at the same time
we're trying to get out a release.
> Pedro.
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
> >
> > Andre did a nice job but the category B tarballs are
> > still in SVN so I dont consider the issue has been
> > solved.
> >
>
> Do you have any proposal for how that could addressed
> without breaking the released AOO 3.4.0 source
> distribution?
>
Hasn't changed.
Axe and add a note to the src distribution to let
people know where to find the (already optional)
tarballs.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jun 18, 2012 at 9:16 AM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> --- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
>
>> On Sun, Jun 3, 2012 at 8:40 PM, Pedro Giffuni
>> wrote:
>> >
> ...
>> >
>> > I certainly think this makes sense.
>> >
>> > Discriminating the Category-B tarballs in the mirrors
>> > is easier and does not give the impression that it is
>> > ASF code or that we are maintaining it. Plus mirrors
>> > are absolutely more adequate for distributing tarballs
>> > than a SVN repository.
>> >
>>
>> Hi Pedro,
>>
>> Andrew made some changes to the way ext-sources are
>> downloaded. Does
>> that address the concerns you raised on the graduation
>> thread? Could you confirm?
>>
>
> Andre did a nice job but the category B tarballs are
> still in SVN so I dont consider the issue has been
> solved.
>
Do you have any proposal for how that could addressed without breaking
the released AOO 3.4.0 source distribution?
-Rob
> Pedro.
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jun 18, 2012 at 8:58 AM, Rob Weir <ro...@apache.org> wrote:
> On Sun, Jun 3, 2012 at 8:40 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>
>> --- Sab 2/6/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
>>
>>> This situation doesn't seem to be
>>> diffusing itself,
>>> even tho I have tried to explain that the 3.4.0 release
>>> deps "packaging" does not comply with infra policy.
>>>
>>> Surely there is a middle ground here- that the missing
>>> release deps package simply be generated from those
>>> tarballs in svn. So long as the source release uses
>>>
>>> deps from the (downloaded from mirrors) deps package
>>>
>>> instead of directly from svn, AFAICT this project will
>>> be in compliance with all legal and infra policies.
>>>
>>
>>
>> I certainly think this makes sense.
>>
>> Discriminating the Category-B tarballs in the mirrors
>> is easier and does not give the impression that it is
>> ASF code or that we are maintaining it. Plus mirrors
>> are absolutely more adequate for distributing tarballs
>> than a SVN repository.
>>
>
> Hi Pedro,
>
> Andrew made some changes to the way ext-sources are downloaded. Does
Sorry, a typo. Andre did that work, of course.
-Rob
> that address the concerns you raised on the graduation thread? Could
> you confirm?
>
> Thanks!
>
> -Rob
>
>
>> Pedro.
>>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 18/6/12, Rob Weir <ro...@apache.org> ha scritto:
> On Sun, Jun 3, 2012 at 8:40 PM, Pedro Giffuni
> wrote:
> >
...
> >
> > I certainly think this makes sense.
> >
> > Discriminating the Category-B tarballs in the mirrors
> > is easier and does not give the impression that it is
> > ASF code or that we are maintaining it. Plus mirrors
> > are absolutely more adequate for distributing tarballs
> > than a SVN repository.
> >
>
> Hi Pedro,
>
> Andrew made some changes to the way ext-sources are
> downloaded. Does
> that address the concerns you raised on the graduation
> thread? Could you confirm?
>
Andre did a nice job but the category B tarballs are
still in SVN so I dont consider the issue has been
solved.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Jun 3, 2012 at 8:40 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
>
> --- Sab 2/6/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
>
>> This situation doesn't seem to be
>> diffusing itself,
>> even tho I have tried to explain that the 3.4.0 release
>> deps "packaging" does not comply with infra policy.
>>
>> Surely there is a middle ground here- that the missing
>> release deps package simply be generated from those
>> tarballs in svn. So long as the source release uses
>>
>> deps from the (downloaded from mirrors) deps package
>>
>> instead of directly from svn, AFAICT this project will
>> be in compliance with all legal and infra policies.
>>
>
>
> I certainly think this makes sense.
>
> Discriminating the Category-B tarballs in the mirrors
> is easier and does not give the impression that it is
> ASF code or that we are maintaining it. Plus mirrors
> are absolutely more adequate for distributing tarballs
> than a SVN repository.
>
Hi Pedro,
Andrew made some changes to the way ext-sources are downloaded. Does
that address the concerns you raised on the graduation thread? Could
you confirm?
Thanks!
-Rob
> Pedro.
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Sat, Jun 2, 2012 at 6:30 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>>________________________________
>> From: Rob Weir <ro...@apache.org>
>>To: ooo-dev@incubator.apache.org
>>Sent: Saturday, June 2, 2012 6:20 PM
>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>
>>On Sat, Jun 2, 2012 at 6:04 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>>> This situation doesn't seem to be diffusing itself,
>>> even tho I have tried to explain that the 3.4.0 release
>>> deps "packaging" does not comply with infra policy.
>>>
>>> Surely there is a middle ground here- that the missing
>>> release deps package simply be generated from those
>>> tarballs in svn. So long as the source release uses
>>>
>>> deps from the (downloaded from mirrors) deps package
>>>
>>> instead of directly from svn, AFAICT this project will
>>> be in compliance with all legal and infra policies.
>>>
>>
>>So what would the status of the debs tarball be? Is it part of the
>>release? Do we vote on it? It has cat-b source in it, so one would
>>think that this could not be in a release, and not on the mirrors? Or
>>is there a recognized exception for dependencies provided as a
>>convenience?
>
>
> There are few if any legal policy constraints on convenience artfacts-
> if you go through the mirrors you will find instances of non-open-source
> items (eg Windows installers, binaries, etc). Convenience artifacts
> do not form the basis of a release vote. I see no reason why the
> licensing on source artifacts that we distribute as a convenience
> should be more restrictive than the licensing on binaries- policy
> designed around Java artifacts isn't meant to place unreasonable
> limits on what AOO can reasonably distribute on the mirrors.
>
> Does that help?
>
Thanks. That does give us another option to consider.
>
>
>
>
>>
>>
>>> Whether that's best practice is debatable, but I don't
>>> believe it's so unreasonable that a rational person
>>> would withhold their participation in the project over it.
>>>
>>>
>>> HTH
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Pedro Giffuni <pf...@apache.org>
>>>>To: ooo-dev@incubator.apache.org; Jürgen Schmidt <jo...@googlemail.com>
>>>>Sent: Saturday, June 2, 2012 5:52 PM
>>>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>>>
>>>>On 06/02/12 15:11, Juergen Schmidt wrote:
>>>>> ...
>>>>>>
>>>>>> Well I am a committer in the only big UNIX-like
>>>>>> distribution that is carrying Apache OpenOffice
>>>>>> nowadays. We would really like to use a source
>>>>>> distribution through ASF mirrors but since the ASF
>>>>>> doesn't provide one that works well we have been
>>>>>> rolling our own. Having a working source
>>>>>> distribution would help attract linux packagers,
>>>>>> I think.
>>>>>>
>>>>>>
>>>>> well if that is really the case you have failed on several levels
>>>>>
>>>>> - you didn't really have used or tried the source tarball
>>>>> - you didn't gave the appropriate and necessary feedback
>>>>> - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
>>>>
>>>>Sure, I am not perfect but you can't really blame the
>>>>messenger if the package was broken.
>>>>
>>>>I have huge experience packaging stuff for my own selfish
>>>>purposes in the past (BRL-CAD, FEM utilities, stuff like that),
>>>>however I am not a ports committer/packager myself;
>>>>I am a src committer. You can see my work in some sound
>>>>drivers, the ext2fs implementation and some compiler
>>>>updates. I have been very busy between kernel coding
>>>>and the AOO SVN stuff to work also on the AOO
>>>>packaging.
>>>>
>>>>The vast packaging work in FreeBSD has been done by
>>>>Maho-san for several years and he has been so efficient
>>>>I haven't really had to intervene other than to give some
>>>>minor suggestions. He is a ports committer and I am so
>>>>glad he has been around to take care of things.
>>>>
>>>>I have been busy on some updates and I only noticed
>>>>a few days ago that we are not using the source tarballs
>>>>provided by Apache. I can't really test everything behind
>>>>a release and, with due respect, all I do is voluntary work
>>>>so I do have to spend my time in other activities too.
>>>>
>>>>I am attempting to provide some feedback here but
>>>>I would suggest you ask the guys doing Ubuntu or
>>>>Debian packaging if they are using the src tarballs
>>>>and how we can make the packaging easier.
>>>>
>>>>> That makes me really thinking ...
>>>>
>>>>Please stop imagining things. I know you guys are not
>>>>happy about having to do extra reshuffling in the tree
>>>>and playing with scripts to adapt things to what *I*
>>>>think is the Apache way. In all honesty let's admit I had
>>>>mentioned this was a grey area since a long time ago
>>>>and I have even offered to step aside and let
>>>>the project evolve on it's own.
>>>>
>>>>Pedro.
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Joe Schaefer <jo...@yahoo.com>.
>________________________________
> From: Rob Weir <ro...@apache.org>
>To: ooo-dev@incubator.apache.org
>Sent: Saturday, June 2, 2012 6:20 PM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
>On Sat, Jun 2, 2012 at 6:04 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>> This situation doesn't seem to be diffusing itself,
>> even tho I have tried to explain that the 3.4.0 release
>> deps "packaging" does not comply with infra policy.
>>
>> Surely there is a middle ground here- that the missing
>> release deps package simply be generated from those
>> tarballs in svn. So long as the source release uses
>>
>> deps from the (downloaded from mirrors) deps package
>>
>> instead of directly from svn, AFAICT this project will
>> be in compliance with all legal and infra policies.
>>
>
>So what would the status of the debs tarball be? Is it part of the
>release? Do we vote on it? It has cat-b source in it, so one would
>think that this could not be in a release, and not on the mirrors? Or
>is there a recognized exception for dependencies provided as a
>convenience?
There are few if any legal policy constraints on convenience artfacts-
if you go through the mirrors you will find instances of non-open-source
items (eg Windows installers, binaries, etc). Convenience artifacts
do not form the basis of a release vote. I see no reason why the
licensing on source artifacts that we distribute as a convenience
should be more restrictive than the licensing on binaries- policy
designed around Java artifacts isn't meant to place unreasonable
limits on what AOO can reasonably distribute on the mirrors.
Does that help?
>
>
>> Whether that's best practice is debatable, but I don't
>> believe it's so unreasonable that a rational person
>> would withhold their participation in the project over it.
>>
>>
>> HTH
>>
>>
>>
>>
>>>________________________________
>>> From: Pedro Giffuni <pf...@apache.org>
>>>To: ooo-dev@incubator.apache.org; Jürgen Schmidt <jo...@googlemail.com>
>>>Sent: Saturday, June 2, 2012 5:52 PM
>>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>>
>>>On 06/02/12 15:11, Juergen Schmidt wrote:
>>>> ...
>>>>>
>>>>> Well I am a committer in the only big UNIX-like
>>>>> distribution that is carrying Apache OpenOffice
>>>>> nowadays. We would really like to use a source
>>>>> distribution through ASF mirrors but since the ASF
>>>>> doesn't provide one that works well we have been
>>>>> rolling our own. Having a working source
>>>>> distribution would help attract linux packagers,
>>>>> I think.
>>>>>
>>>>>
>>>> well if that is really the case you have failed on several levels
>>>>
>>>> - you didn't really have used or tried the source tarball
>>>> - you didn't gave the appropriate and necessary feedback
>>>> - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
>>>
>>>Sure, I am not perfect but you can't really blame the
>>>messenger if the package was broken.
>>>
>>>I have huge experience packaging stuff for my own selfish
>>>purposes in the past (BRL-CAD, FEM utilities, stuff like that),
>>>however I am not a ports committer/packager myself;
>>>I am a src committer. You can see my work in some sound
>>>drivers, the ext2fs implementation and some compiler
>>>updates. I have been very busy between kernel coding
>>>and the AOO SVN stuff to work also on the AOO
>>>packaging.
>>>
>>>The vast packaging work in FreeBSD has been done by
>>>Maho-san for several years and he has been so efficient
>>>I haven't really had to intervene other than to give some
>>>minor suggestions. He is a ports committer and I am so
>>>glad he has been around to take care of things.
>>>
>>>I have been busy on some updates and I only noticed
>>>a few days ago that we are not using the source tarballs
>>>provided by Apache. I can't really test everything behind
>>>a release and, with due respect, all I do is voluntary work
>>>so I do have to spend my time in other activities too.
>>>
>>>I am attempting to provide some feedback here but
>>>I would suggest you ask the guys doing Ubuntu or
>>>Debian packaging if they are using the src tarballs
>>>and how we can make the packaging easier.
>>>
>>>> That makes me really thinking ...
>>>
>>>Please stop imagining things. I know you guys are not
>>>happy about having to do extra reshuffling in the tree
>>>and playing with scripts to adapt things to what *I*
>>>think is the Apache way. In all honesty let's admit I had
>>>mentioned this was a grey area since a long time ago
>>>and I have even offered to step aside and let
>>>the project evolve on it's own.
>>>
>>>Pedro.
>>>
>>>
>>>
>>>
>
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Sat, Jun 2, 2012 at 6:04 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> This situation doesn't seem to be diffusing itself,
> even tho I have tried to explain that the 3.4.0 release
> deps "packaging" does not comply with infra policy.
>
> Surely there is a middle ground here- that the missing
> release deps package simply be generated from those
> tarballs in svn. So long as the source release uses
>
> deps from the (downloaded from mirrors) deps package
>
> instead of directly from svn, AFAICT this project will
> be in compliance with all legal and infra policies.
>
So what would the status of the debs tarball be? Is it part of the
release? Do we vote on it? It has cat-b source in it, so one would
think that this could not be in a release, and not on the mirrors? Or
is there a recognized exception for dependencies provided as a
convenience?
> Whether that's best practice is debatable, but I don't
> believe it's so unreasonable that a rational person
> would withhold their participation in the project over it.
>
>
> HTH
>
>
>
>
>>________________________________
>> From: Pedro Giffuni <pf...@apache.org>
>>To: ooo-dev@incubator.apache.org; Jürgen Schmidt <jo...@googlemail.com>
>>Sent: Saturday, June 2, 2012 5:52 PM
>>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>>
>>On 06/02/12 15:11, Juergen Schmidt wrote:
>>> ...
>>>>
>>>> Well I am a committer in the only big UNIX-like
>>>> distribution that is carrying Apache OpenOffice
>>>> nowadays. We would really like to use a source
>>>> distribution through ASF mirrors but since the ASF
>>>> doesn't provide one that works well we have been
>>>> rolling our own. Having a working source
>>>> distribution would help attract linux packagers,
>>>> I think.
>>>>
>>>>
>>> well if that is really the case you have failed on several levels
>>>
>>> - you didn't really have used or tried the source tarball
>>> - you didn't gave the appropriate and necessary feedback
>>> - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
>>
>>Sure, I am not perfect but you can't really blame the
>>messenger if the package was broken.
>>
>>I have huge experience packaging stuff for my own selfish
>>purposes in the past (BRL-CAD, FEM utilities, stuff like that),
>>however I am not a ports committer/packager myself;
>>I am a src committer. You can see my work in some sound
>>drivers, the ext2fs implementation and some compiler
>>updates. I have been very busy between kernel coding
>>and the AOO SVN stuff to work also on the AOO
>>packaging.
>>
>>The vast packaging work in FreeBSD has been done by
>>Maho-san for several years and he has been so efficient
>>I haven't really had to intervene other than to give some
>>minor suggestions. He is a ports committer and I am so
>>glad he has been around to take care of things.
>>
>>I have been busy on some updates and I only noticed
>>a few days ago that we are not using the source tarballs
>>provided by Apache. I can't really test everything behind
>>a release and, with due respect, all I do is voluntary work
>>so I do have to spend my time in other activities too.
>>
>>I am attempting to provide some feedback here but
>>I would suggest you ask the guys doing Ubuntu or
>>Debian packaging if they are using the src tarballs
>>and how we can make the packaging easier.
>>
>>> That makes me really thinking ...
>>
>>Please stop imagining things. I know you guys are not
>>happy about having to do extra reshuffling in the tree
>>and playing with scripts to adapt things to what *I*
>>think is the Apache way. In all honesty let's admit I had
>>mentioned this was a grey area since a long time ago
>>and I have even offered to step aside and let
>>the project evolve on it's own.
>>
>>Pedro.
>>
>>
>>
>>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Sab 2/6/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
> This situation doesn't seem to be
> diffusing itself,
> even tho I have tried to explain that the 3.4.0 release
> deps "packaging" does not comply with infra policy.
>
> Surely there is a middle ground here- that the missing
> release deps package simply be generated from those
> tarballs in svn. So long as the source release uses
>
> deps from the (downloaded from mirrors) deps package
>
> instead of directly from svn, AFAICT this project will
> be in compliance with all legal and infra policies.
>
I certainly think this makes sense.
Discriminating the Category-B tarballs in the mirrors
is easier and does not give the impression that it is
ASF code or that we are maintaining it. Plus mirrors
are absolutely more adequate for distributing tarballs
than a SVN repository.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Joe Schaefer <jo...@yahoo.com>.
This situation doesn't seem to be diffusing itself,
even tho I have tried to explain that the 3.4.0 release
deps "packaging" does not comply with infra policy.
Surely there is a middle ground here- that the missing
release deps package simply be generated from those
tarballs in svn. So long as the source release uses
deps from the (downloaded from mirrors) deps package
instead of directly from svn, AFAICT this project will
be in compliance with all legal and infra policies.
Whether that's best practice is debatable, but I don't
believe it's so unreasonable that a rational person
would withhold their participation in the project over it.
HTH
>________________________________
> From: Pedro Giffuni <pf...@apache.org>
>To: ooo-dev@incubator.apache.org; Jürgen Schmidt <jo...@googlemail.com>
>Sent: Saturday, June 2, 2012 5:52 PM
>Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
>
>On 06/02/12 15:11, Juergen Schmidt wrote:
>> ...
>>>
>>> Well I am a committer in the only big UNIX-like
>>> distribution that is carrying Apache OpenOffice
>>> nowadays. We would really like to use a source
>>> distribution through ASF mirrors but since the ASF
>>> doesn't provide one that works well we have been
>>> rolling our own. Having a working source
>>> distribution would help attract linux packagers,
>>> I think.
>>>
>>>
>> well if that is really the case you have failed on several levels
>>
>> - you didn't really have used or tried the source tarball
>> - you didn't gave the appropriate and necessary feedback
>> - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
>
>Sure, I am not perfect but you can't really blame the
>messenger if the package was broken.
>
>I have huge experience packaging stuff for my own selfish
>purposes in the past (BRL-CAD, FEM utilities, stuff like that),
>however I am not a ports committer/packager myself;
>I am a src committer. You can see my work in some sound
>drivers, the ext2fs implementation and some compiler
>updates. I have been very busy between kernel coding
>and the AOO SVN stuff to work also on the AOO
>packaging.
>
>The vast packaging work in FreeBSD has been done by
>Maho-san for several years and he has been so efficient
>I haven't really had to intervene other than to give some
>minor suggestions. He is a ports committer and I am so
>glad he has been around to take care of things.
>
>I have been busy on some updates and I only noticed
>a few days ago that we are not using the source tarballs
>provided by Apache. I can't really test everything behind
>a release and, with due respect, all I do is voluntary work
>so I do have to spend my time in other activities too.
>
>I am attempting to provide some feedback here but
>I would suggest you ask the guys doing Ubuntu or
>Debian packaging if they are using the src tarballs
>and how we can make the packaging easier.
>
>> That makes me really thinking ...
>
>Please stop imagining things. I know you guys are not
>happy about having to do extra reshuffling in the tree
>and playing with scripts to adapt things to what *I*
>think is the Apache way. In all honesty let's admit I had
>mentioned this was a grey area since a long time ago
>and I have even offered to step aside and let
>the project evolve on it's own.
>
>Pedro.
>
>
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
On 06/02/12 15:11, Juergen Schmidt wrote:
> ...
>>
>> Well I am a committer in the only big UNIX-like
>> distribution that is carrying Apache OpenOffice
>> nowadays. We would really like to use a source
>> distribution through ASF mirrors but since the ASF
>> doesn't provide one that works well we have been
>> rolling our own. Having a working source
>> distribution would help attract linux packagers,
>> I think.
>>
>>
> well if that is really the case you have failed on several levels
>
> - you didn't really have used or tried the source tarball
> - you didn't gave the appropriate and necessary feedback
> - you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
Sure, I am not perfect but you can't really blame the
messenger if the package was broken.
I have huge experience packaging stuff for my own selfish
purposes in the past (BRL-CAD, FEM utilities, stuff like that),
however I am not a ports committer/packager myself;
I am a src committer. You can see my work in some sound
drivers, the ext2fs implementation and some compiler
updates. I have been very busy between kernel coding
and the AOO SVN stuff to work also on the AOO
packaging.
The vast packaging work in FreeBSD has been done by
Maho-san for several years and he has been so efficient
I haven't really had to intervene other than to give some
minor suggestions. He is a ports committer and I am so
glad he has been around to take care of things.
I have been busy on some updates and I only noticed
a few days ago that we are not using the source tarballs
provided by Apache. I can't really test everything behind
a release and, with due respect, all I do is voluntary work
so I do have to spend my time in other activities too.
I am attempting to provide some feedback here but
I would suggest you ask the guys doing Ubuntu or
Debian packaging if they are using the src tarballs
and how we can make the packaging easier.
> That makes me really thinking ...
Please stop imagining things. I know you guys are not
happy about having to do extra reshuffling in the tree
and playing with scripts to adapt things to what *I*
think is the Apache way. In all honesty let's admit I had
mentioned this was a grey area since a long time ago
and I have even offered to step aside and let
the project evolve on it's own.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Juergen Schmidt <jo...@googlemail.com>.
Am Samstag, 2. Juni 2012 um 00:41 schrieb Pedro Giffuni:
>
> --- Ven 1/6/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
> > >
> > > And computers need electricity, which is not free and
> > > not available under a compatible license. I wish you
> > > could keep focused or at least do an effort to
> > > understand the issues so we can solve them.
> > >
> >
> >
> > Be nice.
>
> Couldn't resist :-P. But I really think you can
> bring more intelligent arguments to the discussion
> if you focus more on solvig the issues and less on
> making your point.
>
> > > The tarball release must be consistent; we cannot hide
> > > tarballs in SVN. Creating a directory with the
> > >
> >
> > Category-A
> > > tarballs that form a base of the release along with
> >
> > the
> > > base distribution is not really a problem. Some of
> >
> > them
> > > are not available upstream anymore.
> >
> >
> > That is one possible technique. But not the only
> > one. I'm a committer on another Apache project,
> > the ODF Toolkit, and we do not include any of the
> > dependencies in our release, not even other
> > category-a ones.
> >
>
>
> Well I am a committer in the only big UNIX-like
> distribution that is carrying Apache OpenOffice
> nowadays. We would really like to use a source
> distribution through ASF mirrors but since the ASF
> doesn't provide one that works well we have been
> rolling our own. Having a working source
> distribution would help attract linux packagers,
> I think.
>
>
well if that is really the case you have failed on several levels
- you didn't really have used or tried the source tarball
- you didn't gave the appropriate and necessary feedback
- you didn't helped to fix your concerns relating the source release. At least it seems you have some concerns
That makes me really thinking ...
Juergen
>
> Perhaps you happen to have data about how many
> people are finding the current source
> distribution tarballs useful?
>
> > All of them are downloaded on the fly
> > from a central repository. That is the
> > beauty of Maven.
> >
>
>
> I have personal experience packaging stuff
> and this is undesirable. One of my ports
> was rejected recently because its inconvenient
> to have the buildbot depend on network access.
>
> Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Ven 1/6/12, Rob Weir <ro...@apache.org> ha scritto:
...
> >
> > And computers need electricity, which is not free and
> > not available under a compatible license. I wish you
> > could keep focused or at least do an effort to
> > understand the issues so we can solve them.
> >
>
> Be nice.
>
Couldn't resist :-P. But I really think you can
bring more intelligent arguments to the discussion
if you focus more on solvig the issues and less on
making your point.
> > The tarball release must be consistent; we cannot hide
> > tarballs in SVN. Creating a directory with the
> Category-A
> > tarballs that form a base of the release along with
> the
> > base distribution is not really a problem. Some of
> them
> > are not available upstream anymore.
> >
>
> That is one possible technique. But not the only
> one. I'm a committer on another Apache project,
> the ODF Toolkit, and we do not include any of the
> dependencies in our release, not even other
> category-a ones.
Well I am a committer in the only big UNIX-like
distribution that is carrying Apache OpenOffice
nowadays. We would really like to use a source
distribution through ASF mirrors but since the ASF
doesn't provide one that works well we have been
rolling our own. Having a working source
distribution would help attract linux packagers,
I think.
Perhaps you happen to have data about how many
people are finding the current source
distribution tarballs useful?
> All of them are downloaded on the fly
> from a central repository. That is the
> beauty of Maven.
>
I have personal experience packaging stuff
and this is undesirable. One of my ports
was rejected recently because its inconvenient
to have the buildbot depend on network access.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 1, 2012 at 3:10 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> Ugh ...
>
> --- Ven 1/6/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
>
>>
>> No release is buildable on its own. You need an
>> operating system, a compiler, often other pre-existing
>> libraries on the system, other prerequisites that need
>> to be installed by the developers.
>>
>
> And computers need electricity, which is not free and
> not available under a compatible license. I wish you
> could keep focused or at least do an effort to
> understand the issues so we can solve them.
>
Be nice.
> The tarball release must be consistent; we cannot hide
> tarballs in SVN. Creating a directory with the Category-A
> tarballs that form a base of the release along with the
> base distribution is not really a problem. Some of them
> are not available upstream anymore.
>
That is one possible technique. But not the only one. I'm a
committer on another Apache project, the ODF Toolkit, and we do not
include any of the dependencies in our release, not even other
category-a ones. All of them are downloaded on the fly from a central
repository. That is the beauty of Maven.
There are advantages of disadvantages of each approach. But we can't
reject one approach outright with a policy argument. Both methods are
in use at Apache today.
-rob
> Pedro.
>
>
>
>
>
>
>> Even in its cleanest form, a Java program using Maven, a
>> release will
>> not build until the user first installs Maven.
>>
>> So no one (except maybe you) is arguing that our release
>> should be
>> buildable without any dependencies that are not included in
>> the
>> release. The real questions should be
>> thought of from the
>> developer's perspective:
>>
>> 1) What dependencies are mandatory and which ones are
>> optional, needed
>> only for specific features?
>>
>> 2) What are the obligations that a developer has when they
>> make use
>> of, or modify code in a particular dependency?
>>
>> 3) What do I need to provision my dev environment to build,
>> with or
>> without any given dependency.
>>
>> What we do at Apache, providing open source software for the
>> good, is
>> directed to making things simple for the downstream
>> consumers of our
>> releases.
>>
>> What we're doing with ext_sources is making #3 far easier,
>> for the
>> developer, compared to tracking down and fetching
>> dependencies from
>> other websites. And I think we've taken the proper
>> steps to provide
>> information, build flags, NOTICE and LICENSE files to cover
>> the other
>> two concerns.
>>
>>
>> >
>> >
>> >>
>> >>>> We also agreed to clean up as much as
>> possible of the dependencies to
>> >>>> category-b stuff over time. But that takes
>> time and is a lot of work.
>> >>>
>> >>> I admit this is very clear. I don't expect such
>> development to be
>> >>> a requirement for graduation but the transitory
>> situation of a source
>> >>> release that depends on carrying category-B
>> tarballs in SVN now is
>> >>> not really acceptable.
>> >>
>> >> well that is exactly the question. I don't know for
>> sure if it is a real
>> >> problem to have them in svn.
>> >>
>> >> svn or any other server would be equal as long as
>> we don't
>> >> change/improve the download part.
>> >>
>> >> So the real problem seems to be a different one.
>> >>
>> >
>> > I will address the Category-B + patches issue on
>> another email.
>> >
>> >
>>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
Ugh ...
--- Ven 1/6/12, Rob Weir <ro...@apache.org> ha scritto:
...
>
> No release is buildable on its own. You need an
> operating system, a compiler, often other pre-existing
> libraries on the system, other prerequisites that need
> to be installed by the developers.
>
And computers need electricity, which is not free and
not available under a compatible license. I wish you
could keep focused or at least do an effort to
understand the issues so we can solve them.
The tarball release must be consistent; we cannot hide
tarballs in SVN. Creating a directory with the Category-A
tarballs that form a base of the release along with the
base distribution is not really a problem. Some of them
are not available upstream anymore.
Pedro.
> Even in its cleanest form, a Java program using Maven, a
> release will
> not build until the user first installs Maven.
>
> So no one (except maybe you) is arguing that our release
> should be
> buildable without any dependencies that are not included in
> the
> release. The real questions should be
> thought of from the
> developer's perspective:
>
> 1) What dependencies are mandatory and which ones are
> optional, needed
> only for specific features?
>
> 2) What are the obligations that a developer has when they
> make use
> of, or modify code in a particular dependency?
>
> 3) What do I need to provision my dev environment to build,
> with or
> without any given dependency.
>
> What we do at Apache, providing open source software for the
> good, is
> directed to making things simple for the downstream
> consumers of our
> releases.
>
> What we're doing with ext_sources is making #3 far easier,
> for the
> developer, compared to tracking down and fetching
> dependencies from
> other websites. And I think we've taken the proper
> steps to provide
> information, build flags, NOTICE and LICENSE files to cover
> the other
> two concerns.
>
>
> >
> >
> >>
> >>>> We also agreed to clean up as much as
> possible of the dependencies to
> >>>> category-b stuff over time. But that takes
> time and is a lot of work.
> >>>
> >>> I admit this is very clear. I don't expect such
> development to be
> >>> a requirement for graduation but the transitory
> situation of a source
> >>> release that depends on carrying category-B
> tarballs in SVN now is
> >>> not really acceptable.
> >>
> >> well that is exactly the question. I don't know for
> sure if it is a real
> >> problem to have them in svn.
> >>
> >> svn or any other server would be equal as long as
> we don't
> >> change/improve the download part.
> >>
> >> So the real problem seems to be a different one.
> >>
> >
> > I will address the Category-B + patches issue on
> another email.
> >
> >
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 1, 2012 at 12:37 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Jürgen;
>
>
> On 06/01/12 03:16, Jürgen Schmidt wrote:
>>
>> On 5/31/12 6:26 PM, Pedro Giffuni wrote:
>>>
>>> ...
>>>
>>> First of all we should clarify what a source release is in this context.
>>> Does our source release contain Category-A tarballs? In other
>>> words, does this file:
>>>
>>> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
>>>
>> I hoped that was clear, our source release files don't contain any
>> tar-balls from ext_sources
>
> OK. So what we are releasing is only the part of the SVN tree labelled
> "main",
> (not sure if ext_libraries is included, it should be). I would think a
> source
> release should be able to build without having to look for extra libraries
> in
> our SVN. Call me old fashioned but I am thinking of people trying to
> distribute the sources in a CD-ROM.
>
>
>
>>> Build on it's own? Or are developers/builders expected to download
>>> more tarballs from SVN.
>>
>> yes, you unpack the source, solve some basic build env requirements
>> according the building guide, run configure and build. The tar-balls get
>> downloaded during the bootstrap step automatically.
>>
>> After checking it again, the only drawback currently is that all
>> tar-balls are downloaded even if they are not used. That is true for all
>> categories.
>>
>> But this is something that we can improve for the 3.5 (already started).
>> We should only download the tar-balls that we need by configure ...
>>
>> Why not 3.4.1? Because it is a maintenance release only and we want to
>> be careful. For 3.4.1 we change the url to download from our 3.4 revision.
>
> I think all releases must respect Apache policies ASAP.
>
>
>>
>>>> It seems to be really an item for legal to decide if hosting the
>>>> category-b tar-balls in svn is not allowed for convenience at all.
>>>>
>>>> Furthermore we agreed to accept and of course support the move to
>>>> another server but it is important that we don't break our 3.4 release.
>>>
>>> As you noted before, removing Category-B tarballs shouldn't break
>>> the default build. But I will go further ahead with mentioning that
>>> the 3.4 Release is theoretically broken already with the Lucene and
>>> Apache Commons updates (the development branch is for
>>> development, right?), and since no one complained people must be
>>> getting the files from somewhere else.
>>
>> well that is a very bad example and probably wrong. We all know or
>> expect that not many people will build AOO from the source release.
>> People who are interested will more likely check it out from svn as you
>> and I did it as well.
>
> I think the problem is your definition of source release. The source release
> in the source tarballs should be 1:1 equivalent to the source release in
> SVN.
> If you think release (in the tarball) is only what you have under "main"
> then
> we do have trouble moving dependencies in the tree. but if you include the
> tarballs in the release, then we don't have trouble. In other words:
>
> If 3.4.1-Release is this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
> it has never been broken.
> If it is only this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/
>
> Then the release is unbuildable on it's own.
>
No release is buildable on its own. You need an operating system, a
compiler, often other pre-existing libraries on the system, other
prerequisites that need to be installed by the developers.
Even in its cleanest form, a Java program using Maven, a release will
not build until the user first installs Maven.
So no one (except maybe you) is arguing that our release should be
buildable without any dependencies that are not included in the
release. The real questions should be thought of from the
developer's perspective:
1) What dependencies are mandatory and which ones are optional, needed
only for specific features?
2) What are the obligations that a developer has when they make use
of, or modify code in a particular dependency?
3) What do I need to provision my dev environment to build, with or
without any given dependency.
What we do at Apache, providing open source software for the good, is
directed to making things simple for the downstream consumers of our
releases.
What we're doing with ext_sources is making #3 far easier, for the
developer, compared to tracking down and fetching dependencies from
other websites. And I think we've taken the proper steps to provide
information, build flags, NOTICE and LICENSE files to cover the other
two concerns.
>
>
>>
>>>> We also agreed to clean up as much as possible of the dependencies to
>>>> category-b stuff over time. But that takes time and is a lot of work.
>>>
>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now is
>>> not really acceptable.
>>
>> well that is exactly the question. I don't know for sure if it is a real
>> problem to have them in svn.
>>
>> svn or any other server would be equal as long as we don't
>> change/improve the download part.
>>
>> So the real problem seems to be a different one.
>>
>
> I will address the Category-B + patches issue on another email.
>
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Jürgen;
On 06/01/12 03:16, Jürgen Schmidt wrote:
> On 5/31/12 6:26 PM, Pedro Giffuni wrote:
>> ...
>> First of all we should clarify what a source release is in this context.
>> Does our source release contain Category-A tarballs? In other
>> words, does this file:
>> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
>>
> I hoped that was clear, our source release files don't contain any
> tar-balls from ext_sources
OK. So what we are releasing is only the part of the SVN tree labelled
"main",
(not sure if ext_libraries is included, it should be). I would think a
source
release should be able to build without having to look for extra
libraries in
our SVN. Call me old fashioned but I am thinking of people trying to
distribute the sources in a CD-ROM.
>> Build on it's own? Or are developers/builders expected to download
>> more tarballs from SVN.
> yes, you unpack the source, solve some basic build env requirements
> according the building guide, run configure and build. The tar-balls get
> downloaded during the bootstrap step automatically.
>
> After checking it again, the only drawback currently is that all
> tar-balls are downloaded even if they are not used. That is true for all
> categories.
>
> But this is something that we can improve for the 3.5 (already started).
> We should only download the tar-balls that we need by configure ...
>
> Why not 3.4.1? Because it is a maintenance release only and we want to
> be careful. For 3.4.1 we change the url to download from our 3.4 revision.
I think all releases must respect Apache policies ASAP.
>
>>> It seems to be really an item for legal to decide if hosting the
>>> category-b tar-balls in svn is not allowed for convenience at all.
>>>
>>> Furthermore we agreed to accept and of course support the move to
>>> another server but it is important that we don't break our 3.4 release.
>> As you noted before, removing Category-B tarballs shouldn't break
>> the default build. But I will go further ahead with mentioning that
>> the 3.4 Release is theoretically broken already with the Lucene and
>> Apache Commons updates (the development branch is for
>> development, right?), and since no one complained people must be
>> getting the files from somewhere else.
> well that is a very bad example and probably wrong. We all know or
> expect that not many people will build AOO from the source release.
> People who are interested will more likely check it out from svn as you
> and I did it as well.
I think the problem is your definition of source release. The source release
in the source tarballs should be 1:1 equivalent to the source release in
SVN.
If you think release (in the tarball) is only what you have under "main"
then
we do have trouble moving dependencies in the tree. but if you include the
tarballs in the release, then we don't have trouble. In other words:
If 3.4.1-Release is this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
it has never been broken.
If it is only this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/
Then the release is unbuildable on it's own.
>
>>> We also agreed to clean up as much as possible of the dependencies to
>>> category-b stuff over time. But that takes time and is a lot of work.
>> I admit this is very clear. I don't expect such development to be
>> a requirement for graduation but the transitory situation of a source
>> release that depends on carrying category-B tarballs in SVN now is
>> not really acceptable.
> well that is exactly the question. I don't know for sure if it is a real
> problem to have them in svn.
>
> svn or any other server would be equal as long as we don't
> change/improve the download part.
>
> So the real problem seems to be a different one.
>
I will address the Category-B + patches issue on another email.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 5/31/12 6:26 PM, Pedro Giffuni wrote:
> Hi Jürgen;
>
> Let me clarify some issues too ...
>
> On 05/31/12 10:39, Jürgen Schmidt wrote:
>> ...
>> let me explain some details here because I think they can help to
>> understand.
>>
>> 1. we have dependencies to several external libraries including
>> category-b for some features
>> 2. we have checked in all this source tar-balls in ext_sources for
>> convenience and to ensure that they are always available. Another option
>> would have been to host them somewhere else on extras or any other
>> reliable server. We use the easier way for convenience reasons I think.
>> 3. our source release don't contain any category-b source tar-balls
> First of all we should clarify what a source release is in this context.
> Does our source release contain Category-A tarballs? In other
> words, does this file:
> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
>
I hoped that was clear, our source release files don't contain any
tar-balls from ext_sources
>
> Build on it's own? Or are developers/builders expected to download
> more tarballs from SVN.
yes, you unpack the source, solve some basic build env requirements
according the building guide, run configure and build. The tar-balls get
downloaded during the bootstrap step automatically.
After checking it again, the only drawback currently is that all
tar-balls are downloaded even if they are not used. That is true for all
categories.
But this is something that we can improve for the 3.5 (already started).
We should only download the tar-balls that we need by configure ...
Why not 3.4.1? Because it is a maintenance release only and we want to
be careful. For 3.4.1 we change the url to download from our 3.4 revision.
>
>> 4. from a source release perspective we don't make use of any category-b
>> stuff per default. A user have to explicitly trigger the use of
>> category-b stuff and related features. The tar-balls are downloaded on
>> demand, some kind of dependency mechanism if you want.
> So if we remove the Category-B tarballs from SVN the default
> build doesn't break, this is important. Now.. if the tarballs are
> downloaded on demand, are you meaning those are downloaded from
> SVN? (It's an honest question: I normally checkout all the tree from
> SVN, including the Category-B, tarballs so I haven't experienced the
> on-demand part of it)
exactly the tar-balls are downloaded via the svn url (see the ooo.lst
file) on demand if they are not already present. When you checkout trunk
you get them and the download is not necessary. Well that is what I
meant with convenience.
>
>
>> 5. the download on demand is the same and I don't really see a
>> difference between downloading the tar-balls from svn or any other place.
> OK. Do note that doing a SVN checkout, as suggested in CWiki,
> there's no easy way to exclude the category-B tarballs:
>
> svn co https://svn.apache.org/repos/asf/incubator/ooo/trunk ooo
that is true, but they are not used without further action or to
explicitly enable them.
I never said that it can't be improved and having the tar-balls in trunk
is of course not the best solution. As we have seen right now with the
latest updates that will or can break our source release when someone
use the correct configure switches.
And of course we agreed to move them and adapt the download scripts.
The whole mechanism is a little bit comparable from my pint view with
maven and how maven solve external dependencies.
>
>
>> 6. we agreed to upstream changes to external libs where possible and
>> necessary. And we agreed to improve the workflow to use the tar-balls
>> from their original source where possible over time and where we can
>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>
> Yes. Most of them are just uninteresting upstream.
>
>> It seems to be really an item for legal to decide if hosting the
>> category-b tar-balls in svn is not allowed for convenience at all.
>>
>> Furthermore we agreed to accept and of course support the move to
>> another server but it is important that we don't break our 3.4 release.
> As you noted before, removing Category-B tarballs shouldn't break
> the default build. But I will go further ahead with mentioning that
> the 3.4 Release is theoretically broken already with the Lucene and
> Apache Commons updates (the development branch is for
> development, right?), and since no one complained people must be
> getting the files from somewhere else.
well that is a very bad example and probably wrong. We all know or
expect that not many people will build AOO from the source release.
People who are interested will more likely check it out from svn as you
and I did it as well.
>
>> We also agreed to clean up as much as possible of the dependencies to
>> category-b stuff over time. But that takes time and is a lot of work.
>
> I admit this is very clear. I don't expect such development to be
> a requirement for graduation but the transitory situation of a source
> release that depends on carrying category-B tarballs in SVN now is
> not really acceptable.
well that is exactly the question. I don't know for sure if it is a real
problem to have them in svn.
svn or any other server would be equal as long as we don't
change/improve the download part.
So the real problem seems to be a different one.
>
>
>> We are also open for any other action that we have to take to be conform
>> to existing policies.
>>
>> I think we have shown in the past that we take everything serious and
>> address issues in time where possible.
>>
>
> I hope you agree that solving the issue is possible.
sure and I never said something different and we started working on it.
My point was more that I didn't put this in relation with the
graduation. And I never argued in a way to increase any pressure to
influence a decision or vote. It's fine to raise concerns and even
better to start work on solving the underlying issues.
Juergen
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Jürgen;
Let me clarify some issues too ...
On 05/31/12 10:39, Jürgen Schmidt wrote:
> ...
> let me explain some details here because I think they can help to
> understand.
>
> 1. we have dependencies to several external libraries including
> category-b for some features
> 2. we have checked in all this source tar-balls in ext_sources for
> convenience and to ensure that they are always available. Another option
> would have been to host them somewhere else on extras or any other
> reliable server. We use the easier way for convenience reasons I think.
> 3. our source release don't contain any category-b source tar-balls
First of all we should clarify what a source release is in this context.
Does our source release contain Category-A tarballs? In other
words, does this file:
http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
Build on it's own? Or are developers/builders expected to download
more tarballs from SVN.
> 4. from a source release perspective we don't make use of any category-b
> stuff per default. A user have to explicitly trigger the use of
> category-b stuff and related features. The tar-balls are downloaded on
> demand, some kind of dependency mechanism if you want.
So if we remove the Category-B tarballs from SVN the default
build doesn't break, this is important. Now.. if the tarballs are
downloaded on demand, are you meaning those are downloaded from
SVN? (It's an honest question: I normally checkout all the tree from
SVN, including the Category-B, tarballs so I haven't experienced the
on-demand part of it)
> 5. the download on demand is the same and I don't really see a
> difference between downloading the tar-balls from svn or any other place.
OK. Do note that doing a SVN checkout, as suggested in CWiki,
there's no easy way to exclude the category-B tarballs:
svn co https://svn.apache.org/repos/asf/incubator/ooo/trunk ooo
> 6. we agreed to upstream changes to external libs where possible and
> necessary. And we agreed to improve the workflow to use the tar-balls
> from their original source where possible over time and where we can
> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>
Yes. Most of them are just uninteresting upstream.
> It seems to be really an item for legal to decide if hosting the
> category-b tar-balls in svn is not allowed for convenience at all.
>
> Furthermore we agreed to accept and of course support the move to
> another server but it is important that we don't break our 3.4 release.
As you noted before, removing Category-B tarballs shouldn't break
the default build. But I will go further ahead with mentioning that
the 3.4 Release is theoretically broken already with the Lucene and
Apache Commons updates (the development branch is for
development, right?), and since no one complained people must be
getting the files from somewhere else.
> We also agreed to clean up as much as possible of the dependencies to
> category-b stuff over time. But that takes time and is a lot of work.
I admit this is very clear. I don't expect such development to be
a requirement for graduation but the transitory situation of a source
release that depends on carrying category-B tarballs in SVN now is
not really acceptable.
> We are also open for any other action that we have to take to be conform
> to existing policies.
>
> I think we have shown in the past that we take everything serious and
> address issues in time where possible.
>
I hope you agree that solving the issue is possible.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 5/31/12 2:30 PM, Ross Gardler wrote:
> On 31 May 2012 12:54, Andre Fischer <af...@a-w-f.de> wrote:
>> On 31.05.2012 03:45, Pedro Giffuni wrote:
>>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>
> ...
>
>>> You mean source distribution (tarballs) don't build on
>>> their own and depend on what we carry in SVN? Sounds
>>> like something is wrong.
>>
>>
>> It will still build but without the tar-balls there will be missing
>> features. And I think that missing features are much harder to explain to
>> end users than a clean license status.
>
> (NOTE: I am neither making nor implying judgement on the dispute here
> about category-b licenses, I'm just making some general observations)
>
> ASF projects release source artifacts for downstream users, not
> binaries for end users. Yes, many projects, such as AOO, choose to
> provide a service whereby binaries are released. Those binaries must
> conform to the ASF licensing policies and, in the case of category-b
> licensed libraries, we have more room for maneuver since distribution
> is in binary form. The AOO3.4 binary release was audited and deemed
> conformant. I don't think anyone is questioning this so lets leave
> binaries and end-user needs out of the discussion.
>
> The complexity arises when the project deems it necessary to maintain
> category-b licensed source code independently of the originating
> project. Most ASF projects do not concern themselves with these
> complexities because either:
>
> a) they are implemented in a cross platform language,
>
> b) they do not release binaries for multiple platforms (although they
> may provide links to third-party binary builds, e.g. Subversion)
>
> c) they only use libraries that are available on the platforms needed,
> working with the upstream projects where necessary
>
> (there may be other approaches in projects I'm not familiar with).
>
> Option a) is not possible here, so option b) or c) are the only ones
> needing consideration (other than asking for legal@ or IPMC guidance
> on alternatives).
>
> As a mentor I want this resolved before graduation can progress. It
> might turn out that the current solution is acceptable to legal@, it
> might turn out that it is not. I don't really care as long as we are
> clear that the AOO approach to managing its dependencies is acceptable
> from an ASF policy perspective. At the time of writing the only thing
> I am certain of is that I, and at least two other mentors, have
> expressed a desire to see this issue resolved.
let me explain some details here because I think they can help to
understand.
1. we have dependencies to several external libraries including
category-b for some features
2. we have checked in all this source tar-balls in ext_sources for
convenience and to ensure that they are always available. Another option
would have been to host them somewhere else on extras or any other
reliable server. We use the easier way for convenience reasons I think.
3. our source release don't contain any category-b source tar-balls
4. from a source release perspective we don't make use of any category-b
stuff per default. A user have to explicitly trigger the use of
category-b stuff and related features. The tar-balls are downloaded on
demand, some kind of dependency mechanism if you want.
5. the download on demand is the same and I don't really see a
difference between downloading the tar-balls from svn or any other place.
6. we agreed to upstream changes to external libs where possible and
necessary. And we agreed to improve the workflow to use the tar-balls
from their original source where possible over time and where we can
rely on the overall availability (e.g. dependencies to Apache libs, etc.)
It seems to be really an item for legal to decide if hosting the
category-b tar-balls in svn is not allowed for convenience at all.
Furthermore we agreed to accept and of course support the move to
another server but it is important that we don't break our 3.4 release.
We also agreed to clean up as much as possible of the dependencies to
category-b stuff over time. But that takes time and is a lot of work.
We are also open for any other action that we have to take to be conform
to existing policies.
I think we have shown in the past that we take everything serious and
address issues in time where possible.
Juergen
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Ross Gardler <rg...@opendirective.com>.
On 31 May 2012 12:54, Andre Fischer <af...@a-w-f.de> wrote:
> On 31.05.2012 03:45, Pedro Giffuni wrote:
>> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
...
>> You mean source distribution (tarballs) don't build on
>> their own and depend on what we carry in SVN? Sounds
>> like something is wrong.
>
>
> It will still build but without the tar-balls there will be missing
> features. And I think that missing features are much harder to explain to
> end users than a clean license status.
(NOTE: I am neither making nor implying judgement on the dispute here
about category-b licenses, I'm just making some general observations)
ASF projects release source artifacts for downstream users, not
binaries for end users. Yes, many projects, such as AOO, choose to
provide a service whereby binaries are released. Those binaries must
conform to the ASF licensing policies and, in the case of category-b
licensed libraries, we have more room for maneuver since distribution
is in binary form. The AOO3.4 binary release was audited and deemed
conformant. I don't think anyone is questioning this so lets leave
binaries and end-user needs out of the discussion.
The complexity arises when the project deems it necessary to maintain
category-b licensed source code independently of the originating
project. Most ASF projects do not concern themselves with these
complexities because either:
a) they are implemented in a cross platform language,
b) they do not release binaries for multiple platforms (although they
may provide links to third-party binary builds, e.g. Subversion)
c) they only use libraries that are available on the platforms needed,
working with the upstream projects where necessary
(there may be other approaches in projects I'm not familiar with).
Option a) is not possible here, so option b) or c) are the only ones
needing consideration (other than asking for legal@ or IPMC guidance
on alternatives).
As a mentor I want this resolved before graduation can progress. It
might turn out that the current solution is acceptable to legal@, it
might turn out that it is not. I don't really care as long as we are
clear that the AOO approach to managing its dependencies is acceptable
from an ASF policy perspective. At the time of writing the only thing
I am certain of is that I, and at least two other mentors, have
expressed a desire to see this issue resolved.
Ross
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Andre Fischer <af...@a-w-f.de>.
Hi Pedro,
On 31.05.2012 03:45, Pedro Giffuni wrote:
>
>
> --- Mer 30/5/12, Rob Weir<ro...@apache.org> ha scritto:
>
>>>
>>> So *NOW* you are admitting that those tarballs are
>> part
>>> of the Release??
>>>
>>
>> Not at all. But they are referenced from build
>> files. I hope this distinction is clear.
>
> No. If they are just referenced then we don't depend
> on having them there: we just have to replace the
> reference. A nice text file mentioning where to find
> them (ooo-exttas @ Apache Extras) *is* a reference.
>
>
>> Again, go back to the licensing page and the principles
>> stated there. This is not a crusade to eradicate
>> category-b code from the face of the earth.
>
> I didn'r say I am eradicating anything (yet), they just can't
> be in SVN.
Good. May plan is to use this opportunity to make the fetch_tarballs.sh
script handle more than one download site and be more fault tolerant.
Until then it is important that the tar-balls stay where they are,
regardless of their licenses.
>
> This is about making it clear to downstream
>> consumers what
>> the dependencies are, what obligations those dependencies
>> bring, and
>> to require an explicit, informed decision for the downstream
>> developer
>> to enable the use of category-b binaries. We
>> are doing all of that.
>>
>>> We don't have permission from legal@ to ship
>> Category-B
>>> sources .. that must be fixed .. with axe.
I don't agree for several reasons which all have been discussed to some
length.
>>>
>>
>> Put the axe away, Pedro. As you know,
>> category-b code is not
>> included in the release. We already went through the
>> audit on that.
>>
>
> There was no audit. Mr RAT never examined those and we
> discussed this was a temporary situation.
>
>> In case it is not clear, I'll veto any attempt by you to
>> break the 3.4 source distributions.
+1
But I am afraid that this has already happened (see below.)
>>
>
> You mean source distribution (tarballs) don't build on
> their own and depend on what we carry in SVN? Sounds
> like something is wrong.
It will still build but without the tar-balls there will be missing
features. And I think that missing features are much harder to explain
to end users than a clean license status.
>
> Well ... those files are not required by default for
> the build, they are only optionally used and we did it
> on purpose so as long as we make a small adjustment in
> the buildbots I don't see what you can veto about it.
>
> And while you are so brave about vetoing hypothetical
> issues ... I already axed a couple of tarballs from the
> old Apache commons and Lucene. Have fun putting them
> back :-P.
Good that you mention this, but not so good that you did it. Someone
(you, me or someone else) will have to recover the old versions of these
libraries.
Without the previous versions in trunk the ooo.lst file in the (source)
release points to files that are not there anymore. configure should be
able to handle this but will disable some features.
Pedro, I understand that you don't like the category-B libraries. I
agree that we should try to get rid of them. But I think that we should
do this more carefully. Breaking existing releases is a bad thing.
Losing features in coming releases is also a bad thing.
Regards,
Andre
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Mer 30/5/12, Rob Weir <ro...@apache.org> ha scritto:
> >
> > So *NOW* you are admitting that those tarballs are
> part
> > of the Release??
> >
>
> Not at all. But they are referenced from build
> files. I hope this distinction is clear.
No. If they are just referenced then we don't depend
on having them there: we just have to replace the
reference. A nice text file mentioning where to find
them (ooo-exttas @ Apache Extras) *is* a reference.
> Again, go back to the licensing page and the principles
> stated there. This is not a crusade to eradicate
> category-b code from the face of the earth.
I didn'r say I am eradicating anything (yet), they just can't
be in SVN.
This is about making it clear to downstream
> consumers what
> the dependencies are, what obligations those dependencies
> bring, and
> to require an explicit, informed decision for the downstream
> developer
> to enable the use of category-b binaries. We
> are doing all of that.
>
> > We don't have permission from legal@ to ship
> Category-B
> > sources .. that must be fixed .. with axe.
> >
>
> Put the axe away, Pedro. As you know,
> category-b code is not
> included in the release. We already went through the
> audit on that.
>
There was no audit. Mr RAT never examined those and we
discussed this was a temporary situation.
> In case it is not clear, I'll veto any attempt by you to
> break the 3.4 source distributions.
>
You mean source distribution (tarballs) don't build on
their own and depend on what we carry in SVN? Sounds
like something is wrong.
Well ... those files are not required by default for
the build, they are only optionally used and we did it
on purpose so as long as we make a small adjustment in
the buildbots I don't see what you can veto about it.
And while you are so brave about vetoing hypothetical
issues ... I already axed a couple of tarballs from the
old Apache commons and Lucene. Have fun putting them
back :-P.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 30, 2012 at 6:04 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Oh boy ...
>
> --- Mer 30/5/12, Rob Weir <ro...@apache.org> ha scritto:
>
> ...
>>
>> You can copy the category-b binaries someplace else, but you
>> must not remove the ones that are already here. Otherwise you
>> will break not only the buildbots, but you will also break
>> every one who has downloaded the source from our 3.4
>> release.
>
> So *NOW* you are admitting that those tarballs are part
> of the Release??
>
Not at all. But they are referenced from build files. I hope this
distinction is clear. Remember, the build also references local
category-x files in the sense of Linux system dependencies. But
referencing them by name or directory or URL is not the same as
including them in a release. Sure you see this?
Again, go back to the licensing page and the principles stated there.
This is not a crusade to eradicate category-b code from the face of
the earth. This is about making it clear to downstream consumers what
the dependencies are, what obligations those dependencies bring, and
to require an explicit, informed decision for the downstream developer
to enable the use of category-b binaries. We are doing all of that.
> We don't have permission from legal@ to ship Category-B
> sources .. that must be fixed .. with axe.
>
Put the axe away, Pedro. As you know, category-b code is not
included in the release. We already went through the audit on that.
In case it is not clear, I'll veto any attempt by you to break the 3.4
source distributions.
-Rob
> Pedro.
>
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Posted by Pedro Giffuni <pf...@apache.org>.
Oh boy ...
--- Mer 30/5/12, Rob Weir <ro...@apache.org> ha scritto:
...
>
> You can copy the category-b binaries someplace else, but you
> must not remove the ones that are already here. Otherwise you
> will break not only the buildbots, but you will also break
> every one who has downloaded the source from our 3.4
> release.
So *NOW* you are admitting that those tarballs are part
of the Release??
We don't have permission from legal@ to ship Category-B
sources .. that must be fixed .. with axe.
Pedro.
Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
graduation process)
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 30, 2012 at 4:42 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Thanks Andre!
>
> On 05/30/12 04:34, Andre Fischer wrote:
>>
>> ...
>> But the binary builds have to come from somewhere. Unless we want to drop
>> the features for which we need category-B libraries then making it harder to
>> build them is IMHO not the right way to go.
>>
>> But maybe moving the offending libraries to another server would be a
>> first step? If you find a server and copy the files over then I am willing
>> to adapt the scripts accordingly.
>>
>
> I took your offer and I placed them here so we can play with them:
>
> http://code.google.com/a/apache-extras.org/p/ooo-extras/downloads/list
>
> (If any Apache committer wants access, like to add the mysql connector or
> the old wordperfect/buildreporter libraries, let me know in private your
> google-compatible address).
>
> I moved placed the OFL fonts there but IMHO those can stay as
> they are binaries. I think before removing the copyleft libraries
> from the server we should discontinue the category B flag in
> the buildbot (we can use it for releases of course).
>
You can copy the category-b binaries someplace else, but you must not
remove the ones that are already here. Otherwise you will break not
only the buildbots, but you will also break every one who has
downloaded the source from our 3.4 release. You'll need to wait for
a 3.4.1 release (at least) before you think of removing them. Or, as
an alternative, you could work with Infra on some redirect rules to
handle the requests for the 3.4.0 ext_sources.
And shouldn't the buldbots be building what we intend to release? I
could see alternating builds, with and without the category-b flag.
But the direction forward should be to enable te capability to spin
releases from the buildbots. Your suggestion would move us further
away from that.
-Rob
> Pedro.
>
Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation
process)
Posted by Pedro Giffuni <pf...@apache.org>.
Thanks Andre!
On 05/30/12 04:34, Andre Fischer wrote:
> ...
> But the binary builds have to come from somewhere. Unless we want to
> drop the features for which we need category-B libraries then making
> it harder to build them is IMHO not the right way to go.
>
> But maybe moving the offending libraries to another server would be a
> first step? If you find a server and copy the files over then I am
> willing to adapt the scripts accordingly.
>
I took your offer and I placed them here so we can play with them:
http://code.google.com/a/apache-extras.org/p/ooo-extras/downloads/list
(If any Apache committer wants access, like to add the mysql connector or
the old wordperfect/buildreporter libraries, let me know in private your
google-compatible address).
I moved placed the OFL fonts there but IMHO those can stay as
they are binaries. I think before removing the copyleft libraries
from the server we should discontinue the category B flag in
the buildbot (we can use it for releases of course).
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
--- Mer 30/5/12, Louis Suárez-Potts <lu...@gmail.com> ha scritto:
>
> On 2012-05-30, at 11:05 , Pedro Giffuni wrote:
>
> >
> > I will do this next week. I will probably use Apache
> extras and
> > at a later time we could leave there the old GPL'd
> stuff too
> > (unsupported of course).
> >
> > Pedro.
>
>
> A good solution, i'd guess, and thanks. but this leaves the
> obvious question, of timing and roadmaps (or equivalent).
> I'm not rushing or nagging, just curious.
>
IMO, just moving those files would put us in compliance with
Apache Policies. I wouldn't start the graduation process
before that is done but we can see what other preparations
are required.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Louis Suárez-Potts <lu...@gmail.com>.
On 2012-05-30, at 11:05 , Pedro Giffuni wrote:
>
> I will do this next week. I will probably use Apache extras and
> at a later time we could leave there the old GPL'd stuff too
> (unsupported of course).
>
> Pedro.
A good solution, i'd guess, and thanks. but this leaves the obvious question, of timing and roadmaps (or equivalent). I'm not rushing or nagging, just curious.
Louis
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Andre;
--- Mer 30/5/12, Andre Fischer <af...@a-w-f.de> ha scritto:
...
> >
> > The idea that we have remaining issues with Category-B
> > tarballs in the tree has been around since before the
> > release, and one of our mentors (Ross I recall) did
> > acknowledge my point of view.
> >
> > I did offer to step down then but I don't mean to make
> > a big issue out of this. If I step down it will be
> > communicated in the private list exclusively. I would
> > still be a committer and nothing would really change
> > for me.
> >
> > What I feel is disappointing is the lack of
> > acknowledgement that there *is* an issue. Category-B
> > software can be included in releases in binary form
> > but it should be otherwise actively discouraged, and
> in
> > general unsupported: it should not be included in the
> > buildbots and using it should be, in general terms, a
> > PITA.
>
> But the binary builds have to come from somewhere.
> Unless we want to drop the features for which we
> need category-B libraries then making it
> harder to build them is IMHO not the right way to go.
>
I have an idea: if you look at the stax api module,
there is an option to copy the binaries in a download
dir. This works very well for java libraries (saxon,
rhino, even beanshell).
Seamonkey we can probably live without.
The big problem is still Coin-MP: we really should have
the option to use the external library in configure.
> But maybe moving the offending libraries to another server
> would be a first step? If you find a server and copy the files
> over then I am willing to adapt the scripts accordingly.
>
I will do this next week. I will probably use Apache extras and
at a later time we could leave there the old GPL'd stuff too
(unsupported of course).
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Andre Fischer <af...@a-w-f.de>.
On 29.05.2012 20:29, Pedro Giffuni wrote:
> Hi Drew;
>
> --- Mar 29/5/12, drew<dr...@baseanswers.com> ha scritto:
>
> <snip>
>
>>>>>>>
>>>>> Yes the situation was specifically postponed as a graduation
>>>>> issue, I am not going through that discussion again.
>>>>>
>>>>> I made a concrete proposal with two alternatives:
>>>>>
>>>>> - They are moved to a friendly ftp/http site.
>>>>> - I step down from the PPMC to avoid the community
>>>>> the pain of a -1 vote.
>>>>
> ...
>>
>> Could be - it was just the way Pedro phrased his comment I
>> thought perhaps his thinking was being influenced by the
>> earlier remarks.
>>
>
> The idea that we have remaining issues with Category-B
> tarballs in the tree has been around since before the
> release, and one of our mentors (Ross I recall) did
> acknowledge my point of view.
>
> I did offer to step down then but I don't mean to make
> a big issue out of this. If I step down it will be
> communicated in the private list exclusively. I would
> still be a committer and nothing would really change
> for me.
>
> What I feel is disappointing is the lack of
> acknowledgement that there *is* an issue. Category-B
> software can be included in releases in binary form
> but it should be otherwise actively discouraged, and in
> general unsupported: it should not be included in the
> buildbots and using it should be, in general terms, a
> PITA.
But the binary builds have to come from somewhere. Unless we want to
drop the features for which we need category-B libraries then making it
harder to build them is IMHO not the right way to go.
But maybe moving the offending libraries to another server would be a
first step? If you find a server and copy the files over then I am
willing to adapt the scripts accordingly.
-Andre
>
> IMHO this project benefited greatly from the Category-X
> replacement and in general I would like the project to
> head in a direction that will lead to greater license
> and code simplification but the current situation where
> we work-around the policy issues instead of solving them
> is (again IMO) unacceptable.
>
> Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Drew;
--- Mar 29/5/12, drew <dr...@baseanswers.com> ha scritto:
<snip>
> > >> >>
>> >> Yes the situation was specifically postponed as a graduation
>> >> issue, I am not going through that discussion again.
>> >>
>> >> I made a concrete proposal with two alternatives:
>> >>
>> >> - They are moved to a friendly ftp/http site.
>> >> - I step down from the PPMC to avoid the community
>> >> the pain of a -1 vote.
>> >
...
>
> Could be - it was just the way Pedro phrased his comment I
> thought perhaps his thinking was being influenced by the
> earlier remarks.
>
The idea that we have remaining issues with Category-B
tarballs in the tree has been around since before the
release, and one of our mentors (Ross I recall) did
acknowledge my point of view.
I did offer to step down then but I don't mean to make
a big issue out of this. If I step down it will be
communicated in the private list exclusively. I would
still be a committer and nothing would really change
for me.
What I feel is disappointing is the lack of
acknowledgement that there *is* an issue. Category-B
software can be included in releases in binary form
but it should be otherwise actively discouraged, and in
general unsupported: it should not be included in the
buildbots and using it should be, in general terms, a
PITA.
IMHO this project benefited greatly from the Category-X
replacement and in general I would like the project to
head in a direction that will lead to greater license
and code simplification but the current situation where
we work-around the policy issues instead of solving them
is (again IMO) unacceptable.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by drew <dr...@baseanswers.com>.
On Tue, 2012-05-29 at 13:35 -0400, Rob Weir wrote:
> On Tue, May 29, 2012 at 1:18 PM, drew <dr...@baseanswers.com> wrote:
> > On Tue, 2012-05-29 at 13:15 -0400, Rob Weir wrote:
> >> On Tue, May 29, 2012 at 12:16 PM, drew <dr...@baseanswers.com> wrote:
> >> > On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
> >> >> On 05/28/12 14:25, Rob Weir wrote:
> >> >> > On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
> >> >> >> Hi Rob;
> >> >> >>
> >> >> >>
> >> >> >> On 05/28/12 13:10, Rob Weir wrote:
> >> >> >>> I'd like to start the graduation process, with the aim of being a TLP
> >> >> >>> in time for the 3.4.1 release.
> >> >> >>>
> >> >> >>> The IPMC has a "Guide to Successful Graduation" page with a lot of
> >> >> >>> detail and advice: http://incubator.apache.org/guides/graduation.html
> >> >> >>>
> >> >> >>> The calendar here is especially useful:
> >> >> >>> http://incubator.apache.org/guides/graduation.html#toplevel
> >> >> >>>
> >> >> >>> It shows 4 steps:
> >> >> >>>
> >> >> >>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
> >> >> >>>
> >> >> >>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
> >> >> >>> TLP
> >> >> >>>
> >> >> >>> 3) an IPMC vote on whether or not to recommend the podling for graduation
> >> >> >>>
> >> >> >>> 4) a vote by the ASF Board on a resolution creating the new TLP
> >> >> >>>
> >> >> >>> This thread is just a proposal. It is not the actual vote called for
> >> >> >>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> >> >> >>> for going ahead? If not, please list what pre-graduation tasks you
> >> >> >>> believe need to be done first.
> >> >> >>>
> >> >> >>> Thanks!
> >> >> >>>
> >> >> >>> -Rob
> >> >> >>
> >> >> >> A reminder of a small, but IMHO significant, technical issue:
> >> >> >>
> >> >> >> We do have to take the category-B tarballs out of the tree
> >> >> >> before graduation.
> >> >> >>
> >> >> > Do we? If I recall, there were multiple views on this and no
> >> >> > consensus. But you are welcome to make a concrete proposal.
> >> >>
> >> >> Yes the situation was specifically postponed as a graduation
> >> >> issue, I am not going through that discussion again.
> >> >>
> >> >> I made a concrete proposal with two alternatives:
> >> >>
> >> >> - They are moved to a friendly ftp/http site.
> >> >> - I step down from the PPMC to avoid the community
> >> >> the pain of a -1 vote.
> >> >
> >> > Please do not do the second - I know that someone was putting forward
> >> > the idea that a -1 vote on the first RC was enough to disqualify that
> >> > person from serving on the PMC but that was something that I can't
> >> > believe people in general would agree with.
> >> >
> >>
> >> A citation, please?
> >
> > Juergen talking about the fellow that didn't think a trranslation
> > (Finish I think it was) was up to date - if you want me to search the
> > archive I will but it is there.
> >
>
> OK. I think at that time some were under the impression that a -1 on
> a release vote was a veto. We now know that this is not the case.
>
Could be - it was just the way Pedro phrased his comment I thought
perhaps his thinking was being influenced by the earlier remarks.
Thanks
//drew
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 1:18 PM, drew <dr...@baseanswers.com> wrote:
> On Tue, 2012-05-29 at 13:15 -0400, Rob Weir wrote:
>> On Tue, May 29, 2012 at 12:16 PM, drew <dr...@baseanswers.com> wrote:
>> > On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
>> >> On 05/28/12 14:25, Rob Weir wrote:
>> >> > On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>> >> >> Hi Rob;
>> >> >>
>> >> >>
>> >> >> On 05/28/12 13:10, Rob Weir wrote:
>> >> >>> I'd like to start the graduation process, with the aim of being a TLP
>> >> >>> in time for the 3.4.1 release.
>> >> >>>
>> >> >>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> >> >>> detail and advice: http://incubator.apache.org/guides/graduation.html
>> >> >>>
>> >> >>> The calendar here is especially useful:
>> >> >>> http://incubator.apache.org/guides/graduation.html#toplevel
>> >> >>>
>> >> >>> It shows 4 steps:
>> >> >>>
>> >> >>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>> >> >>>
>> >> >>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>> >> >>> TLP
>> >> >>>
>> >> >>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>> >> >>>
>> >> >>> 4) a vote by the ASF Board on a resolution creating the new TLP
>> >> >>>
>> >> >>> This thread is just a proposal. It is not the actual vote called for
>> >> >>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> >> >>> for going ahead? If not, please list what pre-graduation tasks you
>> >> >>> believe need to be done first.
>> >> >>>
>> >> >>> Thanks!
>> >> >>>
>> >> >>> -Rob
>> >> >>
>> >> >> A reminder of a small, but IMHO significant, technical issue:
>> >> >>
>> >> >> We do have to take the category-B tarballs out of the tree
>> >> >> before graduation.
>> >> >>
>> >> > Do we? If I recall, there were multiple views on this and no
>> >> > consensus. But you are welcome to make a concrete proposal.
>> >>
>> >> Yes the situation was specifically postponed as a graduation
>> >> issue, I am not going through that discussion again.
>> >>
>> >> I made a concrete proposal with two alternatives:
>> >>
>> >> - They are moved to a friendly ftp/http site.
>> >> - I step down from the PPMC to avoid the community
>> >> the pain of a -1 vote.
>> >
>> > Please do not do the second - I know that someone was putting forward
>> > the idea that a -1 vote on the first RC was enough to disqualify that
>> > person from serving on the PMC but that was something that I can't
>> > believe people in general would agree with.
>> >
>>
>> A citation, please?
>
> Juergen talking about the fellow that didn't think a trranslation
> (Finish I think it was) was up to date - if you want me to search the
> archive I will but it is there.
>
OK. I think at that time some were under the impression that a -1 on
a release vote was a veto. We now know that this is not the case.
> //drew
>
>>
>> >
>> >
>> >>
>> >> Pedro.
>> >>
>> >
>> >
>>
>
>
Re: [PROPOSAL] Starting the graduation process
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 5/29/12 7:18 PM, drew wrote:
> On Tue, 2012-05-29 at 13:15 -0400, Rob Weir wrote:
>> On Tue, May 29, 2012 at 12:16 PM, drew<dr...@baseanswers.com> wrote:
>>> On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
>>>> On 05/28/12 14:25, Rob Weir wrote:
>>>>> On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>>>>> Hi Rob;
>>>>>>
>>>>>>
>>>>>> On 05/28/12 13:10, Rob Weir wrote:
>>>>>>> I'd like to start the graduation process, with the aim of being a TLP
>>>>>>> in time for the 3.4.1 release.
>>>>>>>
>>>>>>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>>>>>>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>>>>>>
>>>>>>> The calendar here is especially useful:
>>>>>>> http://incubator.apache.org/guides/graduation.html#toplevel
>>>>>>>
>>>>>>> It shows 4 steps:
>>>>>>>
>>>>>>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>>>>>>
>>>>>>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>>>>>>> TLP
>>>>>>>
>>>>>>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>>>>>>
>>>>>>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>>>>>>
>>>>>>> This thread is just a proposal. It is not the actual vote called for
>>>>>>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>>>>>>> for going ahead? If not, please list what pre-graduation tasks you
>>>>>>> believe need to be done first.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> -Rob
>>>>>>
>>>>>> A reminder of a small, but IMHO significant, technical issue:
>>>>>>
>>>>>> We do have to take the category-B tarballs out of the tree
>>>>>> before graduation.
>>>>>>
>>>>> Do we? If I recall, there were multiple views on this and no
>>>>> consensus. But you are welcome to make a concrete proposal.
>>>>
>>>> Yes the situation was specifically postponed as a graduation
>>>> issue, I am not going through that discussion again.
>>>>
>>>> I made a concrete proposal with two alternatives:
>>>>
>>>> - They are moved to a friendly ftp/http site.
>>>> - I step down from the PPMC to avoid the community
>>>> the pain of a -1 vote.
>>>
>>> Please do not do the second - I know that someone was putting forward
>>> the idea that a -1 vote on the first RC was enough to disqualify that
>>> person from serving on the PMC but that was something that I can't
>>> believe people in general would agree with.
>>>
>>
>> A citation, please?
>
> Juergen talking about the fellow that didn't think a trranslation
> (Finish I think it was) was up to date - if you want me to search the
> archive I will but it is there.
it was indeed a misunderstanding and I indeed didn't understand the
voting of -1 at this time. But putting it in this context is really not
correct. I welcome everybody in the PMC. In this special case I tried to
highlight that the common project goal should be higher rated than
personal ones. But probably I wasn't able to find the correct words to
explain it ;-)
Juergen
>
> //drew
>
>>
>>>
>>>
>>>>
>>>> Pedro.
>>>>
>>>
>>>
>>
>
>
Re: [PROPOSAL] Starting the graduation process
Posted by drew <dr...@baseanswers.com>.
On Tue, 2012-05-29 at 13:15 -0400, Rob Weir wrote:
> On Tue, May 29, 2012 at 12:16 PM, drew <dr...@baseanswers.com> wrote:
> > On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
> >> On 05/28/12 14:25, Rob Weir wrote:
> >> > On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
> >> >> Hi Rob;
> >> >>
> >> >>
> >> >> On 05/28/12 13:10, Rob Weir wrote:
> >> >>> I'd like to start the graduation process, with the aim of being a TLP
> >> >>> in time for the 3.4.1 release.
> >> >>>
> >> >>> The IPMC has a "Guide to Successful Graduation" page with a lot of
> >> >>> detail and advice: http://incubator.apache.org/guides/graduation.html
> >> >>>
> >> >>> The calendar here is especially useful:
> >> >>> http://incubator.apache.org/guides/graduation.html#toplevel
> >> >>>
> >> >>> It shows 4 steps:
> >> >>>
> >> >>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
> >> >>>
> >> >>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
> >> >>> TLP
> >> >>>
> >> >>> 3) an IPMC vote on whether or not to recommend the podling for graduation
> >> >>>
> >> >>> 4) a vote by the ASF Board on a resolution creating the new TLP
> >> >>>
> >> >>> This thread is just a proposal. It is not the actual vote called for
> >> >>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> >> >>> for going ahead? If not, please list what pre-graduation tasks you
> >> >>> believe need to be done first.
> >> >>>
> >> >>> Thanks!
> >> >>>
> >> >>> -Rob
> >> >>
> >> >> A reminder of a small, but IMHO significant, technical issue:
> >> >>
> >> >> We do have to take the category-B tarballs out of the tree
> >> >> before graduation.
> >> >>
> >> > Do we? If I recall, there were multiple views on this and no
> >> > consensus. But you are welcome to make a concrete proposal.
> >>
> >> Yes the situation was specifically postponed as a graduation
> >> issue, I am not going through that discussion again.
> >>
> >> I made a concrete proposal with two alternatives:
> >>
> >> - They are moved to a friendly ftp/http site.
> >> - I step down from the PPMC to avoid the community
> >> the pain of a -1 vote.
> >
> > Please do not do the second - I know that someone was putting forward
> > the idea that a -1 vote on the first RC was enough to disqualify that
> > person from serving on the PMC but that was something that I can't
> > believe people in general would agree with.
> >
>
> A citation, please?
Juergen talking about the fellow that didn't think a trranslation
(Finish I think it was) was up to date - if you want me to search the
archive I will but it is there.
//drew
>
> >
> >
> >>
> >> Pedro.
> >>
> >
> >
>
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 12:16 PM, drew <dr...@baseanswers.com> wrote:
> On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
>> On 05/28/12 14:25, Rob Weir wrote:
>> > On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>> >> Hi Rob;
>> >>
>> >>
>> >> On 05/28/12 13:10, Rob Weir wrote:
>> >>> I'd like to start the graduation process, with the aim of being a TLP
>> >>> in time for the 3.4.1 release.
>> >>>
>> >>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> >>> detail and advice: http://incubator.apache.org/guides/graduation.html
>> >>>
>> >>> The calendar here is especially useful:
>> >>> http://incubator.apache.org/guides/graduation.html#toplevel
>> >>>
>> >>> It shows 4 steps:
>> >>>
>> >>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>> >>>
>> >>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>> >>> TLP
>> >>>
>> >>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>> >>>
>> >>> 4) a vote by the ASF Board on a resolution creating the new TLP
>> >>>
>> >>> This thread is just a proposal. It is not the actual vote called for
>> >>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> >>> for going ahead? If not, please list what pre-graduation tasks you
>> >>> believe need to be done first.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> -Rob
>> >>
>> >> A reminder of a small, but IMHO significant, technical issue:
>> >>
>> >> We do have to take the category-B tarballs out of the tree
>> >> before graduation.
>> >>
>> > Do we? If I recall, there were multiple views on this and no
>> > consensus. But you are welcome to make a concrete proposal.
>>
>> Yes the situation was specifically postponed as a graduation
>> issue, I am not going through that discussion again.
>>
>> I made a concrete proposal with two alternatives:
>>
>> - They are moved to a friendly ftp/http site.
>> - I step down from the PPMC to avoid the community
>> the pain of a -1 vote.
>
> Please do not do the second - I know that someone was putting forward
> the idea that a -1 vote on the first RC was enough to disqualify that
> person from serving on the PMC but that was something that I can't
> believe people in general would agree with.
>
A citation, please?
>
>
>>
>> Pedro.
>>
>
>
Re: [PROPOSAL] Starting the graduation process
Posted by drew <dr...@baseanswers.com>.
On Mon, 2012-05-28 at 14:50 -0500, Pedro Giffuni wrote:
> On 05/28/12 14:25, Rob Weir wrote:
> > On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
> >> Hi Rob;
> >>
> >>
> >> On 05/28/12 13:10, Rob Weir wrote:
> >>> I'd like to start the graduation process, with the aim of being a TLP
> >>> in time for the 3.4.1 release.
> >>>
> >>> The IPMC has a "Guide to Successful Graduation" page with a lot of
> >>> detail and advice: http://incubator.apache.org/guides/graduation.html
> >>>
> >>> The calendar here is especially useful:
> >>> http://incubator.apache.org/guides/graduation.html#toplevel
> >>>
> >>> It shows 4 steps:
> >>>
> >>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
> >>>
> >>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
> >>> TLP
> >>>
> >>> 3) an IPMC vote on whether or not to recommend the podling for graduation
> >>>
> >>> 4) a vote by the ASF Board on a resolution creating the new TLP
> >>>
> >>> This thread is just a proposal. It is not the actual vote called for
> >>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> >>> for going ahead? If not, please list what pre-graduation tasks you
> >>> believe need to be done first.
> >>>
> >>> Thanks!
> >>>
> >>> -Rob
> >>
> >> A reminder of a small, but IMHO significant, technical issue:
> >>
> >> We do have to take the category-B tarballs out of the tree
> >> before graduation.
> >>
> > Do we? If I recall, there were multiple views on this and no
> > consensus. But you are welcome to make a concrete proposal.
>
> Yes the situation was specifically postponed as a graduation
> issue, I am not going through that discussion again.
>
> I made a concrete proposal with two alternatives:
>
> - They are moved to a friendly ftp/http site.
> - I step down from the PPMC to avoid the community
> the pain of a -1 vote.
Please do not do the second - I know that someone was putting forward
the idea that a -1 vote on the first RC was enough to disqualify that
person from serving on the PMC but that was something that I can't
believe people in general would agree with.
>
> Pedro.
>
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
On 05/28/12 14:25, Rob Weir wrote:
> On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni<pf...@apache.org> wrote:
>> Hi Rob;
>>
>>
>> On 05/28/12 13:10, Rob Weir wrote:
>>> I'd like to start the graduation process, with the aim of being a TLP
>>> in time for the 3.4.1 release.
>>>
>>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>>
>>> The calendar here is especially useful:
>>> http://incubator.apache.org/guides/graduation.html#toplevel
>>>
>>> It shows 4 steps:
>>>
>>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>>
>>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>>> TLP
>>>
>>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>>
>>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>>
>>> This thread is just a proposal. It is not the actual vote called for
>>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>>> for going ahead? If not, please list what pre-graduation tasks you
>>> believe need to be done first.
>>>
>>> Thanks!
>>>
>>> -Rob
>>
>> A reminder of a small, but IMHO significant, technical issue:
>>
>> We do have to take the category-B tarballs out of the tree
>> before graduation.
>>
> Do we? If I recall, there were multiple views on this and no
> consensus. But you are welcome to make a concrete proposal.
Yes the situation was specifically postponed as a graduation
issue, I am not going through that discussion again.
I made a concrete proposal with two alternatives:
- They are moved to a friendly ftp/http site.
- I step down from the PPMC to avoid the community
the pain of a -1 vote.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 28, 2012 at 2:45 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Rob;
>
>
> On 05/28/12 13:10, Rob Weir wrote:
>>
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>>
>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>
>> The calendar here is especially useful:
>> http://incubator.apache.org/guides/graduation.html#toplevel
>>
>> It shows 4 steps:
>>
>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>
>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>> TLP
>>
>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>
>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>
>> This thread is just a proposal. It is not the actual vote called for
>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> for going ahead? If not, please list what pre-graduation tasks you
>> believe need to be done first.
>>
>> Thanks!
>>
>> -Rob
>
>
> A reminder of a small, but IMHO significant, technical issue:
>
> We do have to take the category-B tarballs out of the tree
> before graduation.
>
Do we? If I recall, there were multiple views on this and no
consensus. But you are welcome to make a concrete proposal.
> In general we should also clear out any other unclear
> content .. so I am not sure what to say about the
> Symphony code since it also contains some code
> that has not been fully IP reviewed.
>
Receiving and processing software grants is an ongoing responsibility
of TLP's. So the fact that we are working on processing an additional
grant, beyond the initial OpenOffice one, is not a graduation issue.
> Pedro.
>
Re: [PROPOSAL] Starting the graduation process
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Rob;
On 05/28/12 13:10, Rob Weir wrote:
> I'd like to start the graduation process, with the aim of being a TLP
> in time for the 3.4.1 release.
>
> The IPMC has a "Guide to Successful Graduation" page with a lot of
> detail and advice: http://incubator.apache.org/guides/graduation.html
>
> The calendar here is especially useful:
> http://incubator.apache.org/guides/graduation.html#toplevel
>
> It shows 4 steps:
>
> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>
> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>
> 3) an IPMC vote on whether or not to recommend the podling for graduation
>
> 4) a vote by the ASF Board on a resolution creating the new TLP
>
> This thread is just a proposal. It is not the actual vote called for
> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> for going ahead? If not, please list what pre-graduation tasks you
> believe need to be done first.
>
> Thanks!
>
> -Rob
A reminder of a small, but IMHO significant, technical issue:
We do have to take the category-B tarballs out of the tree
before graduation.
In general we should also clear out any other unclear
content .. so I am not sure what to say about the
Symphony code since it also contains some code
that has not been fully IP reviewed.
Pedro.
Re: [PROPOSAL] Starting the graduation process
Posted by Dave Fisher <da...@comcast.net>.
Sent from my iPhone
On May 31, 2012, at 10:15 AM, Ross Gardler <rg...@opendirective.com> wrote:
> On 31 May 2012 15:01, Rob Weir <ro...@apache.org> wrote:
>> On Thu, May 31, 2012 at 9:00 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 28 May 2012 19:10, Rob Weir <ro...@apache.org> wrote:
>>> There is one particularly nasty job left to do - decide who will be in
>>> the PMC upon graduation and who will not. In the past I have
>>> volunteered to do this. I will compile a list of people I recommend
>>> should be a part of the PPMC and will post this for consideration. I
>>> will not take kindly to anyone contacting me offlist to make a case
>>> for or against any individuals, so please don't bother. Wait until I
>>> post the list here.
>>>
>>
>> It is good to have someone neutral do this, so thanks.
>
> Yes, that's what I figured, and why I am volunteering myself. .
>
>> I assume you
>> will take care to look at contributions as recorded in SVN commits,
>> but also forums, translations, Bugzilla, and other areas.
>
> I will do my best to consider all forms of contribution through
> official community channels. However, I am not infallible. My initial
> list will be an opportunity to explore and validate my process. It
> will not be the final list, that will be drawn up after the PPMC have
> an opportunity to feed back.
>
> Note, it is *not* my intention to make any kind of quality assessment
> of peoples contributions. I'm only interested in whether people are
> sufficiently *active* to warrant full privileges in the PMC. Exactly
> what "sufficiently active" means at this point is unclear. Each
> project has a different bar for PMC membership and we'll find that bar
> through evaluation of my initial list and process. I imagine the whole
> process will take a number of weeks.
Thank you!
Regards,
Dave
>
> Ross
Re: [PROPOSAL] Starting the graduation process
Posted by Ross Gardler <rg...@opendirective.com>.
On 31 May 2012 15:01, Rob Weir <ro...@apache.org> wrote:
> On Thu, May 31, 2012 at 9:00 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 28 May 2012 19:10, Rob Weir <ro...@apache.org> wrote:
>> There is one particularly nasty job left to do - decide who will be in
>> the PMC upon graduation and who will not. In the past I have
>> volunteered to do this. I will compile a list of people I recommend
>> should be a part of the PPMC and will post this for consideration. I
>> will not take kindly to anyone contacting me offlist to make a case
>> for or against any individuals, so please don't bother. Wait until I
>> post the list here.
>>
>
> It is good to have someone neutral do this, so thanks.
Yes, that's what I figured, and why I am volunteering myself. .
> I assume you
> will take care to look at contributions as recorded in SVN commits,
> but also forums, translations, Bugzilla, and other areas.
I will do my best to consider all forms of contribution through
official community channels. However, I am not infallible. My initial
list will be an opportunity to explore and validate my process. It
will not be the final list, that will be drawn up after the PPMC have
an opportunity to feed back.
Note, it is *not* my intention to make any kind of quality assessment
of peoples contributions. I'm only interested in whether people are
sufficiently *active* to warrant full privileges in the PMC. Exactly
what "sufficiently active" means at this point is unclear. Each
project has a different bar for PMC membership and we'll find that bar
through evaluation of my initial list and process. I imagine the whole
process will take a number of weeks.
Ross
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Thu, May 31, 2012 at 9:00 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 28 May 2012 19:10, Rob Weir <ro...@apache.org> wrote:
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>
> Speaking as a mentor...
>
> I want to see clarity on the category-b issue. I've commented
> elsewhere and hope to see progress there. Since so many people here
> are convinced that the current solution is OK then why doesn't someone
> do exactly as Rob suggests later in this thread and get a
> clarification of the policy? It would take far less time than arguing
> about it.
>
> This is the only blocker I see for graduation at this time.
>
I agree this needs to be resolved. If we have even one person on the
PPMC with concerns about our current approach there is a reasonable
chance that there will be at least one person on the IPMC with similar
concerns. It doesn't mean what we're doing is necessarily wrong. It
just means that it is not sufficiently obvious that what we're doing
is right.
> There is one particularly nasty job left to do - decide who will be in
> the PMC upon graduation and who will not. In the past I have
> volunteered to do this. I will compile a list of people I recommend
> should be a part of the PPMC and will post this for consideration. I
> will not take kindly to anyone contacting me offlist to make a case
> for or against any individuals, so please don't bother. Wait until I
> post the list here.
>
It is good to have someone neutral do this, so thanks. I assume you
will take care to look at contributions as recorded in SVN commits,
but also forums, translations, Bugzilla, and other areas.
> Ross
>
>
>>
>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>
>> The calendar here is especially useful:
>> http://incubator.apache.org/guides/graduation.html#toplevel
>>
>> It shows 4 steps:
>>
>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>
>> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>>
>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>
>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>
>> This thread is just a proposal. It is not the actual vote called for
>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> for going ahead? If not, please list what pre-graduation tasks you
>> believe need to be done first.
>>
>> Thanks!
>>
>> -Rob
>
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
Re: [PROPOSAL] Starting the graduation process
Posted by Ross Gardler <rg...@opendirective.com>.
On 28 May 2012 19:10, Rob Weir <ro...@apache.org> wrote:
> I'd like to start the graduation process, with the aim of being a TLP
> in time for the 3.4.1 release.
Speaking as a mentor...
I want to see clarity on the category-b issue. I've commented
elsewhere and hope to see progress there. Since so many people here
are convinced that the current solution is OK then why doesn't someone
do exactly as Rob suggests later in this thread and get a
clarification of the policy? It would take far less time than arguing
about it.
This is the only blocker I see for graduation at this time.
There is one particularly nasty job left to do - decide who will be in
the PMC upon graduation and who will not. In the past I have
volunteered to do this. I will compile a list of people I recommend
should be a part of the PPMC and will post this for consideration. I
will not take kindly to anyone contacting me offlist to make a case
for or against any individuals, so please don't bother. Wait until I
post the list here.
Ross
>
> The IPMC has a "Guide to Successful Graduation" page with a lot of
> detail and advice: http://incubator.apache.org/guides/graduation.html
>
> The calendar here is especially useful:
> http://incubator.apache.org/guides/graduation.html#toplevel
>
> It shows 4 steps:
>
> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>
> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>
> 3) an IPMC vote on whether or not to recommend the podling for graduation
>
> 4) a vote by the ASF Board on a resolution creating the new TLP
>
> This thread is just a proposal. It is not the actual vote called for
> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> for going ahead? If not, please list what pre-graduation tasks you
> believe need to be done first.
>
> Thanks!
>
> -Rob
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: [PROPOSAL] Starting the graduation process
Posted by Wolf Halton <wo...@gmail.com>.
+1 to start graduation process.
To me it seems that just as in an apprenticeship system, graduation does
not imply perfection or mastery of the endeavour, but readiness to attempt
journeyman-level work.
Wolf
http://evergreen-community-01.lyrasistechnology.org
http://sourcefreedom.com
Apache developer:
wolfhalton@apache.org
On Jun 1, 2012 12:31 PM, "Kay Schenk" <ka...@gmail.com> wrote:
>
>
> On 05/31/2012 03:27 PM, Phillip Rhodes wrote:
>
>> On Mon, May 28, 2012 at 1:10 PM, Rob Weir<ro...@apache.org> wrote:
>>
>>> I'd like to start the graduation process, with the aim of being a TLP
>>> in time for the 3.4.1 release.
>>>
>>>
>> If, by and large, folks thing we're ready to graduate, then yes, let's
>> get the process started. I personally wouldn't emphasize tying
>> graduation to a specific release though. If there has to be another
>> "-incubating" release, I wouldn't consider that the end of the world.
>>
>>
>> Phil
>>
>
> +1 from me on starting the graduation process and Phil's assessment above.
>
>
>
>
> --
> ------------------------------**------------------------------**
> ------------
> MzK
>
> "So let it rock, let it roll
> Let the bible belt come and save my soul
> Hold on to sixteen as long as you can
> Changes come around real soon make us woman and men."
> -- "Jack and Diane", John Mellencamp
>
Re: [PROPOSAL] Starting the graduation process
Posted by Kay Schenk <ka...@gmail.com>.
On 05/31/2012 03:27 PM, Phillip Rhodes wrote:
> On Mon, May 28, 2012 at 1:10 PM, Rob Weir<ro...@apache.org> wrote:
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>>
>
> If, by and large, folks thing we're ready to graduate, then yes, let's
> get the process started. I personally wouldn't emphasize tying
> graduation to a specific release though. If there has to be another
> "-incubating" release, I wouldn't consider that the end of the world.
>
>
> Phil
+1 from me on starting the graduation process and Phil's assessment above.
--
------------------------------------------------------------------------
MzK
"So let it rock, let it roll
Let the bible belt come and save my soul
Hold on to sixteen as long as you can
Changes come around real soon make us woman and men."
-- "Jack and Diane", John Mellencamp
Re: [PROPOSAL] Starting the graduation process
Posted by Phillip Rhodes <mo...@gmail.com>.
On Mon, May 28, 2012 at 1:10 PM, Rob Weir <ro...@apache.org> wrote:
> I'd like to start the graduation process, with the aim of being a TLP
> in time for the 3.4.1 release.
>
If, by and large, folks thing we're ready to graduate, then yes, let's
get the process started. I personally wouldn't emphasize tying
graduation to a specific release though. If there has to be another
"-incubating" release, I wouldn't consider that the end of the world.
Phil
Re: [PROPOSAL] Starting the graduation process
Posted by Yong Lin Ma <ma...@apache.org>.
My proposal is simple. Wait one or two months to see what we will get
for next release.
3.4.1 doesn't count to me. It is a must have when we get AOO 3.4 released.
On Wed, May 30, 2012 at 12:07 AM, Jürgen Schmidt
<jo...@googlemail.com> wrote:
> On 5/29/12 5:42 PM, Yong Lin Ma wrote:
>>
>> We are close to starting the graduation process. But I think we need
>> give the project more time to demonstrate the ability to
>>
>> Create an Apache Release
>
>
> I think the project have shown that it is able to act as TLP and that the
> project is able to manage project relevant issues in the Apache way.
>
>
>> AOO 3.4 is an real achievement. But the major issue it solved are due
>> to legal concerns. It has improvement in SVG just because we are
>> lucky to have Armin with us.
>> It is still early to say that the project is ready to get to next release.
>> We need at least
>> Close a couple of new feature cycles. Propose and discuss about new
>> features -> spec review -> design review -> implementation -> QE sign
>> off
>> See a steady defect fix rate.
>
>
> Our next planned release 3.4.1 will be a bug fix release only. No big new
> features are intended or planned for this release. Only important bug fixes
> + new translations. So I don't see really your point here.
>
> Graduation means that the project is able to self manage all project
> relevant issues in a proper way that is aligned with the Apache rules and
> the Apache way.
>
>
>>
>>
>> Create an Open and Diverse community
>> We need more committers. There still no committer from C2SC.
>
>
> sure we need more committers and that will be a steady and continuously
> process in the future. But do you want define a number of say 150 committers
> as boundary for a potential graduation? Probably not because it means
> nothing. We have committers who are not longer active here in the project
> and graduation would also mean that we are able to clean up some things.
>
> C2SC people should participate actively in the project and should talk about
> the things they are doing that other people get aware of it. Nothing special
> here, saying I will do is not enough but doing it will change things over
> time ;-)
>
> The important message is that we are ready to manage the project in the
> Apache way.
>
> We should focus on things that are potentially relevant for graduation and
> Pedro have raised his concern about the category-b libraries that are valid
> and we have indeed postponed the decision after our first release. We should
> now either simply move them or should clarify if it is ok to keep them in
> the repo from a legal perspective to be simply save here to address Pedro's
> concern.
>
> But in general I would support Rob's idea to start the graduation process
> now and address all relevant issues.
>
> Juergen
>
>
>
>
>>
>>
>> On Tue, May 29, 2012 at 2:10 AM, Rob Weir<ro...@apache.org> wrote:
>>>
>>> I'd like to start the graduation process, with the aim of being a TLP
>>> in time for the 3.4.1 release.
>>>
>>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>>
>>> The calendar here is especially useful:
>>> http://incubator.apache.org/guides/graduation.html#toplevel
>>>
>>> It shows 4 steps:
>>>
>>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate
>>> now
>>>
>>> 2) a discussion on ooo-dev leading to the draft of a charter for the new
>>> TLP
>>>
>>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>>
>>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>>
>>> This thread is just a proposal. It is not the actual vote called for
>>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>>> for going ahead? If not, please list what pre-graduation tasks you
>>> believe need to be done first.
>>>
>>> Thanks!
>>>
>>> -Rob
>
>
Re: [PROPOSAL] Starting the graduation process
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 5/29/12 5:42 PM, Yong Lin Ma wrote:
> We are close to starting the graduation process. But I think we need
> give the project more time to demonstrate the ability to
>
> Create an Apache Release
I think the project have shown that it is able to act as TLP and that
the project is able to manage project relevant issues in the Apache way.
> AOO 3.4 is an real achievement. But the major issue it solved are due
> to legal concerns. It has improvement in SVG just because we are
> lucky to have Armin with us.
> It is still early to say that the project is ready to get to next release.
> We need at least
> Close a couple of new feature cycles. Propose and discuss about new
> features -> spec review -> design review -> implementation -> QE sign
> off
> See a steady defect fix rate.
Our next planned release 3.4.1 will be a bug fix release only. No big
new features are intended or planned for this release. Only important
bug fixes + new translations. So I don't see really your point here.
Graduation means that the project is able to self manage all project
relevant issues in a proper way that is aligned with the Apache rules
and the Apache way.
>
>
> Create an Open and Diverse community
> We need more committers. There still no committer from C2SC.
sure we need more committers and that will be a steady and continuously
process in the future. But do you want define a number of say 150
committers as boundary for a potential graduation? Probably not because
it means nothing. We have committers who are not longer active here in
the project and graduation would also mean that we are able to clean up
some things.
C2SC people should participate actively in the project and should talk
about the things they are doing that other people get aware of it.
Nothing special here, saying I will do is not enough but doing it will
change things over time ;-)
The important message is that we are ready to manage the project in the
Apache way.
We should focus on things that are potentially relevant for graduation
and Pedro have raised his concern about the category-b libraries that
are valid and we have indeed postponed the decision after our first
release. We should now either simply move them or should clarify if it
is ok to keep them in the repo from a legal perspective to be simply
save here to address Pedro's concern.
But in general I would support Rob's idea to start the graduation
process now and address all relevant issues.
Juergen
>
>
> On Tue, May 29, 2012 at 2:10 AM, Rob Weir<ro...@apache.org> wrote:
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>>
>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>
>> The calendar here is especially useful:
>> http://incubator.apache.org/guides/graduation.html#toplevel
>>
>> It shows 4 steps:
>>
>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>
>> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>>
>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>
>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>
>> This thread is just a proposal. It is not the actual vote called for
>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> for going ahead? If not, please list what pre-graduation tasks you
>> believe need to be done first.
>>
>> Thanks!
>>
>> -Rob
Re: [PROPOSAL] Starting the graduation process
Posted by Peter Junge <pe...@gmx.org>.
On 5/30/2012 12:13 AM, Rob Weir wrote:
> On Tue, May 29, 2012 at 11:42 AM, Yong Lin Ma<ma...@apache.org> wrote:
[...]
> Are there any contributions yet from C2SC? If there are, then by all
> means, review them and if they are of good quality, then propose them
> for becoming committers. It would be a graduation issue if we had
> volunteers making sustained contributions but we failed to make them
> committers. That would mean we were not open. But I don't see that
> happening.
>
I just found that we already have a PPMC member from CS2C. An Hongyun
joined us from the beginning while she was still working for RedFlag 2000.
An Hongyun,
looks like you have an important role now. I'm convinced you will do it
good.
Peter
Re: [PROPOSAL] Starting the graduation process
Posted by Peter Junge <pe...@gmx.org>.
On 5/30/2012 12:13 AM, Rob Weir wrote:
> On Tue, May 29, 2012 at 11:42 AM, Yong Lin Ma<ma...@apache.org> wrote:
[...]
>> Create an Open and Diverse community
>> We need more committers. There still no committer from C2SC.
>>
>
> Are there any contributions yet from C2SC? ...
Likely not. I've been meeting with some of the guys last week and
pointed them on some of the things they need to do to get started. If
necessary, I'll be available for further help.
Peter
Re: [PROPOSAL] Starting the graduation process
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 29, 2012 at 11:42 AM, Yong Lin Ma <ma...@apache.org> wrote:
> We are close to starting the graduation process. But I think we need
> give the project more time to demonstrate the ability to
>
> Create an Apache Release
> AOO 3.4 is an real achievement. But the major issue it solved are due
> to legal concerns. It has improvement in SVG just because we are
> lucky to have Armin with us.
> It is still early to say that the project is ready to get to next release.
> We need at least
> Close a couple of new feature cycles. Propose and discuss about new
> features -> spec review -> design review -> implementation -> QE sign
> off
> See a steady defect fix rate.
I think you misunderstand what Apache Incubation is. There is no
requirement that we first establish a "steady defect rate" or show
that we have a process for design reviews, or any other such project
technical concerns.
The two primary goals of incubation are:
1) Ensure the initial code contribution is reviewed and brought into
conformance with Apache policy. We did that.
2) Ensure that the community is working well, per The Apache Way and
other relevant Apache guidelines and policies. We're doing that.
With healthy code and a healthy community we'll naturally develop
additional processes within the project. That is a normal evolution
and part of any Top Level Project at Apache.
>
>
> Create an Open and Diverse community
> We need more committers. There still no committer from C2SC.
>
Are there any contributions yet from C2SC? If there are, then by all
means, review them and if they are of good quality, then propose them
for becoming committers. It would be a graduation issue if we had
volunteers making sustained contributions but we failed to make them
committers. That would mean we were not open. But I don't see that
happening.
>
> On Tue, May 29, 2012 at 2:10 AM, Rob Weir <ro...@apache.org> wrote:
>> I'd like to start the graduation process, with the aim of being a TLP
>> in time for the 3.4.1 release.
>>
>> The IPMC has a "Guide to Successful Graduation" page with a lot of
>> detail and advice: http://incubator.apache.org/guides/graduation.html
>>
>> The calendar here is especially useful:
>> http://incubator.apache.org/guides/graduation.html#toplevel
>>
>> It shows 4 steps:
>>
>> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>>
>> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>>
>> 3) an IPMC vote on whether or not to recommend the podling for graduation
>>
>> 4) a vote by the ASF Board on a resolution creating the new TLP
>>
>> This thread is just a proposal. It is not the actual vote called for
>> in #1 above. But I'd like to gauge current sentiment. Are we all +1
>> for going ahead? If not, please list what pre-graduation tasks you
>> believe need to be done first.
>>
>> Thanks!
>>
>> -Rob
Re: [PROPOSAL] Starting the graduation process
Posted by Yong Lin Ma <ma...@apache.org>.
We are close to starting the graduation process. But I think we need
give the project more time to demonstrate the ability to
Create an Apache Release
AOO 3.4 is an real achievement. But the major issue it solved are due
to legal concerns. It has improvement in SVG just because we are
lucky to have Armin with us.
It is still early to say that the project is ready to get to next release.
We need at least
Close a couple of new feature cycles. Propose and discuss about new
features -> spec review -> design review -> implementation -> QE sign
off
See a steady defect fix rate.
Create an Open and Diverse community
We need more committers. There still no committer from C2SC.
On Tue, May 29, 2012 at 2:10 AM, Rob Weir <ro...@apache.org> wrote:
> I'd like to start the graduation process, with the aim of being a TLP
> in time for the 3.4.1 release.
>
> The IPMC has a "Guide to Successful Graduation" page with a lot of
> detail and advice: http://incubator.apache.org/guides/graduation.html
>
> The calendar here is especially useful:
> http://incubator.apache.org/guides/graduation.html#toplevel
>
> It shows 4 steps:
>
> 1) a vote on ooo-dev (a community vote) on whether we want to graduate now
>
> 2) a discussion on ooo-dev leading to the draft of a charter for the new TLP
>
> 3) an IPMC vote on whether or not to recommend the podling for graduation
>
> 4) a vote by the ASF Board on a resolution creating the new TLP
>
> This thread is just a proposal. It is not the actual vote called for
> in #1 above. But I'd like to gauge current sentiment. Are we all +1
> for going ahead? If not, please list what pre-graduation tasks you
> believe need to be done first.
>
> Thanks!
>
> -Rob