You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2012/01/10 04:38:03 UTC
[lucy-dev] 0.3.0 release prep
I am starting the prep for the 0.3.0 release. The first step is to confirm that
the RAT report passes:
http://ci.apache.org/projects/lucy/rat-output.html
It looks like a bunch of files are missing the Apache License, many of them the
start of the C implementation, but also a bunch of .gitignore files. I can add
the license header to the c/ files. Does it make sense to have the .gitignore
files include a license? Can we tell RAT to ignore the ignore files?
For the c/ files, since that is just the stub of the tip of the beginning of a
start for that code, do we even want it in the release? Could/should files be
removed from a branch if they do not represent 'finished' product? I realize
this last is a philosophical as well as practical question.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0 release prep
Posted by Chris Hostetter <ho...@fucit.org>.
: > For the c/ files, since that is just the stub of the tip of the beginning of a
: > start for that code, do we even want it in the release?
:
: IMO: yes. Canonical release tarballs should be snapshots from the VCS.
: Things get annoyingly complicated if you deviate from that.
:
: If we don't want something in an official release, we should develop it on a
: branch. That will be more straightforward once we switch to Git in a few
: months.
:
: > Could/should files be removed from a branch if they do not represent
: > 'finished' product? I realize this last is a philosophical as well as
: > practical question.
:
: I don't think it matters much. All of the 0.2.x releases have had a ruby/
: dir containing useless in-progress code; nobody complained.
On the philosophical side: Lucy is a young project that still needs to
think hard about focusing on atracting to "contributing-users" first, and
"non-contributing-users" second.
I think it should be considered preferable for the releases to be "warts
and all" and include all of the half-finished unpolished partly-broken
language bindings that are in progress, because having that code in a
release will make it (the unfinished code) more visible and more likely to
attract new contributors who might think "hmmm... here's a binding that's
already started i can help out out" but who otherwise night have never
considered contributing back to Lucy ... perhaps because they had no idea
how to "get started" with a binding for XYZ (and wouldn't realize someone
already had if it wasn't in the release). The only downside to
unfinished/non-working code in a release, is it may discourage / scare-off
novice users who might try it and think "hmmm... this stuff doesn't even
work!" w/o realizing how much *does* work.
In otherwords: i would suggest that for now, avoid the "let's build this
feature on a branch until it's stable" mentality, and reserve branches for
"let's experiment with changing this existing API/functionality on a
branch so we don't risk it leaking out into a release before we're sure it
doesn't break existing users" type situations.
The caveat to all of this is that as you guys add new bindings, it should
be drop dead simple for someone browsing the release artifacts to see what
stuff is expected to "work" and what stuff is still in progress; to help
mitigate the number of pissed off users who get really excited when
they see binding XYZ and then waste a day of coding before they discover
that it's only half implemented and they need to start over from scratch
(because thye don't know enough C code to help finish it)
You could put this type of info at the top of a README file for every
binding, (afterall: every binding should really have a README describing
what it is, how it owrks, etc...) but i would suggest that something like
the top level STATUS file might also be a good idea to have in each
individual binding directory. I might even go so far as to suggest that
the *name* of the status file should indicate (at a high level) it's
usability, ie...
STATUS
.. for bindings that work and are tested and and there is an intention
to remain back compatable moving forward. contents contain wishlist of
features to add.
STATUS_EXPERIMENTAL
.. for bindings that are complete, but still need vetting and the
contracts might need changed in the future. contents should spell out
exactly what the open concerns are as well as wishlist of future features.
STATUS_BROKEN
.. for bindings that are so rough and in progress users shouldn't even
try them unless they are planning on helping to write them. contents
should list what needs to be done in order to finish and become
"experimental"
...etc. (the exact names could be anything, but you get the idea)
-Hoss
Re: [lucy-dev] RAT buildbot troubles
Posted by Logan Bell <lo...@gmail.com>.
I think the RAT build has been broken for a while:
http://ci.apache.org/builders/lucy-trunk-rat
At this point I'm not certain what could possibly be wrong, other than
it's probably looking for the wrong file name.
As discussed on IRC, I'll go ahead and take the liberty and forward
this infrastructure@apache.org and builds@apache.org for assistance.
Thanks,
Logan
On Thu, Jan 12, 2012 at 3:52 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Wed, Jan 11, 2012 at 04:08:17PM -0600, Peter Karman wrote:
>> Marvin Humphrey wrote on 1/11/12 3:27 PM:
>>
>> > Please also commit those license header changes to trunk. It will be great to
>> > see <http://ci.apache.org/projects/lucy/rat-output.html> passing once again.
>> >
>>
>> I did last night, in
>> http://svn.apache.org/viewvc?view=revision&revision=1229867
>>
>> /me is wondering why RAT is not seeing that...
>
> It may be that the RAT buildbot is broken right now.
>
> Here's the current RAT build result:
>
> http://ci.apache.org/builders/lucy-trunk-rat/builds/120
>
> I got to that page by following links from these pages:
>
> http://ci.apache.org/
> http://ci.apache.org/buildbot.html
> http://ci.apache.org/builders
> http://ci.apache.org/builders/lucy-trunk-rat
>
> It seems suspicious that this is the failing step:
>
> 3. upload uploading rat-output.xml ( 0 secs )
>
> Here's the content of stderr for that step:
>
> Cannot open file
> '/home/buildslave2/slave2/lucy-trunk-rat/build/../rat-output.xml' for upload
>
> Logan pointed me at our buildbot config:
>
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/lucy.conf
>
> This appears to be the step that's failing:
>
> # Above performs RAT tests on entire lucy build directories, output to txt file.
> # Now we will publish that report to ci.apache.org/projects/lucy/rat-output.xml
> # assuming that the report step itself was successful.
>
> f_lucy_1.addStep(rat_report_upload(slavesrc="../rat-output.xml",
> masterdest="/tmp/lucy/rat-output.xml",
> haltOnFailure=True,
> ))
>
> Dunno why it's b0rken, or how to fix it myself.
>
> I think the next step is to escalate to the builds@a.o list.
>
> http://mail-archives.apache.org/mod_mbox/www-builds/
>
> Marvin Humphrey
>
Fwd: [lucy-dev] RAT buildbot troubles
Posted by Logan Bell <lo...@gmail.com>.
Infrastructure
We've been having some problems with the RAT build for a while now.
Below you will see some of the initial findings by Marvin. It really
just appears the build can't find rat-output.xml.
It would be appreciated if you could show us what needs to be done to
correct this.
The link to our broken build:
http://ci.apache.org/builders/lucy-trunk-rat/builds/120
Thanks in advance,
Logan
---------- Forwarded message ----------
From: Marvin Humphrey <ma...@rectangular.com>
Date: Thu, Jan 12, 2012 at 3:52 PM
Subject: [lucy-dev] RAT buildbot troubles
To: lucy-dev@incubator.apache.org, peter@peknet.com
On Wed, Jan 11, 2012 at 04:08:17PM -0600, Peter Karman wrote:
> Marvin Humphrey wrote on 1/11/12 3:27 PM:
>
> > Please also commit those license header changes to trunk. It will be great to
> > see <http://ci.apache.org/projects/lucy/rat-output.html> passing once again.
> >
>
> I did last night, in
> http://svn.apache.org/viewvc?view=revision&revision=1229867
>
> /me is wondering why RAT is not seeing that...
It may be that the RAT buildbot is broken right now.
Here's the current RAT build result:
http://ci.apache.org/builders/lucy-trunk-rat/builds/120
I got to that page by following links from these pages:
http://ci.apache.org/
http://ci.apache.org/buildbot.html
http://ci.apache.org/builders
http://ci.apache.org/builders/lucy-trunk-rat
It seems suspicious that this is the failing step:
3. upload uploading rat-output.xml ( 0 secs )
Here's the content of stderr for that step:
Cannot open file
'/home/buildslave2/slave2/lucy-trunk-rat/build/../rat-output.xml' for upload
Logan pointed me at our buildbot config:
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/lucy.conf
This appears to be the step that's failing:
# Above performs RAT tests on entire lucy build directories, output
to txt file.
# Now we will publish that report to
ci.apache.org/projects/lucy/rat-output.xml
# assuming that the report step itself was successful.
f_lucy_1.addStep(rat_report_upload(slavesrc="../rat-output.xml",
masterdest="/tmp/lucy/rat-output.xml",
haltOnFailure=True,
))
Dunno why it's b0rken, or how to fix it myself.
I think the next step is to escalate to the builds@a.o list.
http://mail-archives.apache.org/mod_mbox/www-builds/
Marvin Humphrey
[lucy-dev] RAT buildbot troubles
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jan 11, 2012 at 04:08:17PM -0600, Peter Karman wrote:
> Marvin Humphrey wrote on 1/11/12 3:27 PM:
>
> > Please also commit those license header changes to trunk. It will be great to
> > see <http://ci.apache.org/projects/lucy/rat-output.html> passing once again.
> >
>
> I did last night, in
> http://svn.apache.org/viewvc?view=revision&revision=1229867
>
> /me is wondering why RAT is not seeing that...
It may be that the RAT buildbot is broken right now.
Here's the current RAT build result:
http://ci.apache.org/builders/lucy-trunk-rat/builds/120
I got to that page by following links from these pages:
http://ci.apache.org/
http://ci.apache.org/buildbot.html
http://ci.apache.org/builders
http://ci.apache.org/builders/lucy-trunk-rat
It seems suspicious that this is the failing step:
3. upload uploading rat-output.xml ( 0 secs )
Here's the content of stderr for that step:
Cannot open file
'/home/buildslave2/slave2/lucy-trunk-rat/build/../rat-output.xml' for upload
Logan pointed me at our buildbot config:
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/lucy.conf
This appears to be the step that's failing:
# Above performs RAT tests on entire lucy build directories, output to txt file.
# Now we will publish that report to ci.apache.org/projects/lucy/rat-output.xml
# assuming that the report step itself was successful.
f_lucy_1.addStep(rat_report_upload(slavesrc="../rat-output.xml",
masterdest="/tmp/lucy/rat-output.xml",
haltOnFailure=True,
))
Dunno why it's b0rken, or how to fix it myself.
I think the next step is to escalate to the builds@a.o list.
http://mail-archives.apache.org/mod_mbox/www-builds/
Marvin Humphrey
Re: [lucy-dev] 0.3.0 release prep
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/11/12 3:27 PM:
> Please also commit those license header changes to trunk. It will be great to
> see <http://ci.apache.org/projects/lucy/rat-output.html> passing once again.
>
I did last night, in
http://svn.apache.org/viewvc?view=revision&revision=1229867
/me is wondering why RAT is not seeing that...
>> I've now gone through all the steps on http://wiki.apache.org/lucy/ReleasePrep
>> except for the Portability and Extended Tests section. Would someone please
>> volunteer to do those steps?
>
> The test_valgrind build target passes for the 0.3 branch on Perl 5.15.4.
>
> The 0.3 branch builds and passes tests on my ActivePerl, Strawberry Perl and
> Cygwin rigs.
>
> I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
> be nice to get that in before 0.3.0.
>
> +1 to move forward!
>
great, thanks, Marvin.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0 release prep
Posted by Peter Karman <pe...@peknet.com>.
Nick Wellnhofer wrote on 1/15/12 4:19 AM:
> On 14/01/2012 13:22, Peter Karman wrote:
>> Nick Wellnhofer wrote on 1/11/12 4:03 PM:
>>> On 11/01/2012 22:27, Marvin Humphrey wrote:
>>>> I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
>>>> be nice to get that in before 0.3.0.
>>>
>>> I'm going to merge it tomorrow morning.
>>>
>>
>> Thanks, Nick.
>>
>> Please update https://issues.apache.org/jira/browse/LUCY-199 and change the
>> version to 0.3.0. Then I'll cut RC1.
>
> LUCY-199 isn't resolved yet. My patch is only a band-aid.
ah ok. Thanks. I'll not note it in CHANGES then.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0 release prep
Posted by Nick Wellnhofer <we...@aevum.de>.
On 14/01/2012 13:22, Peter Karman wrote:
> Nick Wellnhofer wrote on 1/11/12 4:03 PM:
>> On 11/01/2012 22:27, Marvin Humphrey wrote:
>>> I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
>>> be nice to get that in before 0.3.0.
>>
>> I'm going to merge it tomorrow morning.
>>
>
> Thanks, Nick.
>
> Please update https://issues.apache.org/jira/browse/LUCY-199 and change the
> version to 0.3.0. Then I'll cut RC1.
LUCY-199 isn't resolved yet. My patch is only a band-aid.
Nick
Re: [lucy-dev] 0.3.0 release prep
Posted by Peter Karman <pe...@peknet.com>.
Nick Wellnhofer wrote on 1/11/12 4:03 PM:
> On 11/01/2012 22:27, Marvin Humphrey wrote:
>> I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
>> be nice to get that in before 0.3.0.
>
> I'm going to merge it tomorrow morning.
>
Thanks, Nick.
Please update https://issues.apache.org/jira/browse/LUCY-199 and change the
version to 0.3.0. Then I'll cut RC1.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0 release prep
Posted by Nick Wellnhofer <we...@aevum.de>.
On 11/01/2012 22:27, Marvin Humphrey wrote:
> I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
> be nice to get that in before 0.3.0.
I'm going to merge it tomorrow morning.
Nick
Re: [lucy-dev] 0.3.0 release prep
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Jan 10, 2012 at 09:11:30PM -0600, Peter Karman wrote:
> done
> done
> done
Nice. :)
Please also commit those license header changes to trunk. It will be great to
see <http://ci.apache.org/projects/lucy/rat-output.html> passing once again.
> I've now gone through all the steps on http://wiki.apache.org/lucy/ReleasePrep
> except for the Portability and Extended Tests section. Would someone please
> volunteer to do those steps?
The test_valgrind build target passes for the 0.3 branch on Perl 5.15.4.
The 0.3 branch builds and passes tests on my ActivePerl, Strawberry Perl and
Cygwin rigs.
I performed all tests with Nick's LUCY-199-quickfix.patch applied. It would
be nice to get that in before 0.3.0.
+1 to move forward!
Marvin Humphrey
Re: [lucy-dev] 0.3.0 release prep
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 1/9/12 11:27 PM:
>
> Ignoring the .gitignore files is fine -- just add them to
> devel/conf/rat-excludes.
done
>
> Adding CONTRIBUTING to rat-excludes is fine as well.
done
>
> There's also install-sh, which has an MIT/X11 license. It will be necessary
> to add the text of that license to LICENSE.
done
>
>> For the c/ files, since that is just the stub of the tip of the beginning of a
>> start for that code, do we even want it in the release?
>
> IMO: yes. Canonical release tarballs should be snapshots from the VCS.
> Things get annoyingly complicated if you deviate from that.
10-4
>
> If we don't want something in an official release, we should develop it on a
> branch. That will be more straightforward once we switch to Git in a few
> months.
>
>> Could/should files be removed from a branch if they do not represent
>> 'finished' product? I realize this last is a philosophical as well as
>> practical question.
>
> I don't think it matters much. All of the 0.2.x releases have had a ruby/
> dir containing useless in-progress code; nobody complained.
check. Hoss, your comments much appreciated on this topic too. I will take it as
a TODO for myself to update STATUS and README for the c/ bindings, though imo
that's not a show-stopper for 0.3.0.
I've now gone through all the steps on http://wiki.apache.org/lucy/ReleasePrep
except for the Portability and Extended Tests section. Would someone please
volunteer to do those steps? Once we're satisfied with those, I will start the
actual 0.3.0 ReleaseGuide process.
tia,
pek
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.3.0 release prep
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jan 09, 2012 at 09:38:03PM -0600, Peter Karman wrote:
> I am starting the prep for the 0.3.0 release. The first step is to confirm that
> the RAT report passes:
>
> http://ci.apache.org/projects/lucy/rat-output.html
>
> It looks like a bunch of files are missing the Apache License, many of them
> the start of the C implementation, but also a bunch of .gitignore files. I
> can add the license header to the c/ files. Does it make sense to have the
> .gitignore files include a license? Can we tell RAT to ignore the ignore
> files?
Ignoring the .gitignore files is fine -- just add them to
devel/conf/rat-excludes.
Adding CONTRIBUTING to rat-excludes is fine as well.
There's also install-sh, which has an MIT/X11 license. It will be necessary
to add the text of that license to LICENSE.
> For the c/ files, since that is just the stub of the tip of the beginning of a
> start for that code, do we even want it in the release?
IMO: yes. Canonical release tarballs should be snapshots from the VCS.
Things get annoyingly complicated if you deviate from that.
If we don't want something in an official release, we should develop it on a
branch. That will be more straightforward once we switch to Git in a few
months.
> Could/should files be removed from a branch if they do not represent
> 'finished' product? I realize this last is a philosophical as well as
> practical question.
I don't think it matters much. All of the 0.2.x releases have had a ruby/
dir containing useless in-progress code; nobody complained.
Marvin Humphrey