On Sat, Sep 18, 2010 at 7:52 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> Helau!

LOL - that made my day uwe :D
>
> (means +1)

same here! +1
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -----Original Message-----
>> From: Lance Norskog [mailto:goks...@gmail.com]
>> Sent: Friday, September 17, 2010 10:19 PM
>> To: dev@lucene.apache.org
>> Subject: Re: discussion about release frequency.
>>
>> +1 on the ant-only policy. I've recently been futzing with Mahout and I
>> had not been faced with the scrofulous horror of Maven. Please keep it out
> of
>> the main source tree of solr. You can do whatever you want with the
> internal
>> Apache build process.
>>
>> Chris Hostetter wrote:
>> > My unscientific, off the cuff, sociological impression is that once we
>> > moved forward with the "multi-branch" development plan and created the
>> > 3x branch, a lot of people who use to be the big proponents of regular
>> > releases got really about the freedom involved in working on the
>> > trunk, and lost their motivation to push for releases - because a big
>> > part of that motivation came from the backcompat concerns and the need
>> > to churn out releasees with deprecations so that future versions could
>> > move forward ith more interesting APIs.  "trunk" turned into the new
>> > hot sexiness.
>> >
>> > but like i said: that's just my unscientific impression.
>> >
>> > : I think now that we have a "trunk" for unstable development, and a
>> > : "3x" stable branch, that we should think about cutting releases from
>> > : this branch much more often, for example every month or two.
>> >
>> > I think that might be overly ambitious, particularly because we've
>> > never really talked about how the release process for the 3x branch
>> > *should* work (given the lucene/solr development merged) let alone
>> > start on those changes to make it easy (that process doc that scares
>> > the crap out of you is just for Lucene-Java, there's an equally scaray
>> > one for Solr)
>> >
>> >
>> > I think it's going to take some work just on build/process before we
>> > can get our first "merged" release from 3x.  Assuming we improve some
>> > automation while we're at it, then i think it's feasible that we could
>> > start doing releases off of it every couple of months.  it would
>> > remain to be seen wether we sould *need* to release that often -- it
>> > will depend on wether anything new gets committed there -- but it
>> > would certianly be nice to be able to.
>> >
>> > : Finally, as far as getting someone to do the work, I can certainly
>> > : volunteer to help in the following ways:
>> > : * being RM if you are ok with a non-maven release (until LUCENE-2268
>> > : is fixed, i am uncomfortable with maven)
>> >
>> > maven is such a contentious issue -- people either don't give a shit
>> > about it, or think it's the end of the world if the jars aren't there.
>> >
>> > In the past i've argued that enough users care about maven we should
>> > really try to make sure we play nicely, but the more i think about it
>> > the less i think it should be part of the release process.
>> >
>> > the ASF releases source code.  When we vote on a release, tha's what
>> > we are voting on: source.  We may also distribute precompiled binary
>> > jars via the download mirrors, or via maven, but that's not what the
>> > release is about -- so let's get hte pom template files out of hte src
>> > tree, let's get the maven related tasks out of the build.xml file and
>> > treat publishing to maven as a seperate process that happens *after*
>> > the release.  We vote on the release, we release it, and then the
>> > folks that care about maven can publish the jars after the fact.
>> >
>> >
>> >
>> >
>> >
>> > -Hoss
>> >
>> > --
>> > http://lucenerevolution.org/  ...  October 7-8, Boston
>> > http://bit.ly/stump-hoss      ...  Stump The Chump!
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>> > additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
>> commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to