curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evaristo José Camarero <>
Subject Re: [VOTE] Graduate Curator from Apache Incubator
Date Thu, 25 Jul 2013 09:32:27 GMT


Said that:
Thanks to Jordan for your work, for the effort and for being so responsive.
Honestly, if I were Jordan I would like to receive more encouraging words from some Apache
mentors. Sometimes the blocking issue for a release has been that 5 lines description is missing
in the web or similar things. That's also important but probably can be managed in a different
way, without blocking the project milestones



 De: Eric Tschetter <>
Para: "" <> 
Enviado: Jueves 25 de julio de 2013 8:17
Asunto: Re: [VOTE] Graduate Curator from Apache Incubator

On Wednesday, July 24, 2013, Enis Söztutar wrote:

> On Wed, Jul 24, 2013 at 7:19 PM, Eric Tschetter <<javascript:;>>
> 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 early
> > 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 they
> > 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 is
> > fit for release.
> >
> > During that two weeks the code sat, it aged a bit like wine, except when
> we
> > uncorked it, it hadn't actually changed.
> >
> Eric, there is no technical reason why the commits have to be frozen while
> 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 more
> > 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.

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
> >
> > On Wednesday, July 24, 2013, Luciano Resende wrote:
> >
> > > On Wed, Jul 24, 2013 at 6:49 PM, Jordan Zimmerman <
> > > <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 can
> > > > continue outside of Apache?
> > > >
> > > > ====================
> > > >
> > >
> > >
> > > How do you see the project changing when it becomes a TLP ? Or, let me
> > put
> > > in another way, what issue do you have as having it as an "Incubator"
> > > project for couple more months ?
> > >
> > >
> > > --
> > > Luciano Resende
> > >
> > >
> > >
> > >
> >
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message