You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Assaf Arkin <ar...@intalio.com> on 2008/06/04 04:43:20 UTC
VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Looks like we've got another dependency problem.
There are two workarounds, install from source or remove the newer
hoe/rubyforge dependency, both of which will have to be done after
installing/upgrading 1.3.1, and every time you run gem update, which
will restore the newer dependencies.
I'm proposing we push a new Gem to RubyForge without making an
official release, there will not be a corresponding Apache
distribution, and it will not contain any other changes from trunk
besides new version number and fixed Gem dependencies.
Assaf
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Alex Boisvert <bo...@intalio.com>.
+1
On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
> Assaf
>
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Yanko Ivanov <ya...@gmail.com>.
+1 from me
regards,
yanko
2008/6/4 Assaf Arkin <ar...@intalio.com>:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
> Assaf
>
--
Tanzen ist -- wenn man mit den Beinen träumt!
http://www.floridita.at -- Lerne die leidenschaftliche Sprache der
Seele und des Körpers
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Victor Hugo Borja <vi...@gmail.com>.
+1
On Tue, Jun 3, 2008 at 9:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
> Assaf
>
--
vic
Quaerendo invenietis.
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Shane Witbeck <sh...@digitalsanctum.com>.
I also confirmed this with a fresh install of MRI on Windows XP. JRuby
1.1.2 is another story and I've filed a bug for it.
Thanks a lot for getting this release out to fix the crucial install
issue. You're absolutely right about community first even if it skirts
the normal processes once in a while.
On Thu, Jun 5, 2008 at 5:08 PM, Assaf Arkin <ar...@intalio.com> wrote:
> 1.3.1.1 is up on RubyForge and installs nicely on my machine.
>
> Assaf
>
--
-Shane
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Assaf Arkin <ar...@intalio.com>.
1.3.1.1 is up on RubyForge and installs nicely on my machine.
Assaf
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Assaf Arkin <ar...@intalio.com>.
On Thu, Jun 5, 2008 at 5:19 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jun 4, 2008, at 7:22 PM, Matthieu Riou wrote:
>>
>> Now with my PMC hat on, I'd *really* like the documentation to make very
>> clear that what's published on Rubyforge isn't in any way endorsed by
>> Apache
>> and is only community driven. We should have a disclaimer explaining why
>> we
>> do this (emergency Rubygems conf related releases) and how people can
>> install making sure you only get the Apache releases.
>>
>
> It seems to me, with my PMC hat on as well, that we appear to
> be playing fast and loose with "releases", following the regular
> ASF process when it's convenient and finding alternate ways around
> it when not... this is NOT a good precedent.
I think our focus should be on giving people something that works and
they can use. The process must provide a way to make sure issues like
this don't happen again, but when they do, provide a quick way to
react and resolve them.
We have code freeze, testing, staging and voting, and that involves a
lot of checks to surface issues before making a release. And each
time something goes wrong, we add a check to make sure it doesn't
happen again. So one task for 1.3.2 is improving dependency checks.
That process generally leads to higher quality releases, and part of
that is correlated to having a very lengthy release process. Most
often that's a good thing, but when something like this slips through
our quality checks, the process must provide a way to quickly act and
respond to it.
Otherwise, we're serving the process, not the community.
Assaf
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 4, 2008, at 7:22 PM, Matthieu Riou wrote:
>
> Now with my PMC hat on, I'd *really* like the documentation to make
> very
> clear that what's published on Rubyforge isn't in any way endorsed
> by Apache
> and is only community driven. We should have a disclaimer explaining
> why we
> do this (emergency Rubygems conf related releases) and how people can
> install making sure you only get the Apache releases.
>
It seems to me, with my PMC hat on as well, that we appear to
be playing fast and loose with "releases", following the regular
ASF process when it's convenient and finding alternate ways around
it when not... this is NOT a good precedent.
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Assaf Arkin <ar...@intalio.com>.
On Wed, Jun 4, 2008 at 4:59 PM, Victor Hugo Borja <vi...@gmail.com> wrote:
> Agree with Matthieu on version numbering, I think it should be 1.3.1.1 as
> changes are mainly little bugs/dependency fixes.
>
> Also .. given that we have an *unofficial* mirror on github, we could just
> push the gemspec, so that people wanting to play with the version at HEAD
> can do:
>
> sudo env JAVA_HOME=/opt/sun-jdk-1.5.0.13/ gem install vic-buildr -s
> http://gems.github.com
I'm not sure it creates a new Gem unless you update the .spec file.
Also, the .spec file doesn't include any dependencies specific to
MRI/JRuby (e.g. RJB), not sure how to work around that.
Also possible, publishing a script that will grab head/trunk and use
rake install to install it locally (but with remote dependencies).
Assaf
> On Wed, Jun 4, 2008 at 6:22 PM, Matthieu Riou <ma...@offthelip.org>
> wrote:
>
>> On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <ar...@intalio.com> wrote:
>>
>> > On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <ma...@offthelip.org>
>> > wrote:
>> > > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
>> > >
>> > >> Looks like we've got another dependency problem.
>> > >>
>> > >> There are two workarounds, install from source or remove the newer
>> > >> hoe/rubyforge dependency, both of which will have to be done after
>> > >> installing/upgrading 1.3.1, and every time you run gem update, which
>> > >> will restore the newer dependencies.
>> > >>
>> > >> I'm proposing we push a new Gem to RubyForge without making an
>> > >> official release, there will not be a corresponding Apache
>> > >> distribution, and it will not contain any other changes from trunk
>> > >> besides new version number and fixed Gem dependencies.
>> > >>
>> > >
>> > > Why?
>> >
>> > Because minimizing it to just a majority vote on buildr-dev, and then
>> > packaging a Gem and uploading to RubyForge and is something we can get
>> > over and done with today.
>> >
>> > Going through the full process, not until mid/late next week.
>> >
>>
>> So given that this is an unofficial release that you decide to publish for
>> people's convenience, without my PMC hat on and only as a community member,
>> I'll vote +1 because this little packaging problem needs fixing. I'd rather
>> name this 1.3.1.1 if possible though, to avoid holes in the official
>> release
>> numbering.
>>
>> Now with my PMC hat on, I'd *really* like the documentation to make very
>> clear that what's published on Rubyforge isn't in any way endorsed by
>> Apache
>> and is only community driven. We should have a disclaimer explaining why we
>> do this (emergency Rubygems conf related releases) and how people can
>> install making sure you only get the Apache releases.
>>
>> I'd also suggest that if another unofficial release is needed, we clearly
>> flag the vote e-mail with unofficial to avoid readers' confusion.
>>
>> Cheers,
>> Matthieu
>>
>>
>> >
>> > Assaf
>> >
>>
>
>
>
> --
> vic
>
> Quaerendo invenietis.
>
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Victor Hugo Borja <vi...@gmail.com>.
Agree with Matthieu on version numbering, I think it should be 1.3.1.1 as
changes are mainly little bugs/dependency fixes.
Also .. given that we have an *unofficial* mirror on github, we could just
push the gemspec, so that people wanting to play with the version at HEAD
can do:
sudo env JAVA_HOME=/opt/sun-jdk-1.5.0.13/ gem install vic-buildr -s
http://gems.github.com
On Wed, Jun 4, 2008 at 6:22 PM, Matthieu Riou <ma...@offthelip.org>
wrote:
> On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> > On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <ma...@offthelip.org>
> > wrote:
> > > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> > >
> > >> Looks like we've got another dependency problem.
> > >>
> > >> There are two workarounds, install from source or remove the newer
> > >> hoe/rubyforge dependency, both of which will have to be done after
> > >> installing/upgrading 1.3.1, and every time you run gem update, which
> > >> will restore the newer dependencies.
> > >>
> > >> I'm proposing we push a new Gem to RubyForge without making an
> > >> official release, there will not be a corresponding Apache
> > >> distribution, and it will not contain any other changes from trunk
> > >> besides new version number and fixed Gem dependencies.
> > >>
> > >
> > > Why?
> >
> > Because minimizing it to just a majority vote on buildr-dev, and then
> > packaging a Gem and uploading to RubyForge and is something we can get
> > over and done with today.
> >
> > Going through the full process, not until mid/late next week.
> >
>
> So given that this is an unofficial release that you decide to publish for
> people's convenience, without my PMC hat on and only as a community member,
> I'll vote +1 because this little packaging problem needs fixing. I'd rather
> name this 1.3.1.1 if possible though, to avoid holes in the official
> release
> numbering.
>
> Now with my PMC hat on, I'd *really* like the documentation to make very
> clear that what's published on Rubyforge isn't in any way endorsed by
> Apache
> and is only community driven. We should have a disclaimer explaining why we
> do this (emergency Rubygems conf related releases) and how people can
> install making sure you only get the Apache releases.
>
> I'd also suggest that if another unofficial release is needed, we clearly
> flag the vote e-mail with unofficial to avoid readers' confusion.
>
> Cheers,
> Matthieu
>
>
> >
> > Assaf
> >
>
--
vic
Quaerendo invenietis.
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Assaf Arkin <ar...@intalio.com>.
On Wed, Jun 4, 2008 at 4:22 PM, Matthieu Riou <ma...@offthelip.org> wrote:
> So given that this is an unofficial release that you decide to publish for
> people's convenience, without my PMC hat on and only as a community member,
> I'll vote +1 because this little packaging problem needs fixing. I'd rather
> name this 1.3.1.1 if possible though, to avoid holes in the official release
> numbering.
I must have been thinking of some other dependency system, because Gem
doesn't mind if we use 1.3.1.1 for the next release, so there's no
need to jump to 1.3.2.
> Now with my PMC hat on, I'd *really* like the documentation to make very
> clear that what's published on Rubyforge isn't in any way endorsed by Apache
> and is only community driven. We should have a disclaimer explaining why we
> do this (emergency Rubygems conf related releases) and how people can
> install making sure you only get the Apache releases.
I filed an issue for that.
> I'd also suggest that if another unofficial release is needed, we clearly
> flag the vote e-mail with unofficial to avoid readers' confusion.
Point taken.
Assaf
>
> Cheers,
> Matthieu
>
>
>>
>> Assaf
>>
>
--
CTO, Intalio
http://www.intalio.com
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> >> Looks like we've got another dependency problem.
> >>
> >> There are two workarounds, install from source or remove the newer
> >> hoe/rubyforge dependency, both of which will have to be done after
> >> installing/upgrading 1.3.1, and every time you run gem update, which
> >> will restore the newer dependencies.
> >>
> >> I'm proposing we push a new Gem to RubyForge without making an
> >> official release, there will not be a corresponding Apache
> >> distribution, and it will not contain any other changes from trunk
> >> besides new version number and fixed Gem dependencies.
> >>
> >
> > Why?
>
> Because minimizing it to just a majority vote on buildr-dev, and then
> packaging a Gem and uploading to RubyForge and is something we can get
> over and done with today.
>
> Going through the full process, not until mid/late next week.
>
So given that this is an unofficial release that you decide to publish for
people's convenience, without my PMC hat on and only as a community member,
I'll vote +1 because this little packaging problem needs fixing. I'd rather
name this 1.3.1.1 if possible though, to avoid holes in the official release
numbering.
Now with my PMC hat on, I'd *really* like the documentation to make very
clear that what's published on Rubyforge isn't in any way endorsed by Apache
and is only community driven. We should have a disclaimer explaining why we
do this (emergency Rubygems conf related releases) and how people can
install making sure you only get the Apache releases.
I'd also suggest that if another unofficial release is needed, we clearly
flag the vote e-mail with unofficial to avoid readers' confusion.
Cheers,
Matthieu
>
> Assaf
>
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Assaf Arkin <ar...@intalio.com>.
On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <ma...@offthelip.org> wrote:
> On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
>> Looks like we've got another dependency problem.
>>
>> There are two workarounds, install from source or remove the newer
>> hoe/rubyforge dependency, both of which will have to be done after
>> installing/upgrading 1.3.1, and every time you run gem update, which
>> will restore the newer dependencies.
>>
>> I'm proposing we push a new Gem to RubyForge without making an
>> official release, there will not be a corresponding Apache
>> distribution, and it will not contain any other changes from trunk
>> besides new version number and fixed Gem dependencies.
>>
>
> Why?
Because minimizing it to just a majority vote on buildr-dev, and then
packaging a Gem and uploading to RubyForge and is something we can get
over and done with today.
Going through the full process, not until mid/late next week.
Assaf
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Matthieu Riou <ma...@offthelip.org>.
On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
Why?
>
> Assaf
>
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Tal Rotbart <re...@gmail.com>.
+1 on this one, for sure.
On Wed, Jun 4, 2008 at 5:43 AM, Assaf Arkin <ar...@intalio.com> wrote:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
> Assaf
>
Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Posted by Shane Witbeck <sh...@digitalsanctum.com>.
+1
On Tue, Jun 3, 2008 at 10:43 PM, Assaf Arkin <ar...@intalio.com> wrote:
> Looks like we've got another dependency problem.
>
> There are two workarounds, install from source or remove the newer
> hoe/rubyforge dependency, both of which will have to be done after
> installing/upgrading 1.3.1, and every time you run gem update, which
> will restore the newer dependencies.
>
> I'm proposing we push a new Gem to RubyForge without making an
> official release, there will not be a corresponding Apache
> distribution, and it will not contain any other changes from trunk
> besides new version number and fixed Gem dependencies.
>
> Assaf
>
--
-Shane