Re: Renaming ruby-factory-girl to ruby-factory-bot
On വെള്ളി 01 ഡിസംബര് 2017 04:44 രാവിലെ, Georg Faerber wrote: > Hi all, > > Upstream decided [1] to rename factory-girl to factory-bot, because "The > name "Factory Girl" was confusing to some developers who encountered > this library, and offensive or problematic to others." [2] > > We're using this in schleuder, therefore I would like to update the name > accordingly. > > However, as I'm still quite new to Debian packaging, at least up until > now I've never done a task like this, I'm unsure what this does involve: > > - A ITP for a new package? > - "Just" renaming? What about reverse dependencies? I think renaming and updating reverse dependencies will be enough. It will still have to go through NEW and once it clears, you will need update reverse dependencies and request removal of old package. > - Does this need in fact a transition? Only 3 packages needs changes (reverse-depends -b ruby-factory-girl) so I don't think we need a transition. * ruby-factory-girl-rails * schleuder * tmuxinator > - Besides all of the above: I'm planning to backport this to stretch, as > well. > I don't know if backporting is worth just for the rename. > Thanks for any insights. > > Best, > Georg > > > [1] > https://github.com/thoughtbot/factory_bot/commit/c716ce01b448ce4e0bf855c5a2c63ecb9206322e > [2] > https://github.com/thoughtbot/factory_bot/commit/e083f4a904ae30d170872385d4be3b37d44276e5 > > signature.asc Description: OpenPGP digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi On Fri, Dec 01, 2017 at 11:43:49AM +0530, Pirate Praveen wrote: > I think renaming and updating reverse dependencies will be enough. It > will still have to go through NEW and once it clears, you will need > update reverse dependencies and request removal of old package. The new source package ruby-factory-bot will have to provide a ruby-factory-girl transitional package for the life cycle of the next stable release to ensure that the upgrade from stretch to buster will go smoothly for people who had ruby-factory-girl installed. The wiki page https://wiki.debian.org/PackageTransition has some discussion about the dependency packages should have (it's Scenario #5 I think). Cheers, Cédric signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On Fri, Dec 01, 2017 at 12:14:14AM +0100, Georg Faerber wrote: > Hi all, > > Upstream decided [1] to rename factory-girl to factory-bot, because "The > name "Factory Girl" was confusing to some developers who encountered > this library, and offensive or problematic to others." [2] > > We're using this in schleuder, therefore I would like to update the name > accordingly. > > However, as I'm still quite new to Debian packaging, at least up until > now I've never done a task like this, I'm unsure what this does involve: > > - A ITP for a new package? no > - "Just" renaming? What about reverse dependencies? no > - Does this need in fact a transition? yes, please be nice and considerate. also it seems to just affect 3 packages, so: - package factory-bot, provide a transitional factory-girl package (=rename the source package and provide a new binary package). then file bugs against the depending packages and tell them what happened and ask them to depend on factory-bot. if it were a big transition, starting with wishlist bugs might be appropriate, but here I think you can go straight to "important". (and in the case of bigger/larger/more painful transitions you'd eventually escalate to RC...). then get those bugs fixed and once noone depends on factory-girl anymore, remove that transitional package from factory-bot for good. this is described in more detail in debian-policy and/or developers reference. > - Besides all of the above: I'm planning to backport this to stretch, as > well. get it fixed in buster first... -- cheers, Holger signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi all, On 17-12-01 00:14:14, Georg Faerber wrote: > Upstream decided [1] to rename factory-girl to factory-bot, because > "The name "Factory Girl" was confusing to some developers who > encountered this library, and offensive or problematic to others." [2] > > We're using this in schleuder, therefore I would like to update the > name accordingly. I've worked on this now, and would be more than happy, if someone could review my work [1]. Note: That's not yet ready for upload, before, I would like to transfer ownership of this repo to the ruby-team. However, I'm currently unsure how to do this, see my mail regarding this subject I wrote recently. Thanks, Georg [1] https://salsa.debian.org/georg-guest/ruby-factory-bot/commit/25c8afd59a7057e77736d51aed8689c3f941818e signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 2/19/18, Georg Faerber wrote:
> I've worked on this now, and would be more than happy, if someone could
> review my work [1]. Note: That's not yet ready for upload, before, I
d/changelog:
Please remove this line as this is not an initial release:
* Initial release.
d/files, d/ruby-factory-bot.subsvars:
Please remove these files as they are automatically generated during a build.
d/gemspec:
Why did you create it?
d/control:
For binary ruby-factory-bot:
1) Replace 4.7.0-1~ with ${source:Version}
2) Add Provides: ruby-factory-girl
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi Hleb,
Thanks a lot for the review, I've created a repo now [1].
On 18-02-19 10:53:00, Hleb Valoshka wrote:
> On 2/19/18, Georg Faerber wrote:
> > I've worked on this now, and would be more than happy, if someone could
> > review my work [1]. Note: That's not yet ready for upload, before, I
>
> d/changelog:
> Please remove this line as this is not an initial release:
> * Initial release.
Done.
Actually, I've posted a comment in salsa.d.o referencing the code and
explaining that I was unsure what to put there, but somehow the comment
was lost, it seems.
> d/files, d/ruby-factory-bot.subsvars:
> Please remove these files as they are automatically generated during a build.
Done.
> d/gemspec:
> Why did you create it?
Upstream ships two gemspec files: factory_bot and factory_girl.
Exporting DH_RUBY_GEMSPEC=factory_bot.gemspec via d/rules worked for the
build, but failed for autopkgtest; the symlink works for both cases.
> d/control:
> For binary ruby-factory-bot:
> 1) Replace 4.7.0-1~ with ${source:Version}
Done.
> 2) Add Provides: ruby-factory-girl
I'm just doing this for the first time, so quite possible I'm wrong on
this, but reading [2], case #5, "Provides" is marked optional, that is,
to be used if "there are some packages which depend on A". While this is
clearly the case here, ruby-factory-bot isn't a "drop-in" package for
ruby-factory-girl. The reverse dependencies have to be changed as well,
as code within ruby-factory-bot changed. Therefore, I think that
Provides: isn't correct, as apt would pull in this automatically,
wouldn't it?
Thanks again,
Georg
[1] https://salsa.debian.org/ruby-team/ruby-factory-bot/
[2] https://wiki.debian.org/PackageTransition#Package_Transition
signature.asc
Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi Hleb, all,
On 18-02-19 20:07:44, Georg Faerber wrote:
> Thanks a lot for the review, I've created a repo now [1].
>
> On 18-02-19 10:53:00, Hleb Valoshka wrote:
> > On 2/19/18, Georg Faerber wrote:
> > > I've worked on this now, and would be more than happy, if someone could
> > > review my work [1]. Note: That's not yet ready for upload, before, I
> >
> > d/changelog:
> > Please remove this line as this is not an initial release:
> > * Initial release.
>
> Done.
>
> Actually, I've posted a comment in salsa.d.o referencing the code and
> explaining that I was unsure what to put there, but somehow the comment
> was lost, it seems.
>
> > d/files, d/ruby-factory-bot.subsvars:
> > Please remove these files as they are automatically generated during a
> > build.
>
> Done.
>
> > d/gemspec:
> > Why did you create it?
>
> Upstream ships two gemspec files: factory_bot and factory_girl.
> Exporting DH_RUBY_GEMSPEC=factory_bot.gemspec via d/rules worked for the
> build, but failed for autopkgtest; the symlink works for both cases.
>
> > d/control:
> > For binary ruby-factory-bot:
> > 1) Replace 4.7.0-1~ with ${source:Version}
>
> Done.
>
> > 2) Add Provides: ruby-factory-girl
>
> I'm just doing this for the first time, so quite possible I'm wrong on
> this, but reading [2], case #5, "Provides" is marked optional, that is,
> to be used if "there are some packages which depend on A". While this is
> clearly the case here, ruby-factory-bot isn't a "drop-in" package for
> ruby-factory-girl. The reverse dependencies have to be changed as well,
> as code within ruby-factory-bot changed. Therefore, I think that
> Provides: isn't correct, as apt would pull in this automatically,
> wouldn't it?
>
> [1] https://salsa.debian.org/ruby-team/ruby-factory-bot/
> [2] https://wiki.debian.org/PackageTransition#Package_Transition
Could you / someone else continue with the review, or, in case
everything is fine, upload the package?
Thanks,
Georg
signature.asc
Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 2/26/18, Georg Faerber wrote: > Could you / someone else continue with the review, or, in case > everything is fine, upload the package? Looks good for me, but I don't have upload privileges :)
Re: Renaming ruby-factory-girl to ruby-factory-bot
It looks fine for me too. I would just propose to include the old changelog from ruby-factory-girl, so that the history is not gone, when the source package ruby-factory-girl is removed. Please keep also the previous uploaders in the control file. Cédric signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On Sat, Mar 03, 2018 at 03:05:14PM +0100, Cédric Boutillier wrote: > It looks fine for me too. I would just propose to include the old > changelog from ruby-factory-girl, so that the history is not gone, when > the source package ruby-factory-girl is removed. > Please keep also the previous uploaders in the control file. I think it should be also 'autopkgtest-pkg-ruby' instead of 'autopkgtest' for Testsuite field in debian/control but the smart autopkgtest seems to detect that it is indeed a ruby package anyway. Cédric signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
And a last detail: ruby-factory-girl-rails fails to build because of dependency checking looking for a factory_girl gemspec file instead of a factory_bot. I don't know if it is better to fix factory-girl-rails gemspecs, or to ship also the factor_girl.gemspec file too with ruby-factory-bot. Cédric signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi Cédric, Thanks for your review. On 18-03-03 15:05:14, Cédric Boutillier wrote: > I would just propose to include the old changelog from > ruby-factory-girl, so that the history is not gone, when the source > package ruby-factory-girl is removed. Done. > Please keep also the previous uploaders in the control file. Done. I've also extended d/copyright appropriately. Cheers, Georg signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 18-03-03 15:35:29, Cédric Boutillier wrote: > I think it should be also 'autopkgtest-pkg-ruby' instead of > 'autopkgtest' for Testsuite field in debian/control but the smart > autopkgtest seems to detect that it is indeed a ruby package anyway. Thanks, it worked with 'autopkgtest' as well, but nonetheless, I've changed this as per your advice. Cheers, Georg signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi, On 18-03-03 16:30:36, Cédric Boutillier wrote: > ruby-factory-girl-rails fails to build because of dependency checking > looking for a factory_girl gemspec file instead of a factory_bot. > > I don't know if it is better to fix factory-girl-rails gemspecs, or to > ship also the factor_girl.gemspec file too with ruby-factory-bot. Hm, I'm not really sure how to deal with this, as I already (tried?) to describe in one of my initial mails: Not only to name changed, but also code within, and no "compat helper / level" was introduced. This means, that code which depends on factory_girl needs to change as well. Upstream described the necessary steps regarding this [1]. Given these circumstances, I'm not really sure if using 'Replaces' in d/control and providing a transitional package is the right way to go. What about introducing ruby-factory-bot as a new package without 'Breaks', 'Replaces' and a transitional package, and removing ruby-factory-girl once all upstreams of the reverse dependencies have changed to ruby-factory-bot? FWIW: I could also introduce / prepare ruby-factory-bot-rails, as this was renamed as well. @Pirate: Asking you, because currently you're listed as the only uploader: Would this help, any opinion? Personally, I'm not sure if this is needed at all, given there are no rdepends. Cheers, Georg [1] https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi Cédric, all, On 18-03-04 22:04:46, Georg Faerber wrote: > On 18-03-03 16:30:36, Cédric Boutillier wrote: > > ruby-factory-girl-rails fails to build because of dependency > > checking looking for a factory_girl gemspec file instead of a > > factory_bot. > > > > I don't know if it is better to fix factory-girl-rails gemspecs, or > > to ship also the factor_girl.gemspec file too with ruby-factory-bot. > > Hm, I'm not really sure how to deal with this, as I already (tried?) > to describe in one of my initial mails: Not only to name changed, but > also code within, and no "compat helper / level" was introduced. This > means, that code which depends on factory_girl needs to change as > well. Upstream described the necessary steps regarding this [1]. > > Given these circumstances, I'm not really sure if using 'Replaces' in > d/control and providing a transitional package is the right way to go. > > What about introducing ruby-factory-bot as a new package without > 'Breaks', 'Replaces' and a transitional package, and removing > ruby-factory-girl once all upstreams of the reverse dependencies have > changed to ruby-factory-bot? > > FWIW: I could also introduce / prepare ruby-factory-bot-rails, as this > was renamed as well. > @Pirate: Asking you, because currently you're listed as the only > uploader: Would this help, any opinion? Personally, I'm not sure if > this is needed at all, given there are no rdepends. > > Cheers, > Georg > > > [1] > https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md Friendly ping, I would like to get this done.. Any further input on this? Cheers, Georg signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote: > Hi, > > On 18-03-03 16:30:36, Cédric Boutillier wrote: > > ruby-factory-girl-rails fails to build because of dependency checking > > looking for a factory_girl gemspec file instead of a factory_bot. > > > > I don't know if it is better to fix factory-girl-rails gemspecs, or to > > ship also the factor_girl.gemspec file too with ruby-factory-bot. > > Hm, I'm not really sure how to deal with this, as I already (tried?) to > describe in one of my initial mails: Not only to name changed, but also > code within, and no "compat helper / level" was introduced. This means, > that code which depends on factory_girl needs to change as well. > Upstream described the necessary steps regarding this [1]. > > Given these circumstances, I'm not really sure if using 'Replaces' in > d/control and providing a transitional package is the right way to go. > > What about introducing ruby-factory-bot as a new package without > 'Breaks', 'Replaces' and a transitional package, and removing > ruby-factory-girl once all upstreams of the reverse dependencies have > changed to ruby-factory-bot? If the new package is not backwards compatible, it should not have breaks/replaces or anything like that. you need to make the old package deprecated, report bugs against reverse dependencies, and wait for them to switch to the new library. signature.asc Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 18-03-13 16:30:16, Antonio Terceiro wrote:
> On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote:
> > On 18-03-03 16:30:36, Cédric Boutillier wrote:
> > > ruby-factory-girl-rails fails to build because of dependency checking
> > > looking for a factory_girl gemspec file instead of a factory_bot.
> > >
> > > I don't know if it is better to fix factory-girl-rails gemspecs, or to
> > > ship also the factor_girl.gemspec file too with ruby-factory-bot.
> >
> > Hm, I'm not really sure how to deal with this, as I already (tried?) to
> > describe in one of my initial mails: Not only to name changed, but also
> > code within, and no "compat helper / level" was introduced. This means,
> > that code which depends on factory_girl needs to change as well.
> > Upstream described the necessary steps regarding this [1].
> >
> > Given these circumstances, I'm not really sure if using 'Replaces' in
> > d/control and providing a transitional package is the right way to go.
> >
> > What about introducing ruby-factory-bot as a new package without
> > 'Breaks', 'Replaces' and a transitional package, and removing
> > ruby-factory-girl once all upstreams of the reverse dependencies have
> > changed to ruby-factory-bot?
>
> If the new package is not backwards compatible, it should not have
> breaks/replaces or anything like that. you need to make the old package
> deprecated, report bugs against reverse dependencies, and wait for them
> to switch to the new library.
Alright -- so I'll create an ITP and package ruby-factory-bot
accordingly? After this, both ruby-factory-{bot,girl} will exist in the
archive then, but I guess this is okay? Reverse dependencies are then
able to change their dependency anytime they wish.
Thanks,
Georg
signature.asc
Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On Wed, Mar 14, 2018 at 11:36:14AM +0100, Georg Faerber wrote:
> On 18-03-13 16:30:16, Antonio Terceiro wrote:
> > On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote:
> > > On 18-03-03 16:30:36, Cédric Boutillier wrote:
> > > > ruby-factory-girl-rails fails to build because of dependency checking
> > > > looking for a factory_girl gemspec file instead of a factory_bot.
> > > >
> > > > I don't know if it is better to fix factory-girl-rails gemspecs, or to
> > > > ship also the factor_girl.gemspec file too with ruby-factory-bot.
> > >
> > > Hm, I'm not really sure how to deal with this, as I already (tried?) to
> > > describe in one of my initial mails: Not only to name changed, but also
> > > code within, and no "compat helper / level" was introduced. This means,
> > > that code which depends on factory_girl needs to change as well.
> > > Upstream described the necessary steps regarding this [1].
> > >
> > > Given these circumstances, I'm not really sure if using 'Replaces' in
> > > d/control and providing a transitional package is the right way to go.
> > >
> > > What about introducing ruby-factory-bot as a new package without
> > > 'Breaks', 'Replaces' and a transitional package, and removing
> > > ruby-factory-girl once all upstreams of the reverse dependencies have
> > > changed to ruby-factory-bot?
> >
> > If the new package is not backwards compatible, it should not have
> > breaks/replaces or anything like that. you need to make the old package
> > deprecated, report bugs against reverse dependencies, and wait for them
> > to switch to the new library.
>
> Alright -- so I'll create an ITP and package ruby-factory-bot
> accordingly? After this, both ruby-factory-{bot,girl} will exist in the
> archive then, but I guess this is okay?
I don't think there is a way around that, since the new package is not a
drop-in replacement for the old ...
> Reverse dependencies are then able to change their dependency anytime
> they wish.
yes, but ideally we want to push that, hence my suggestion of reporting
bugs etc. depending on your motivation levels you may want to make this
transition a personal quest. ;-)
signature.asc
Description: PGP signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 18-03-14 10:18:24, Antonio Terceiro wrote:
> On Wed, Mar 14, 2018 at 11:36:14AM +0100, Georg Faerber wrote:
> > On 18-03-13 16:30:16, Antonio Terceiro wrote:
> > > On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote:
> > > > On 18-03-03 16:30:36, Cédric Boutillier wrote:
> > > > > ruby-factory-girl-rails fails to build because of dependency checking
> > > > > looking for a factory_girl gemspec file instead of a factory_bot.
> > > > >
> > > > > I don't know if it is better to fix factory-girl-rails gemspecs, or to
> > > > > ship also the factor_girl.gemspec file too with ruby-factory-bot.
> > > >
> > > > Hm, I'm not really sure how to deal with this, as I already (tried?) to
> > > > describe in one of my initial mails: Not only to name changed, but also
> > > > code within, and no "compat helper / level" was introduced. This means,
> > > > that code which depends on factory_girl needs to change as well.
> > > > Upstream described the necessary steps regarding this [1].
> > > >
> > > > Given these circumstances, I'm not really sure if using 'Replaces' in
> > > > d/control and providing a transitional package is the right way to go.
> > > >
> > > > What about introducing ruby-factory-bot as a new package without
> > > > 'Breaks', 'Replaces' and a transitional package, and removing
> > > > ruby-factory-girl once all upstreams of the reverse dependencies have
> > > > changed to ruby-factory-bot?
> > >
> > > If the new package is not backwards compatible, it should not have
> > > breaks/replaces or anything like that. you need to make the old
> > > package deprecated, report bugs against reverse dependencies, and
> > > wait for them to switch to the new library.
> >
> > Alright -- so I'll create an ITP and package ruby-factory-bot
> > accordingly? After this, both ruby-factory-{bot,girl} will exist in
> > the archive then, but I guess this is okay?
>
> I don't think there is a way around that, since the new package is not
> a drop-in replacement for the old ...
Alright.
> > Reverse dependencies are then able to change their dependency
> > anytime they wish.
>
> yes, but ideally we want to push that, hence my suggestion of
> reporting bugs etc. depending on your motivation levels you may want
> to make this transition a personal quest. ;-)
Sure, I'll do this, and planned to do so anyway, but I'll start with
this after the new packages is available in the archive.
Thanks,
Georg
signature.asc
Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 18-03-14 16:53:42, Georg Faerber wrote:
> On 18-03-14 10:18:24, Antonio Terceiro wrote:
> > On Wed, Mar 14, 2018 at 11:36:14AM +0100, Georg Faerber wrote:
> > > On 18-03-13 16:30:16, Antonio Terceiro wrote:
> > > > On Sun, Mar 04, 2018 at 10:04:46PM +0100, Georg Faerber wrote:
> > > > > On 18-03-03 16:30:36, Cédric Boutillier wrote:
> > > > > > ruby-factory-girl-rails fails to build because of dependency
> > > > > > checking
> > > > > > looking for a factory_girl gemspec file instead of a factory_bot.
> > > > > >
> > > > > > I don't know if it is better to fix factory-girl-rails gemspecs, or
> > > > > > to
> > > > > > ship also the factor_girl.gemspec file too with ruby-factory-bot.
> > > > >
> > > > > Hm, I'm not really sure how to deal with this, as I already (tried?)
> > > > > to
> > > > > describe in one of my initial mails: Not only to name changed, but
> > > > > also
> > > > > code within, and no "compat helper / level" was introduced. This
> > > > > means,
> > > > > that code which depends on factory_girl needs to change as well.
> > > > > Upstream described the necessary steps regarding this [1].
> > > > >
> > > > > Given these circumstances, I'm not really sure if using 'Replaces' in
> > > > > d/control and providing a transitional package is the right way to go.
> > > > >
> > > > > What about introducing ruby-factory-bot as a new package without
> > > > > 'Breaks', 'Replaces' and a transitional package, and removing
> > > > > ruby-factory-girl once all upstreams of the reverse dependencies have
> > > > > changed to ruby-factory-bot?
> > > >
> > > > If the new package is not backwards compatible, it should not have
> > > > breaks/replaces or anything like that. you need to make the old
> > > > package deprecated, report bugs against reverse dependencies, and
> > > > wait for them to switch to the new library.
> > >
> > > Alright -- so I'll create an ITP and package ruby-factory-bot
> > > accordingly? After this, both ruby-factory-{bot,girl} will exist in
> > > the archive then, but I guess this is okay?
> >
> > I don't think there is a way around that, since the new package is not
> > a drop-in replacement for the old ...
>
> Alright.
JFTR: I've submitted a ITP bug and pushed changes to git, accordingly.
Cheers,
Georg
signature.asc
Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
For the record, I uploaded this package. Cheers, Cédric
Re: Renaming ruby-factory-girl to ruby-factory-bot
On 18-03-14 16:53:42, Georg Faerber wrote: > On 18-03-14 10:18:24, Antonio Terceiro wrote: > > On Wed, Mar 14, 2018 at 11:36:14AM +0100, Georg Faerber wrote: > > > Reverse dependencies are then able to change their dependency > > > anytime they wish. > > > > yes, but ideally we want to push that, hence my suggestion of > > reporting bugs etc. depending on your motivation levels you may want > > to make this transition a personal quest. ;-) > > Sure, I'll do this, and planned to do so anyway, but I'll start with > this after the new packages is available in the archive. Update: - ruby-factory-girl-rails: @Pirate: If you need help with this, tell me. - schleuder: I'll take care of this when uploading the next release. - tmuxinator: I've filled #894162 (and pushed the change upstream). Cheers, Georg signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On March 27, 2018 3:01:33 AM GMT+05:30, Georg Faerber wrote: >- ruby-factory-girl-rails: @Pirate: If you need help with this, tell >me. If you can do it, that'll be good. I don't know when I'll come back to this package. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Renaming ruby-factory-girl to ruby-factory-bot
Hi, On 18-03-27 10:03:37, Pirate Praveen wrote: > On March 27, 2018 3:01:33 AM GMT+05:30, Georg Faerber > wrote: > >- ruby-factory-girl-rails: @Pirate: If you need help with this, tell > > me. > > If you can do it, that'll be good. I don't know when I'll come back to > this package. Sure -- I was just wondering, if this package is still used? Popcon seems quite low, and there are no (build) rdepends. Cheers, Georg signature.asc Description: Digital signature
Re: Renaming ruby-factory-girl to ruby-factory-bot
On ചൊവ്വ 27 മാർച്ച് 2018 04:17 വൈകു, Georg Faerber wrote: > Sure -- I was just wondering, if this package is still used? Popcon > seems quite low, and there are no (build) rdepends. > This is a test dependency of diaspora. https://salsa.debian.org/ruby-team/diaspora/blob/master/Gemfile#L285 We are currently not running any tests, but hope to be able to enable it some day. signature.asc Description: OpenPGP digital signature
