Mailing-List: contact dev-help@curator.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of echeddar@gmail.com designates
 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMUu0w88-ca9ftcKVSDkcs2O_BRCV0-PSmkVDiu_aFKcBOH5JQ@mail.gmail.com>
References: <F635F285-A487-4150-9BDB-C0AB240099A8@jordanzimmerman.com>
	<CAGU5spdnjCyj88VKRbLOH7HY9bhpf4jhcX+inirtBjD0VLm2UA@mail.gmail.com>
	<778C7DA1-70E6-4FC9-9229-FD70C938C0BC@jordanzimmerman.com>
	<CAGU5spfaf+uAZo+5W78ALxWjVOqpO_iDaeJOCZ8c9f=hJB3R6g@mail.gmail.com>
	<CAB8U+h3AaQVKRKdY33xY0Dz2QZuFs-GFJ60eMEmp=16y1iK1JQ@mail.gmail.com>
	<CAMUu0w88-ca9ftcKVSDkcs2O_BRCV0-PSmkVDiu_aFKcBOH5JQ@mail.gmail.com>
Date: Wed, 24 Jul 2013 23:17:29 -0700
Message-ID: 
 <CAB8U+h1UPobYvpZgdx7vy-c0NZhHa5J32xhL3UO961WMaHs3-g@mail.gmail.com>
Subject: Re: [VOTE] Graduate Curator from Apache Incubator
From: Eric Tschetter <echeddar@gmail.com>
To: "dev@curator.incubator.apache.org" <dev@curator.incubator.apache.org>
Content-Type: multipart/alternative; boundary=f46d044286e214712b04e24ffb35

--f46d044286e214712b04e24ffb35
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, July 24, 2013, Enis S=C3=B6ztutar wrote:

> On Wed, Jul 24, 2013 at 7:19 PM, Eric Tschetter <echeddar@gmail.com<javas=
cript:;>>
> wrote:
>
> > I don't know about Jordan's full motivations, but I can say from my
> > perspective it really sucked that I gave him a bunch of patches in earl=
y
> > April, they didn't get applied until May because we were waiting on a
> > release vote for 2.0.0, which was the exact same code as what was the
> most
> > current, stable version on github.  Then when we decided we were ready =
to
> > release the changes (prompted by a user wanting a fix in an artifact th=
ey
> > could actually depend on), we sat there for two weeks waiting on a
> release
> > vote from the mentors, who had to be prompted multiple times and I don'=
t
> > believe know the code or have any real understanding about whether it i=
s
> > fit for release.
> >
> > During that two weeks the code sat, it aged a bit like wine, except whe=
n
> we
> > uncorked it, it hadn't actually changed.
> >
>
> Eric, there is no technical reason why the commits have to be frozen whil=
e
> a release candidate is going on. You can just create a branch for the
> candidate release, and keep on committing to master branches.
>
> As one of the mentors, I am sorry to cause that. But remember that the
> mentors and other committers might have other duties and day jobs. The
> rational for 72 hours for the voting has been explained several times. It
> is there to give every body, and people in other time zones a chance to
> test and verify the release candidate.
>
>
> >
> > During this whole time from April, I maintained my own fork of the
> project
> > outside of apache with artifacts deployed to my own artifactory because=
 I
> > am not willing to slow down my development cycle.
> >
> > So far, my impression of the transfer to Apache is that it is now more
> > painful to actually get changes into a state where other things can
> depend
> > on them, which seems like the opposite of what you want to increase
> > adoption of a library.
> >
>
> This is a matter of using SCM correctly. Nothing is specific about Apache
> process. You can create as many branches as you need, and people can
> collaborate on these.


Perhaps there is miscommunication here.  I completely understand that I can
continue modifying the code in a branch, that is not the problem.  The
problem is that for my other projects to use my code I need a jar in maven.
 A jar in maven means I need a tag in SCM and that tag should be a proper
release artifact.

This is the way that my world operates right now.  We do not build from
source and include those dependencies, we declare dependencies on pre-built
artifacts that have a well-known tag backing them in case modifications
need to be made.  The way to make these artifacts is to cut a release.  A
release might have bugs, it might not be entirely correct, but it is a
frozen snapshot of the code with a well-known artifact built around it.
 The existence of bugs is less important because we use semantic versioning
to communicate the binary compatibility of the release.  Numbers are cheap,
slowing down development and progress is expensive.


>
> >
> > All of this is aside from the general feeling that its significantly mo=
re
> > difficult to actually interact with Apache infrastructure than GitHub,
> but
> > that won't be fixed by becoming a TLP.
> >
>
> That is generally true. Though, having seen many large projects (hadoop,
> lucene, hbase, etc) I think that it is not as bad.


The existence of people who have overcome some adversity is not an
indication that said adversity is (a) warranted or (b) a good thing.

That said, I will stick by Jordan in whichever decision he takes.  Curator
is a body of code that makes it easier to use ZK, I'll continue with it and
operate in whatever world I need to operate in whether it is labelled
Apache or not.  I personally find Apache has made it harder to make changes
and push the project forward (even as a committer, there are technical
infrastructure hurdles that get in my way, mostly the lack of a
fork/edit/pull request work flow with built-in code review tools, I.e.
github).

I offered my thoughts as an answer to what I think would improve as a TLP.
 I'm not trying to flame nor am I trying to actually push an agenda.  These
are my candid thoughts as someone who has primarily only interacted with
the current young, inexperienced, bleeding edge of how Open Source
can operate.

--Eric


>
>
> >
> > --Eric
> >
> > On Wednesday, July 24, 2013, Luciano Resende wrote:
> >
> > > On Wed, Jul 24, 2013 at 6:49 PM, Jordan Zimmerman <
> > > jordan@jordanzimmerman.com <javascript:;> <javascript:;>> wrote:
> > >
> > > > I am quickly coming to the conclusion that it was a mistake to put
> > > Curator
> > > > into Apache. I was cautioned by many colleagues that I shouldn't do
> it
> > > and
> > > > I now understand why they were correct. I'm not interested in
> another 3
> > > > months of incubation.
> > > >
> > > > What is the process for failing out of incubation so that Curator c=
an
> > > > continue outside of Apache?
> > > >
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >
> > >
> > >
> > > How do you see the project changing when it becomes a TLP ? Or, let m=
e
> > put
> > > in another way, what issue do you have as having it as an "Incubator"
> > > project for couple more months ?
> > >
> > >
> > > --
> > > Luciano Resende
> > > http://people.apache.org/~lresende
> > > http://twitter.com/lresende1975
> > > http://lresende.blogspot.com/
> > >
> >
>

--f46d044286e214712b04e24ffb35--