curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: [VOTE] Graduate Curator from Apache Incubator
Date Thu, 25 Jul 2013 02:48:57 GMT
On Wed, Jul 24, 2013 at 7:19 PM, Eric Tschetter <echeddar@gmail.com> 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.


>
> 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.


>
> --Eric
>
> On Wednesday, July 24, 2013, Luciano Resende wrote:
>
> > On Wed, Jul 24, 2013 at 6:49 PM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com <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
> > http://people.apache.org/~lresende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message