+1
Now lets get back in topic. A maturity model starts at immature and works
towards mature. All views are allowed on that spectrum (the hard part is
agreeing where each view is but luckily the Apache Way defines much if that for
us)
Sent from my Windows Phone
On Tue, Jan 6, 2015 at 3:36 PM, Louis Suárez-Potts wrote:
>
> > On 6 Jan 2015, at 18:09, jan i wrote:
> >
> > On Wednesday, January 7, 2015, Ted Dunning
> wrote:
> >
> >> These are *open* source. Plotting strategy for marketing on a private
> list
> >> has no place in Apache projects. Private
> On 6 Jan 2015, at 18:09, jan i wrote:
>
> On Wednesday, January 7, 2015, Ted Dunning wrote:
>
>> These are *open* source. Plotting strategy for marketing on a private list
>> has no place in Apache projects. Private lists have very limited
>> appropriate uses and that policy has served Apa
On Wednesday, January 7, 2015, Ted Dunning wrote:
> These are *open* source. Plotting strategy for marketing on a private list
> has no place in Apache projects. Private lists have very limited
> appropriate uses and that policy has served Apache very well.
+1
jan i
>
>
>
> On Tue, Jan 6, 20
These are *open* source. Plotting strategy for marketing on a private list
has no place in Apache projects. Private lists have very limited
appropriate uses and that policy has served Apache very well.
On Tue, Jan 6, 2015 at 11:48 AM, Andrea Pescetti
wrote:
> On 06/01/2015 Daniel Gruno wrote
By the way, if anyone has any reason at all that one of the proposed
keynoters is going to be an embarrassment, *PLEASE* speak up sooner
rather than later, and don't be worried about hurting feelings.
Canceling a keynote at the last minute is a HUGE embarrassment, not to
mention cost, and if yo
It seems to me that the journalist practice of wanting confidential access
serves the interests of the journalist, not the project. I would simply deny
such requests and/or encourage the journalist to put questions on a public list.
With regard to "competitors," I just remind myself that forkin
I would add something about the build of the sources. Because having sources
without having a repeatable build or having no clue about how to build it, it
makes the sources quite useless.
I had some troubles recently with a project. Its build depends on a resource
which is not available anymore
On 06/01/2015 Tim Williams wrote:
On Tue, Jan 6, 2015 at 3:06 PM, Andrea Pescetti wrote:
The binaries OpenOffice makes available for download from its official site
are "convenience binaries" as per Bertrand's description. We are not going
to ask users to build it themselves!
We're heading off-
On Tue, Jan 6, 2015 at 2:12 PM, Marvin Humphrey
wrote:
> On Tue, Jan 6, 2015 at 11:16 AM, Mike Drob wrote:
>
> > How much of this is already covered by the Incubation process? Hopefully
> > projects don't revert to improper licensing or closed development after
> > they graduate.
>
> The absence
> On 6 Jan 2015, at 14:48, Andrea Pescetti wrote:
>
> On 06/01/2015 Daniel Gruno wrote:
>> projects unfortunately have a tendency to use their private lists for
>> much more than committer votes and security issues, which I find is bad
>> practice.
>
> If you as a project had a competitor, poss
On Tue, Jan 6, 2015 at 11:16 AM, Mike Drob wrote:
> How much of this is already covered by the Incubation process? Hopefully
> projects don't revert to improper licensing or closed development after
> they graduate.
The absence of clear documentation harms projects both during and after
incubati
On Tue, Jan 6, 2015 at 3:06 PM, Andrea Pescetti wrote:
> On 06/01/2015 Vincent Keunen wrote:
>>
>> On 2015-01-06 19:15, Bertrand Delacretaz wrote:
>>>
>>> convenience binaries are not Apache Releases.
>>
>> Let's not forget OpenOffice and the likes. Having all users compile the
>> source code *ma
On 06/01/2015 Vincent Keunen wrote:
On 2015-01-06 19:15, Bertrand Delacretaz wrote:
convenience binaries are not Apache Releases.
Let's not forget OpenOffice and the likes. Having all users compile the
source code *may* reduce the installed base. ;-)
The binaries OpenOffice makes available
On 06/01/2015 Daniel Gruno wrote:
projects unfortunately have a tendency to use their private lists for
much more than committer votes and security issues, which I find is bad
practice.
If you as a project had a competitor, possibly a proprietary one, would
you discuss marketing strategy in pu
On Tue, Jan 6, 2015 at 11:28 AM, Bertrand Delacretaz wrote:
> Hi,
>
> Creating such a model has been on my todo list for ages, and in a
> related discussion on board@ people seem to agree that having this can
> be useful.
>
> So let's start - here's my rough initial list of items:
>
> Code: open,
> On 6 Jan 2015, at 14:05, Vincent Keunen wrote:
>
>
> On 2015-01-06 19:15, Bertrand Delacretaz wrote:
>> Hi Marcel,
>>
>> On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
>> wrote:
>>> ...Since the only official releases *are* source releases the
>>> statement “source code only” probably app
On 6 January 2015 at 18:31, Bertrand Delacretaz wrote:
> On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno wrote:
>> ...How about a compromise:
>> distribution of releases and source: publicly, in a _consistent_ manner
>> according to foundation guidelines?...
>
> Works for me.
Does not work for me.
On 2015-01-06 19:15, Bertrand Delacretaz wrote:
Hi Marcel,
On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
wrote:
...Since the only official releases *are* source releases the
statement “source code only” probably applies to the source code
release, meaning that it should not contain any bin
On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno wrote:
> ...How about a compromise:
> distribution of releases and source: publicly, in a _consistent_ manner
> according to foundation guidelines?...
Works for me.
-Bertrand
On 2015-01-06 19:15, Bertrand Delacretaz wrote:
Hi Marcel,
On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
wrote:
...Since the only official releases *are* source releases the
statement “source code only” probably applies to the source code
release, meaning that it should not contain any bin
Hi Marcel,
On Tue, Jan 6, 2015 at 7:06 PM, Marcel Offermans
wrote:
> ...Since the only official releases *are* source releases the
> statement “source code only” probably applies to the source code
> release, meaning that it should not contain any binaries. Since
> convenience binaries are not of
On Tuesday, January 6, 2015, Daniel Gruno wrote:
>
> On 2015-01-06 18:53, Vincent Keunen wrote:
>
>> Good idea.
>>
>> I would just remove the "only" from "Releases: source code only". Maybe
>> say "Releases: source code at the minimum" ? It's not a problem to have
>> some projects also release b
On 6 Jan 2015 at 19:01:01, Daniel Gruno (humbed...@apache.org) wrote:
On 2015-01-06 18:53, Vincent Keunen wrote:
> Good idea.
>
> I would just remove the "only" from "Releases: source code only".
> Maybe say "Releases: source code at the minimum" ? It's not a problem
> to have some projects al
On 2015-01-06 18:53, Vincent Keunen wrote:
Good idea.
I would just remove the "only" from "Releases: source code only".
Maybe say "Releases: source code at the minimum" ? It's not a problem
to have some projects also release binaries, is it?
Releasing binaries have, to this point, always b
Good idea.
I would just remove the "only" from "Releases: source code only". Maybe
say "Releases: source code at the minimum" ? It's not a problem to have
some projects also release binaries, is it?
Shouldn't there be also something about a minimum documentation? Not
necessarily doc on sour
Hi,
Creating such a model has been on my todo list for ages, and in a
related discussion on board@ people seem to agree that having this can
be useful.
So let's start - here's my rough initial list of items:
Code: open, discoverable, fully public history, documented provenance
Quality: security,
thanks for the tip, I will get it corrected.
rgds
jan i
On Tuesday, January 6, 2015, Andrea Pescetti wrote:
> On 13/12/2014 jan i wrote:
>
>> The Travel Assistance Committee (TAC) are pleased to announce that travel
>> assistance applications for ApacheCon North America 2015 are now open! ...
>
On 13/12/2014 jan i wrote:
The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance applications for ApacheCon North America 2015 are now open! ...
http://www.apache.org/travel/
The passport/visa information on that page are still the ones for
Budapest and EU appare
29 matches
Mail list logo
