You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Johan Oskarsson <jo...@oskarsson.nu> on 2009/01/30 12:57:41 UTC
Feature freeze date?
I'm curious if there is any set feature freeze dates? If not, how about
setting one for end of February?
Even though the active developers and hardcore users might not have a
need for a release I think it makes a huge difference for new users who
just want to go to the site, download a tarfile and be on their merry
way. Always getting the latest from trunk might lead to
incompatibilities and if unlucky the user might get a buggy revision.
Having a proper release also makes it easier to get Thrift into other
projects.
Had a quick look at the wiki and can't find a release procedure, but a
rough idea would be to announce a freeze date to the list. On that date
move all the non critical issues in jira to the next version and create
a new branch in svn. Once the critical bugs are fixed a release can be
rolled.
/Johan
Re: Feature freeze date?
Posted by Esteve Fernandez <es...@sindominio.net>.
On Tuesday 03 February 2009 23:01:38 David Reiss wrote:
> Why do we need to assign priority to each language? I think the
> de-facto point people have been:
Note that I said "officially". For example, I didn't know there was someone
responsible for the OCaml bindings. Why not make it official and have a
language-maintainer pairing list?
> Python: David Reiss (and several contributors)
And Ben Maurer. I'm tempted to appoint myself, but it's probably not very
polite.
BTW, I think it's important to give a priority to each language, because not
all of them have an extensive testsuite, have much activity in the mailing
list, etc. and we should strive to ship proven and stable code.
Cheers.
Re: Feature freeze date?
Posted by Chad Walters <Ch...@microsoft.com>.
I believe we have folks who care about C# as well.
C is one other language I'd love to see get into the top-tier, but I wouldn't hold up the release for this.
Chad
On 2/3/09 10:39 AM, "Kevin Clark" <ke...@gmail.com> wrote:
On Tue, Feb 3, 2009 at 10:33 AM, Carlos Valiente <su...@gmail.com> wrote:
>> Personally, I care most about Ruby, C++, Java, Erlang.
>
> As user I would love to see Python and Perl in that list, as well.
Yup, those make sense as top tier languages (and we have committers
who watch them).
--
Kevin Clark
http://glu.ttono.us
Re: Feature freeze date?
Posted by Kevin Clark <ke...@gmail.com>.
On Tue, Feb 3, 2009 at 10:33 AM, Carlos Valiente <su...@gmail.com> wrote:
>> Personally, I care most about Ruby, C++, Java, Erlang.
>
> As user I would love to see Python and Perl in that list, as well.
Yup, those make sense as top tier languages (and we have committers
who watch them).
--
Kevin Clark
http://glu.ttono.us
Re: Feature freeze date?
Posted by Carlos Valiente <su...@gmail.com>.
> Personally, I care most about Ruby, C++, Java, Erlang.
As user I would love to see Python and Perl in that list, as well.
C
Re: Feature freeze date?
Posted by David Reiss <dr...@facebook.com>.
Why do we need to assign priority to each language? I think the
de-facto point people have been:
C++: David Reiss, Mark Slee, Jake Luciani
Java: Bryan Duxbury, David Reiss
C#: Michael Greene, Will Palmeri (non-committers, for now)
Cocoa: Andrew McGeachie (non-committer)
Python: David Reiss (and several contributors)
Ruby: Kevin Clark, Kevin Ballard, Bryan Duxbury
Perl: Jake Luciani
PHP: David Reiss, Mark Slee
Erlang: Todd Lipcon, David Reiss
OCaml: Iain Proctor (non-committer)
Haskell: Iain Proctor (non-committer)
Smalltalk: Patrick Collison (non-committer)
Kevin Clark wrote:
> Sounds like a good course of action to me. Though I sorta feel like
> many contributors stick to the languages that impact them the most, so
> I'm not sure how to rank priority in the scope of the project...
> Personally, I care most about Ruby, C++, Java, Erlang.
>
> David? Bryan? Jake? Other active committers? *nudge* Want to weigh in?
>
> Anyone know if there's a way to tag tickets as needing to be handled
> for the next release? Might help to focus our work if there's a single
> queue.
>
> On Tue, Feb 3, 2009 at 9:44 AM, Esteve Fernandez <es...@sindominio.net> wrote:
>> On Tuesday 03 February 2009 18:15:08 Kevin Clark wrote:
>>> Ok, I'd support this. Anyone have suggestions for how we go about it?
>> I'd start by:
>>
>> - deciding which languages have the highest priority
>> - officially appointing someone as the key person for each language and/or
>> platform
>> - trying to close old or pending issues. A bug squashing fest would be great.
>>
>> Cheers.
>>
>
>
>
Re: Feature freeze date?
Posted by Johan Oskarsson <jo...@oskarsson.nu>.
The process described here works quite well for Hadoop:
http://wiki.apache.org/hadoop/HowToRelease
People can assign improvements and new features to certain version, but
if they aren't resolved by the feature freeze date a comitter
responsible for the release will push the ticket to the next version in
line. The only tickets left for the version to be released at this point
should be bugs that need to be fixed before the release goes out.
How about a vote on the next feature freeze date?
I'd suggest 2nd of March. Thoughts?
/Johan
Bryan Duxbury wrote:
> I think generally the reporter shouldn't assign fix versions. Instead,
> the committers in charge of a given language can assign features to fix
> versions as they see fit.
>
> We already have a version 0.1 in Jira which is titled "first release
> from Apache", which I think it makes sense to use. I've just assigned a
> bunch of Ruby and Java issues to this version. Others should do so for
> their favorite libraries as they see fit.
>
> -Bryan
>
> On Feb 3, 2009, at 10:46 AM, Michael Greene wrote:
>
>> I'm invested in the C# and Python libs, and I know we have other users
>> around here. How do we get a version setup in JIRA? David?
>>
>> Is the process that a reporter assigns a version, and then the
>> community and committers police that, de-scoping as necessary?
>>
>> On Tue, Feb 3, 2009 at 12:40 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
>>> I'm for doing a feature freeze and planning a release. I'm focused on
>>> Ruby
>>> and Java.
>>>
>>> We can create "versions" in Jira, and then tag issues with the
>>> version we
>>> want to fix it in. This will give us a version-oriented work queue.
>>>
>>> On Feb 3, 2009, at 10:22 AM, Kevin Clark wrote:
>>>
>>>> Sounds like a good course of action to me. Though I sorta feel like
>>>> many contributors stick to the languages that impact them the most, so
>>>> I'm not sure how to rank priority in the scope of the project...
>>>> Personally, I care most about Ruby, C++, Java, Erlang.
>
Re: Feature freeze date?
Posted by Bryan Duxbury <br...@rapleaf.com>.
I think generally the reporter shouldn't assign fix versions.
Instead, the committers in charge of a given language can assign
features to fix versions as they see fit.
We already have a version 0.1 in Jira which is titled "first release
from Apache", which I think it makes sense to use. I've just assigned
a bunch of Ruby and Java issues to this version. Others should do so
for their favorite libraries as they see fit.
-Bryan
On Feb 3, 2009, at 10:46 AM, Michael Greene wrote:
> I'm invested in the C# and Python libs, and I know we have other users
> around here. How do we get a version setup in JIRA? David?
>
> Is the process that a reporter assigns a version, and then the
> community and committers police that, de-scoping as necessary?
>
> On Tue, Feb 3, 2009 at 12:40 PM, Bryan Duxbury <br...@rapleaf.com>
> wrote:
>> I'm for doing a feature freeze and planning a release. I'm focused
>> on Ruby
>> and Java.
>>
>> We can create "versions" in Jira, and then tag issues with the
>> version we
>> want to fix it in. This will give us a version-oriented work queue.
>>
>> On Feb 3, 2009, at 10:22 AM, Kevin Clark wrote:
>>
>>> Sounds like a good course of action to me. Though I sorta feel like
>>> many contributors stick to the languages that impact them the
>>> most, so
>>> I'm not sure how to rank priority in the scope of the project...
>>> Personally, I care most about Ruby, C++, Java, Erlang.
Re: Feature freeze date?
Posted by Michael Greene <mi...@gmail.com>.
I'm invested in the C# and Python libs, and I know we have other users
around here. How do we get a version setup in JIRA? David?
Is the process that a reporter assigns a version, and then the
community and committers police that, de-scoping as necessary?
On Tue, Feb 3, 2009 at 12:40 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> I'm for doing a feature freeze and planning a release. I'm focused on Ruby
> and Java.
>
> We can create "versions" in Jira, and then tag issues with the version we
> want to fix it in. This will give us a version-oriented work queue.
>
> On Feb 3, 2009, at 10:22 AM, Kevin Clark wrote:
>
>> Sounds like a good course of action to me. Though I sorta feel like
>> many contributors stick to the languages that impact them the most, so
>> I'm not sure how to rank priority in the scope of the project...
>> Personally, I care most about Ruby, C++, Java, Erlang.
Re: Feature freeze date?
Posted by Bryan Duxbury <br...@rapleaf.com>.
I'm for doing a feature freeze and planning a release. I'm focused on
Ruby and Java.
We can create "versions" in Jira, and then tag issues with the
version we want to fix it in. This will give us a version-oriented
work queue.
On Feb 3, 2009, at 10:22 AM, Kevin Clark wrote:
> Sounds like a good course of action to me. Though I sorta feel like
> many contributors stick to the languages that impact them the most, so
> I'm not sure how to rank priority in the scope of the project...
> Personally, I care most about Ruby, C++, Java, Erlang.
>
> David? Bryan? Jake? Other active committers? *nudge* Want to weigh in?
>
> Anyone know if there's a way to tag tickets as needing to be handled
> for the next release? Might help to focus our work if there's a single
> queue.
>
> On Tue, Feb 3, 2009 at 9:44 AM, Esteve Fernandez
> <es...@sindominio.net> wrote:
>> On Tuesday 03 February 2009 18:15:08 Kevin Clark wrote:
>>> Ok, I'd support this. Anyone have suggestions for how we go about
>>> it?
>>
>> I'd start by:
>>
>> - deciding which languages have the highest priority
>> - officially appointing someone as the key person for each
>> language and/or
>> platform
>> - trying to close old or pending issues. A bug squashing fest
>> would be great.
>>
>> Cheers.
>>
>
>
>
> --
> Kevin Clark
> http://glu.ttono.us
Re: Feature freeze date?
Posted by Kevin Clark <ke...@gmail.com>.
Sounds like a good course of action to me. Though I sorta feel like
many contributors stick to the languages that impact them the most, so
I'm not sure how to rank priority in the scope of the project...
Personally, I care most about Ruby, C++, Java, Erlang.
David? Bryan? Jake? Other active committers? *nudge* Want to weigh in?
Anyone know if there's a way to tag tickets as needing to be handled
for the next release? Might help to focus our work if there's a single
queue.
On Tue, Feb 3, 2009 at 9:44 AM, Esteve Fernandez <es...@sindominio.net> wrote:
> On Tuesday 03 February 2009 18:15:08 Kevin Clark wrote:
>> Ok, I'd support this. Anyone have suggestions for how we go about it?
>
> I'd start by:
>
> - deciding which languages have the highest priority
> - officially appointing someone as the key person for each language and/or
> platform
> - trying to close old or pending issues. A bug squashing fest would be great.
>
> Cheers.
>
--
Kevin Clark
http://glu.ttono.us
Re: Feature freeze date?
Posted by Esteve Fernandez <es...@sindominio.net>.
On Tuesday 03 February 2009 18:15:08 Kevin Clark wrote:
> Ok, I'd support this. Anyone have suggestions for how we go about it?
I'd start by:
- deciding which languages have the highest priority
- officially appointing someone as the key person for each language and/or
platform
- trying to close old or pending issues. A bug squashing fest would be great.
Cheers.
Re: Feature freeze date?
Posted by Todd Lipcon <tl...@gmail.com>.
On Sat, Feb 7, 2009 at 4:56 AM, Esteve Fernandez
>
>
> As for the top-tier languages, here's a list (in no particular order) of
> those
> that have been asked by someone, at least once, in this mailing list:
>
> - Ruby
> - C++
> - Java
> - Erlang
> - Python
> - Perl
> - C#
>
Don't forget PHP here - there are definitely several big users of the PHP
clients.
-Todd
Re: Feature freeze date?
Posted by Esteve Fernandez <es...@sindominio.net>.
On Friday 06 February 2009 01:59:33 David Reiss wrote:
> Esteve Fernandez wrote:
> > Anyway, as Thrift's project lead, what do you think of having a release
> > plan/roadmap?
>
> I think it sounds great.
Good. So, when do we start? The next board report is due in April, I don't
think we can (or should) roll a new release by then, but at least it would be
nice if we have things in place and the release process is clearly defined.
As for the top-tier languages, here's a list (in no particular order) of those
that have been asked by someone, at least once, in this mailing list:
- Ruby
- C++
- Java
- Erlang
- Python
- Perl
- C#
I wouldn't include support for the others in the next release for these
reasons:
- if nobody expressed interest, it probably means that nobody is tracking
their progress and we won't be able to give responsive feedback
- there are no committers who can maintain them
We have a list of seven languages. However, I'm not sure about supporting C#
and Perl:
- there are no committers for C#. I'd nominate a couple of contributors, but
I'm not a PMC member, so I'll keep it to myself. Anyway, it's pretty clear
who's contributing to C# and adding them to the committer team would help
closing a bunch of months-old issues
- Perl lacks an extensive test suite. Also, adding another committer would be
nice.
These are my only concerns, but I'm sure they can be worked out before the
next board report and we'll be able to make C# and Perl first class languages
in Thrift.
Anyway, I think having a more formal process would be nice towards shipping a
new version, so I'll try to keep this thread alive.
Cheers.
Re: Feature freeze date?
Posted by David Reiss <dr...@facebook.com>.
Esteve Fernandez wrote:
> Anyway, as Thrift's project lead, what do you think of having a release
> plan/roadmap?
I think it sounds great.
Re: Feature freeze date?
Posted by Esteve Fernandez <es...@sindominio.net>.
On Tuesday 03 February 2009 23:05:01 David Reiss wrote:
> > 1 - It's not particularly easy to maintain pending patches against trunk.
> > I'd rather contribute patches against a released version, not an ever
> > changing branch.
>
> I don't think this will change. Patches submitted against the last
> released version will always have to be applied to the latest trunk in
> order to be merged.
Yes, but I don't think it's something that reporters/non-committers should do.
It's the duty of committers to see if a contributed patch fixes an issue,
apply it and port it to trunk.
Anyway, as Thrift's project lead, what do you think of having a release
plan/roadmap?
Cheers.
Re: Feature freeze date?
Posted by Kevin Clark <ke...@gmail.com>.
Ok, I'd support this. Anyone have suggestions for how we go about it?
On Tue, Feb 3, 2009 at 9:08 AM, Esteve Fernandez <es...@sindominio.net> wrote:
> +1 Actually, this issue has been raised quite a few times, but there wasn't a
> conclusive official reply.
>
> As others pointed out in the past, an incubating project must have a healthy
> release process (among other things) before it graduates.
>
> Apart from the reasons already exposed, mine are:
>
> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
> rather contribute patches against a released version, not an ever changing
> branch.
>
> 2 - It's almost impossible for Thrift to be officially packaged by
> distributors. We're maintaining packages for Ubuntu at our Launchpad PPA and
> giving them away, but we only update them once in a while, primarily if
> there's something that we need to integrate or interests us (namely Python).
> An officially sanctioned release will help Thrift to get some exposure.
>
> Cheers.
>
> On Friday 30 January 2009 15:35:32 Michael Greene wrote:
>> I am also in favor of this, as commented on in THRIFT-274, with these
>> additional reasons:
>>
>> 1. The moderate difficulty getting a compilation environment setup
>> on Windows for new users
>> 2. The inability to get new builds into other Apache releases (see
>> https://issues.apache.org/jira/browse/HADOOP-3754?focusedCommentId=12620772
>>#action_12620772 )
>>
>> Michael
>>
>> On Fri, Jan 30, 2009 at 8:30 AM, Erik Frey <er...@last.fm> wrote:
>> > I'd like this, too. Our company has enough systems/teams using thrift
>> > now that there's often conflict between people still using the old
>> > 20080411p1 and those of us working out of trunk.
>> >
>> > Erik
>> >
>> > Johan Oskarsson wrote:
>> >> I'm curious if there is any set feature freeze dates? If not, how about
>> >> setting one for end of February?
>> >>
>> >> Even though the active developers and hardcore users might not have a
>> >> need for a release I think it makes a huge difference for new users who
>> >> just want to go to the site, download a tarfile and be on their merry
>> >> way. Always getting the latest from trunk might lead to
>> >> incompatibilities and if unlucky the user might get a buggy revision.
>> >> Having a proper release also makes it easier to get Thrift into other
>> >> projects.
>
>
>
--
Kevin Clark
http://glu.ttono.us
Re: Feature freeze date?
Posted by Jérémie BORDIER <ah...@gmail.com>.
I agree with everything said so far, it's definitively a good thing to
have a release objective fixed.
I do know quite well the C++ library, but i'm also at ease with Ruby,
Python and Java.
--
Jérémie
On Tue, Feb 3, 2009 at 6:57 PM, Todd Lipcon <tl...@gmail.com> wrote:
> +1 from our standpoint as well, for the same reasons Esteve mentioned below.
>
> -Todd
>
> On Tue, Feb 3, 2009 at 12:08 PM, Esteve Fernandez <es...@sindominio.net>wrote:
>
>> +1 Actually, this issue has been raised quite a few times, but there wasn't
>> a
>> conclusive official reply.
>>
>> As others pointed out in the past, an incubating project must have a
>> healthy
>> release process (among other things) before it graduates.
>>
>> Apart from the reasons already exposed, mine are:
>>
>> 1 - It's not particularly easy to maintain pending patches against trunk.
>> I'd
>> rather contribute patches against a released version, not an ever changing
>> branch.
>>
>> 2 - It's almost impossible for Thrift to be officially packaged by
>> distributors. We're maintaining packages for Ubuntu at our Launchpad PPA
>> and
>> giving them away, but we only update them once in a while, primarily if
>> there's something that we need to integrate or interests us (namely
>> Python).
>> An officially sanctioned release will help Thrift to get some exposure.
>>
>> Cheers.
>>
>> On Friday 30 January 2009 15:35:32 Michael Greene wrote:
>> > I am also in favor of this, as commented on in THRIFT-274, with these
>> > additional reasons:
>> >
>> > 1. The moderate difficulty getting a compilation environment setup
>> > on Windows for new users
>> > 2. The inability to get new builds into other Apache releases (see
>> >
>> https://issues.apache.org/jira/browse/HADOOP-3754?focusedCommentId=12620772
>> >#action_12620772 )
>> >
>> > Michael
>> >
>> > On Fri, Jan 30, 2009 at 8:30 AM, Erik Frey <er...@last.fm> wrote:
>> > > I'd like this, too. Our company has enough systems/teams using thrift
>> > > now that there's often conflict between people still using the old
>> > > 20080411p1 and those of us working out of trunk.
>> > >
>> > > Erik
>> > >
>> > > Johan Oskarsson wrote:
>> > >> I'm curious if there is any set feature freeze dates? If not, how
>> about
>> > >> setting one for end of February?
>> > >>
>> > >> Even though the active developers and hardcore users might not have a
>> > >> need for a release I think it makes a huge difference for new users
>> who
>> > >> just want to go to the site, download a tarfile and be on their merry
>> > >> way. Always getting the latest from trunk might lead to
>> > >> incompatibilities and if unlucky the user might get a buggy revision.
>> > >> Having a proper release also makes it easier to get Thrift into other
>> > >> projects.
>>
>>
>>
>
--
Jérémie 'ahFeel' BORDIER
Re: Feature freeze date?
Posted by Todd Lipcon <tl...@gmail.com>.
+1 from our standpoint as well, for the same reasons Esteve mentioned below.
-Todd
On Tue, Feb 3, 2009 at 12:08 PM, Esteve Fernandez <es...@sindominio.net>wrote:
> +1 Actually, this issue has been raised quite a few times, but there wasn't
> a
> conclusive official reply.
>
> As others pointed out in the past, an incubating project must have a
> healthy
> release process (among other things) before it graduates.
>
> Apart from the reasons already exposed, mine are:
>
> 1 - It's not particularly easy to maintain pending patches against trunk.
> I'd
> rather contribute patches against a released version, not an ever changing
> branch.
>
> 2 - It's almost impossible for Thrift to be officially packaged by
> distributors. We're maintaining packages for Ubuntu at our Launchpad PPA
> and
> giving them away, but we only update them once in a while, primarily if
> there's something that we need to integrate or interests us (namely
> Python).
> An officially sanctioned release will help Thrift to get some exposure.
>
> Cheers.
>
> On Friday 30 January 2009 15:35:32 Michael Greene wrote:
> > I am also in favor of this, as commented on in THRIFT-274, with these
> > additional reasons:
> >
> > 1. The moderate difficulty getting a compilation environment setup
> > on Windows for new users
> > 2. The inability to get new builds into other Apache releases (see
> >
> https://issues.apache.org/jira/browse/HADOOP-3754?focusedCommentId=12620772
> >#action_12620772 )
> >
> > Michael
> >
> > On Fri, Jan 30, 2009 at 8:30 AM, Erik Frey <er...@last.fm> wrote:
> > > I'd like this, too. Our company has enough systems/teams using thrift
> > > now that there's often conflict between people still using the old
> > > 20080411p1 and those of us working out of trunk.
> > >
> > > Erik
> > >
> > > Johan Oskarsson wrote:
> > >> I'm curious if there is any set feature freeze dates? If not, how
> about
> > >> setting one for end of February?
> > >>
> > >> Even though the active developers and hardcore users might not have a
> > >> need for a release I think it makes a huge difference for new users
> who
> > >> just want to go to the site, download a tarfile and be on their merry
> > >> way. Always getting the latest from trunk might lead to
> > >> incompatibilities and if unlucky the user might get a buggy revision.
> > >> Having a proper release also makes it easier to get Thrift into other
> > >> projects.
>
>
>
Re: Feature freeze date?
Posted by Johan Oskarsson <jo...@oskarsson.nu>.
How about asking for acccess to Hudson to make sure Thrift builds and
runs on supported platforms?
Setup correctly we should be able to have it build the compiler nightly
on a fresh ubuntu/freebsd/whatever install as well as run any unit tests
in at least a few languages.
Hudson is also pretty extensible so worst case we could create our own
plugin for it, but just getting the compile running would be a start.
No idea if Apache have licenses for VMware, but this might be worth a
look: http://hudson.gotdns.com/wiki/display/HUDSON/VMware+plugin
More info on Apache's Hudson setup: http://wiki.apache.org/general/Hudson
/Johan
David Reiss wrote:
> I think we should include pkg.m4 in the release tarball, which should
> solve that problem for people using the release.
>
> I'd say the supported platforms are:
>
> Compiler: Any POSIX system (including Cygwin and OSX), msys.
> C++ Library: Linux, Recent BSDs, Solaris 10 (might be some open patches on these), OSX?
> Cocoa Library: Any OSX?
> Others: Wherever the runtimes run, I guess.
>
> Jake Luciani wrote:
>> Do we cleanly compile on most systems? I still have issue on osx THRIFT-201
>>
>> What are the supported platforms?
>>
>>
>> On Tue, Feb 3, 2009 at 5:05 PM, David Reiss <dr...@facebook.com> wrote:
>>>> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
>>>> rather contribute patches against a released version, not an ever changing
>>>> branch.
>>> I don't think this will change. Patches submitted against the last released
>>> version will always have to be applied to the latest trunk in order to be merged.
>>>
Re: Feature freeze date?
Posted by Andrew McGeachie <ge...@gmail.com>.
On Feb 3, 2009, at 7:40 PM, David Reiss wrote:
> I think we should include pkg.m4 in the release tarball, which should
> solve that problem for people using the release.
>
> I'd say the supported platforms are:
>
> Compiler: Any POSIX system (including Cygwin and OSX), msys.
> C++ Library: Linux, Recent BSDs, Solaris 10 (might be some open
> patches on these), OSX?
> Cocoa Library: Any OSX?
The Cocoa library should run on OS X 10.4 (Tiger) and OS X 10.5
(Leopard). I can't vouch or test for earlier versions though.
- a
Re: Feature freeze date?
Posted by Jérémie BORDIER <ah...@gmail.com>.
The only issue i experience with building Thrift on OSX is the static
Makefile of the tutorial that need to be adapted to the right Boost
location.
Otherwise, it works like a charm.
Jérémie
On Wed, Feb 4, 2009 at 1:40 AM, David Reiss <dr...@facebook.com> wrote:
> I think we should include pkg.m4 in the release tarball, which should
> solve that problem for people using the release.
>
> I'd say the supported platforms are:
>
> Compiler: Any POSIX system (including Cygwin and OSX), msys.
> C++ Library: Linux, Recent BSDs, Solaris 10 (might be some open patches on these), OSX?
> Cocoa Library: Any OSX?
> Others: Wherever the runtimes run, I guess.
>
> Jake Luciani wrote:
>> Do we cleanly compile on most systems? I still have issue on osx THRIFT-201
>>
>> What are the supported platforms?
>>
>>
>> On Tue, Feb 3, 2009 at 5:05 PM, David Reiss <dr...@facebook.com> wrote:
>>>> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
>>>> rather contribute patches against a released version, not an ever changing
>>>> branch.
>>> I don't think this will change. Patches submitted against the last released
>>> version will always have to be applied to the latest trunk in order to be merged.
>>>
>
--
Jérémie 'ahFeel' BORDIER
Re: Feature freeze date?
Posted by Jake Luciani <ja...@gmail.com>.
great
On Tue, Feb 3, 2009 at 7:40 PM, David Reiss <dr...@facebook.com> wrote:
> I think we should include pkg.m4 in the release tarball, which should
> solve that problem for people using the release.
>
> I'd say the supported platforms are:
>
> Compiler: Any POSIX system (including Cygwin and OSX), msys.
> C++ Library: Linux, Recent BSDs, Solaris 10 (might be some open patches on these), OSX?
> Cocoa Library: Any OSX?
> Others: Wherever the runtimes run, I guess.
>
> Jake Luciani wrote:
>> Do we cleanly compile on most systems? I still have issue on osx THRIFT-201
>>
>> What are the supported platforms?
>>
>>
>> On Tue, Feb 3, 2009 at 5:05 PM, David Reiss <dr...@facebook.com> wrote:
>>>> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
>>>> rather contribute patches against a released version, not an ever changing
>>>> branch.
>>> I don't think this will change. Patches submitted against the last released
>>> version will always have to be applied to the latest trunk in order to be merged.
>>>
>
Re: Feature freeze date?
Posted by David Reiss <dr...@facebook.com>.
I think we should include pkg.m4 in the release tarball, which should
solve that problem for people using the release.
I'd say the supported platforms are:
Compiler: Any POSIX system (including Cygwin and OSX), msys.
C++ Library: Linux, Recent BSDs, Solaris 10 (might be some open patches on these), OSX?
Cocoa Library: Any OSX?
Others: Wherever the runtimes run, I guess.
Jake Luciani wrote:
> Do we cleanly compile on most systems? I still have issue on osx THRIFT-201
>
> What are the supported platforms?
>
>
> On Tue, Feb 3, 2009 at 5:05 PM, David Reiss <dr...@facebook.com> wrote:
>>> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
>>> rather contribute patches against a released version, not an ever changing
>>> branch.
>> I don't think this will change. Patches submitted against the last released
>> version will always have to be applied to the latest trunk in order to be merged.
>>
Re: Feature freeze date?
Posted by Jake Luciani <ja...@gmail.com>.
Do we cleanly compile on most systems? I still have issue on osx THRIFT-201
What are the supported platforms?
On Tue, Feb 3, 2009 at 5:05 PM, David Reiss <dr...@facebook.com> wrote:
>> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
>> rather contribute patches against a released version, not an ever changing
>> branch.
> I don't think this will change. Patches submitted against the last released
> version will always have to be applied to the latest trunk in order to be merged.
>
Re: Feature freeze date?
Posted by David Reiss <dr...@facebook.com>.
> 1 - It's not particularly easy to maintain pending patches against trunk. I'd
> rather contribute patches against a released version, not an ever changing
> branch.
I don't think this will change. Patches submitted against the last released
version will always have to be applied to the latest trunk in order to be merged.
Re: Feature freeze date?
Posted by Esteve Fernandez <es...@sindominio.net>.
+1 Actually, this issue has been raised quite a few times, but there wasn't a
conclusive official reply.
As others pointed out in the past, an incubating project must have a healthy
release process (among other things) before it graduates.
Apart from the reasons already exposed, mine are:
1 - It's not particularly easy to maintain pending patches against trunk. I'd
rather contribute patches against a released version, not an ever changing
branch.
2 - It's almost impossible for Thrift to be officially packaged by
distributors. We're maintaining packages for Ubuntu at our Launchpad PPA and
giving them away, but we only update them once in a while, primarily if
there's something that we need to integrate or interests us (namely Python).
An officially sanctioned release will help Thrift to get some exposure.
Cheers.
On Friday 30 January 2009 15:35:32 Michael Greene wrote:
> I am also in favor of this, as commented on in THRIFT-274, with these
> additional reasons:
>
> 1. The moderate difficulty getting a compilation environment setup
> on Windows for new users
> 2. The inability to get new builds into other Apache releases (see
> https://issues.apache.org/jira/browse/HADOOP-3754?focusedCommentId=12620772
>#action_12620772 )
>
> Michael
>
> On Fri, Jan 30, 2009 at 8:30 AM, Erik Frey <er...@last.fm> wrote:
> > I'd like this, too. Our company has enough systems/teams using thrift
> > now that there's often conflict between people still using the old
> > 20080411p1 and those of us working out of trunk.
> >
> > Erik
> >
> > Johan Oskarsson wrote:
> >> I'm curious if there is any set feature freeze dates? If not, how about
> >> setting one for end of February?
> >>
> >> Even though the active developers and hardcore users might not have a
> >> need for a release I think it makes a huge difference for new users who
> >> just want to go to the site, download a tarfile and be on their merry
> >> way. Always getting the latest from trunk might lead to
> >> incompatibilities and if unlucky the user might get a buggy revision.
> >> Having a proper release also makes it easier to get Thrift into other
> >> projects.
Re: Feature freeze date?
Posted by Michael Greene <mi...@gmail.com>.
I am also in favor of this, as commented on in THRIFT-274, with these
additional reasons:
1. The moderate difficulty getting a compilation environment setup
on Windows for new users
2. The inability to get new builds into other Apache releases (see
https://issues.apache.org/jira/browse/HADOOP-3754?focusedCommentId=12620772#action_12620772
)
Michael
On Fri, Jan 30, 2009 at 8:30 AM, Erik Frey <er...@last.fm> wrote:
> I'd like this, too. Our company has enough systems/teams using thrift now
> that there's often conflict between people still using the old 20080411p1
> and those of us working out of trunk.
>
> Erik
>
> Johan Oskarsson wrote:
>>
>> I'm curious if there is any set feature freeze dates? If not, how about
>> setting one for end of February?
>>
>> Even though the active developers and hardcore users might not have a
>> need for a release I think it makes a huge difference for new users who
>> just want to go to the site, download a tarfile and be on their merry
>> way. Always getting the latest from trunk might lead to
>> incompatibilities and if unlucky the user might get a buggy revision.
>> Having a proper release also makes it easier to get Thrift into other
>> projects.
Re: Feature freeze date?
Posted by Dan Sully <da...@electricrain.com>.
Another +1 here.
I'd much prefer to be able to bring a specific known
good release into my environment for packaging.
-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.
Re: Feature freeze date?
Posted by Erik Frey <er...@last.fm>.
I'd like this, too. Our company has enough systems/teams using thrift
now that there's often conflict between people still using the old
20080411p1 and those of us working out of trunk.
Erik
Johan Oskarsson wrote:
> I'm curious if there is any set feature freeze dates? If not, how about
> setting one for end of February?
>
> Even though the active developers and hardcore users might not have a
> need for a release I think it makes a huge difference for new users who
> just want to go to the site, download a tarfile and be on their merry
> way. Always getting the latest from trunk might lead to
> incompatibilities and if unlucky the user might get a buggy revision.
> Having a proper release also makes it easier to get Thrift into other
> projects.
>
> Had a quick look at the wiki and can't find a release procedure, but a
> rough idea would be to announce a freeze date to the list. On that date
> move all the non critical issues in jira to the next version and create
> a new branch in svn. Once the critical bugs are fixed a release can be
> rolled.
>
> /Johan
>